Enable theming backend/frontend UI differently

[djay]

User problem

A themer would like to visually separate

• backend UI: edit/config/site setup
• frontend or public facing views (like /view, sitemap, search etc)
  While still letting the editor be logged in and browse the site in frontend mode but also have the toolbar to quickly edit any page they are looking at.

The reasons they would want to do this is

• its expensive to style all the backend pages.
• often the effort is half done and the result doesn't look good
• additional plugins might require theme changes to work
• you might have public theme you have little control over that might conflict with css and js from plone UI. e.g. jquery verisons
• front end theme might have fixed width or even mobile only, and have no room for backend UI like tinymce

(from UX hitlist )

see PLIP 20154 https://dev.plone.org/ticket/20154

Internal

Plone 5 makes this somewhat easier by use of better CSS classes but doesn't solve the problem.

Options

1. You can setup an "unthemed" domain and theme out all plone UI from the public theme. Train users to switch domains when they want to edit.
2. A body tag called "plone_backend" on all pages which only an editor can see but aren't the main view.
   • the themer can then adjust the theme so these pages are largely left unthemed.
   • the can also improve the backend theme by removing unneeded elements like header, footer and completely changing the backend look and feel.
   • the frontend part of the theme could strip out everything from plone but the much smaller bundle which handles the toolbar.
   • prototype https://github.com/collective/plonetheme.cmsui - except it switches based on urls. This can be shipped with plone as an example theme, or be separate as a plugin.
3. same as above but use 'viewpermission-view', 'viewpermission-none' and 'viewrole-anonynous' tags to determine what frontend views.
   • pro: little more general that (2) so might allow other kinds of theming.
4. Use a themeswitcher so you have two seperate themes thats tiggered by what kind of page you are looking at.
5. by convention, in your rules.xml file to just check for a class if the user is logged in include one set of rules and if they are not, include another
   • con: you want to see it themed when logged in. Just not when looking at stuff that isn't part of the content.
6. need a way to prevent overlays for sharing etc as they bypass theming and mean the frontend theme the needs to support them.
   • looks like <drop attributes="class" css:content="#edit-bar a.pat-plone-modal" /> might work
7. need to get rid of status messages in public views - editor warnings/info boxes have to be themed #715

[vangheem]

1. eek
2. Wouldn't there be a way, by convention, in your rules.xml file to just check for a class if the user is logged in include one set of rules and if they are not, include another? Our toolbar contains js. Not sure we could do what we want with it with no js.

[djay]

Really we want someone to be able to edit the site, see it as the public would see it (themed) but all the stuff that the public doesn't see should be unthemed. This is option 2.

• toolbar js and css should be minimal so it's not a burden to include.
• every backend UI - sharing, editing, site setup etc - has a special body tag we can use to prefer a different theme that includes much more of the internal js and css.
• Get rid of things we don't need in the backend UI. plone logo, navigation, portlets. search. Use only the toolbar or specially made UI.

[djay]

@vangheem I'm going to see if there is some simple way do (2), ie a body tag called "plone_backend" on all pages which only an editor can see but aren't the main view

[djay]

@vangheem how would a themer disable overlays from items on the toolbar?

[vangheem]

something like this should work:

<drop attributes="class" css:content="#edit-bar a.pat-plone-modal" />

[djay]

@bloodbare I notice in the documentation there no longer seems to be a "plonenoui" bundle that only includes what is needed for the toolbar without any of the patterns stuff (which you don't need if you separating frontend from backend)
http://docs.plone.org/5/en/adapt-and-extend/theming/resources.html#default-plone-bundles

[djay]

so far works ok using the rule body.viewpermission-view,body.viewpermission-none except for the following

• content_status_history is viewable by anonymous. Why?
• @@HistoryView is viewable by anonymous. Why?
• lost dropdowns in frontend mode. js must be in another bundle.
• striping out header and footer we have no search. need to replace somehow.
• need a close button to return to /view
• need a rule to make the topnav not go behind the toolbar.
• need to get rid of status messages in public views - editor warnings/info boxes have to be themed #715
• barcelonta breadcrumbs too far off screen
• manifest.cfg only lets me include one css and js. why?

[jcerjak]

Nice! How does this approach work if you have a view that is guarded by a 'View' permission and you want it to be themed?

I like approach 4.), since you can focus only on your theme and not worry about the backend. E.g. by default the backend would be styled using barceloneta, but you would have the option in the theming control panel to switch the backend theme or use the same theme as for the frontend. Though this approach is probably a bit less flexible than 2.) and 3.). Note that a PR was recently merged that allows theme switching: plone/plone.app.theming#61

manifest.cfg only lets me include one css and js. why?

I think the idea is to use one LESS and one requirejs file, which import/include all the other LESS files and js dependencies. And for the production mode you provide a single merged/minified css and js file, using your own build system. I'm still wrapping my head around how all this fits together with the registry etc. We definitely need to work on the docs and provide clear instructions on how to work with static resources - it should be obvious how to integrate a static HTML/CSS/JS theme you get e.g. on themeforest (that doesn't use LESS and requirejs).

[vangheem]

Yes, some views do their own specific security checks so that makes things more difficult.

[djay]

