Diazo Theme Customisation

No there is no control panel, but you can do that with Diazo (XSL):
I use this to add some classes for a custom grid, to support mosaic grid classes.

<replace css:content=".mosaic-width-full">
    <xsl:copy>
        <xsl:copy-of select="@*" />
        <xsl:attribute name="class"><xsl:value-of select="./@class" /> 12u</xsl:attribute>
        <xsl:apply-templates />
    </xsl:copy>
</replace>

So with this you can build your self some snippets which you can use to transform your markup to what ever you want. It's possible to remove, add or replace attributes like class or id.

for the full snippet see here: https://gist.github.com/MrTango/c9d26e1f576b0ba1f5fa45069c60c5c7

@espenmn There is a control panel. It's the theme editor.
There is not a lot of point simplifying diazo further. For a little more learning you get a lot more flexibility.

I believe the syntax is simpler than what @MrTango specifies.
`
"attributes
If you want to replace attributes instead of tags, you can use the attributes attribute to provide a space-separated list of attributes that should be replaced on the matched theme node(s). For example, with attributes="class" the class attribute on the matched theme node(s) will be replaced by the class attribute of the matched content node(s)."

So should be something like <replace attributes="class" css:theme="h1.bigheader" css:content="h1.documentFirstHeader" />

Great!
Would it be possible to somehow 'loop this with diazo'.

Then: one could set the replacements classes (ids) somewhere:

something like
replace = [['h1.documentFirstHeader', 'h1.bigheader'], ['.someclass', '.someotherclass'], ['etc', 'etc'], ...... ]

This would make things much easier, I assume.

I don't like this because the whole theming situation is already pretty terrible in my opinion and adding yet another layer of settings is just over-engineering the whole thing. How about Plone just uses default Bootstrap to begin with, there's an idea...

...and really, the in-line theme editor is just so... What. I mean I get that we're wanting to make the whole thing more accessible to designers and frontend developers but it just makes no sense in the first place since the amount of people trying to theme Plone as designers is from what I can see, pretty negligible. I guess that's why you can find loads of Django themes and well, basically none for Plone. And the custom themes that are there for Plone aren't up to snuff when you consider what's already out there.

Not to rant, but I definitely would like to see some simplification of the theming system, Diazo and Barceloneta are all great and well, but they become incredibly tenuous to handle when you start REALLY trying to develop a custom UI or application styling.

For example I'd love to implement https://getuikit.com/ into a Plone application, but where would you even start before having to fix stuff before creating things. It should be the other way around.

As I see it you can either use Barceloneta and re-theme the site/application or if you want to create a custom theme and decide to disable Barceloneta then you're thrown in the wild to have to re-style pretty much the entire interface and since Barceloneta only uses derivatives of Bootstrap, but not Bootstrap class names or styling, and since most of the Plone templates don't use defaults for classes but custom ids here and there, you basically end up with a broken interface.

+1 - sensible defaults and all that. Those who get hung up on themeing would be better starting from there, those who want to use other systems are probably better placed to change it.

Hi Jesse,

This editor is only there to do things TTW, quick and dirty in my opinion. And therefor it's perfectly fine. For more advanced theming I always use the filesystem approach with all the tools I need and like (grunt, less/compass compiler, browsersync, ...; see the new theming training docs for example: https://training.plone.org/5/theming/theme-package.html)

You can use Barceloneta for backend and your theme for frontend only, see https://training.plone.org/5/theming/theme-package-2.html#unthemed-backend.

I see this as a problem as well and will discuss it at the conference in Barcelona next week.

My themes are almost always Bootstrap based, and usually I do something like this:

    <!-- Add Bootstrap stylesheet. -->
    <before css:theme-children="html head">
      <link rel="stylesheet" href="{$portal_url}/++theme++mytheme/assets/libraries/bootstrap3/css/bootstrap.min.css?v={$theme_version}" type="text/css" />
    </before>

    <!-- Add theme base CSS. -->
    <after css:theme-children="html head">
      <link rel="stylesheet" href="{$portal_url}/++theme++mytheme/assets/css/theme.css?v={$theme_version}" type="text/css" />
    </after>

    <!-- Add selected theme color option from spirit.plone.theming. -->
    <after css:theme-children="html head" css:if-content="#PLONE_THEMING_COLOR_OPTION">
      <link rel="stylesheet" href="{$portal_url}/++theme++mytheme/assets/css/theme-{$color}.css?v={$theme_version}" type="text/css" />
    </after>

    <!-- Add default theme color in case we have no option. -->
    <after css:theme-children="html head" css:if-not-content="#PLONE_THEMING_COLOR_OPTION">
      <link rel="stylesheet" href="{$portal_url}/++theme++mytheme/assets/css/theme-blue.css?v={$theme_version}" type="text/css" />
    </after>

    <after css:theme-children="html body">
      <!-- Bootstrap JS local fallback -->
      <script>if(typeof($.fn.modal) === 'undefined') {document.write(unescape('%3Cscript src="++theme++mytheme/assets/libraries/bootstrap3/js/bootstrap.min.js"%3E%3C/script%3E'))}</script>

      <!-- Add custom JavaScript. -->
      <script src="{$portal_url}/++theme++mytheme/static/main.js?v={$theme_version}"></script>
    </after>

I add the Bootstrap CSS and JS, if not already there, using diazo.

I also use the Plone Theming Extension I wrote some time ago to make it easier for integrators/end users to customize their theme (I think the advanced theming options are too complicated and can break your theme when used wrong).

I know you can use Barceloneta for the backend only, but then all you're doing is alleviating the issue, not solving it. You still end up with a nightmare structure to theme for the frontend. The theming for the backend should be very explicitly separated from the frontend, functionality should still remain and flexibility should still be there without having to circumvent a multitude of configurations and settings.

Using Diazo is for me, a nightmare. You lose the flexibility of creating view templates while introducing yet another configuration and syntax to handle.

I'm not the first to admit as a developer, not a designer that when I create things I tend to over-complicate and engineer stuff because from my view, it's cool. I see this with Plone, you can see it was created by a bunch of developers and programmers, it shows. But it also hurts it and makes it less accessible because there's always an extra setting, an extra configuration and so on...

I mean just see how many threads there are on this forum for "How to use my JS lib" (me included), "Where to get Plone themes", "Why is there no styling" and so on... Nobody coming into Plone has any idea what's going on, I may as well go open a spell-book and start learning new enchantments on how to make a giant chocolate dinosaur, it makes about as much sense and is equally as mystifying as when you delve into Plone in general.

So your solution and contribution to change/fix this is...?

Frontend / theming people might want to keep track of some of the initiatives to go headless with Plone:




These should be more in tune of the modern baseline expectations of the problem scope.

It would be nice for frontend / theming people if an English description was added to those projects.
(for example, the readme file could start with explaining what 'IT DOES' instead of how to install etc.

1 Like

I've learned to stop ranting about things. So now I'll try to provide a possible solution and contribute to this. In my opintion three major points nerve me when adding custom themes or trying to improve e.g. the experience on mobile devices.

Plone's Default Theme

  • Drop Barceloneta and replace with templates that strictly following Bootstrap markup
  • Make use of default CSS classes
  • Every Bootstrap-based Theme can benefit from this
  • Easier rules in Diazo

TTW vs. File System

  • Drop Theme Editor and support for TTW
  • Make things easier
  • Concentrate on FSS development (in code and in documentation)

Compatibility

  • Drop backwards-compatiblity in templates
  • Remove double-classes
  • Clean cut between major releases

I know I have to create a PLIP to contribute. My questions are:

  • Is it worth to bring up a PLIP for this?
  • Are there people supporting this effort?

I'm in Barcelona next week and happy to discuss on this. Is there a discussion already planned for this?

Not sure about that, if I understand you right.

I think for example
<a class='button blue'

is better than

<a class='bluebutton'

With the first one, you can style all buttons with the same and then just (for example)

.blue { color: blue;}

.

I was talking about documentDescription and description...

I want to address some issues and maybe new features as well, and I think the conference is the perfect place to do that. I think we will find some time to discuss this in a group and maybe sprint on that as well.

I'm definitely in for putting some spare time into this, I'd really like to see some improvements in this area. Interested to see where this goes...

Hi, I am not a themer or programmer - I've a site admin and integrator - so this depth of discussion on theming isn't for me.

However, I have what I hope is a simple question and I'm asking for some general guidance on the area of themes.

If i go to a site such as themeforest.com and chose an "HTML" theme that conforms to pure html5 and CSS, how possible is it to have that (by someone who knows Plone) brought into Plone 5? I realize this is a general question, but I'm sure there are others interested.

if it is possible is it a good approach? or should I start with the standard plone 5 theme and do some mods? I had some really bad experience with a plone 5 theme I bought from a reputable vendor but had constant problems (their theme depended on other P5 products, which changd and broke the theme.)

@rileydog. yes. we've done this before using a themeforest theme, mosaic and plone 5 and diazo.

The problem is exactly as you say, Mosiac, Plone 5 and Diazo - this is too many layers of abstraction just to get a theme usable.

As far as integrating a custom theme from themeforest.com say, It's actually relatively simple to use Diazo and a rules.xml file to create some conditions. The problem therein is that you lose (in my opinion) a lot of flexibility that working directly with Plone allows. This is why using just defaults would really help this situation.

I'd like to see a theming standard defined for Plone, similar to the way people came together to define the File System Hierarchy Standard FHS http://www.pathname.com/fhs/pub/fhs-2.3.html (This standard consists of a set of requirements and guidelines for file and directory placement under UNIX-like operating systems.).

The standard would be based on real world theming experience gained from actually porting a few themes.

If you think of Mosiac as a system for building out a drag and drop experience in Plone then there should be no conflict moving forward. It is our job to simplify the layers so that they don't feel like we're juggling lots of balls.

Porting a theme to Plone with Diazo is quick and easy (probably 1 to 2 hours of work for the experienced).
Porting it properly so that you can use Plone's machinery is not (think 30 to 40 hours). When you're done you have a fully integrated experience. The problem is that we don't have a system.

Themeforest themes have a system (I think)

I see this with the themes at themeforest, they tend to have the following 6 things:

  • home page layout
  • inner pages (team, about)
  • list and collection views (including a solution for pagination)
  • photo gallery variations
  • blog views (several variations)
  • shop views

Let's make Plone friendly to their system

@tmassman, @djay, @Netroxen,
What I'd like to discuss is a system. So that ANY themeforest theme can be ported in 5 to 6 hours.

To build out a system, these are my assumptions:

  • 80% of themeforest html themes are bootstrap based
  • 80% of themeforest html themes use the 6 things approach.

To build out a system, this is how I'd do it:

  • Sign off on a standardized Plone stack that deliberately and "unapologetically" supports the 6 things noted above.
  • Port themes by mapping the themeforest capabilities to the "6 things ready stack"
  • Create mosaic tiles that map to key components
  • Ship with ready made sample Mosaic layouts
  • Based on the first experience of porting a theme, create reusable diazo rules and mosaic tiles

The beginnings of a system

One approach I've worked on that already does some of this is called Gloss. The Gloss approach uses predefined diazo rules and allows a designer to simply take a theme and assign special classes to parts of that theme which magically make the theme Plone compatible

Combine this with a collection of reusable snippets that show examples of commonly implemented things and we would be 80% there.

Thanks everyone for the comments.

I'd like to say, at the risk of offending others, theming is emblematic of a bigger issue with Plone: the users, integrators, and even the customers are too often lost in the technical haze of creating, managing and promoting such a complicated piece of software that is Plone. it is amazing that all of this is done by volunteers. Thanks.

Themes Are important to clients. If it costs (based on @pigeonflight $2k - $3K) just to convert an existing html theme (which you had to pay for) in fully functioning Plone theme, this is a big deal for any client but the largest.

I can understand the reason why technical challenges like headless Plone attracts the Plone developers -- it would be challenging and cool to pull off. However, lost in the shuffle is the realization that Plone has lost ground to other (less solid) software like Drupal (I never compare Plone and WordPress).

Part of the reason is the ability to choose from inexpensive Drupal themes. Also, the number of products of Plone 5 has dropped well below Plone 4. I realize this is no revelation to people on this site.

This isn't a rant. I am willing to help in the only way I can: I am willing to donate up to $500 if there is a project started that raises enough interest and money to get Plone themes to a point where someone like @pigeonflight believes they should be. I remember taking with David in Boston and reading his posts here, so I know it is important to him and he appears to have good ideas ( others of course would weigh in to review the technical aspects)

So, is anyone interested in this? The offer stays open through the end of this year.