During the installation of Drupal core, PIFR re-constructs the install.php URL where it posts to.

This means that any additional installation parameters that have been added by the installer itself are lost.

This breaks my patch in:
#1798732-54: Convert install_task, install_time and install_current_batch to use the state system

My patch adds a new 'bootstrap' GET query parameter during the course of the installation.

Since PIFR is using the same browser as Simpletest, I actually don't see why it has to override those URLs at all.

In core, we're successfully processing and stepping through batch patches like update.php in the same way.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

Priority: Major » Critical

Bumping this to critical, since it additionally blocks #1067408: Themes do not have an installation status

sun’s picture

Project: Project Issue File Review » Drupal.org Testbots
Version: 6.x-2.x-dev »

Moving to testbot project in the hope to gain some attention. ;)

rfay’s picture

Project: Drupal.org Testbots » Project Issue File Review
Version: » 6.x-2.x-dev

Same amount of attention either place. Same people listening. Since it's got a patch, better to have it in PIFR.

boombatower’s picture

It would depend if

// Call install.php with path again since browser will have messed up URL.

has been fixed since I remember there was an issue with the url encoding...so not sure this will work. Assume no one has executed this code yet? If it works seems fine. Also remember the browser pifr uses _was_ a copy of simpletest (static though not checked out with core to ensure stability) so we may need to update that.

http://drupalcode.org/project/project_issue_file_review.git/blob?f=clien...

sun’s picture

Is there any chance to move forward here?

The required adjustments for the installer are blocking a couple of critical + major core issues (the dependency chains are getting larger every day), and we're slowly running out of time to feature freeze...

sun’s picture

Attached is a diff between contrib simpletest 6.x-2.x and core simpletest 7.x. I removed irrelevant parts.

I cannot see any significant change to the cURL/drupalPost processing that would cause simpletest 6.x-2.x to not follow progressive batch redirects.

jthorson’s picture

Confirmed that the bots pass install phase on 6.x, 7.x, and 8.x HEAD tests; as well as 6.x and 7.x versions of a contrib project. Assuming the 8.x HEAD run comes back fully clean, I'll commit to 6.x-2.x.

jthorson’s picture

Status: Needs review » Fixed

Committed to 6.x-2.x (Commit id 778c7d7).

jthorson’s picture

... and deployed.

sun’s picture

Thank you! :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.