The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Per #2417827-10: Evaluate and document each use of base: in core:
@mpdonadio et al: We were digging into the uninstaller issues and authorize.php and we noticed since around the Feb 8th 2015 the redirect path has busted for that Url generation.
@SebCorbin noticed it here:
#2042447-82: Install a module user interface does not install modules (or themes)
It's reproducible with the following circumstances:Use a path prefix install or a language prefix and run this in drush:
drush ev "use Drupal\Core\Url; echo Url::fromUri('user-path:/core/authorize.php');"
drush ev "use Drupal\Core\Url; echo Url::fromUri('base:core/authorize.php');"Without the path prefix/language prefix you will get what you expect:
/core/authorize.php@SebCorbin was getting this with or without path prefixing:
/index.php/core/authorize.phpWhich seems to think that it's a path and not a file.
And as you can see in the issue above we were getting the following after the batch redirect:
@SebCorbin: http://localhost:8080/d8-sandbox/core/authorize.php/en/%3Cnone%3E
@joelpittet: http://d8.dev/core/authorize.php/%3Cnone%3EBoth are incorrect so I thought I'd ask here before opening a new issue as I know you all are working hard on straightening this out.
See also #2042447: Install a module user interface does not install modules (or themes)
Tasks
- Fix the bug.
- Remove @todos from #2042447: Install a module user interface does not install modules (or themes) that reference this issue. Note that one of them is for a test that asserts the correct URL, so additional tests for this issue may not be needed.
- See if other issues with URL generation in authorize.php (for example, links that point to
/authorize.php/admin/modulesrather than/admin/modules) are due to the same problem, and if so, fix them.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | interdiff.txt | 1.86 KB | stefan.r |
| #11 | 2042447-2526392.patch | 26.28 KB | stefan.r |
| #10 | 2526392-10.patch | 599 bytes | stefan.r |
Comments
Comment #1
dawehnerI'm pretty sure that base:core/authorize.php should work ... in general I'm a little bit confused that it doesn't work, given that we kinda hve tests for that.
Comment #2
stefan.r commentedJust to clarify, this happens at the end of the batch run when installing a new module from the update manager. I did manually test this earlier so it must not be covered by tests yet.
Comment #3
dawehnerAh okay.
Comment #4
David_Rothstein commentedNot sure if we need any new tests here (assuming #2042447: Install a module user interface does not install modules (or themes) gets committed) since one of the tests there currently has to assert a URL with the presence of the
<none>- when we fix that here it will serve as a regression test.Comment #5
David_Rothstein commentedOf course that depends on exactly what the cause of the bug is, whether it's authorize.php-specific or not.
Comment #6
David_Rothstein commentedComment #7
stefan.r commentedI'm trying to decipher what is happening here in a debugger and just wondering if this is redirecting to core/authorize.php while it already is on core/authorize.php? (which would make it become core/authorize.php/core/authorize.php)
Comment #8
stefan.r commentedComment #9
stefan.r commentedComment #10
stefan.r commentedDepending on the front controller we're using,
base:core/authorize.phpgoes to one place or to another.In the first step of the batch it works (as we're still on index.php) but when we're finished we're already on authorize.php and this stops working. So if we turn the redirect into an absolute URL, I guess it should work for both cases.
Comment #11
stefan.r commentedAdding in #2042447: Install a module user interface does not install modules (or themes) (which is still waiting to be committed) with an updated test just to see if this is green.
I also wonder if we might have this same problem with changing front controllers elsewhere in the codebase?
Comment #14
webchickSo we ended up rolling this fix into #2042447: Install a module user interface does not install modules (or themes), since without this we had to hack .htaccess. I therefore think this issue can be closed as a duplicate.
Comment #15
David_Rothstein commentedFrom the issue summary:
Note that this part is now being handled in #1885564: theme.maintenance.inc (authorize.php) - Convert theme_ functions to Twig - after going through one or two other issues in the meantime :)