We have a tiny fraction of themes easily available for Plone, compared to more popular systems. Be it free or $$$. Mostly it's simply a consequence of user base size, but perhaps there's something we could do that would mitigate the issue at least a little, with time.
The themes that exist can of course be found by googling or surfing the sites of providers. But how about adding a section to plone.org or plone.com or both for themes? Or does such place already exist somewhere?
To ease the maintenance of such a section on plone.org/com, how about allowing people and companies offering themes access and the means to update the information themselves on plone.org/com? At least a title & description, a nice screenshot and a link to the page where there's more information? Even better, also include price.
Perhaps we could also make theming a regular (proposed) part of sprint agenda? If each sprint just converted some nice freely available theme and/or fixed a few bugs in existing ones, after just one year we would already have a dozen new quality themes. In a few years, there'd be enough that nobody would complain about there 'not being nice themes for Plone'. Of course we could just as well have a small sprint for just fixing / adding new themes?
I wonder, would this have been a good GSoC topic? Or maybe there was someone selected for doing theming?
This was a listed GSoC topic but I'm glad to have you jump in with your suggestions - means I wasn't totally out to lunch
The few themes I know of for Plone 5 are listed on the plone.org/download page.
There are more reasons behind the dearth of freely available Plone 5 themes than "user base size"... the kinds of clients that most of us have, whether Plone service providers/consultants or in-house developers for large organizations, have their own proprietary branding and would not take kindly to their theme being made available for free download or reuse.
I got a pypi classifier created for Plone themes a few weeks ago. I plan to push theme developers to include this classifier in their setup.py, if they're making them available as add-ons (as opposed to zip files).
We have a GSoC project "Improving plone.org" that includes fixing the add-ons listing that never really made it to the relaunched plone.org last year. The add-ons listing will include themes.
OK last thing I'll throw out here for now: with Diazo, it's relatively easy (with training/experience) to take an HTML theme from say themeforest.net or a WordPress theme and turn it into a Plone Diazo theme. It takes an experienced person a matter of hours, not days. For simpler themes, a couple of hours.
@tkimnguyen I wonder if its possible to create a theme forrest adapter. ie, just download theme X, get the plonetheme X adapter, combine and upload for a working theme X on plone.
Does plone 4/5 documentation include a (visual) description of the most common layout elements and their CSS classes and identifiers?
Such a document would be very useful for theming, and especially for converting themes designed for e.g. WordPress or plain html/css/js/font/image "bundles.
Furthermore, maintaining that document and keeping a disciplined approach to making any changes to the elements and their class/id names would help transfering themes from a Plone version to the next. Then, it might even be possible to automate that to a degree by providing some sort of theme upgrade steps. Maybe they could be written as diazo rules, or XSLT?
Perhaps this would merit a PLIP? Although this is more about maintaining a rigorous and disciplined process and documentation, than about software artifacts.
Continuing on that thought of maintaining UI documentation for themers, we should also consider how to handle the fact that add-ons would provide/change/remove such documented UI layout elements.
If there was a mechanism to document the elements and changes, perhaps we could provide means for the Plone theme generation system to read and parse such "UI layout declarations" and take them into account accordingly. So that themes could for example be downgraded gracefully when needed.
Or is this getting into over-engineering of something for which there can be no reasonable ROI?
failing an automatic conversion of HTML theme to plone, what about identifying people who want to focus on this as they're main skill. thus, if an HTML theme can be converted in a few hours (for a skilled person) it now becomes possible to pick a theme you like, pay license fee, and then have someone bring it into plone. So you could have a plone theme for maybe $300 us. As a site developer I would consider this reasonable.
if people specialized in this, and were identified here, this would be a great way to help people get the theme that want at a reasonable price and help plone programmers make a living. Also, we could encourage people who had themes converted to make them available to others. (licensing fee from origninal source would have to be considered)
@datakurre do pages created using plone.app.mosaic have distinct CSS classes and ids for each page element? I am not sure of the terminology - are those called blocks? Or tiles? Likewise, does the chosen layout show up as a CSS class or id?
I am just wondering if it is possible to tie diazo rules to p.a.m layouts and the said page elements easily...? Many non-Plone themes out there have more content elements on a page than just the "regular" title, description and body text that we are used to in standard Plone pages. By using p.a.m it becomes easy to provide such extra page elements.
For the same purpose, it would be very useful if the elements could be given (per-page) labels that are persisted with the page and show up in the p.a.m editor. Now it seems the label is always just the type (block type?) name.
I personally have done this, so has https://wildcardcorp.com (the company I work for), and I'm willing to bet any non-individual Plone provider (Providers) has done this.
When Mosaic layout has been set as the selected view, it adds template-layout_view class for body. But this is because of normal body class policy, which looks for the name of the active template.
When Mosaic editor places tiles, it adds the tile type as class name. But this is not really for CSS, but for the editor itself (but CSS could use it by escaping dots in the class name).
Why there is no better class names and ids, is probably because of the original idea preferred explicit markup instead magical injections.
I agree that the current implementation is not perfect, but I've not hit the limitations myself and therefore been unable to "fix it" (without real own use case).
@datakurre I'm sure there was the capability to add custom classes to tiles and rows. I remember clearly the discussion to add row classes and you adding that in. It was for this very purpose. Same use case as the portlet styles plugin.
BTW, the best way of doing this is to have the user select from a list which is defined in the theme rather than having it free text, just like portlet styles did it.
Surely its easy to add a class based on the layout id too? That would be very useful.
@rileydog I think theme ecosystem is like a chicken and egg problem. Wordpress has it because of the scale of the numbers of people wanting quick cheap websites. But one of the reason people go to wordpress for quick cheap websites is because of the availability of off the shelf themes.
However its not the only reason. Easy to host is another big reason which plone has some catching up on. Learning curve is another area. Lots of ways of customising Plone still require buildout, eggs, ZCML and lots of frustration before getting any results.
I believe efforts like plone-docker, rapido, some GSOC enhancements to theme editor, putting mosaic in the core or at least having a distribution that combines mosiac and rapido could overcome some of those learning curve issue. Then with the right marketting and some nice themes we could create some marketing around plone being the most powerful easy to customise open source CMS.
Imagine with docker on AWS, if with a couple of commands, or the rancher UI, you could create an auto scaling multisite plone platform as well as your own set of 3rd party plugins... hopefully on free tier to start with. Something resilient enough for most simple sites. Then the rest you did using the the Plone UI, customise diazo, add JS, add python using rapido, create content types, create mini db apps using plomino, sync that all to git using a single command.
At the root of the downloaded, unzipped file, there's an index.html and sub-directories for static assets.
What is the preferred way of taking the template's index.html file and static assets and getting them into Plone? It would be helpful to see a minimal example manifest.cfg and rules.xml. I'm working locally on a development instance, so I have file system access.
I understand that I'll need to add rules and add CSS IDs to the HTML. I'll cross that bridge after this first step.
Basically I'm not satisfied with any of the readily available themes, and I want to start from scratch so I can learn by doing.
I am not really an expert on this topic, but here are some thoughts regardless:
Bootstrap & Zurb are full-fledged front-end (theming) frameworks. When using them, they rather quickly start imposing framework-specific requirements on your HTML (DOM structure, special attributes & values). Thus if you want to convert a theme using either of them, you will also have to (sooner rather than later) add some (complex, AFAIK) rules or raw XSLT to transform the HTML generated by Plone.
Now, perhaps one day we'll have (hint, hint!) Plone theming "shims" that bridge this "gap" between "Plone HTML" & "Bootstrap/ZURB HTML".
But until then, I would recommend starting with what I think are known as plain "HTML5" themes that do not require transforming your HTML. It'll be less work and frustration for you.
but I'm glad to have you jump in with your suggestions - means I wasn't totally out to lunch 