Question

I have a Plone 4 site that was created 3 or 4 years ago and has had little maintenance since. A third party installed a theme that I was never happy with, but since nobody else seemed to care I didn’t pay much attention. Now I’ve been hired to update the theme, and I see the real problem with the old site is that many of the standard .css files are not being included.

When I install the theme into a brand new Plone site, it looks good, but when I install it on the old site, member.css, for instance, is not loaded.

I can fix it by exporting the cssregistry.xml from portal_setup in the new site and loading it into the old site, but I’d rather find out why it’s wrong as it is – what product should be installing member.css? It looks as if it should be Products.CMFPlone (from Plone-4.0.7 in my case), so how would I force it to reinstall its registry?

[Edit: In fact, I did force it to reinstall it’s registry by going to portal_setup import and reimporting the “Stylesheet Registry” step. That broke my custom theme and some adapter (very odd, that), so I tried reimporting all steps and broke everything. Good thing this is just a test copy!]

Answer 1

If you have an old and migrated site, I would just go into the ZMI and manually fix the problems. member.css has been part of core Plone itself since the beginning. So if that’s not enabled someone did a manual change to your old site.

It’s much easier to just fix the one broken site via the ZMI than to write any code or profiles to do it.

In my opinion it only makes sense to write GenericSetup profiles, if you do it all the way. So no changes via the ZMI or Plone control panels are allowed. You always have an extension profile in your policy code that will create a new site exactly mirroring the live site. You write upgrade steps for your own changes and run those instead of reapplying any profiles. You make sure to only use add-ons that are well behaved and use upgrade steps or you fix those to behave correctly.

But all of that costs time which only makes sense if you expect to change your site continuously and have tests for your site specific configuration. If you produce one-off sites that won’t change anymore after they are deployed, this whole overhead is probably not worth it.