Path alias filter by system path

Hello, I made a patch for this issue. It works fine, review this patch please.

Really? It's still not accepted?
Can smb take care about it?

I use this patch with several projects and it's awesome!
Why it is still not accepted?

@kala4ek It is great to hear the patch works for you. In order to move the issue along, someone must provide a peer review. Provide a detailed review and the maintainers will notice.

Also, I do not think this issue is "Major" priority according to the priority guide. It sounds like this is accurate:

Normal issues are those that are not Critical or Major; they have isolated impact and may have workarounds.

The workaround in this case is a database query. You may disagree with me. If so, make a case for why this is "Major", based on the guide.

Mark this task as Major.

This task providing a better UX for creating, editing & managing path aliases.
Because now - it's very hard to find alias which contains few slashes in path.

Shouldn't this go into 8.x first?

I might take a stab at a backport to D7

Woops, just realized it already is a D7 patch.

+1 for this functionality to be added to D7/D8

RTBC the D7 patch,
great work. This should definately be done in D8 as well if it hasn't already been done.

D8 needs work

Just confirmed that this functionality is also needed for D8 as well as D7.

Without this patch its really hard to find url aliases. Especially if you have 10000 pages with the string 'news' in it and you're searching for the one url alias for the 'news' page.

The only way to use the UI is if you know the system path to filter by that. This patch allows filtering by system path, so without it, you'd have to do a database query to find the url alias making the GUI pretty pointless. This patch adds a radio box option with the extra filter option, very helpful usability improvement for Drupal. I see no regression with the D7 patch, it works like a dream. D8 also needs it.

Uploading initial patch for D8

Hello,
@mohit_aghera seems your patch is not working.
I`ve fixed it, for me it works ok.
Thanks.

Couple of corrections about translations:
* Use $this->t() for translation within buildForm().
* Seems, by default translation for 'Path alias' string in buildForm() is missed.
* Better to set up a default value for filter type (e.g. 'alias').

Hello,
@IRuslan, thank you for your review,
I`ve attached the patch with corrections.

Tested on 8.3.x and 8.2.6
Works well for me.

Rerolled & removed some coding standard issues from last patch.

+++ b/core/modules/path/src/Form/PathFilterForm.php
@@ -20,17 +20,30 @@ public function getFormId() {
+    $filter_type = array(
+      'alias' => $this->t('Alias'),
+      'source' => $this->t('Source'),
+    );
+    $form['basic']['type'] = array(
+      '#type' => 'radios',
+      '#options' => $filter_type,
+      '#title' => $this->t('Choose your filter'),
+      '#title_display' => 'invisible',
+      '#default_value' => !empty($type) ? $type : 'alias',
+      '#maxlength' => 128,
+      '#size' => 25,
+    );

@@ -55,7 +68,10 @@ public function buildForm(array $form, FormStateInterface $form_state, $keys = N
+      'query' => array(
+        'search' => trim($form_state->getValue('filter')),
+        'type' => trim($form_state->getValue('type')),
+      ),

use short array syntax (new coding standard).

A little clean up for Form API.

Works for me ok on 8.4.x.

Re-roll for #33

@kala4ek What's the idea behind the limit of 50?

Tx, works like a charm! If I just had found this patch earlier :)

I have tested the patch mentioned in comment #33 and it is working as expected.
Looks like RTBC. PFA screenshots before and after applying the patch.

someone should reroll the patch, removing the limit of 50
as per comment #37

Re-roll the patch, removing the limit of 50 as per comment #37.

I think this could use a review by the usability team. Luckily this already has before/after screenshots that are available in the file list in the issue summary, so hopefully that's enough for someone from the usability team to make a call on this.

Only thing that's may be confusing is if its's radio button then either one them should mandatory. No? When you arrive at the alias page, there's nothing selected. Does that mean it searches from both source and alias?

When none of them is selected, it searches from Alias.
I agree with @hkirsman, one of the field should be selected by default. I would suggest, we should select Alias by default.
I would suggest changing the name of Source to Alias would be more meaningful.
Changing the status to Needs Work.

There is updated patch regarding #44, #45 comments.

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

RTBC+ patch #1 for D7

patching file core/modules/path/src/Form/PathFilterForm.php
Hunk #1 FAILED at 20.
Hunk #2 succeeded at 67 (offset 2 lines).

This needs a reroll.

@kala4ek could you address the concerns in #47?

Reroll path from #46 with renaming "Source" to "System".

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

Missed this part, will update patch soon.

Ho guys! Attached patch where we can search by both (alias and source). Type removed. Please review

Interdiff 54 with previous 52

Updated for 8.6.x

Just set "Needs review" again, because of failed tests caused by interdiff file.

Attached new patch with correct tests, interdiff with patch #52

Corrected interdiff

Allows searching by either system path or alias and one field. I like it:)

