Convert the path alias admin overview to a list builder

#2336597: Convert path aliases to full featured entities is in.

1. +++ /dev/null
   @@ -1,16 +0,0 @@
   -path.admin_overview_filter:
   
   +++ b/core/modules/path/src/PathAliasListBuilder.php
   @@ -0,0 +1,194 @@
   +   */
   +  protected function getEntityIds() {
   +    $query = $this->getStorage()->getQuery();
   +
   +    $search = $this->currentRequest->query->get('search');
   +    if ($search) {
   +      $query->condition('alias', $search, 'CONTAINS');
   +    }
   +
   +    // Only add the pager if a limit is specified.
   +    if ($this->limit) {
   +      $query->pager($this->limit);
   +    }
   +
   +    // Allow the entity query to sort using the table header.
   +    $header = $this->buildHeader();
   

   Interesting, so we're going to keep the custom exposed filters instead of replacing it with a view.

   Specific reason for that or was it just easier to keep that working instead of adding views and upgrade path for it?

2. +++ b/core/modules/path/src/PathAliasListBuilder.php
   @@ -0,0 +1,194 @@
   +    $build['path_admin_filter_form'] = $this->formBuilder->getForm('Drupal\path\Form\PathFilterForm', $keys);
   

   Could use PathFilterForm::class.

3. +++ b/core/modules/path/src/PathAliasListBuilder.php
   @@ -0,0 +1,194 @@
   +
   +    // Enable language column and filter if multiple languages are added.
   +    if ($this->languageManager->isMultilingual()) {
   +      $header['language_name'] = [
   +        'data' => $this->t('Language'),
   +        'field' => 'langcode',
   +        'specifier' => 'langcode',
   +        'class' => [RESPONSIVE_PRIORITY_MEDIUM],
   +      ];
   +    }
   

   And we even have a feature here that still doesn't work in views. I guess that was another argument for keeping it hardcoded?

4. +++ b/core/modules/path/src/PathAliasListBuilder.php
   @@ -0,0 +1,194 @@
   +
   +    // If the system path maps to a different URL alias, highlight this table
   +    // row to let the user know of old aliases.
   +    if ($alias != $this->aliasManager->getAliasByPath($path, $langcode)) {
   +      $row['class'] = ['warning'];
   

   I never even knew that feature existed, doesn't seem very intuitive :)

This looks ready as well, given that testbot agrees.

We're not actually saving any LOC here according to the diffstatt, also because the path alias list has a few special features that we keep, but it removes important usages of AliasStorage methods that we need to remove to be able to deprecate that properly.

It is a bit uncommon to have exposed filters and sorting in a list builder, but adding views integration, specifically for some of the extra features (see #16), would be a lot more work.

Looks great, just a couple of non-blocking nits!

However, the change in the page title introduced a visual inconsistency that might affect UX:

I'll ask Angie or Gábor about this.

1. +++ b/core/modules/path/src/PathAliasListBuilder.php
   @@ -0,0 +1,195 @@
   +  public function __construct(EntityTypeInterface $entity_type, EntityStorageInterface $storage, RequestStack $request_stack, FormBuilderInterface $form_builder, LanguageManagerInterface $language_manager, AliasManagerInterface $alias_manager) {
   ...
   +    $this->currentRequest = $request_stack->getCurrentRequest();
   ...
   +      $container->get('request_stack'),
   

   Would it make sense to inject the current request directly?

2. +++ b/core/modules/path/src/PathAliasListBuilder.php
   @@ -0,0 +1,195 @@
   +    $build = $build + parent::render();
   

   += :)

Just spoke with Gábor about this: the inconsistency should be fixed before this lands. We should probably change all user facing labels to "URL alias(es)" to keep the current UX. It may be worth doing that in a separate issue, since that wouldn't be specifically about this page, but not feeling strongly about this.

Just spoke with @Berdir: I meant that we should change the entity type definition user-facing labels, nothing else. Sorry for the confusion.

Looks great, thanks! I will wait for the testbot and then commit, unless someone beats me to it ;)

Committed 55a2b40 and pushed to 9.0.x and friends. Thanks!

Let's not forget to update the relevant CRs :)