?
avatar smz
smz
6 Jul 2015

Steps to reproduce the issue

  • Create a multilingual site and publish the language switcher
  • Enable "Smart Search" functionality and publish the "Smart Search" module in the "Search" position
  • Navigate to a non-existing page (e.g.: the proverbial /foobar)

Expected result

  • The Language Switcher should be correctly displayed
  • Smart Search should be fully operational (i.e: suggestions should work)

Actual result

  • The Language Switcher is un-styled
  • Smart Search suggestions do not work

Additional comments

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:

  • Do not publish any module in error.php
  • Find a way to have <jdoc:include type="head" /> (or something equivalent...) to work in error.php too
avatar smz smz - open - 6 Jul 2015
avatar smz smz - change - 6 Jul 2015
Title
Protostar - Error page lacks needed elements in the
Protostar - Error page lacks needed elements in the head
avatar smz smz - change - 6 Jul 2015
Title
Protostar - Error page lacks needed elements in the
Protostar - Error page lacks needed elements in the head
avatar mbabker
mbabker - comment - 6 Jul 2015

Error pages are rendered by JDocumentError which is a different subclass than JDocumentHTML. 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 include JDocumentRendererHead 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.

avatar smz
smz - comment - 6 Jul 2015

This being the case, I think it would be better if we don't load any module in error.php...

avatar mbabker
mbabker - comment - 6 Jul 2015

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.

avatar smz
smz - comment - 6 Jul 2015

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...

avatar smz smz - change - 13 Jul 2015
Status New Closed
Closed_Date 0000-00-00 00:00:00 2015-07-13 08:17:02
Closed_By smz
avatar smz smz - close - 13 Jul 2015

Add a Comment

Login with GitHub to post a comment