Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Protostar - Error page lacks needed elements in the head #7349

Closed
smz opened this issue Jul 6, 2015 · 4 comments
Closed

Protostar - Error page lacks needed elements in the head #7349

smz opened this issue Jul 6, 2015 · 4 comments
Labels
No Code Attached Yet

Comments

@smz
Copy link
Contributor

smz commented Jul 6, 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
@smz smz changed the title Protostar - Error page lacks needed elements in the Protostar - Error page lacks needed elements in the head Jul 6, 2015
@mbabker
Copy link
Contributor

mbabker commented Jul 6, 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.

@smz
Copy link
Contributor Author

smz commented Jul 6, 2015

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

@mbabker
Copy link
Contributor

mbabker commented Jul 6, 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.

@smz
Copy link
Contributor Author

smz commented Jul 6, 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...

@smz smz closed this as completed Jul 13, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
No Code Attached Yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mbabker @smz @joomla-cms-bot