Remove truncation of path alias

I posted a PR.

Uploaded a patch file in case anyone needs an immutable version.

The last submitted patch, 4: 3351638-4.patch, failed testing. View results →

I am working on fixing the test failures.

I did some digging into the history and found that this truncation came from this issue https://www.drupal.org/project/drupal/issues/86461 📌 Truncate long paths and path aliases on admin/build/path Fixed which arbitrarily picked 50 characters for the truncation by the first person attempting to patch it.

There was no discussion as to how useless this would render the UI and no discussion of alternative like CSS to solve the problem instead of hiding the relevant data completely. The issue itself did suggest truncation OR wrapping but it was never discussed and truncation was the first patch that came in.

This patch adjust the test to not look for truncation.

I tested this, and it's working in my environment.

Can see the problem with not being able to see the URLs

I don't think it should be an issue to remove.

Updated IS with the solution that was chosen.

Thank you @skywriter and @smustgrave

Just to be sure that this patch does not make a breaking change, I created a 255 char long alias. It displays just fine in the list of aliases

So with some git archaeology 🤠 I traced this back to 📌 Truncate long paths and path aliases on admin/build/path Fixed - yes a 5 digit NID from 11 years ago where we made this change intentionally.

So now we're directly reversing that.

The motivation given there was 'it looks bad and can break template layout'

I think we should put this to the usability team to decide if the decision we made 11 years ago was the wrong one or not.

Crediting myself as the git archaeology required going back to before we even had controllers.

Thanks @larowlan. Glad to see you came to the same archeological roots that I called out in comment #6.

That issue made a lot of reference to the method of truncation and what tests were needed, but little was done to address concerns like

@David_Rothstein : but can someone clarify why we are choosing 50 characters as the number to truncate at? That seems like an awfully small number.

That went unanswered and the 50 count just came from the original patch in the thread.
Until @Poker_10 commented a decade later

3. Reopen this for D9 to change the truncated length from 50 characters to another number

The problem is, the purpose of the Alias UI is to help you manage aliases. By truncating them to any level, we get in the way that purpose. In its current state, managing the aliases is like a child's game of memory.

Which of the 27 aliases that all look identical is the one I really want?
Click.
Not that one.
Click.
Not that one either.
Click.
Nope.
{frustration builds}
Click.
Yay, I finally found the right one.

The way I read the thread of the original issue, the usability of the page was never considered, or at least not discussed. We took a usable interface and made it less useful but slightly more pretty.

I also think there are Accessibility concerns introduced in the original issue too because the link title was made the same as the next column (the system path). So anyone using screen readers is presented with not enough information (due to the truncation) and they also get to hear the system path read twice back to back.

Listen to it with a screen reader, it is annoying.

That is not to say that this issue does not need usability review. I agree that it does and by essentially rolling back #86461 we are undoing the usability review that was never done on that issue.

Interesting to see that the original issue 📌 Truncate long paths and path aliases on admin/build/path Fixed was started in 2006, before the iPhone was released. The goal at the time was "When working with small-width templates, the long paths can destroy the nice look/layout of the template." Thanks for doing the research on this @swirt & @larowlan.

This does look like an accessibility problem currently. I haven't looked at the source code of this in a long time, however taking away the truncation and providing the whole link should resolve the accessibility problems with these links.

Sample html without truncation

<td><a href="/2021-post-911-gi-bill-chapter-33-rates" title="/node/39676">/2021-post-911-gi-bill-chapter-33-rates</a></td>
<td><a href="/2021-post-911-gi-bill-chapter-33-rates" title="/node/39676">/node/39676</a></td>

+1 for removing the title attribute that was added for the purpose of showing the full path. Titles are best suited for situations where link text isn't available. In this case, the full text should be linked, making the title attribute redundant (and possibly noisy for screen readers).

Based on what maggiewachs has identified, it sounds like we should be doing this

<td><a href="/2021-post-911-gi-bill-chapter-33-rates">/2021-post-911-gi-bill-chapter-33-rates</a></td>
<td><a href="/node/39676">/node/39676</a></td>

This includes:

1. Removing the title attributes from both alias link and system path link.
2. Making the system href use the system path rather than the alias.*

* Yes this system path should lead to the alias version via a rewrite but sometimes there are redirects that interfere so this allows testing that in the UI.

Here is an immutable patch file from the PR.

Proof of life

 <tr class="odd">
                      <td><a href="/2021-post-911-gi-bill-chapter-33-rates">/2021-post-911-gi-bill-chapter-33-rates</a></td>
                      <td><a href="/node/39676">/node/39676</a></td>
                      <td class="priority-medium">English</td>
                      <td>  <div class="dropbutton-wrapper"><div class="dropbutton-widget"> ... removed from this paste ... </div></div></td>
                  </tr>

