Language prefix and relative links broken

Patch from #2428185: Language prefix and relative links broken works for me too.

Okay, since TheodorosPloumis says it worked for him too, I'll say it's RTBC! Which means that I'll see this the next time I'm looking for patches to include for Link.

It appears this is happening in 7.X-1.4 as well... Does anyone have a version of the patch that will work on 1.4?

@johnpicozzi you can apply the above patch against the 7.x-1.4 branch as well.

I can also confirm that the upgrade from version 1.3 to version 1.4 breaks the urls on multilanguage sites. Which gets fixed by applying the above patch.

Maybe I am missing something here but I have the following in a link field.

sites/xxx.mysite.com.fr/files/some.pdf

On output of the link I am getting

xxx.mysite.com/fr/en/sites/xxx.mysite.com.fr/files/some.pdf

where my base url is xxx.mysite.com/fr - The en shouldn't be in the relative path as it's a language code. correct?

Thanks for the help!

For us only the patch from #3 works. If we apply the one at #5 we get an error like: EntityMalformedException: Missing bundle property on entity of type paragraphs_item. in entity_extract_ids() (line 7880 of ../includes/common.inc).

We are using the Paragraphs module and the error occurs only when having a paragraph with a link field inside another paragraph.

re-rolled the patch to only set a flag on the item processed. Setting the $item['_link_sanitize_raw'] = $item; can lead to memory leaks on multiple calls for the same item since the $item is passed by reference.
The updated patch returns if the item has been processed since there is no need to re-process the link item.

I confirm this bug. I confirm that patch #14 works for me well.

I'm not sure if my problem falls under this issue but it seems to be similar. In my multilingual site I have a problem when I am trying to create internal link to a node with different language using it's path. For example if I am in a node which language is finnish and type to the link field path "example-node", which would be a node in english, I would assume that it will create a link to a node which path alias is "example-node". Instead it will create the link with the current nodes language prefix "fi/example-node".
I understand this is propably more of a problem with the i18n and how it adds the prefix but I was able to create the link correctly when I manually set the language of link in the url() function which is used in the _link_sanitize function. So I'm wondering if it could be possible to get the language of the node where the internal link leads to and use it to form the link correctly. This is also propably the cause for the failing validation of multilingual links which atleast I have run into since the language of the linked node does not seem to be used for the drupal_lookup_path.

The patch works for me. I had a small review issue; the test contains

global $base_url, $base_path;

but these globals are never used. Attached is an updated version of the patch with this line removed. If somebody could verify this is a valid change, RTBC has my vote.

Hi,
I don't think this patch works in all of the cases.
Having a property getter in some cases creates an invalid url. The first part to avoid multiple sanitisation looks good, but the property getter is not called every time, and this leads to links without language prefixes (url function is not called on raw value if property getter is not called.)

Why did you modify that part? I think we should delete that part and keep only the _sanitize property checking.

Here is a patch without the getter.
Works fine for us on relative URLs, without the patch we get double language prefixes.

this one works great

added patch

added patch

#26 works fine

Patch #14 works well for me.

The Patch #22 and #26 seem to add extra coding standard fixes which are not necessary to address this issue. So I'd like to reroll the patch #19 with the added tests in the patch #17.

There will be a lot of failed tests but I'm not sure they're related to this change.

FYI, subjective function _link_sanitize() is going to be fixed in other issues and we'll need to update the patch after other patches are committed.

#2707887: Sanitize function changes url

Patch in #31 works for me on 7.x-1.4, thanks! (We were up to THREE language prefixes.)

Patch in #31 works for me too! Before the patch I also had up to three language prefixes.

Failed tests must be resolved with a patch in #2843813: Fix failing tests due to missing 'administer fields' permission.

The automated tests are passing again. Setting status back to 'Needs review.

Patch in #31 works for me too!
link:7.x-1.4
drupal: 7.55

Re-rolled against link 1.5.

Can we have some more feedback on #38? Thanks for all the hard work on this over the time but it is related to another fixed link issue which has maybe caused this issue and has some akward shadow reports. I would like to prevent chain patching if this breaks. Would love to RTBC it and commit it after some more successful feedback since it is open for so long already. And we need a re-roll against latest dev...

#38 works fine for me.

+1

Works good for me.

How could it happen this fix is not in 7.x-1.6?

Link 1.6 is effectively a hotfix on top of 1.5; it doesn't contain any of the work in the dev branch added since 1.5. So some of us could do with a re-rolled version!

Link 1.6 is effectively a hotfix on top of 1.5; it doesn't contain any of the work in the dev branch added since 1.5. So some of us could do with a re-rolled version!

However, you could try just applying the patch of the security fix for 1.6. For example, this drush make snippet:

projects[link][subdir] = "contrib"
projects[link][version] = "1.5"
projects[link][patch][] = "https://cgit.drupalcode.org/link/patch/?id=a1870f1efcd2a0c170243fe0fcc12..."
projects[link][patch][] = "https://cgit.drupalcode.org/link/patch/?id=610ff54b37f5dd1314e1c560ad1f2..."

@james.williams, thanks for your clarification!
But I don't see how https://cgit.drupalcode.org/link/patch/?id=610ff54b37f5dd1314e1c560ad1f2... is linked to this issue?
I only needed https://cgit.drupalcode.org/link/patch/?id=a1870f1efcd2a0c170243fe0fcc12...

https://cgit.drupalcode.org/link/patch/?id=610ff54b37f5dd1314e1c560ad1f2... is the security fix that was added in 1.6... so you do want it! :-) Perhaps this is clearer:

projects[link][subdir] = "contrib"
projects[link][version] = "1.5"
; Add patch from https://www.drupal.org/project/link/issues/2428185 that is in the dev branch, but neither Link 1.5 nor 1.6.
projects[link][patch][] = "https://cgit.drupalcode.org/link/patch/?id=a1870f1efcd2a0c170243fe0fcc12c8a0b9a9e41"
; Add security fix (Link 1.6).
projects[link][patch][] = "https://cgit.drupalcode.org/link/patch/?id=610ff54b37f5dd1314e1c560ad1f29087e460108"

Ah, that explains. Sorry I looked over the Link module version number 1.5

My piece of make file goes like this.

projects[link][subdir] = "contrib"
projects[link][version] = "1.6"
projects[link][patch][] = "https://www.drupal.org/files/issues/2018-06-12/link-broken-relative-urls-with-language-prefix-2428185-38.patch"

So, version 1.6, which has the security patch included.

This issue seems to be introduced by #2428185: Language prefix and relative links broken