Plone Mosaic 2.0 and 2.1 release and roadmap

[datakurre]

FYI @agitator, @jensens, @tomgross, @AnneGilles and @vangheem (even Nathan is using Castle CMS fork)

Anything particular you wish to be fixed for Mosaic 2.0.0? I did not face any migration issues myself in upgrading from Mosaic 1.x to 2.0. Old text and persistent media tiles kept working as expected.

I'll do a one more RC (and releases of other packages) soon and hope to release it as a final.

I'm in urgent need for better site layout / multiple panels support in editor, which forces me to work already towards 2.1. Things I'm working on:

• removing dead code (undo, upload)
• replacing mosaic overlay (and no longer hiding fields from properties)
• multiple panels support (a few issues since content layouts were introduced)
• support customizing statically positioned tiles in site layout
• cleanup and refactoring / commenting here and there

Possibly also

• upgrading terms as discussed in various issues
• integrating site layouts with layout / design menu
• i18n

I should be able to blog / document about our recent Mosaic usage in January. I'm aware that most of my use-cases could fix filled with clever use of content-layouts and introducing meta-tiles from Castle CMS, but I still feel traction towards original Deco design :+)

[jensens]

+1 for release plan and every single item on the list.

[agitator]

no pressing issue for 2.0 here, go for it!

[tomgross]

I have to confirm with my team tomorrow but I think it's green from our side. agitator notifications@github.com schrieb am Di. 13. Dez. 2016 um 16:08:

no pressing issue for 2.0 here, go for it!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/plone/plone.app.mosaic/issues/328#issuecomment-266762822, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUtuLfUQkMJH65SsKG7wq3m4ntier8rks5rHrT_gaJpZM4LLkWs .

[vangheem]

It seems fine. I'm interested to see what you come up with. I wanted to keep things simple...

[datakurre]

http://plonemosaic200rc4.herokuapp.com/Plone

[tomgross]

:+1: for a 2.0 release soon. We had an issue with the change from the rawhtml to html tile but this might already be covered.

[webrooster]

I would be nice to have a "Save & Close"-Button (closes the edited document and switching to the view mode), and a "Save"-Button. The "Save"-button saves the edited document only, without switching to the view mode.

[datakurre]

@webrooster, Do you mean real save or more like "auto save" to prevent loss (and allow to continue later)?

[webrooster]

Yes, a "real save" for the "Save" button but stays in edit mode. In my view, an "auto save" is not necessary.

[datakurre]

@vangheem This is what I have currently in-house:

• We use site layouts deployed in theme, but copied into portal_resources/sitelayout by c.themesitesetup
• Site layouts contain non-editable regular tiles just as usual (for head-tags, toolbar, repetitive theming elements, etc)
• But site layouts may contain any amount of panels
• Panels may contain either a) any html with tiles or b) mosaic-editor-grid with tiles
• Mosaic editor allows to customize tiles in both a) and b), but allows add/move/delete tiles only in b)
• Mosaic editor loads default grid and tiles for (empty/missing) panels from the current site layout

The main feature I wanted was a), because it allows us to have easily layouts with e.g. WYSIWYG customizable carousel with minimal work: we can use any carousel js, almost any carousel markup, and simply place image / html tiles where we need customizable data in carousel. (Currently, the edit mode still has some additional structure for tiles in a) panels, but those don't seem to harm WYSIWYG experience and don't exist in view mode.)

So, in feature-wise, this is brings features of "content layouts" without "content layouts" as I wanted in the beginning, but could only implement now, because of how way we refactored tile data storage and editor for content layouts.

We will be keep using also the current content layouts as they are, because your UI for them is the easiest way to configure page specific site layout (we just use named /++sitelayout++/ instead of @@page-site-layout in content layouts). So, eventually, we will have Design menu with only one concept of "design" for the end users. Changing "Design" may change both content layout and site layout for the current page, but that just an implementation detail.

[tomgross]

p.a.multilingual Translation should work with p.a.mosaic activated #330