Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Linkit filter is stripping out the query string and the fragment from the URL.
Proposed resolution
Fix it.
Remaining tasks
None.
User interface changes
None.
API changes
New \Drupal\linkit\SubstitutionInterface::getUrl() signature:
/**
* Get the URL associated with a given entity.
*
* @param \Drupal\Core\Entity\EntityInterface $entity
* The entity to get a URL for.
* @param array $options
* (optional) See UrlGeneratorInterface::generateFromRoute() for the
* available options. Defaults to [].
*
* @return \Drupal\Core\GeneratedUrl
* A url to replace.
*
* @see \Drupal\Core\Routing\UrlGeneratorInterface::generateFromRoute()
*/
public function getUrl(EntityInterface $entity, $options = []);
Note that there's no BC break as the new parameter is optional.
Data model changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | 2895153-17.patch | 2.88 KB | idebr |
| #17 | 2895153-17-test-only.patch | 1.15 KB | idebr |
Comments
Comment #2
claudiu.cristeaPatch.
Comment #3
claudiu.cristeaComment #4
claudiu.cristeaThe previous patch incorrectly used
Url::fromUri(). Fix this and also the Media plugin can reuse code from File, so I extended Media from File.Comment #5
claudiu.cristeaIt seems that I misunderstood what this filter is doing. This filter transforms markup like:
into:
I would like to have this filter. But what about the case when the incoming markup has already set a
href="..."? In my specific case I have initial markup that contains also tags like:This is recreating the
hrefbut is ignoring totally the existinghref="..."and so I'm losing the query and the fragment. I see two options:href="...", if exists.Note that the new setting may refer only to preserve the query & fragment part of the incoming link.
I would like a maintainer input before improving the patch and writing tests.
Comment #6
John Pitcairn CreditAttribution: John Pitcairn commentedI posted a similar issue a few months ago, I will mark that as a duplicate of this.
Option 2 will not generate aliased paths, which is not very desirable.
I would favor option 1. Extract any existing query parameters and fragment, then add those to the generated URL.
Comment #7
anonI'm unable to save links with query and/or fragments through the GUI, how did you manage to do that? However, if I editor the source in the editor so the href have query and fragments I can see the problem.
For the first solution: where do we store the extracted info?
For the secound; If I understand it correct, that would generate alises, and then add the query and fragment parts from the original href. But do we need a new filter settings for this? Why not do it all the time?
Comment #8
anonComment #9
John Pitcairn CreditAttribution: John Pitcairn commentedThanks. I'm not editing source, just appending them to the path that is generated after selecting a target in the dialog, before clicking "save" in the dialog. They are preserved in the editor and on display but the path does not get aliased. The query works, but the fragment only works if Redirect is not used to redirect to aliased paths.
The query and fragment are preserved in the saved content for me, so that presumably would allow the filter to handle it? But if they are not preserved for you, um...
Indeed, why not? Presumably we could use Drupal's URL-parsing to split the path and reappend query and fragment.
This begs the question "what about extra arguments" like views args especially. If those can be parsed off and reappended after the alias is generated that would be pretty cool.
Comment #10
Jānis Bebrītis CreditAttribution: Jānis Bebrītis at Wunder commentedHaving the same issue, "/node/123?test=1#anchor" gets translated into "/somepath" instead of "/somepath?test=1#anchor".
I did not notice the existing patch, so I made a quick one for 5.0-beta5. Tried to change patch from #4 to work with both 5.0-beta5 and 5.0-beta6, but it did not work out, there are some rejects in it. Also, this did not fix my issue, so I'm posting mine.
Comment #11
bgilhome CreditAttribution: bgilhome commentedThanks Jānis - the patch just needed a slight reroll from current 5.x.dev, attached.
Comment #12
LendudeHere is a test for this, test-only file is also the interdiff to #11
Comment #14
LendudeIn order to get a proper workflow when working within the dialog, the
$href_dirty_checkcheck should not fail when you only add a fragment, so changed this to only check the URL.If we don't do this, you would need to select the right option from the autocomplete, then type in the fragment and then select the right option from the autocomplete again to get it to work.
Comment #16
LendudeDuh, left out half the patch
Comment #17
idebr CreditAttribution: idebr at iO commentedPosting a test-only patch to show the tests are working correctly. The full patch is unchanged.
Comment #19
idebr CreditAttribution: idebr at iO commentedThanks, the patch works as expected! Setting to RTBC.
Comment #20
larowlan+1 RTBC, manually tested this on a site and it works a charm 💎
Thanks!
Comment #21
attisan+1 works great
Comment #22
nortmas CreditAttribution: nortmas commentedWorks good, thank you!
Comment #23
jeremyr CreditAttribution: jeremyr commented+1 works for me too.
Comment #24
jeremyr CreditAttribution: jeremyr commentedIs there anything else needed here? Is someone able to commit this?
Comment #26
anon