Example of untruncated output.

And here is the same output on a much narrower screen

Removing my credit because I missed the comment in #6

@swirt could you reformat your link using the [#nid] format so it gets updated to emit the title?

Sounds like we have broad buy in here, next step is to visit the #ux channel in Slack and put this in the bot generated agenda reminder so the kind folks there can look at it in their next meeting. Before doing so, making sure we have before and after shots in the issue summary

Moving to 10.1.x as we don't commit tasks to 9.5.x

If you could make the argument that this is a bug it would be eligible to backport

Thanks @larowlan.

Crediting @larawlan because he gave great guidance on how to move this along. ;)

Added before and after screen caps to original.

Posted in the #UX channel.

I would call it a "Bug" because the Alias UI is intended to make make it possible to manage aliases effectively, and when we can't see the alias variations in a meaningful way, it prevents me from doing what I need to do.

swirt → closed merge request !3776

This was presented at the 📌 Drupal Usability Meeting 2023-04-07 Fixed

Discussion on the call touched on whether this was fixing a bug, or just an improvement.
There was agreement that it borders on these bug criteria

• Incorrect or misleading user interface text. - This is considered because the system path link was href to the alias and not the system path.
• Usability issues that prevent people from using functionality (as if it didn't work at all). - Not fully useless as there is a workaround for sighted users by hovering over the truncated alias and have the browser surface the actual destination.
• Accessibility issues that prevent people from using functionality (as if it didn't work at all) - screen readers would not reveal the destination of the url so non-sighted users could not detect the actual alias by hovering over the truncated link.

Changing to a bug per #34

Sounds like from the UX meeting there is nothing that needs to be fixed. Think this is good for committer review.

I just tested the patch in our PR environment. The URLs are no longer truncated and are thus visually distinguishable from each other.

Thank you both for reviewing and testing.

+++ b/core/modules/path/src/PathAliasListBuilder.php
@@ -170,10 +170,13 @@ public function buildRow(EntityInterface $entity) {
+    // We want the unaliased system path.
+    $system_url = Url::fromUri("base:{$path}");
     $row['data']['path']['data'] = [
       '#type' => 'link',
       '#title' => $path,
-      '#url' => $path,
+      '#url' => $system_url,

Why was this change needed?

There were two reasons for this.
1. Having two visually different links that were the same links in adjacent columns was misleading especially to visually impaired since the links sound like different urls but are in fact the same. (An accessibility concern)

2. There are time when a system link does not end up resolving to it's alias due to a redirect or some other rewiring. This allows the ability to verify where the actual system link resolves

Should we move those changes to a different issue to have a separate discussion?

@larowlan That aspect was discussed specifically on the Drupal Usability Meeting

Incorrect or misleading user interface text. - This is considered because the system path link was href to the alias and not the system path.

It received positive review from all in attendance. I tried to reference the meeting transcript or the recording but they have not been added yet #3350284

My vote would be not to separate it out as then this UI will still have have a significant accessibility issue.

Ok, I'll wait for the recording and watch that - thanks

Trying for a better title.

@larowlan Seems like the Drupal Usability Meeting recording was published today.

Due to the scope expansion that @larowlan identified in #39, one of the following changes needs to happen for this to be committable:

1. Update the issue summary so the issue scope includes the additional changes as mentioned in #39. Much of this can probably repurpose the motivations explained in #42. Note that I personally would not commit this version as I feel they are unrelated issues that happen to be in close proximity. I'd also be fine if another committer was OK with the expanded scope.
2. Remove the changes pointed out in #39 and open a followup. This is my preference as it contains the issue scope so the commit-worthiness is clear and basically an unqualified improvement.

And I hope this additional process isn't too annoying. The rationale for the additional changes is good ones and I'd like to see those changes. The benefits to containing the scope of an issue are less immediate, but become more apparent later. For example, if accessibility concerns are brought up and someone demands a revert (this happens enough that it's example-worthy), we wind up losing the no-truncation benefit due to concerns that are unrelated to it.

Sounds good. I created #3362007 and will break up this patch into two patches.

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened → , as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

I updated the MR to remove the use of the actual system path. The system path is back the way it was, now only with the truncation removed.

Thanks for the flexibility @swirt, this looks ready to me.

For additional assurance this is a good idea, I messed with this at different widths and when the viewport is narrow enough to cause unwanted vertical scrolling, the experience really isn't improved with the truncation. Perhaps slightly less horizontal scrolling is needed, but it is still needed. That's a larger problem to be addressed in #3068696: Tables overflow on mobile →

Committed 9daaabe and pushed to 11.x. Thanks!

Leaving open for potential 10.1.x backport.

lauriii → closed merge request !3771

Decided to backport to 10.1.x with a +1 from @longwave.

Automatically closed - issue fixed for 2 weeks with no activity.