I have commited a possible fix in a wichert=request-modifier branch. I made a change which tests if a traversal step did any real traversing or only did something else and use that to control calling of the before publish hook. All Zope tests are passing with this change. Wichert. On 2010-2-21 21:21, Wichert Akkerman wrote:
Apologies for the cross post, but since there are many components involved here I'm not sure what the right list is.
Plone uses plone.theme to set an IBrowserSkinType on the request that matches the currently selected CMF skin. This is very useful since it allows you to register browser views and other components for a CMF skin. plone.theme does this by using the __before_publishing_traverse__ hook on the site root.
For one site I want to offer a different skin to people coming in via a separate URL. I do this by proxying to the site and adding a ++skin++ traverser to set the skin layer.
However this does not work due to how Zope 2 publication works. What happens is this:
1. ZPublisher traverses over the site root and calls the CMF __before_publishing_traverse__ hooks. Via a IBeforeTraverseEvent event plone.theme gets called and adds a IBrowserSkinType layer for the current CMF skin. 2. ZPublisher handles ++skin++name, which sets an IBrowserSkinType layer for my new skin, replacing the layer set by plone.theme. The traverser returns the same object, our site root, again. 3. ZPublishes procees by calling the __before_publishing_traverse__ for the site root again, which ends up calling plone.theme again and replacing my skin layer again.
The problem here is that a ++skin++ traverser always returns the same object again, and ZPublisher will happily treat it as a new object and call all hooks for it again.
The only way to avoid this that I can see is to make ZPublisher check if a traversal step returns the same object again, and if so skip the __before_publishing_traverse__ hook in that case. This feels like a safe change, but I am not sure if this would break anything.
Wichert.
-- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.