?
avatar mbabker
mbabker
23 Mar 2016

I keep seeing it in the forums and a post there today made me check the joomla.org properties and I'm seeing the same issue with those now too.

Considering JUri nor the declaration of $this->baseurl in JDocumentHtml changed between 3.4 and 3.5, can't say what might be causing the issue.

But, previously $this->baseurl would resolve to / (even though it probably should not have given JUri::base() documentation when the param is set to true) and now it's returning an empty value.

avatar mbabker mbabker - open - 23 Mar 2016
avatar b2z
b2z - comment - 24 Mar 2016

I can confirm it - a bunch of reports on our RU forum.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9554.

avatar brianteeman brianteeman - change - 24 Mar 2016
Status New Confirmed
avatar brianteeman brianteeman - change - 24 Mar 2016
Category Libraries
avatar brianteeman brianteeman - change - 24 Mar 2016
Labels Added: ?
avatar JacquesR
JacquesR - comment - 24 Mar 2016

I did tests on a 3.4.8 site, and then repeated it after updating to 3.5.0 and can confirm that there's been a change in specifically what the output is in href tags.

It looks like an update intentionally or even unintentional fixed the different behaviour of $this->baseurl when used inside href.

Same for $this->baseurl; , JURI::base(true) and JURI::root(true)

The new behaviour matches the documentation: https://docs.joomla.org/JURI/base
but could result in logo-link and other template links not working as before.

Here's a few examples of the tests I did:

On 3.4.8

<p><?php echo JURI::base() ?></p>
<p><?php echo JURI::base(true) ?></p>
<p><?php echo JURI::base() ?>/</p>
<p><?php echo JURI::base(true) ?>/</p>

result

<p>http://example.com/</p>
<p></p>
<p>http://example.com//</p>
<p>/</p>

and

<a href="<?php echo JURI::base() ?>"></a>
<a href="<?php echo JURI::base(true) ?>"></a>
<a href="<?php echo JURI::base() ?>/"></a>
<a href="<?php echo JURI::base(true) ?>/"></a>

gives a different result:

<a href="http://example.com/"></a>
<a href="/"></a>
<a href="http://example.com//"></a>
<a href="/"></a>

Once upgraded to 3.5.0 the result inside tags like p and img src remains as before (for those), but the href ones change to match the behaviour of the rest (and how the documentation says it's supposed to be.

So after 3.5.0 update, output is:

<a href="http://example.com/"></a>
<a href=""></a>
<a href="http://example.com//"></a>
<a href="/"></a>
avatar Bakual
Bakual - comment - 24 Mar 2016

The only thing which comes to mind that will do something with those href tags is the SEF plugin. The change may be located there somewhere.

avatar Bakual
Bakual - comment - 24 Mar 2016

There was a bigger rewrite of the plugin with #9080 and there was a smaller PR #8568. One of those is likely the suspect.

avatar andrepereiradasilva
andrepereiradasilva - comment - 24 Mar 2016

i investigated further and it seems to be this part of the sef plugin:
3.5.0
https://github.com/joomla/joomla-cms/blob/staging/plugins/system/sef/sef.php#L86-L97

3.4.8
https://github.com/joomla/joomla-cms/blob/3.4.x/plugins/system/sef/sef.php#L76-L80

try to replace this lines and you will see

What i don't understand is why the SEF plugin should (and has in 3.4.8) replace

<a href="">link text</a>

by

<a href="/">link text</a>

either way, this can be resolved by replacing the regex by this (note + replaced by *)

$regex  = '#\s+' . $attribute . '"(?!/|' . $protocols . '|\#|\')([^"]*)"#m';

If all agree i will create a PR for that

updated the code

avatar brianteeman
brianteeman - comment - 24 Mar 2016

Isnt that from your own PR #9080

avatar andrepereiradasilva
andrepereiradasilva - comment - 24 Mar 2016

yes

avatar andrepereiradasilva
andrepereiradasilva - comment - 24 Mar 2016

shall i make a pr for revert it?

avatar Bakual
Bakual - comment - 24 Mar 2016

Yes, please do a PR with the changed regex so it can be tested.

avatar andrepereiradasilva
andrepereiradasilva - comment - 24 Mar 2016

PR to test #9575

avatar andrepereiradasilva
andrepereiradasilva - comment - 24 Mar 2016

A PR has been made to resolve the issue, so this can be closed. Please test the PR to get merged.

Nevertheless i want to say that this shouldn't work like this.
Just disable SEF in the PR test and you will see that without the SEF plugin it stays href="" so you have different behavior with SEF and without SEF.
And that has been like that for a some time (3.4.8 and maybe earlier).

So, IMHO this was a bug that has been corrected ... and with the new PR we will put it again.

avatar JacquesR
JacquesR - comment - 24 Mar 2016

If the plan is to revert to the previous (3.4.8 and earlier) special behaviour (bug) for href with SEF-enabled links, then this special behaviour should perhaps be mentioned in the documentation for JURI::base(true) and JURI::root(true) that causes "" to become "/" and "//" to become "/"

avatar mbabker
mbabker - comment - 24 Mar 2016

It's not JUri that is doing anything special or behaving differently before/after 3.5. It's the SEF system plugin that's changing the output as noted in the PR.

avatar andrepereiradasilva
andrepereiradasilva - comment - 24 Mar 2016

If the plan is to revert to the previous (3.4.8 and earlier) special behaviour (bug) for href with SEF-enabled links, then this special behaviour should perhaps be mentioned in the documentation for JURI::base(true) and JURI::root(true) that causes "" to become "/" and "//" to become "/"

Only the href="" becomes href="/" in the SEF bug. There is no change in the JUri class.

If you don't use SEF plugin href="" will NOT become href="/" with or without the new PR (like was too in 3.4.8).

Correct me if i'm wrong but i think the right way to make a link `to root in index.php would be:

<a href="<?php echo $this->baseurl; ?>/">Homepage</a>

This will work fine, with or without SEF and with or without the new PR, in 3.4.8 and in 3.5.0.

And also works as the documentation describes https://docs.joomla.org/JURI/base

If true then only the path to the Joomla site is returned; otherwise the scheme, host and port are prepended to the path. Note that when false (default) the URI returned has a trailing "/", but when true the trailing "/" is omitted.

avatar mbabker
mbabker - comment - 24 Mar 2016

That's spot on. The underlying API itself didn't change, but something causing side effects did.

avatar mbabker mbabker - change - 27 Mar 2016
Status Confirmed Closed
Closed_Date 0000-00-00 00:00:00 2016-03-27 22:58:39
Closed_By mbabker
avatar mbabker mbabker - close - 27 Mar 2016

Add a Comment

Login with GitHub to post a comment