Anyone got any suggestions as to how we can create a patch for this issue?
I can probably create a patch that edits the 'src' files, but not sure how the files in the 'build' folder would get updated, or even how I would build these files manually.
Any suggestions welcome.
Thanks, Martin
Any chance this patch can be rolled into the main branch or Development version: 8.x-1.x-dev ?
This module is blocking me from upgrading to Drupal 10. The patch has been applied but composer is still not happy with the module compatibility.
>composer prohibits drupal/core 10.0.0
drupal/core-recommended 9.5.11 requires drupal/core (9.5.11)
drupal/groupmenu 1.0.0-beta3 requires drupal/core (^8 || ^9)
drupal/hal 1.0.3 requires drupal/core (^9)
drupal/core 10.0.0 requires symfony/console (^6.2)
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.
@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?
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.
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?
Thanks @tenden . I think I have fixed the encoding issue, hopefully.
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.
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.
Updating master patch to include the amended line.
Third time lucky
For some reason the patch did not generate correctly. I am re-uploading.
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.