Older Plone site missing many stylesheets_问答_开发者

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 f开发者_运维知识库ix 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!]

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.

If you had many tracebacks like

Traceback (innermost last):
  Module ZPublisher.Publish, line 126, in publish
  Module ZPublisher.mapply, line 77, in mapply
  Module ZPublisher.Publish, line 46, in call_object
Module zope.browserresource.file, line 202, in GET
Module zope.component._api, line 109, in getMultiAdapter
ComponentLookupError: ((<Products.Five.metaclass.DirContainedFileResource17 object at 0xde678ec>,
     <HTTPRequest, URL=http://127.0.0.1:8080/Plone/portal_css/Sunburst%20Theme/++resource++tinymce.stylesheets/tinymce.css>),
     <InterfaceClass zope.browserresource.interfaces.IETag>, u'')

and after reimporting cssregistry.xml, had a broken layout with in the foreground Tracebacks looking like:

2011-10-10 08:42:32 ERROR Zope.SiteErrorLog 1318210952.260.0813518537427      http://127.0.0.1:8080/spirulinea/portal_css/Sunburst%20Theme/member.css
Traceback (innermost last):
Module ZPublisher.Publish, line 115, in publish
Module ZPublisher.BaseRequest, line 516, in traverse
Module ZPublisher.HTTPResponse, line 727, in debugError
NotFound:   Site Error

You may have fall in the same bug than me as it is said on http://tech.groups.yahoo.com/group/zms-developers/message/3674
(for me as well) downgrading to http://download.zope.org/Zope2/index/2.13.2 was the key.

[nota : as the time, I did not encounter any problem with a fresh new Plone on the same instance of Zope, strangely enough .. so after all, may be your custom theme were not broken ]