Method to bypass redirection (Temporary)

Applying temp fix

✨ Method to bypass redirection RTBC was merged into 8.x-1.x branch and released as 8.x-1.0: https://www.drupal.org/project/m4032404/releases/8.x-1.0 →

What is the cause of needing to be patch off 8.x-1.0-alpha6 instead of just using 8.x-1.0?

Is it because of the use of a patch in production using the different config name for negating the path matching? I hadn't considered that it would need a update to help sites using patched version move to main line. It probably does need one.

I've tested this here locally both with and without the "disabled" key and it's working to fix up the config here. Can you use this to patch onto 8.x-1.0 and get it working?

Since using ✨ Method to bypass redirection RTBC was widespread, this should be merged and released quickly to help out others trying to update.

Hello @elc, thanks for chiming in. We intend to upgrade to 1.0 indeed and later to 2.x, but for now, we just created the patch with yesterday's state as we were using the MR's patch url (#3358555 didn't contain patch files, just the MR changes), and with the new commits, made the mr patch url incompatible with the module's version we were using.

As an emergency matter, to prevent our builds to fail, we added this patch file without the recent commits. This was an edge case, and might not apply to others.

Your site will need an update to go from the config from the original patch on #3358555 to what ended up in the final patch in 8.x-1.0 or 2.0.0. There's also a bug in the patch from #3358555 where if the "pages" config is empty, it is still used in the matching logic.

If you were relying on "disabled = TRUE" then the logic will also silently reverse as the outcome of $negate = $this->config->get('negate') ?? FALSE; will be FALSE.

There will a non-zero number of sites using the original patched 8.x-1.0-alpha6 other than yourselves and I'd rather not have sites ending up with unexpected behaviour.

The patch will still be here, but I seem to have usurped your issue of just posting a patch with the realisation that there needs to be a hook_update_N to fix the config for any of those sites.

That's good news because I would have missed updating the config key for those sites again in 📌 Use ConditionManager instead of custom code Active which will once again need to change the configuration.

Going to leave this issue open as you did create a new one instead of adding the patch to #3358555, making me think that it's not possible for you to add a patch file to a "fixed" issue.

When you're done with it, set status to "Fixed".