Path alias filter by system path

This patch works perfectly in D7, the D10/D11 version of this patch should be re-written using the D7 patch improvement behavior as a guide on what should be done for D10/D11.

Since patch #75 no longer applies, and when it did apply it was inferior to the D7 patch, please refer to the D7 patch for how this should behave.

The D7 patch needed a reroll . →

Here's a screenshot of how it looks like in D7, this behavior is what the D11 patch should try to achieve:

Simple and working patch for 9.5.x.
Added new separate filters by system path and language.
No test were changed or added, feel free to add, like during last 8 years :)

Thanks @kala4ek

patch #91 also applies cleanly with only a little bit of fuzz against the 11.x branch.

The test for this needs to be updated to cover the two filtering options. Then provide a tests only patch and we can compare the results with the whole solution. Tests only changes should fail and then with everything is including the test changes the pipeline should pass 100%.

- Fixed the test case failures in the patch.
- Added new test case to filter the system path.
- Hiding all the patches except images for further confusion since we are following MR approach now.

@joseph.olstad:
Regarding test-only patch.
I feel it might not need because we are adding new option to filter form.
Since filter form element isn't available on the 11.x branch, it will always fail.
In that case, can we skip adding `test-only.patch`?

- Hiding all the patches except images for further confusion since we are following MR approach now.

It's a wrong approach, patches still needed, at least to be able to use it in ongoing projects with composer.

@kala4ek,
hiding the patches from the issue doesn't prevent them from being used with Composer.

With that said, the Merge Request also offers a patch.

Here it is:
https://git.drupalcode.org/project/drupal/-/merge_requests/6444.patch

If you navigate to the merge request, click the blue code button, the patch link is down below.

@mohit_aghera , great work on the tests, thank you.

I don't think this functionality needs a change request but perhaps a core maintainer would ask for one. Not sure on the procedure here for that. With that said, the MR is ready and is passing tests.

Also great work @kala4ek on the functionality for 11.x

@kala4ek Here are some information about the transition from patches to MR: #3412417: Disable DrupalCI testing → , including a possibility to link to static MR diffs (but this needs to be implemented in Gitlab). However linking patches from 3rd party sites is not recommended and you should download a separate copy of the patch locally.

The code and tests both look fine, but this needs a screenshot of the functionality - the only screenshot is from Drupal 7 with a different implementation.

Added screenshots.

The 'not specified' on the language filter looks a bit confusing especially with no label. I didn't think this needed usability review with just the system path filter, but with that change it probably does. Moving back to CNR for that.

rkoller brought up a good point but the comment in #47 doesn't appear to be answers

I agree this is not a super useful filter as it is now.

But I don't think it's very clear "source" and "alias" mean. In the table header it says "System" instead of "source", should these not use the same label?

Why not search both aliases and system paths by default and not expose a UI for it? You could then sort on "system" to group system paths and aliases

why not search both aliases?

Easy to answer why not, when there's over 10,000 aliases your results get lost.

The UI improvement as-is is good. make the label changes you want but I still want a filter option. our site has over 10,000 aliases I don't want to be paging through results to find what I'm looking for.

I say go with a simple improvement as proposed now and then later on make a new ticket to add exposed filter options such as "exact match" instead of starts with or contains.

It's already been 9 years to get this far. Lets make a small improvement as proposed, make the label change as you want and move forward.

Can it be better? Yes, it can always be better.
Is what we've done an improvement? Yes

9 years already , let's stay on target and at least make the small improvement this decade.

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-03-29 Needs work . The recording can be found at: https://www.youtube.com/watch?v=1xmloMqjaw0.

For the record, the attendees at the usability meeting were @AaronMcHale, @BlackBamboo, @benjifisher, @rkoller, and @shaal.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

There was a general consensus around the group having separate filters on the URL aliases page is a good and useful thing, since there are particular cases where it is useful being able to restrict and target the search for one particular column. So this feature is a definite improvement to the current state. We've found a few noteworthy details:

• The terminology is inconsistent on the page. h1 and page title use URL aliases, the help text and field set label alias, the place holder path alias, and the table column header again alias. Changing the h1 would entail potentially many changes to the docs. Therefore the idea was simply to adjust the term used for the placeholder (path alias) and change it to alias. That way the usage of the term alias on the page for the help text, field set label, placeholder and column header is consistent and could also be considered as the shorthand of the overall title URL alias used in the h1 and page title.
• In a similar vein, there is also an inconsistency for the path terminology. A detail we've missed during the meeting and I've noticed while writing up the comment. The help text is using the term URL path while the placeholder and column header is using the term system path. In the subsequent discussion on Slack there was a clear consensus between @benjifisher and me that this should ideally be consistent. But which of the two would be the better choice we were uncertain about - it would have to be further discussed and tested. It also has to be added that both terms URL path and system path are both used more or less equally across Drupal Core. One detail in favor of URL path, URL path and URL alias would be a consistent pattern for both of them and URL provides the overall context. But still the recommendation is to move the discussion to a mandatory follow up issue.
• The group agreed to the concern raised in #103 → . On the instance we've tested and discussed the issue on I've created a few nodes and corresponding path aliases with no multilingual modules installed. After installing a second language aside English the language column showed none for all those already existing URL aliases, and the select field with the default option - Not specified - mentioned by @catch showed up.
  If technically possible the group agreed recommending removing the placeholder text and use labels for the two input fields as well as the select field instead. That way the context would be at least easier to grasp for the default option of the select field.
• In regards of the options - Not specified - and - Not applicable - the meaning of those options was not clear to the group. At first we thought none applicable would equal to nodes with language none but turned out it resulted in no results at all. Same if you add a string to the url alias field or system path containing strings used on one of the language none nodes. Somehow you get no result at all for - not applicable -. But since the two terms are not only used for the URL aliases filter and that ambiguity also applies to other pages and contexts, we've agreed to create a follow up issue to discuss that micro copy problem more holistically and make those two options more comprehensible in regards of function and meaning.
• Speaking of the more holistic context, if you compare the filter options on for example admin/content with the options available on the URL aliases page you also notice for one that the filters on the content page also have an - Anything - option and those not specified and not applicable options don't come along with dashes but - Any - is. And on the other hand the content page is using labels for fields and select fields.
  Taking a look at the MR @benjifisher noted that the select field is using a standard form element while the filter on admin/content is a View. So we wondered if it would make sense ensuring a consistent population of the select field alongside other detail on the page if it would be make sense to make the URL aliases page also a View? But completely out of the scope for this issue, but in case others on this issue agree to open up a follow up issue.
• During the testing we've also noticed one odd misbehavior of the reset button. If you try the following:
  1. Add a term to filter for in the alias field
  2. Press the filter button
  3. Clear the field with the inline clear button
  4. Press the filter button

  problem: all URL aliases are shown but so is the reset button that remains shown, but it should be hidden instead.