Makes sense - thanks for your help!

David, I think the reason why the decorator doesn't get applied is because the errorPage handling by the application server doesn't use the same filter chain as a normal request. This means that hitting 404page.action via the 404 error page configured in web.xml doesn't go through the login filter (which checks for a user's session or cookie), or the sitemesh filter (to decorate the page).

Because this isn't fully specified in version 2.3 of the Java servlet specification, we'd need to upgrade our web.xml to servlet 2.4, and only support application servers that support it.

I've raised another issue to upgrade to servlet spec 2.4 to allow this to work correctly: CONF-9793.

I'll close this issue as obsolete.

Essentially that's correct. I've basically got the same header/footer code in 404.vm as I do in main.vmd - now that I've worked out what the content tags were for, the page basically looks identical - apart from some additional whitespace in cases where the content from 404.vm is hidden.

I also picked up some odd behaviour after my last comment - where the main decorator is not applied, it does not seem to pick up the fact that the user is logged in - the #usernavbar macro just shows the 'Log In | Sign Up' links, and the list of spaces only shows spaces visible to anonymous users. Is this expected behaviour?

I'm not sure exactly what you mean, David.

The URLs you included in the original request are still decorated differently. Are you saying that this no longer causes a problem for your customisations?

FYI - I've just fixed this issue.

I was going to investigate an extremely crude work-around using the $title variable within main.vmd, and while digging through 404.vm some odd footer behavior on the 404 pages caught my attention - we were getting double headers where main.vmd was being processed, but still only one footer.

Basically, the problem was caused by the header code that I'd added to 404.vm sitting outside of the <content tag="hideme"> & </content> tags. I suspect that while processing a decorator content within those tags is hidden, but displayed when there is no decorator.

This can probably be closed, although I think it is probably worth me documenting this somewhere for other users to refer to in future - where would be the most appropriate place do you think?

Thanks for your reply, David. I understand now: you want to style the 404 page with your custom layout, and this bug is preventing you from doing so.

I'll update the issue to make this clear.

Unfortunately, I don't have a simple workaround at the moment for you. The problem is that Confluence's SiteMesh filter isn't applying the decorator to some of the URLs above. It's not related to Velocity, and not something you can fix in the decorator itself.

This issue was logged by myself. Unfortunately I have to disagree - in my opinion this is a major issue, rather than a minor feature request, which is why I logged it via the support system instead of raising a feature request myself to begin with.

My reasoning is that it is extremely important to be able to provide a professional and consistent user experience, especially if the wiki's target audience is an organisation's customers (as it is in our case). This problem is preventing us from being able to correctly brand all pages which is certainly not a trivial issue, particularly for brand-conscious/brand-protective organisations such as ours.

So yes - I'd definitely say that fixing this would help in a few ways. It would help Atlassian secure our business as a start, as well as the future business of any other organisations in a similar situation as our own.

Furthermore, a wiki's success relies heavily on the user - there are social/psychological implications that need to be considered. If a site looks unprofessional or 'broken', this will negatively impact a user's attitude toward it. The flow-on effects of this may very easily include reduced adoption and participation rates as users may be less inclined to use the site, trust its content, make their own contributions, etc.

As an alternative, can you (or anyone else from Support) suggest a temporary work-around? For example, I'm quite good with Velocity... if there is some way to recognise that the current page is an error page, I could probably modify the main.vmd decorator to overcome the issue. I had a good play around with the HttpServletRequest object but couldn't see any way to get this information from there.

Unless this is causing some kind of problem, I'll be closing it as "Won't Fix". This will require more investigation than it is worth for something that doesn't really bring any obvious improvement. (I had a look, and the fourohfour.action is set to decorator "none" by decorators.xml, so it's something non-trivial to fix.)

Can the customer affected justify this further? Does fixing this help anything?