update.php doesn't work when Drupal is installed in a subfolder and RewriteBase is used

Looks like #951644: Requirement warnings (e.g. for PHP memory limit) are not shown on install or update unless there is a requirement error also broke this.

I wrote that patch and run Drupal in a subfolder all the time, so I know it works in the general case :) ... I think this issue is limited to sites using RewriteBase?

Here is a mostly untested patch that might help.

Um. Why? bootstrap.inc already handles this in drupal_environment_initialize. Why do we need more / new / untested code?

By using request_uri() the patch is already making it reuse work that was done in bootstrap.inc - and therefore fixing the bug :) But as far as I recall, most of the rest of what happens in bootstrap.inc doesn't apply directly to install.php or update.php. See also #1547184: Refactor Core scripts .

If there's some use for the equivalent of parse_url(request_uri(), PHP_URL_PATH) on normal Drupal page requests, I suppose we could add it to bootstrap.inc also? But I don't think it should happen in this issue unless it turns out to be really easy.

#3: update-1433996-3.patch queued for re-testing.

I've written an issue summary.

Updated issue summary

Amend to Problem/Motivation

#3: update-1433996-3.patch queued for re-testing.

I can confirm that update.php does not work with this patch
and with this configuration:
Mac OS X 10.7.5
PHP ver 5.3.15
Apache 2.2.22
MySQL Server version: 5.5.19-log

After running update.php, the message box is displayed saying "No pending updates."
However, the "Front page" hyperlink directs back to: /core/update.php
and the "Administration pages" hyperlink directs back to: /core/admin/update.php
The user doesn't have a valid link out.

The broken links are being addressed by #2017769: Links from update_helpful_links() should point to site root and not to update.php

Added user name to original report section

Rerolled.

When trying to reproduce this issue to test, following this step:

The base_url variable in the settings.php file has been set to the base url of the site excluding the subdirectory (http://example.com).

simply breaks the site if I have the site in a subdirectory.

Why did you mark this "needs work"?

Patch no longer applies.

Im going to work on this issue during the sprint

I'm a mentor. Helping @fatfish to work on the issue.

auto merge

Added beta evaluation, should be safe to RTBC if testbot says it's OK

Unfortunately, the patch doesn't fix the problem. "Continue" button on update.php page still points to /drupal/update.php instead of /update.php.

The patch in #24 applies cleanly to HEAD.

#27 +1. It seems the problem is still here.

Reproduce:
Drupal 8.4.x + installed with subfolder (/test) + Patch #24

The /test/update.php page is still working but once I click the Continue button:

Continue ->
It will still go to the path like: /test/update.php/selection

I switched the wrong triage tag for the correct one.

@Jerenus That's good work so far on triage. I am giving you credit on this issue based on the amount of work done. Be aware we like to see the triage steps documented (even if brief). It is the only way to know if the triage has actually been completed. Here are some made-up examples of documented triage steps:

• I tested the steps to reproduce and they did (or did not) work (so I am tagging it "Needs issue summary update").
• I searched for duplicate issues but could not find any.
• I checked the issue summary and it is accurate and up-to-date.
• Etc...

Thank you!

Re-roll of the #24 patch because it's failed to apply on 8.4.x branch.

Removed Needs Reroll tag.

Discussed with @catch, @cilefen, @effulgentsia, @lauriii, and @xjm. We agree this is a major bug. The only reason this is not critical is because the set up is unusual. We agreed that discovering that update.php doesn't work why trying to apply a security upgrade would be a really bad time to find out.

Given the code that generates the url for the continue button is:

    $build['link'] = [
      '#type' => 'link',
      '#title' => $this->t('Continue'),
      '#attributes' => ['class' => ['button', 'button--primary']],
      // @todo Revisit once https://www.drupal.org/node/2548095 is in.
      '#url' => Url::fromUri('base://selection'),
    ];

It seems #2548095: Add option to Url() to force the site base_url to be used is very relevant.

Can’t reproduce with just uncommenting RewriteBase /drupalin .htaccess when using site in the subdir /drupal running on Apache.

So it feels like this was a vital step in breaking this:

The base_url variable in the settings.php file has been set to the base url of the site excluding the subdirectory

And we don't do base_url anymore in D9.

Should we move this back to D7 and see if it is still reproducible there or does anybody still have any steps to reproduce this on D9?

lendude was not able to reproduce this problem on Drupal 9, see #52. In the intervening 6 months no one has confirmed that this problem still exists in any supported version of Drupal. However, in case this is applicable to Drupal 7 I am changing the version.