we would like some feed back regarding TTW Theming in Plone 6 Classic UI.
Right now we will not have TTW SCSS > CSS compiling anymore, because the Resource Registry does not bundle TTW anymore. It would be possible to build TTW compiling with Python SCSS > CSS, but no one of the current team has interest in it, so it will only happen except someone has real interest in that and makes sure it is developed before plone 6 is realeased, so this year basically.
The other releated thing is, that since the TTW theming is rather limited without that, we would probably vote for giving up the Theming Editor at all. Reason for this is also the theming-mapper pattern is rather complex and not migrated yet.
That does not mean one can't upload themes TTW anymore, that will be still possible, but a theme can't be copied and modified TTW anymore.
Are you using TTW Theming?
If you are interested in TTW Theming in Plone 6 Classic UI?
Would you work on it or sponsor someone to build it?
I don't care about TTW Theming, let's remove this complexity.
For the last Plone versions, TTW theming has not worked with my setups. I always end up with a Unicode error (or similar).
Slightly because of this: I have made an option for my own themes to disable the theme CSS and / or use custom CSS (file).
With CSS introducing variables and CSS nesting probably being available soon, maybe compiling is not so important anymore? Maybe it could be kept with 'just CSS' ?
Being able to make quick fixes without needing server access makes Plone much more useful and less worrying... Even I don't remember all the details on how to ssh into a server running a particular site, and if the theming fix is small, it is (honestly) a royal pain to have to figure out how to rebuild a file system theme and deploy it to a production server, compared to adjusting something TTW and being done in 2 minutes.
...but I understand that it is up to each person who really believes in the need for a feature to help maintain it or implement it, or find/pay someone who can help do that.
In my experience, though, most of the cases you describe can be fixed through the Custom CSS feature, even more with the new theming based on CSS Variables. I believe we should be fine without TTW editing of themes.
One thing that could be probably done, on the other hand, is providing a decent alternative to the copy-modify-rebuild TTW story for themes that we have in Plone5, like this: instead of copying a theme TTW, one could be able to download a zip with a copy of the theme files, so they can modify that on their laptop, rebuild it and upload it as a new theme.
There's still nothing like being able to make the change on the fly, on the thing I am looking at right now I might not be on a laptop (I might be on my phone on the Eurostar ... you crazy people with great rail systems!) but by golly I need to fix that Hello Kitty logo quickly before @polyester notices.
Even if I had a laptop, I would need to be running a local copy of the site. This scenario would work only for a full fledged developer.
I think we need to keep in mind the audience that, historically, made Plone so popular: the tinkerers, not necessarily fully formed multiyear experienced full time developers who have mastered the practice of building locally and deploying through CI/CD. If that's the only group who will be comfortable using Plone, we are going to be further limiting our reach.
I suspect that asking here who uses it is not going to give you a representative answer. The more someone is likely to use it, the less likely they are to be engaged in the community.
I think bundle compiling has little to do with editing the theme TTW since it never really worked anyway. If you got to the stage of wanting to optimise by bundling then we did that via the commandline and uploaded the theme
But there is a lot more to editing a theme than CSS and anyway CSS variables don't cut it because they assume you are reusing the plone theme? which is unlikely IMO
We use it for
changing/adding images
we use askos theme fragments for custom tiles
changing diazo rules (or perhaps I'm out of date and thats already been removed? which would be a big shame. It is the swiss army knife of server side customisation even if you don't want to use it for all your plone customisation).
adding additional custom css
Letting customers do all of the above on their own site if they have the skills and without having to deal with them having a local build
we also use theme GS profiles to keep everything in one place.
And as Kim points out even if we as professionals don't use editing a live site for day to day development it has very much been used to make emergency fixes that later get downloaded and committed to git.
How easy would it be to split the theme editor into a plugin rather than abondoning it completely?
A plugin that could be a very similar user experience?
Hi @djay thx for your comments. The customization via Diazo, fragments is still possible, just not directly in the browser and probably more targeted to advanced users. CSS customization is easier with the new custom css field and more likely used also by not so experienced people.
Did i use the theming editor in the past, yes sometimes but one reason was, that that was the only way to customize CSS.
GS Profiles in the theme where never in core and currently not available for python 3 if I'm not mistaken.
Could someone do the effort to modernize the theming editor and the filemanager patterns or rebuild them, yes. But who ever want this feature has to build it. And to be fair this is only Classic-UI, in Volto you don't have this option either.
I would prefer to have it as an add-on, but i can live having it in mockup too, if it is easier.
And yes it's true people, who are not developer are probably not here, but i have no way to reach them, so it has to be you who reaches your clients/users to get the feedback and support for this feature.
To sum it up, I'm happy to support, who ever want to rebuild this. But I'll not work on it outside of my projects. We already spent countless hours on Classic-UI/Mockup, mostly not covered by projects. We are close to merge the ES6 work, only some control panels are left. So if there is real interest, somebody has to step up and do the work. That's why I wrote this posts.
In my experience, TTW theming was related only to small css related cusomization (logos, content-type icons, coloring and padding-margining stuffs slightly away from standard plone). In my opinion these are that things that made Plone great since 2.0.5 (do you remember base_properties? and ploneCustom.css?). How much tech knowledge was necessary to handle those objects: almost zero.
On the other hand, diazo rules, less/scss, fragments, etc. they're all quite a different kettle of fish. I would strongly prefer as developer to have a very reliable code generator (plonecli is good) and a updated reference so that I can work comfortably on the filesystem. Writing XSL is something that needs to be versioned very quickly and ttw does not allow it.
Furthermore,
to develop a theme on the filesystem and to be able to upload it as a zip on a site is, imho, a feature that a power user does expect indeed (other CMS have it!). Moreover in a lot of cases you do not have access to the filesystem and TTW you can do already a lot of funny stuff: new dexterity types, collections, pagetemplating, workflows are amazingly powerful embedded weapons that all toghether make Plone different from other CMSes and if uploading a theme with just one click were a missing feature would be a real shame.
In conclusion,
as long as it is still possible to apply small plone styling fixes/customization through the new custom css box directly in Plone:
yes, theming ttw can be removed reducing the complexity of the system
It should still be possible to upload a precompiled zipped theme.
I can see the how a theme IDE can be seen as a non core feature and potentially something an addon could handle. Currently however plone.restapi doesn't support access to the themes and the existing api is currently broken. So any effort to make a replacement theme editor would have to first get a replacement theme api into plone.restapi into the core...
About the power of Plone’s TTW customization (not just themes but content types, etc.): my colleague Annette Lewis, who was new to Plone and was not a developer, made and maintained dozens of incredibly rich sites when she worked at Penn State, WITHOUT ACCESS TO THE FILE SYSTEM. One person (more or less), 80 or so websites, and I’m not talking about just brochures. That is the what TTW offers. That is why we asked her to keynote Plone Conf 2016.
When I was working at the university, where the needs were great and the financial and developer resources were limited, we used the fat theme approach described by Asko Soukka here: On building fat themes for Plone | Asko Soukka
The Theming Editor was used to make small TTW "applications".
We were able to teach advanced editors how to create dexterity TTW content types and modify their XML representation. Some were able to create custom TAL views in the Theming Editor.
And with the
eea.facetednavigation
collective.taxonomy
They were (almost) self-sufficient in replacing shared Excell files with much more practical faceted views.
With collective.dexteritytextindexer they could do full-text searches in their TTW content types. By adding content rules they could notify their colleagues of changes.
With collective.themesitesetup, they could export their work to the theme and version it.
From memory, the 3 biggest gaps observed for this approach were :
an XML configuration for collective.z3cform.datagridfield
the possibility to have a calculated field for the title field, a TALES field would have been ideal
the ability to easily customise the faceted view of a content type
In short, the TTW approach in Plone allows non-developers to create small applications that are a good replacement for some shared Excell files or small home-made databases.
This approach would not have been possible without the Theming Editor.
Asko's add-on's are great, i used them too in the past. I also would love to have a more round TTW story, but the reality is that you will not go far with it. at some point one will hit a wall and then you have to find workarounds or move to filesystem.
I switched to recommend using plonecli together with vs code plone snippets, on th filesystem, it's simple enough and will not let you down.
I just don't see budget for the TTW story.
If that changes, I'm happy too.
But for now we have to move on.
We will probably finish the ES6 work in the coming weeks and merge it.
I know that the TTW approach is limited. I just wanted to share my previous experience at the university.
Plone TTW is limited but so is Plone in the file system. That's why we sometimes use Django or Odoo for some projects
For me the important thing is to know the limits of the TTW approach.
I also think that the audience for the TTW approach and plonecli is not the same. I am still intimidated by some of the files generated by plonecli templates
However I agree with you to move forward to release a version of Plone 6 without the Theming Editor as soon as possible. It can always be added later by the community if the need arises.
I would like to take the opportunity of this post to thank you for all the work you are doing to release Plone 6 Classic. I look forward to working with it.
Compared to for example my experience with Wordpress: it is not so limited. If it was possible (as in Plone 5) to make a view directly at the Dexterity Control panel, it would cover most use cases for 'simple sites'.
I might not be on a laptop (I might be on my phone on the Eurostar ... you crazy people with great rail systems!) but by golly I need to fix that Hello Kitty logo quickly before 