Every Wednesday we are sprinting on Plone 6 Classic topics, like the finalization of the Bootstrap 5 templates, the modernization of Mockup/Patterslib supporting ES6 and the removal of RequireJS from the resource registry.
The goal is to archive a classic UI for Plone 6, which will be easier to handle and manage for the years to come. Integration of addon's will be pain free again and with standardized Bootstrap templates, the theming easier and more accessible for everybody how is familiar with Bootstrap.
Help is very welcome, anything from improving layout (CSS and markup) to modernizing the Mockup/Patternslib JavaScript. Even if you are not a developer, you can help with your ideas how to improve UI parts of Plone 6 Classic.
We are meeting every Wednesday from 09:00 - 18:00 CEST in the following Jitsi room.
we are also on Discord in the Plone Classic UI or ES6/Mockup channels:
I'll try to join, mainly to understand involved technology, sharing ideas and maybe write some rst doc. Is bobtemplates also a topic?
An idea could be to have the "was called" personaltool topbar back, like plone.org now has. Could be empty in the index.html with the ul pulling values from manifest.cfg:
Just join in so we can discuss your ideas. From my perspective regarding the feature with the top-bar: this sounds like an excellent use case to provide this as an add-on first.
if you have questions or ideas for bobtemplates.plone you are right here and very welcome. I've done most of the development in past year's and happy to have more people on board using and improving it.
I wouldn’t use diazo (theme parameters) for this kind of configuration. We usually use a custom action category and then style the markup either in a custom template or use an action portlet which is then transformed via diazo.
The actions control panel doesn’t allow setting images/icons, but in the ZMI you can still do this. For the header links in that case we use SVGs which are linked from inside the template. In the footer the icons are coming from the action config, so they can be adjusted TTW.
Time is scarce these days for me, but I'm really interested in the JS modernization. Is the goal to be able to use a plain JS development path? I.e. that one can only with webpack, or similar tools, build the JS/CSS and then generate the bundles/files in a way that plone understands?
Hi @gforcada, we have most of the patterns in Mockup refactured from using requireJS to plain ES6 modules. Patterslib it self was done a while ago by @thet.
We are currently working on the details of some patterns, layout fixes, dynamic loading of libraries when needed and refactoring of the related-items/content-browser integration in tinymce. Everything is plain JS, we use webpack to bundle it and deploy it in plone.staticresources. Since the whole Mockup bundle will be much smaller when we are done, it's not a big deal to load the whole thing in one bundle. Most of the dendencies can be loaded async when the pattern is used somewhere.
One can also easily take all the resources and create a custom project based bundle. Patterslib/Mockup is just resources in node_modules and addons could be extracted from the resource registry like @datakurre and others did already.
for the ES6 dev we use following PLIP config in buildout.coredev:
Right now there some icons missing in the toolbar and some patterns are missing at least styles. The icons are WIP, we need to refacture the icons to use the new Plone 6 icon resolver.
Yes, that's mostly what I'm interested in: an easy way to bundle the assets myself and, if possible, avoid having to rely on the plone webpack plugin. We are using it, but it feels brittle, to say the least.
Do I get it correctly that the idea is that one can actually bundle all JS/CSS official Plone bundles from within plone.staticresources? And thus, if I have a small fix I can apply it on top of plone.staticresources and generate the bundles again?
Or what is the story for my use case? sorry for asking so much, but I guess this might be a common use case: I'm using Plone, and have my own theme, and for this or that reason I want to add some minimal/big changes on official JS/CSS code.
If, indeed, the goal is to bundle Plone official JS/CSS as a node module, then I guess that the standard(?) way to override JS/CSS files on node world would work (no idea how is that done, but I guess it is possible).
I see that on your last reply you mention the new Plone 6 icon resolver... so I'm not so sure about my paragraph just above then
Last, though it should be on every paragraph: million thanks for the work on keeping the Plone Classic alive and working! Not everyone wants/can move to volto.
The theme is still separate from the rest, but it will be easier for you to overwrite styles in Mockup patterns, since we gave up the isolation. The patterns are using the same bootstrap styles you have in the theme. Or if you don't use a bootstrap based theme, you can style it in a diffrent way or combine using the boostrap styles for the patterns and have your own styles for the general layout.
Staticresources contains the core resources in one or more bundles, as it is in Plone 5.2. It's not final, but we will properly have a webpack config in this package to build it. But most of the components are part of mockup where sofar we have the main webpack config to bundle them. Since patternslib is already available as npm package, we could do the same with mockup, so that one can include them easily in webpack or other bundlers and bundle them together with other project related resources.
All resources are still registered in the resource registry similar to who it was in Plone 4.
So we will have only bundles, which are either plain css/js or somehow compiled outsite of Plone before. Overriding existing CSS is not hard, but if you want to change JS components, you have to replace them with you own version. We might decouple some patterns into separate npm package in the process, so it will be easier to replace or improve them.
If webpack federated modules are workign out for us, we might be able to resolve dependencies for addons too.
The iconresolver, uses a icon name in the url to lookup the icon resource url from the plone.registry. The icons are deployed and registered in staticresources and can be overriden via genic setup as usual. @santonelli currently works on a collective package which registeres fontawesome icons enstead of the default bootstrap icons.
But the icon resolver still needs some documentation.
Last, though it should be on every paragraph: million thanks for the work on keeping the > Plone Classic alive and working! Not everyone wants/can move to volto.
Thx, i think so too however, we could use more support.
Right now we are a smal group of people doing most of the work, which slowes us down.
This week @agitator and I where working on the content rules part of Plone 6 Classic UI.
Since we had to migrate it to mockup and ES6, we also took the time to optimize the UI and the workflow a bit. We find it more useable now, but see your self.
@thet migrated the search part from CMFPlone to Mockup, which leaves us with plone.app.discussion left as the last UI elements to port to ES6. There might be some smaller parts left, we will find them when we are fixing all the broken robot tests in the following weeks, i guess ;). Also @jmevissen is almost done with his work on updating the error log views to be now real browser views, no longer living in portal_skins.
thank you all for spending your time to bring us closer to a neat Plone 6 Classic UI experience.
Please join us and help us with testing the UI and to fix robot tests.
sorry for asking so much, but I guess this might be a common use case: I'm using Plone, and have my own theme, and for this or that reason I want to add some minimal/big changes on official JS/CSS code.
Not everyone wants/can move to volto.
Not everyone wants/can move to volto.
