Support for wildcards

@ricardofaria thanks for #114 it's working for my conditions:
/recipe/* -> /recipes/*

With one file rejected:

--- src/RedirectRepository.php
+++ src/RedirectRepository.php
@@ -188,7 +243,6 @@ class RedirectRepository {
    */
   public function findBySourcePath($source_path) {
     $ids = $this->manager->getStorage('redirect')->getQuery()
-      ->accessCheck(TRUE)
       ->condition('redirect_source.path', $source_path, 'LIKE')
       ->execute();
     return $this->manager->getStorage('redirect')->loadMultiple($ids);
@@ -206,7 +260,6 @@ class RedirectRepository {
   public function findByDestinationUri(array $destination_uri) {
     $storage = $this->manager->getStorage('redirect');
     $ids = $storage->getQuery()
-      ->accessCheck(TRUE)
       ->condition('redirect_redirect.uri', $destination_uri, 'IN')
       ->execute();
     return $storage->loadMultiple($ids);

but worked in redirect 1.7.

It's rejected because code is:

  public function findBySourcePath($source_path) {
    $ids = $this->manager->getStorage('redirect')->getQuery()
      ->accessCheck(TRUE)
      ->condition('redirect_source.path', $source_path, 'LIKE')
      ->execute();
    return $this->manager->getStorage('redirect')->loadMultiple($ids);
  }

@vidorado there's an undefined variable $query in your patch in #104 ✨ Support for wildcards Needs work - line 165 of RedirectRepository.php.

#114 is working for me in Drupal 9.5.10.

I could redirect /properties-location/* to /properties/* while leaving /properties-location untouched.

Patch broke on latest release of redirect so here is an updated patch (same as #114, applied to latest version of redirect).

Tested patch from #120 with core 10.1.5 and redirect 1.9.
With a "From" /foo/bar/* no redirect occurred from either /foo/bar/baz nor /foo/bar/baz/bing. Was hoping for something similar to #119, using a "To" of /foo/bar. Looks like that creates a redirect loop, according to the logs, which isn't surprising, but incompatible with my use case.
I also note however, that editing the "To" to /foo didn't result in any redirects either, which is surprising.
I can't say that this patch works at all.

Sure, patch #114 broke on the latest release and #120 applied successfully.

@sidgrafix: it doesn't appear your patch is a simple reroll ("the same as #114, applied to latest version"). There are a number of material differences. Are the other changes intentional (to get this working) or an accident?

Here is #114 rerolled for the current 8.x-1.x, with the one rejected hunk fixed, (plus a diff of these two patches for verification).

Leaving this as Needs Work, as @azinck's recommendations in #106 are still not addressed.

@jeffschuler - All I did was reroll patch from comment 114 listed as support-for-wildcard-2831605-113.patch (if you compare that to mine they are identicle.

Per "ricardofaria" post 114 he said "Created a patch with a little difference from the previous one. Will need to review this later, but for now its working for me."

- Any changes you mention (if they diverged from the patch prior to support-for-wildcard-2831605-113.patch) were done there in support-for-wildcard-2831605-113.patch before I rerolled.. I assumed that patch was the previous current working if it is not "my bad", apologies for any confusion. Tho the patch has been working fine for me!

@sidgrafix your patch in #120 and the patch in #114 are not identical.

For example, the patch in #114 has this change:

-    $this->assertSession()->statusCodeEquals(404);
+    $this->assertResponse(404, 'Deleted redirect properly clears the internal page cache.');

while your patch does not.

The #114 patch removes this line:

-    $this->assertSession()->pageTextContains('No URL redirects available.');

but yours doesn't:

     $this->assertSession()->pageTextContains('No URL redirects available.');

The #114 patch calls drupalPostForm:

+    $this->drupalPostForm('node/' . $node->id() . '/edit', ['path[0][alias]' => '/node_test_alias_updated'], t('Save'));

and yours calls drupalPostFormForm:

+    $this->drupalPostFormForm('node/' . $node->id() . '/edit', ['path[0][alias]' => '/node_test_alias_updated'], t('Save'));

...

@jeffschuler - I honestly not entirely sure being 5 months ago, there is a chance I patched a non-dev version then by accident and the slight differences in the lines you mention would have been changed in accordance with whatever version of redirect I was patching.

Looking at the composer.json for the site I used patch 120 on I patched redirect 8.x-1.9 (which was for a D9.5 sight, since updated to 10.2.2) again apologies for any confusion this may have caused..

No prob; just want to see this issue continue forward!

I can confirm what Azinck says in #106

Another test that really should be added is to test the interaction with paths that have similarities to the redirected path. For instance, patch 101 introduced a significant bug with this code: $rule->pattern = mb_strtolower(str_replace('/*', '*', $rule->pattern)); -- that causes redirect loops if you create a redirect like:
/foo/* => /foobar/*
That's due to the fact that /foo/* pattern is now really being interpreted as /foo*...which is just not correct. But the tests didn't catch that error.

A redirect /r/* has become /r* which is a CRITICAL bug

The patch from #123 has the problematic line commented:
// $rule->pattern = mb_strtolower(str_replace('/*', '*', $rule->pattern));

And now that bug has gone.

Anybody remembers what was the purpose of that str_replace()? It does not make sense for me right now...

Patch #123 was broken for us in Drupal 10.2.5 as it was removing the now required accessCheck(TRUE) calls from RedirectRepository class.

My patch just adds those two lines of code back.

The patch in #129 commented the line

// $rule->pattern = mb_strtolower(str_replace('/*', '*', $rule->pattern));

And two thing where stripped out:

- The replacing of '/*' to '*'.
- But ALSO making the rule case insensitive.

I attach a new patch to restore the latter.

We noticed a performance impact on our project due to this patch (the query took often 300-500ms) and decided to remove it.
As a safety (in case it ever gets merged) I converted the patch from #130 into an MR and added a config option to enable wildcard support.

I did not update any tests, these might still need changes.

I've not been able to test yet, but I was wondering what this patch/MR would do if there are these wildcard redirects:

a-path/* -> redirect1.com
a-path/b-path/* -> redirect2.com

and you would navigate to a-path/b-path/c-path, which redirect would it use?

@Jelle_S It will select the second one, as it is the more specific one (determined by being the longer string)

I can't update the MR on the GitLab so here's a new version with resolved merge conflict.

@chizh273 If you click on the green button "Get push access" above, you should be able to update the MR. Anyway, @vidorado dit it.

Thanks for the review @gaelg! It is very useful to polish the feature.

I will get into it tomorrow 😊

I've made some changes to address the issues identified by @gaelg, but I can't resolve the threads on git.drupalcode.org; I don't see any button to do so...

I think only the creator of the MR, the person who started the thread or the maintainers of the module can mark threads as resolved.

Thank you for the work @vidorado! I cannot resolve threads either. @Matthijs?

@vidorado @gaëlg I resolved them all.

Thanks for update MR, please check my feedback.

Tests added! :)

Thanks for the review @nikolay

Thanks for removing all unrelated changes, and MR update.
It's much easier to review now.
I left my feedback.
But it would be great someone else also check MR.

I’ve created a patch based on the latest version of merge request !97, introducing a few adjustments to ensure that redirect patterns are matched against URL aliases rather than just internal paths like /node/[nid]. This change supports a specific client requirement where redirects should be defined using node aliases, e.g., example-node-alias/*.

We should review this patch to verify its compatibility across different use cases and evaluate its potential impact on performance.

I tried MR97. I added as a patch, ran composer and so forth. I tried doing something like this:

From: /county-news/*
To: /news/*

It is not working for me. Is this the correct usage of a wildcard?

I found something interesting, however.

It appears that whatever the wildcard represents cannot contain at least a hyphen (-). For example,

If I do this...
From: /depts/voting-and-elections/polling-places/*
To: /county-clerk/voting-and-elections/where-to-vote

This string won't work...
/depts/voting-and-elections/polling-places/precinct-2

But this one will
/depts/voting-and-elections/polling-places/2025 (no hyphen in the wildcard string)

Is this a known issue or something that won't be resolvable? Of course, it would need to be verified. I'm concerned that anything having any valid URL punctuation like hypen - or / backward slash will not be resolvable using wildcards.

Attaching patch from merge request 97.

@ruslan - thank you for the patch. It applied to v1.12, but the wildcards are no longer working. I've verified that the "Enable wildcard support" checkbox is enabled and have cleared the caches, but wildcard paths are now ignored (were working on 1.11 with the previous patch). Do you have any ideas on where the issue might be?