This is due to the lack of the <jdoc:include type="head" />
directive in Protostar error.php
and hence the lack of various CSS and JS dependencies.
Unhappily using <jdoc:include type="head" />
in error.php seems to be impossible, so I think we should either:
<jdoc:include type="head" />
(or something equivalent...) to work in error.php tooTitle |
|
Title |
|
This being the case, I think it would be better if we don't load any module in error.php...
I don't know if there's a good "right" answer for the core templates. It's totally feasible to render modules on the error page if you handle calling the renderer manually AND put all the needed references into the <head>
manually (something that's feasible at a site implementor's level, not so much for a core distributed thing like Protostar or Beez3).
Maybe that's a viable short term option. But really, fixing the error handler needs to be on someone's radar for improvement and not just swept under the rug because it's too difficult or too inconvenient for someone to take on.
Fixing the "Language Switcher" is quite easy: it is enough to load mod_languages's template.css and that would not hurt even mono-lingual sites that do not publish the switcher.
Problem is that the switcher doesn't have a dedicated position: it normally shares Search [position-0]
with other modules typically published for "All" pages (like "Search" or "Smart Search"): we could create a dedicated position for the language switcher.
Other positions currently published in Protostar error.php
are banner
and Naviagtion [position-1]
(note that a custom menu module would probably rely on some CSS/JS): IMHO these are not positions "required" for error page functionality and we could get rid of those.
All of the above is of course feasible only if deemed non B/C breaking...
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-07-13 08:17:02 |
Closed_By | ⇒ | smz |
Error pages are rendered by
JDocumentError
which is a different subclass thanJDocumentHTML
. On one hand, IMO it is the right behavior that the actual document subclass doesn't have all the HTML features built into it; as an error handler that is referenced in a couple of places, it should be format agnostic and smart enough to try and kick back an error in the right format (JSON, XML, etc.). On the other hand, when it does render an HTML document, it should be able to render a limited amount of data (I don't think there's a major issue with it being able to includeJDocumentRendererHead
but the way JDocument in general is coded, not so easy to do).I know that's not very helpful, but the long and short is Joomla's error handling (and the core itself) needs a major overhaul to support more than just HTML pages without hacky workarounds.