css-bug language switcher

[gwsdesk]

Steps to reproduce the issue

Bug in the css of/for the language switcher for the default templates (both)

When logged on as registered user and click on the in the user menu located link "new article" it shows the correct response (non-authorized) However on Protostar the language switcher changes to a "list" layout with flags suddenly showing vertical listed and on Beez the language switcher disappears completely

See screencast

[infograf768]

Looks like the specific css file for the switcher is not loaded. Looking into this

[gwsdesk]

Should have read: J 3.4.4 RC2 :: Mea Culpa

On 9/4/2015 2:53 PM, infograf768 wrote:

Looks like the specific css file for the switcher is not loaded.
Looking into this

—
Reply to this email directly or view it on GitHub
#7812 (comment).

[infograf768]

Went further into this and I do not think it is specifically related to 3.4.4 rc2

we get a 403 for this menu item when not logged in with correct access and, instead of being presented with a login page, we get the error page. That, for me, is the main issue. It was the same behaviour in 2.5.
To work correctly, any User menu item should have a specific access... Registered for the profile and Special for the others (default settings in sample data). The User menu module, if any, should be set to Registered.

Using protostar
If the module is not in position-0 (Search position) or position-1, it is just not displayed and it is normal to not see it as all modules in other positions do not show when we have an error page of this kind.
When the module is in position-0 or position-1, it is displayed but the switcher css is not loaded, which is indeed a bug.

[gwsdesk]

Fully aware of the explanation. However even if the permissions are
wrong and both (in my example) are published to position-0 the layout
should not change nor should it disappear. A user type "registered"
should not get the link to create new articles at all of course but we
are testing ain't we? :) So it is incorrect behavior (?) that the
switcher is getting into stress vertically because of wrong permissions
or as in Beez not showing anymore at all (same position)

On 9/4/2015 3:28 PM, infograf768 wrote:

Went further into this and I do not think it is specifically related
to 3.4.4 rc2

we get a 403 for this menu item when not logged in with correct access
and, instead of being presented with a login page, we get the error
page. That, for me, is the main issue. It was the same behaviour in 2.5.
To work correctly, any User menu item should have a specific access...
Registered for the profile and Special for the others (default
settings in sample data). The User menu module, if any, should be set
to Registered.**

---

Using protostar
If the module is not in position-0 (Search position) or position-1, it
is just not displayed and it is normal to not see it as all modules in
other positions do not show when we have an error page of this kind.
When the module is in position-0 ir position-1, it is displayed but
the switcher css is not loaded, which is indeed a bug.

—
Reply to this email directly or view it on GitHub
#7812 (comment).

[infograf768]

Please test the following:
Change in ROOT/components/com_content/views/form/view.html.php

line 55
JError::raiseError(403, JText::_('JERROR_ALERTNOAUTHOR'));
to
JError::raiseWarning(403, JText::_('JERROR_ALERTNOAUTHOR'));

We will not get any more the error page, but the message and the css for the module will be loaded. :)

If that is satisfactory to you, I will make a PR.

[infograf768]

But it does not solve the global issue when we get a 404 for example

[gwsdesk]

So this stops indeed the error message disappear and it returns simply
to the page but on both templates the flags remain. I am not sure that
this is the ideal way of plugging this little hole but at least we have
no template broken and questions on forums and users can easy be
answered when the link 'basically not reacts' Q: Has the user
permissions to create new articles? "Answer: Thanks I have changed these
and now it works properly "

So a yes for me

Thanks 'Opa JM' -;)

On 9/4/2015 3:45 PM, infograf768 wrote:

|JError::raiseWarning(403, JText::_('JERROR_ALERTNOAUTHOR'));|

[infograf768]

We still have the global issue that a css loaded by a module (in this case mod_languages) is not loaded in the error page although the code is correct:
JHtml::_('stylesheet', 'mod_languages/template.css', array(), true);

[gwsdesk]

No it is worse. With that code the create new article link is not
working even when logged in as Super Blooper

On 9/4/2015 3:58 PM, infograf768 wrote:

We still have the global issue that a css loaded by a module (in this
case mod_languages) is not loaded in the error page although the code
is correct:
|JHtml::_('stylesheet', 'mod_languages/template.css', array(), true);|

—
Reply to this email directly or view it on GitHub
#7812 (comment).

[infograf768]

@gwsdesk
Maybe I was not clear. I was not speaking of adding that code in the error.php page. I was speaking of the general issue with error.php pages who do not let JHtml work normally when called by a module.

[mbabker]

