[3.9.0] Checks need to guide you on where to fix them

[PhilETaylor]

Each check should be hyperlinked to the page where it can be resolved.

For example, to "set a privacy policy" is a million clicks to the plugin manager,, search for the plugin, and then edit the plugin - whereas it could be a single click on the check to take you to (eg) http://example.com/administrator/index.php?option=com_plugins&view=plugin&layout=edit&extension_id=485

[infograf768]

Please test
#22888

[joomla-cms-bot]

Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/22869

[infograf768]

@PhilETaylor
Reopening as PR concerns only one of the checks (the most 'hidden' one) and we need to discuss what we do for the others.

[infograf768]

Folks and @mbabker
I tested on a multilingual site the link we get in dashboard for Published Request Form Menu Item and imho it makes no sense and the getRequestFormPublished() method is not multilingual aware as we may have multiple menu items of that kind depending on the language.

Test

Set SEF OFF
The link obtained depends on the default site language.
To reproduce, on a multilingual site with 2 languages (en-GB and fr-FR), create for each language a Published Request Form Menu Item.
Let's say Itemid for en-GB is 303 and for fr-FR 304.
Now set fr-FR as default site language.
I am getting as link
http://localhost:8888/installmulti/trunkgitnew/index.php?option=com_privacy&view=request&Itemid=303&lang=fr
i.e. it uses the en-GB Itemid...
let's unpublish or trash the fr-FR menu item (associated or not to the en-GB one).
I still get the same url.
Let's delete the fr-FR menu item.
I still get exactly the same url.

Although it will indeed display the form in the frontend French interface, this is quite useless as I do not see anyone using this link to go fill such a request in frontend as it is much easier to just go to Privacy: New Information Request in admin to do it...

Also, when there is no menu item at all, the Itemid of the link is the one of the Default Home page set to ALL languages, which is not used at all in multilang.

Test 2

Delete the en-GB menu item. Create a fr-FR menu item, publish it.
Switch frontend languages.
The Status is set to Unpublished whatever the frontend language.

My thought on this:
We do not need at all to display the frontend url of such menu item in the dashboard but, similar to what I did in #22888 for the Published Privacy Policy, and for each content language when the site is multilingual, a link to edit the menu item —when it exists, published or not—, and, when it does not exist, a simple link to the Menu items manager to be able to create such a menu item.

What do you think?

[mbabker]

The intent was to be able to easily provide a link to the frontend page at all times. Not a link to the menu manager.

[mbabker]

The status check module isn't a walkthrough system and I'd be very hesitant to start throwing random create or edit links into the UI unless you can guarantee they're going to be crystal clear for what the suggested action is. And just dropping someone on the Menu Manager without that guided walkthrough IMO is a worse idea than not having a "click here to go to the Menu Manager to fix this issue" action.

[infograf768]

In any case, even if the intent is to provide a link to the frontend page (which I still think is useless), it does not do the job right as it does not work correctly when multilang is on as I demonstrated in details above.
I can, at least, provide a correct link (language included) and correct Published/Unpublished status for such an existing menu item, totally independent of the site default language.
The limitation would still be that, when there are multiple menu items of that kind, it will only display the link of the one with the lowest id.
PR coming.

[infograf768]

Please test #22909