@vangheem history and workflow actions are both filtered by permissions I think but I still think it's a bug. One should still be authenticated to see it. I'll raise them as separate bugs and see what others think.

[djay]

@jcerjak Currently it themes it if the view is guarded by the view permission or no permission at all.
Not sure if there are cases of views guarded by other permissions that you want themed. Perhaps when it's an intranet and your config screen is used by normal users. I haven't tried discussion yet. That might be one case. I guess such a theme wouldn't be suitable. Or you can add the paths into your theme.
And the other issue is views that have view permission that shouldn't, like history.

[bloodbare]

@djay There wasn't a plonenonui bundle, it's been always a bundle with non-logged-in and logged-in with plone staff in it, that means patterns/mockup. Logged-in does not have tinymce for example, and Non-logged-in has livesearch for example. You can always redefine what you want on each bundle and if you want it loaded by default on your own theme profile registry.xml.

In my case the effort to do the front-end and the back-end using the same theme is not a problem, right now with the actual mockup isolation it's quite easy to integrate all plone js on any diazo theme. We've been doing some only theming plone 5 sites with diazo on top of barceloneta and it's really a pleasure.

Manifest allow you to define a development JS/CSS (that can be a require.js and a less files) and a production JS/CSS (that is supposed that you will compile offline using your preferred tool (grunt/gulp/...)

By the way, I'm always open to review any PR.

[djay]

@bloodbare I forgot that I was the one making that bundle. Here was the old PR. #832
Not sure I got it right but I guess there should be three default bundles logged-in, logged-in-toolbaronly, non-logged-in. or another way to put it would be logged-in-backend, logged-in-frontend, non-logged-in.

[djay]

@bloodbare We aren't having the same luck. We are trying to build on a theme using its own jquery etc and having issues with the fact it doesn't use require js. This is clashing with plones insistance on using require.js. And the goal is to be able to import any theme with minimal tampering with it.

[djay]

@bloodbare I have a branch of barceloneta now that has a cut down version for just backend. You would include it in your theme like

  <!-- Import Barceloneta rules -->
  <xi:include href="++theme++barceloneta/backend.xml" />

    <!-- Apply the following rules to standard Plone pages -->
    <rules css:if-content="#visual-portal-wrapper">
    <rules css:if-content="body.viewpermission-view,body.viewpermission-none">
               <theme href="index.html" />
    ....

The problem is that I can't use another themes bundle from my theme. Or I can't have multiple bundles within a single theme. If I had multiple bundlers, perhaps I can have that includes the barecelonata code.

[djay]

@vangheem @ebrehault @esteele Why is this labeled future? It's an incredibly easy fix which saves themers a large amount of time. Why wouldn't we want to make plone 5 the easy to theme release as well as easy to use?

Here is a video of it working now (well except for the history view which has a bug #842)

[djay]

I mean I created a PLIP, submitted it, did the work, tried to get feedback from others. What did I do wrong? Is the process so opaque that not even I get anything into the core? is there some kind of secret code word? Is the idea of making theming easier somehow against plones roadmap? I'm frustrated no one seems to care about this
.

[tomgross]

I'm supporting the PLIP. We @ FHNW facing the same issue. What can/need we do to make this happen soon?

[vangheem]

@djay sorry, I missed this.

I'm a bit confused on what is supposed to be reviewed/merged here? Is there a PR?

We need branches to test and I probably just labeled it future because we're trying to release shortly.

[esteele]

What needs to be reviewed? There's a WIP pull request referenced here, but otherwise only discussion. I'm happy to look at and merge code, but I'll need some pointers to the pulls related to this ticket.

[djay]

Sorry @esteele, I did a branch for the barceloneta changes but forgot to da a PR. Done in plone/plonetheme.barceloneta#40.

The branches were referenced in https://github.com/plone/buildout.coredev/blob/5.0/plips/plip-20154-easy-backend-theming.cfg

[djay]

@pigeonflight do you want to have a go testing this out?
I've tried it with one theme. Some things that perhaps could be improved:

• the backend.xml has repeated code which isn't good. It also has hard coded css, and js links since diazo bundles only work for the currently activated theme ( @vangheem @bloodbare any way around this?)
• there currently isn't a very small bundle just for the toolbar only. the current method of using <xi:include href="++theme++barceloneta/backend.xml" /> doesn't automatically include the resources for the toolbar. You still have to do that yourself.
• <rules css:if-content="body.viewpermission-view,body.viewpermission-none"> is perhaps too long and not self explanatory.
• if your theme doesn't use require js then you are stuck with having to modify your theme to make it use it. This complicates the "lift and shift" style of theming which plone 5 should be good at. ie, you don't need to modify the theme or understand it, just grab it from themeforest and only learn a few diazo rules. @vangheem @bloodbare is there any way around this?

[vangheem]

@djay we could split it out but then it becomes more complicated. I almost prefer repeating ourselves here for simplicity...

[djay]

Still needs

• history view permissions to be fixed @@historyview publicly visible  #739
• some documentation
• include toolbar only without clashes via toolbar only bundle it is hard to include toolbar in some frontend themes #984
• more testing to see if any other backend views aren't protected with more than a view permission.

[jensens]

since the open tasks are already own issues I close this one