JDocumentError is a different document type than JDocumentHtml. By design it appears fully intended to be a very limited HTML error page and lacks the native renderer objects to process the <jdoc> tags we use in the templates. The problem is our API has so many hacks and extra methods to do things, like render modules, that you can make that error.php HTML document do a lot of things. IMO the current behavior with the lack of <jdoc> parsing is right; the error page should actually be format agnostic and be able to return suitable errors based on the request format but right now it hardcodes to an HTML which will break JSON or XML formats.

Changing the error type only bypasses the "issue". The way our API works, if you really want to start rendering modules in your template's error.php file, you need to be prepared to manually include all of the relevant media too. The other option is we ignore the fact that error responses should be possible in non-HTML formats and we just code JDocumentError to have a majority of the JDocumentHtml featureset, that's a pretty bad idea too.

[gwsdesk]

Does this mean in your opinion that we have no solution in the present
Joomla CMS for this issue and that we should maybe put this on the
agenda of the Joomla 4.x roadmap?

Your guidance is highly appreciated Michael?

Leo
On 9/4/2015 7:47 PM, Michael Babker wrote:

JDocumentError is a different document type than JDocumentHtml. By
design it appears fully intended to be a very limited HTML error page
and lacks the native renderer objects to process the || tags we
use in the templates. The problem is our API has so many hacks and
extra methods to do things, like render modules, that you can make
that error.php HTML document do a lot of things. IMO the current
behavior with the lack of || parsing is right; the error page
should actually be format agnostic and be able to return suitable
errors based on the request format but right now it hardcodes to an
HTML which will break JSON or XML formats.

Changing the error type only bypasses the "issue". The way our API
works, if you really want to start rendering modules in your
template's error.php file, you need to be prepared to manually include
all of the relevant media too. The other option is we ignore the fact
that error responses should be possible in non-HTML formats and we
just code JDocumentError to have a majority of the JDocumentHtml
featureset, that's a pretty bad idea too.

—
Reply to this email directly or view it on GitHub
#7812 (comment).

[mbabker]

A major refactoring of the error system is needed for 4.0, yes. The "dirty man's fix" for things like this is if you are loading modules in your error.php template, you'll need to manually load the relevant media also. Even for our joomla.org site template, we are manually loading jQuery and Bootstrap's JavaScript to ensure our customized error template renders correctly via snippets like <script src="<?php echo JUri::root(); ?>media/jui/js/jquery.min.js" type="text/javascript"></script> since JDocumentError doesn't have code to build the <head> elements. I suppose one could also do some custom parsing of the properties that JDocument stores the stylesheet and script data to (the template files are in the context of a JDocument object so you can call $this->_custom for example in a JDocumentHtml (index.php) template and access the custom snippets directly).

With the refactoring, two things should happen:

1. The general error handler should be smarter about format appropriate responses. If we know the request format, return the error in that format (so if you have a JSON request, the response should be a JSON string)
2. The HTML error handler can better handle being able to process data stored to the JDocument instance (namely scripts and stylesheets)

[gwsdesk]

Thanks Michael, Will bring this to the J4.0 Working Team I recently joint.

On 9/4/2015 10:42 PM, Michael Babker wrote:

A major refactoring of the error system is needed for 4.0, yes. The
"dirty man's fix" for things like this is if you are loading modules
in your error.php template, you'll need to manually load the relevant
media also. Even for our |joomla.org| site template, we are manually
loading jQuery and Bootstrap's JavaScript to ensure our customized
error template renders correctly via snippets like |<script src="media/jui/js/jquery.min.js" type="text/javascript"></script>| since JDocumentError doesn't have
code to build the || elements. I suppose one could also do some
custom parsing of the properties that JDocument stores the stylesheet
and script data to (the template files are in the context of a
JDocument object so you can call |$this->_custom| for example in a
JDocumentHtml (index.php) template and access the custom snippets
directly).

With the refactoring, two things should happen:

1. The general error handler should be smarter about format
   appropriate responses. If we know the request format, return the error
   in that format (so if you have a JSON request, the response should be
   a JSON string)
2. The HTML error handler can better handle being able to process data
   stored to the JDocument instance (namely scripts and stylesheets)

—
Reply to this email directly or view it on GitHub
#7812 (comment).

[infograf768]

In the mean while, I will propose a patch using enqueuemessage when the error concerns JText::_('JERROR_ALERTNOAUTHOR') in frontend. This should do it.

[gwsdesk]

Sounds like a plan to me

On 9/5/2015 1:21 PM, infograf768 wrote:

In the mean while, I will propose a patch using enqueuemessage when
the error concerns JText::_('JERROR_ALERTNOAUTHOR') in frontend. This
should do it.

—
Reply to this email directly or view it on GitHub
#7812 (comment).

[infograf768]

See PR here : #7824

[Bakual]

Closing as we have a PR