Problem/Motivation

To support automatic updates, we need a front end controller that can do what is essentially known as A/B switching.

Proposed resolution

You can read more about the proposed solution and how it relates to the autoupdates initiative at:
#2940731: Automatic Updates Initiative overview and roadmap.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

heddn created an issue. See original summary.

heddn’s picture

This was discussed in #3085755: Automatic updates meeting on 7 November 2019.

Symlinks on windows was a concern.
This is also a pre-task for doing composer updating. And could provide some benefit for non-composer managed sites as well.

So, part of how I'd see this playing out is:
(1) A/B implementation
(2) A Composer implementation that isn't capable of low memory
(3) Refinements to the Composer support

Some PoC work is available in https://github.com/php-rot.

dstol’s picture

Issue summary: View changes
Issue tags: +autoupdates
dstol’s picture

Issue summary: View changes
xjm’s picture

Version: 9.0.x-dev » 9.1.x-dev
Priority: Normal » Critical

This would be a minor-only change. Since 8.9.x and 9.0.x are now in beta, I'm moving this to 9.1.x. Thanks!

Also bumping to critical, since this is like... the future and survival of Drupal.

xjm’s picture

Issue tags: +automatic updates

Where's our roadmap meta? That should be the parent of this issue.

xjm’s picture

There we go.

xjm’s picture

Inaugurating a new issue tag for the initiative's issues.

xjm’s picture

Title: Replace single index.php with a Front End controller that supports A/B updating (automatic updates) » Replace single index.php with a frontend controller that supports A/B updating (automatic updates)
ponies’s picture

Issue summary: View changes
heddn’s picture

From looking at https://github.com/php-rot/d7_poc/blob/master/docroot/index.php and https://github.com/php-rot/rot/blob/master/static/index.php, there seems to be 2 sides to this A/B feature set. Which makes sense.

Side 1) There is a static index.php that regularly checks if there is any need to download a newer version of the code. This feature set is probably do-able using d.o's update.xml and update services. The other part of the static index.php is that it checks if there is valid, fully functioning and updated version of the code-base that it should switch to.

Side 2) A bootloader in the app. This duplicates some of the logic from Side 1 so it can flip us over to a valid, fully functioning and updated version of the code-base. But it has no logic about updating the site.

I think what we could PoC first here is the shared logic of deciding if it should flip over from A/B. See if we can externalize that logic into some type of shared code that might be able to be depended upon as a composer dependency. Does such a thing already exist out in the wild in packagist or a gist somewhere?

effulgentsia’s picture

See if we can externalize that logic into some type of shared code that might be able to be depended upon as a composer dependency.

Can either side 1 or side 2 from #11 use Composer dependencies? This lives outside of the A or B codebases, so how would those dependencies get updated?

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

stephencamilo’s picture

Status: Active » Closed (won't fix)
andypost’s picture

Status: Closed (won't fix) » Active

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

catch’s picture

Category: Task » Feature request
Priority: Critical » Normal

Discussed this briefly with @xjm and @tedbow - the approach automatic_updates uses is composer-stager, which is not this. There could still be a use-case for an A/B controller like running updates, but that makes this a feature request and not critical - so changing priority/category.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.