Important announcements from CouchCMS team
77 posts Page 7 of 8
Previous 1 ... 4, 5, 6, 7, 8 Next
Thanks for the wonderful support!
The changes are quite a lot - I will update the whole kernel - I will report later
Works fine to me :)

I noticed the version was bumped up to RC1 to implement the upgrade. I hope the next update (RC2?) will address config_list_view/config_form_view issue :)
Yes, everything looks fine

I have cloning temolate test.php with:
Code: Select all
        <cms:editable name='test_globals' label='Test' type='text' />

How can I edit this global region with db_persist ?
Code: Select all
      _masterpage  = 'test.php'
      _mode  = 'edit'

      test_globals = '1'               

Thanks :)
@orbital, to hold the global editable regions, Couch internally uses a separate template.
If, for example, the name of your main template is 'test.php', Couch will add a '__globals' (that is double underscores) suffix to it and internally create a new hidden template.

So, to answer your query, you may use the name of the hidden template with <cms:db_persist> to make changes to its values e.g.
Code: Select all
    _masterpage  = 'test.php__globals'
    _mode  = 'edit'

    test_globals = '1'               

Hope this helps.
Hi KK,

This is super cool, thank you very much!
If a mosaic tile has a 'row' editable, it is displayed in the tile view. Can this be fixed or am I forced to use custom styling for this tile? Thanks.

2019-03-28-112655.png (2.33 KiB) Viewed 4012 times
use its counterpart <cms:config_form_view> tag to override the markup used in the editing form

Another issue is the inability to add custom HTML in the tile's popup (form-view). Is it perhaps due to the theme/content_form_mosaic.html is missing <cms:admin_html /> tag?
I have another bug to report.. Due to a large volume of code for my Mosaic I had to split into snippets the definitions of my editables within a tile. It appears, that order in editables from embedded snippets is respected, while the order of the other editables residing directly within tile's definition is set upon their physical appearance (with parameter 'order' ignored).

To illustrate, I created a simplest mosaic with one tile:
Code: Select all
<cms:mosaic name='my_test'>

    <cms:tile name='first' label='First'>

            <cms:editable name='one' type='text' order='10'/>
            <cms:embed 'two.html' />
            <cms:editable name='tre' type='text' order='20' />



Snippet 'two.html' has this editable -
Code: Select all
<cms:editable name='two' type='text' order='15' />

Wrong order of embedded editable
2019-03-29-133546.png (3.03 KiB) Viewed 4003 times

The result is a messed order.
@KK, please fix this! I am forced now to embed full content of my tile..
@trendoman, the default behavior of <cms:tile> was to auto order the contained editable regions (which are its immediate children). When mosaic came into being, the <cms:tile> supported only a very limited sub-set of Couch tags and the default behavior helped. Later on (on popular demand) support for <cms:embed> was allowed and this can cause the results to be skewed, as you noticed.

To preserve backward compatibility, I can only think of adding a param to <cms:tile> where we can turn off the default auto-order behaviour.

I am PMing you a patch. Please try it , let me know if it helps and I'll commit it.

Replying to your other observations -
1. The default 'row' type display -
For type 'group', the default rendering adds a 'group-heading' class to separate it from the other fields.
For type 'row', I am not quite sure how to display it - it is a group but not as distinct as type 'group' region.

Please custom render your tile and share with me how you preferred to display the row.

2. inability to add custom HTML in the tile's popup
It is a known limitation. Unfortunately, for now you'll have to use the older type 'message' editable region to introduce custom HTML/JS/CSS in the form.
Previous 1 ... 4, 5, 6, 7, 8 Next
77 posts Page 7 of 8