No Code Attached Yet
avatar LivioCavallo
LivioCavallo
15 Sep 2017

Steps to reproduce the issue

Set URL SEF not active.
Create a menu item of tagged-elements of a specific category

Expected result

Valid HTML in page.
Menu links should be something like:
?option=com_tags&view=tag&id%05B0%05D=3&types%05B0%05D=2&Itemid=110

Actual result

Invalid HTML is emitted, '[' and ']' are used:
?option=com_tags&view=tag&id[0]=3&types[0]=2&Itemid=110

System information (as much as possible)

At least Joomla 3.4 to 3.7.4

Proposed solution

In ModMenuHelper::getList (/modules/mod_menu/helper.php) at row 133 add:

// Encode '[' and ']' if emitted by any component route (i.e. com_tags 'tagged elements list' menu item does)
$item->flink = preg_replace(array ('/\[/u', '/\]/u'), array('%5B', '%5D'), $item->flink);

Additional comments

We came from joomla-framework:master PR #21. It was closed as the proposed solution seemed too deep and a potential B/C.
The solution proposed here is limited to menu links generated by mod_menus, at presentation layer.

Is preg_replace really needed (to uses u PCRE modifier for unicode)?
JRoute constructor (libraries/joomla/application/route.php) at row 93 does so to replace spaces.
Or should we use str_replace?

avatar LivioCavallo LivioCavallo - open - 15 Sep 2017
avatar joomla-cms-bot joomla-cms-bot - change - 15 Sep 2017
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 15 Sep 2017
avatar LivioCavallo LivioCavallo - change - 15 Sep 2017
The description was changed
avatar LivioCavallo LivioCavallo - edited - 15 Sep 2017
avatar franz-wohlkoenig franz-wohlkoenig - change - 15 Sep 2017
Category com_tags Router / SEF
avatar brianteeman
brianteeman - comment - 16 Sep 2017

For reference on why having [] characters in a url is not good https://perishablepress.com/stop-using-unsafe-characters-in-urls/

avatar mbabker
mbabker - comment - 16 Sep 2017

Unfortunately [] not being in URLs has practicality issues.

<?php
version_compare(PHP_VERSION, '7.0', '>=') or die('Go PHP 7 already');
var_dump($_GET);
$queryString = $_SERVER['QUERY_STRING'] ?? '';
?>
<!DOCTYPE html>
<html lang="en">
	<head>
		<title>Form Tester</title>
	</head>
	<body>
		<form method="get">
			<label for="tag-1">Tag 1</label>
			<input id="tag-1" name="tag[1]" value="<?php echo $_GET['tag'][1] ?? ''; ?>">
			<label for="tag-2">Tag 2</label>
			<input id="tag-2" name="tag[2]" value="<?php echo $_GET['tag'][2] ?? ''; ?>">
			<button type="submit">Submit</button>
		</form>
		<a href="form.php<?php echo !empty($queryString) ? "?$queryString" : ''; ?>">Current Page Link</a>
	</body>
</html>

When the form submits, the (unencoded) query string ends up as ?tag[1]=Foo&tag[2]=Bar. My browser did encode the values and the var_dump had $_GET in the expected structure. So the fact that the brackets are encoded in and of itself is NOT an issue as long as they are handled correctly. Likewise, the current link (even encoded) results in the expected behavior.

So, specifically now, what is the issue, other than the use of encoding in the URL?

avatar LivioCavallo
LivioCavallo - comment - 17 Sep 2017

I see no problem in your example. It validates ok on https://validator.w3.org (after moving php code inside <body>).
The problem is in the page emitted by Joomla! in the conditions I explained. Could you reproduce it?

In your example the broswer has responsability to do the job and does it correctly.
In the case I described the broswer has no role in generating the link, the query string, that is emitted as passed by Joomla! code, unencoded, and it does not validate.

avatar franz-wohlkoenig franz-wohlkoenig - change - 18 Sep 2017
Status New Discussion
avatar brianteeman brianteeman - labeled - 25 Mar 2018
avatar jwaisner jwaisner - change - 11 Mar 2020
Status Discussion Information Required
avatar joomla-cms-bot joomla-cms-bot - unlabeled - 11 Mar 2020
avatar jwaisner
jwaisner - comment - 11 Mar 2020

@LivioCavallo is this still an issue in J3?

avatar Hackwar Hackwar - change - 6 Nov 2022
Status Information Required Closed
Closed_Date 0000-00-00 00:00:00 2022-11-06 19:38:27
Closed_By Hackwar
Labels Added: No Code Attached Yet
Removed: ?
avatar Hackwar Hackwar - close - 6 Nov 2022
avatar Hackwar
Hackwar - comment - 6 Nov 2022

I've been going through this issue time and time again for several years now and on each occasion I put it back on my todo list. "Lets solve or decide this later." Considering that this issue is open for 5 years now and no one seems to have a solution, I'm going to close this. I've not seen others having an issue here and as Michael already wrote, I also don't really see the issue. Browsers are handling this fine.

Add a Comment

Login with GitHub to post a comment