Ticket #11965 (closed PLIP: fixed)
Resource bundles for ResourceRegistries
Reported by: | optilude | Owned by: | optilude |
---|---|---|---|
Priority: | major | Milestone: | 4.2 |
Component: | General | Version: | 4.2 |
Keywords: | Cc: |
Description
Description
Proposer: Martin Aspeli Seconder: Eric Steele
Motivation
The resource registries (portal_css, portal_javascripts and portal_kss) can manage resources with conditions, and are partially theme (skin) aware insofar as that they will always switch to the intended skin so that the appropriate resources and overrides are available. However, it is very difficult to manage different resources for different skins, and there is no logical way to group resources.
One obvious problem with this is the way that all "classic" themes override all the "classic" stylesheets (authoring.css, member.css, etc) - often with blanks - just to disable the standard styles. The alternative would be to delete and replace all resources, but this can easily mess up the registries and merging order and is not feasible for another theme.
This is also an issue for Diazo themes, which should be able to use the resource merging and caching control of portal_css and portal_javascripts. This is often done manually using GenericSetup, though plone.app.theming will likely grow functionality to manage resources automatically in the future (see below).
Finally, if plone.app.cmsui is used (or merged in the future), the need to isolate the editing UI resources entirely from the public skin means having two "active" themes - one for the public site and one for the CMS UI.
Assumptions
N/A
Proposal & Implementation
- Add a 'bundle' property to each resource. This is simply a string tag to identify the resource. For backwards compatibility, any resource without a bundle set is given the bundle 'default'.
- Add a mapping of theme (from portal_skins) to list of bundles. This is a list of strings, maintained in portal_registry. For backwards compatibility, all themes will include the 'default' bundle unless explicitly changed in the ZMI.
- Add ZMI UI elements to manage bundles and theme-to-bundle mappings.
- Change the storage of cooked resources so that it is keyed per theme. Add backwards compatible aliases for the current theme so that existing code (and tests) work. There may be an on-the-fly re-cooking of the resources the first time the site is loaded after upgrade, but no explicit migration will be required.
- Change the merged composition listing to show the merged resources list for each theme.
- Add a named adapter indirection to allow resources to be provided by other means than just the persistent configuration in portal_css/portal_javascripts/portal_kss. This will allow plone.app.theming to supply theme-specific resources automatically without having to maintain persistent settings each time is installed or changed.
Deliverables
- Changes to Products.ResourceRegistries
- Changes to the base profile in Products.CMFPlone and a migration profile to associate bundles with existing resources and associate these with the theme, to make it easier to reuse and enable/disable related groups of resources:
- jQuery
- jQuery Tools
- TinyMCE
- Authoring
- Public
Risks
None at this time
Participants
- Martin Aspeli
- Laurence Rowe
Progress
- Products.ResourceRegistries 2.1a1 has been released with this code already implemented, as a pre-requisite to getting an alpha version of plone.app.cmsui released (this approach was agreed with the release manager)
- CMFPlone base profile changes would be done upon acceptance of the PLIP
Change History
comment:3 Changed 5 years ago by eleddy
- Milestone changed from 4.2 to 4.3
Sorry, but in addition to no real motivation to include this in a release yet, this PLIP was submitted too far outside of the 4.2 deadline. Please understand that this is a new process and we especially can't make exceptions in the first pass.
We started discussing inclusion into core for 4.3, but would like to see a more detailed Risks section. Are there really no risks?
comment:4 Changed 5 years ago by optilude
I'm fine with that - it just means we need to remember that we have a trunk to merge to and p.a.cmsui/p.a.deco users will need to pin to a newer RR release (we'll issue a KGS, of course).
I couldn't think of any non-banal risks (e.g. "it may be buggy" or something like that). It's a pretty small enhancement. I would of course like to hear the Framework Team's view on risks and potential problems, though. ;-)
Martin
comment:5 Changed 5 years ago by eleddy
go forth and implement - we are looking forward to this in 4.3!
comment:6 Changed 4 years ago by rossp
Using plone.app.theming in an instance alongside some previously existing, un-themed plone sites, I found the other sites were getting no CSS/JS/KSS from the resource registries. The simple workaround was to go into the ZMI screen for each registry and click "Save" at the bottom, then all the previously existing plone sites had their resources restored. This does mean, however, that the "on-the-fly re-cooking of the resources" doesn't seem to be happening.
comment:9 Changed 4 years ago by optilude
As far as I know, this is ready to merge. Anything else needed from the FWT?
comment:10 Changed 4 years ago by esteele
- Status changed from assigned to closed
- Version set to 4.2
- Resolution set to fixed
- Milestone changed from 4.3 to 4.2
Merged into 4.2.
comment:11 Changed 4 years ago by esteele
- Status changed from closed to confirmed
Martin, Laurence: What groupings do we want to set up in Plone's default profile?
(In [50818]) PLIP buildout refs #11965