+++ b/core/lib/Drupal/Core/Path/AliasStorage.php
diff --git a/core/lib/Drupal/Core/Path/AliasStorageInterface.php b/core/lib/Drupal/Core/Path/AliasStorageInterface.php
index 398ce07..525a96b 100644

index 398ce07..525a96b 100644
--- a/core/lib/Drupal/Core/Path/AliasStorageInterface.php

--- a/core/lib/Drupal/Core/Path/AliasStorageInterface.php
+++ b/core/lib/Drupal/Core/Path/AliasStorageInterface.php

+++ b/core/lib/Drupal/Core/Path/AliasStorageInterface.php
+++ b/core/lib/Drupal/Core/Path/AliasStorageInterface.php
@@ -141,7 +141,7 @@ public function aliasExists($alias, $langcode, $source = NULL);

@@ -141,7 +141,7 @@ public function aliasExists($alias, $langcode, $source = NULL);
   public function languageAliasExists();
 
   /**
-   * Loads aliases for admin listing.
+   * Loads paths for admin listing.
    *
    * @param array $header
    *   Table header.
@@ -152,7 +152,7 @@ public function languageAliasExists();

@@ -152,7 +152,7 @@ public function languageAliasExists();
    * @return array
    *   Array of items to be displayed on the current page.
    */
-  public function getAliasesForAdminListing($header, $keys = NULL);
+  public function getPathsForAdminListing($header, $keys = NULL);
 

Since there's an interface here, we should duplicate the method and deprecate rather than the direct rename.

This actually seems like an interface that has fully customized implementations, so while it is currently not explicitly tagged as @api or so, it would still likely break custom implementations that store aliases in Redis/MongoDB or so.

Would it be acceptable to just include the condition and leave the names as "Aliases"?

Sorry I didn't see the API change on my review, only the functionality.

I think that marking the existing method as "deprecated" is better than just updating it.
Here are new patch and interdiff from #62.

Reroll of #69.

patch 75 for D8 doesn't seem to do anything, not sure why, it applies cleanly though

the D7 patch works perfectly as advertised

ok patch 75 actually seems to work but it isn't as good as the D7 patch
with the D7 patch it is possible to specify which filter to use but the D8 patch 75 does either or in the same input box.

Is this a duplicate of #2039709: Forward slash in filter aliases in url alias overview doesn't work or are both fixes needed for Drupal 7?

I can't apply patch#75 for drupal 9.3.x-dev.getting error while applying the patch

The D7 patch is still good, but the Symfony patch needs a major reroll, I looked at rerolling it but everything moved around and was changed since 8.9.x. Someone else maybe will get to it before I do.

A related issue, which also improves the user experience, is #2732315: Add ID column to URL aliases admin page UI table, in case it makes sense to take care of both issues at the same time.

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 and system paths by default and not expose a UI for it? You could then sort on "system" to group system paths and aliases

Easy to answer why not, when there's over 10,000 aliases your results get lost. A filter option at the offset is easier to understand than a sort on system.

The UI improvement as-is is good. make the label changes you want but I still want a filter option. My clients sites have 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" , "contains", "starts with" and "ends with".

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 and counting

Usability review

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

For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @BlackBamboo, @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.