Filter by redirect destination does not work with URL alias

This patch is excellent. It would be great if we can get this rolled into a future release as it seems like something most folk will want.
We found that this patch only works for the main Redirect list view (id='redirect') that comes with the module.
So, when we created other Redirect views which had a different id, the patch did not work.
For example, we use the Group module and we wanted a Redirect (view) tab for our Group users alongside all their other tabs.
I have re-rolled the previous patch to change the following line from:
if ($view->id() == "redirect" && $view->getDisplay()->display['id'] == 'page_1') {
to:
if ($view->storage->get('base_table') == "redirect" && $view->getDisplay()->display['id'] == 'page_1') {

Hopefully this will be of help to others.

For some reason the patch did not generate correctly. I am re-uploading.

Third time lucky

Updating master patch to include the amended line.

Thanks for the changes marytbfly.

Our project has added a CSV export Display to this Redirect View, but since the if condition only allows a disply with the name 'page_1', our CSV export page never calls the _redirect_recursively_alter_query_conditions function. This means that the CSV display will never add the join to the path_alias table.

I think having the number of displays restricted to just 1 whose name is 'page_1' is too restrictive.
Is it reasonable to change the if statement inside the redirect_views_query_alter function to the following:
if ($view->storage->get('base_table') == "redirect") {

Please let me know your thoughts.

Thanks @tenden . I would not advice that, as I think the 'page_1' is there to ensure that the code only runs for a display_plugin of type 'page'. You wouldn't want this running for of display_plugin types such as Block.

It may be that your requirement is a little niche, so you could copy down the current patch (then edit it to your requirement), then reference it as a local patch file in your composer.json, rather than reference this patch.

If this patch ever gets merged into the main module code, you can then write a new local patch to add in your required logic, which would be easier to maintain.

Hope this helps.

Just another thought. I suppose if there was a way to check for the existence of a 'To' field on the view that has been 'Exposed to the User' for Filtering - this may also work, as the patch is always required by Redirect views that use the 'To' field for user-enabled filtering.

Just an idea.

Hello @martybfly

That change didn't work for me, but what about this:
if ($view->storage->get('base_table') == "redirect" && (str_starts_with($view->getDisplay()->display['id'], 'page_') || str_starts_with($view->getDisplay()->display['id'], 'data_export_'))) {

It restricts the display_plugin to just the 'page' and 'data_export' types.

Do you see any issues?

Hello @martybfly, the character encoding for lines 129 to 133 has issues. See below.

Patch 10 - lines 129 to 133
+ * "\t" (ASCII 9 (0x09)), tabulación.
+ * "\n" (ASCII 10 (0x0A)), salto de línea.
+ * "\r" (ASCII 13 (0x0D)), retorno de carro.
+ * "\0" (ASCII 0 (0x00)), el byte NUL.
+ * "\x0B" (ASCII 11 (0x0B)), tabulación vertical.

Correct characters - lines 129 to 133
+ * "\t" (ASCII 9 (0x09)), tabulación.
+ * "\n" (ASCII 10 (0x0A)), salto de línea.
+ * "\r" (ASCII 13 (0x0D)), retorno de carro.
+ * "\0" (ASCII 0 (0x00)), el byte NUL.
+ * "\x0B" (ASCII 11 (0x0B)), tabulación vertical.

Thanks @tenden . I think I have fixed the encoding issue, hopefully.

I would not recommend targeting specific plugins within the patch. That does not seem like the best way to go as the patch may need to be updated for every new plugin that gets created.

I am surprised my suggested logic did not work for you. Does the 'To' field filter widget not display for you when using the CSV plugin - is it not set?

Hello @martbfly,

The reason why it does not work for the data_export display is that $view->exposed_widgets is set to an empty array. Thus array_key_exists('redirect_redirect__uri', $view->exposed_widgets) returns false.
That does make sense because the data_export display is only outputting to a file rather than exposing any widgets.

What do you think about changing the if condition to the following:
if ($view->storage->get('base_table') == "redirect" && (isset($view->exposed_widgets)) {
This would ensure that $view->exposed_widgets is at least set even if it is empty.

As before, let me know your thoughts.

That may work but sounds risky to me as could introduce other issues for people. To be honest I am a little confused, as this patch is meant to work with the 'redirect_redirect__uri widget, as it is to fix an issue with how the 'redirect_redirect__uri widget is working - so I am unclear why you are using this particular patch if there is no 'redirect_redirect__uri widget displayed with the data_export plugin.

I don't think this is the patch for you.

You might be better off creating a new thread and creating a separate patch for you particular use case.

Good luck.

@tenden I do not know the history of why this "&& $view->getDisplay()->display['id'] == 'page_1'" was added as an additional check, but it may be ok to remove it?

Removing the additional check on "&& $view->getDisplay()->display['id'] == 'page_1'", as not sure it is needed.

Please feel to revert this with a new revision if it causes anyone any problems.

The patch has a lot of unusual formatting and line breaks. This also needs tests. I don't quite understand what it does, but there has to be a better way than alter the query like this, for example by providing a custom views plugin'

Reworked this patch from scratch to make it easier to understand and to remove the null exceptions thrown in PHP 8.1.

The biggest change was the rewriting of the redirect_alter_where_clause. The old function passed the condition object into Sql.php as an operator of type 'formula'. This caused null pointer exceptions to be thrown on lines 255 and 401 of Condition.php.

To fix this, the where condition changes had to be put into one large string and then passed to Sql.php.

$query->where[$key_group_conditions]['conditions'][$next_key_cond] = [
  'field' => $where_addition,
  'value' => [],
  'operator' => 'formula',
];

Trimmed trailing spaces.

The last submitted patch, 33: 2981544-33.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Removed "use Drupal\Core\Database\Query\Condition;"
Cleaned up various coding standard issues

More coding standards cleanup.

More cleanup.

The last patch doesn't work with the latest version of Redirect module!

Rerolled #37 patch for 1.9.0
Changed the ILIKE operator to LIKE so that the patch also applies to MySQL sites.

The Patch "2981544-40" solves the reported issues.Kindly review the patch

@Harsh
Your #40 is an exact copy of the one I uploaded in #39
Did you upload the wrong file? If not, I'm not sure what is the point of doing that.

Patch #39 works for me. I'm now able to use the To filter on /admin/config/search/redirect to search by URL alias values shown in the To column. Searching by the internal node ID still works as well.

Re-roll the patch in #39 for v1.10.0.