There were some changes to the URL redirect code since 7.x-4.0-rc1. The last of these was #2246597: Extra slash being added to Custom URL redirect, which always generates absolute URLs, and then removes the site's base url (if found). An unintended consequence of this was that a redirect of '<front>' went from being generated as '/' (which, since it didn't contain the base url, was left alone, passed valid_url, and worked) to 'http://www.example.com/', which once the base url was removed gave '' (empty string). It seems to be the intention to ignore a redirect that is specified as an empty string, so that's what it does.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | webform-redirect_to_front-22734871.patch | 1.57 KB | danchadwick |
Comments
Comment #1
danchadwick commentedThis is a bit tricky to fix. You would like to give the tokens an opportunity to be substituted into '<front>'. My solution was to move the replacement of the base_url into webform_replace_url_tokens. After the replacement is complete, if the URL is an empty string and if '<front>' appeared in the path passed to url(), then use a redirect of '/', rather than empty.
Because there have been several issues with redirect, it would be good to put some eyes on this and test it as part of a release candidate. I choose the solution above so as to affect other cases as little as possible so as to not introduce further regression issues.
Comment #4
danchadwick commentedCommitted to 7.x-4.x. Backport. Committed to 8.x
Comment #5
danchadwick commentedComment #7
danchadwick commented