Alain Schlesser 5:15 pm on February 22, 2017
Tags: Bootstrap/Load ( 5 ), core ( 562 )

Nextgen Bootstrap/Load Feature Project

The bootstrapping process of WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. (affectionately called the “Bootstrap/Load” component around here) is a critical piece of the system, and everything else depends on it being reliable and performant. However, developers and system administrators also need it to be flexible enough to adapt to the requirements of their differing projects or environments. Large-scale WordPress installations often require substantial customizations to adjust for scalability and redundancy.

Considering the importance of this component, the documentation is not adequate, and very few people actually know what the exact flow is. More importantly, there isn’t a wide understanding of why specific decisions had been taken, and how later code depends on the bootstrap process.

This proposal aims to launch a feature project to work on the next iteration of the bootstrap component with a set of specific goals in mind.

Goals

To be able to guide the design process and have measurable success metrics, clear goals need to be defined.

Here’s an overview of what specific goals the project should aim for:

The component has proper documentation for every step of the process.
Documentation will include both clear comments in the source as well as an external documentation space that includes reference material, execution flow diagrams, best practices and examples of usage.
The component models a modernized flow which still provides same sane defaults, but enables advanced use cases in a supported way.
Customizing high-volume sites or specialized applications should be less “hacky”, and all of the major subsystems should provide reliable means of configuration/extension.
The component adapts to differing contexts to optimize both performance and memory consumption where possible.
The system should be able to intelligently load only the parts of the code that are strictly necessary for the current requests, through means of conditional execution flows, smart routing, proxy objects and autoloading. Special consideration should be given to the WP REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. endpoints to make them as fast and efficient as possible.
The component offers a coherent way of supporting all versions of multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site (networks), reducing some of the idiosyncrasies that currently exist.
The difference between single sites, networks of sites and networks of networks should be kept as small as possible so that less care needs to be taken to have the code work reliably with all of them.
The component considers both backward compatibility as well as forward compatibility.
It is of paramount importance that existing sites do not break due to the changes that will be proposed with this project. However, forward compatibility needs to be taken into account just as well, to create a next version of the bootstrap component that can easily grow with future requirements in a controlled way.

Project Phases

The project will have four different phases: Discovery, Design, Execution and Merge Proposal.

1. Discovery

The Discovery Phase aims to properly research and document the status quo. It will be a thorough analysis of source code, tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets and contributor discussions to decipher the reasoning behind the current implementation and what the requirements, strengths and weaknesses are. Documentation will be written in parallel, logging all findings and producing a better onboarding process for this component. Characterization tests will be written to be able to detect regressions when making changes in phase 3 later on.

2. Design

The Design phase will examine all the findings from phase one to design a new version of the bootstrap component that meets all the requirements and strengths while reducing some or all of the weaknesses and improving reliability, flexibility and performance.

We want to avoid having yet another component update that just grows organically. There should be strong principles in place that make sure that the new version is not only backward compatible but also forward compatible.

3. Execution

The Execution phase will create a modified fork/branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of WordPress Core, to allow for collaborative work on this new iteration of the bootstrap component.

Through automated tests, refactoring will be guided to implement the design from phase 2. The characterization tests from phase 1 will make sure that compatibility remains a given, even for “compatibility-enforced bugs”. Optional mechanisms to get saner results in such cases will be discussed on a case-by-case basis.

4. Merge Proposal

The Merge Proposal phase will be the final phase of the project, identifying a clean merge process and a proper migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. path to merge the new version of the component into Core.

Metrics will need to be defined to have measurable and achievable goals that can objectively tell whether the Component is ready to be merged.

Contributions

During the initial Discovery Phase, contributions in the following areas will prove to be useful:

Advanced Use Cases

We need lots of data about the types of customizations that people use for their projects: bootstrap modifications (WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/), complex networknetwork (versus site, blog) hierarchies, folder rearrangements, specialized caches, etc.

Problems With Current Code

We need to know about all and any challenges and limitations that you have been experiencing with the current bootstrapping flow: setups that were difficult or impossible to achieve, settings that didn’t yield the expected results, etc.

Documentation

Documentation will not only need to be written for the way the current code works, but also for all deprecated functionality, buggy behavior and unexpected side-effects. We are going for completeness, not ease-of-use here. Documentation should also cover best practices for modifying the bootstrap process.

Join us in #core-bootstrap to start contributing!

Thanks to Helen Hou-Sandì (@helen), Jeremy Felt (@jeremyfelt) and Aaron Jorbin (@jorbin) for their help in shaping this proposal.

#bootstrap-load, #core

Mark-k 5:23 pm on February 22, 2017

Point 3 is probably a non issue for anyone running an up to date PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher version, which probably all the relevant sites do. Having more conditionals just clutters the code and do not save much when the code is already parsed in the memory, something that PHP 5.6 and above do.
- Alain Schlesser 5:37 pm on February 22, 2017
  
  Conditionals and cluttered code is specifically what I want to get rid of. PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher does offer more tools to have adaptable code paths than just ifs.
  
  I want to look into having the entire flow be more modular, with the possibility to decide what modules to load in a given scenario.
  - Mark-k 7:05 pm on February 22, 2017
    
    ok, I will lurk on slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. and see where it is going to. boot speed optimization is surely needed.
LewisCowles 5:52 pm on February 22, 2017

Will the documentation be shared? Also the slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. seems to require an invite.

Mostly to speed up sites at scale (~10M unique pageviews a month is kinda as high as I’ve got with “scale”) I try to avoid the WP-flow by saving out content from WP as HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. for blogblog (versus network, site) articles and pages, letting the webserver use it’s rules to be able to serve that first, if no matches, forward to PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and front controllers.

Most of the challenges are ensuring any user-input goes to an AJAX or REST-APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. endpoint if static is being served, but there is also some de-compositing of features (like breaking an epic into tiny backlog items) and some cool things we can do in JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors.; so that things like choose a random 3 articles is possible without PHP by saving and periodically updating some files we can use as data or just having the webserver cache certain public non-login resources for a time-limit.

The other thing I’ve been saying for years is doing everything at once over a single request/response cycle is probably a pain point. For example, the Adminadmin (and super admin) UIUI User interface actually loads it’s frame, then the editor metaboxes or listing view. which do a lot.

That could become an outer shell that’s cached for let’s say a minute. With that mindset you’ve reduced (60xuxn) where n is number of clients and u is the number of active users the workload.

As for posts, I think hinted at in an earlier post with URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org’s instead of shortcodes, there is an opportunity to have the output cached of resources (phpBB actually used to cache entire posts to save processing)

Lastly switching out DB’s from front-end to admin users we’ve had some nasty hacks in some clients wp-config.php to shallow verify and switch out master to a read slave round-robin using redis to monitor # users per slave for sites that could not be easily made static.

As for drastically changing coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., we’ve certainly never bothered for a live site and have a disclaimer as it’s working against a platform to do that AFAIK.
- Travis Northcutt 6:07 pm on February 22, 2017
  
  Re: slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., go to https://make.wordpress.org/chat/ to get set up.
- Alain Schlesser 6:29 pm on February 22, 2017
  
  Not sure what you mean by invite, but I sent you a channel invite to the existing SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. user @lewiscowles.
  
  Thanks for providing these examples. This sounds a bit like you’ve built yourself a custom Varnish-type static cache. It is an interesting use case, and I will get back to you at a later time to know more details about that.
- Alain Schlesser 8:22 pm on February 22, 2017
  
  Ah, just saw I didn’t reply to your first question.
  
  Yes, all of the documentation will be shared. I’m not yet sure on how best to structure it, but it will probably be a combination of Handbook posts, wiki pages and/or source code annotations.
  - charliespider 5:29 am on February 23, 2017
    
    guess there’s no way a ` docs ` folder with ` .md ` files would fly eh?
    - Alain Schlesser 9:31 am on February 23, 2017
      
      As the “source” for the docs, sure, why not?
Franz Josef Kaiser 7:06 pm on February 22, 2017

This sounds like a very sane and well thought through proposal. I hope it does not get stuck in point 1, while point 4 is in sight. My +1 on this—it’s long overdue.
charliespider 7:14 pm on February 22, 2017

So by Nextgen do you mean using namespaces and proper autoloading?
Would be a fantastic reason to finally drop support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 5.3. Nextgen request routing would be difficult otherwise (not impossible but much more difficult).

The biggest thing I would like to see is an early and strong separation of request types, ie:

* frontend HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.
* adminadmin (and super admin) HTTP
* frontend AJAX (AJAX request originating from frontend requiring access to non-admin components)
* admin AJAX (AJAX request originating from the admin requiring access to admin components)
* REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.
* activation request

I’m also tempted to suggest using a request stack but to really work properly that would require changing when the request headers are sent (which would be a fantastic improvement but not very backwards compatible for WordPress).
- Alain Schlesser 7:27 pm on February 22, 2017
  
  Well, we’ll start with pinpointing the problems first before deciding on specific implementations for the solution, but autoloading is certainly something I’m looking into, as there’s huge potential for saving a lot of processing power and memory… provided that the code paths are flexible enough to make proper use of this.
  
  Regarding the request types and proper routing, there will be major overlap with Nextgen Rewrites, and I will certainly discuss this in more detail with @rmccue when the initial discovery is done.
  
  Ideally, the bootstrap process would at least be flexible enough to allow you to “drop in” a general-purpose router instead of the default WordPress rewrites.
  - Mike Schinkel 3:41 am on February 23, 2017
    
    Ideally, the bootstrap process would at least be flexible enough to allow you to “drop in” a general-purpose router instead of the default WordPress rewrites.
    
    You can already drop in a URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org router using the 'do_parse_request' hook (thanks Andy Skelton for recognizing the value.) In that hook you can spin off and do whatever routing you want, or you can set a flag in $wp-query_vars and match that flag in the 'template_redirect' hook to call whatever function or method you like, if 'do_parse_request' is too early.
    
    But to completely replace the URL router in WordPress ignores the fact that WordPress uses a query-based router and not a mapping router like most PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher frameworks do.
    
    The point is, at least for WordPress and URL routing, if you replace the default router with a mapping router you are essentially throwing the baby out with the bathwater because so much of WordPress is built around the former and the former has benefits the latter does not have. And since there is already a workaround with no real limitations to allow those who want to use mapping routers it does not make sense to do throw out the query-based router. Improve the granularity of the query-based router and allow context sensitive routing in addition to context free routing? Yes. Replace it with a mapping router? No.
    
    P.S. This comment is only about URL routing. No comment (yet?) on the rest of the proposal.
    - Alain Schlesser 9:33 am on February 23, 2017
      
      I don’t want to delve too much into future implementation details at this point. There are several problems that people commonly face, and I would like to brainstorm on solutions for these only after we’ve collected them.
      
      Maybe general-purpose routing is needed, maybe not. Maybe we’ll try to build something nobody has considered in the past. I want to stay as open-minded as possible for the time being.
    - charliespider 1:33 am on February 24, 2017
      
      That’s a good point Mike, but one of the main reasons I commented about having an early and strong separation of request types, was to allow for the use of routers that were optimized for that specific request type. Look at my list of suggested request types again:
      
      frontend HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.
      
      adminadmin (and super admin) HTTP
      
      frontend AJAX
      
      admin AJAX
      
      REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.
      
      activation request
      
      certainly we would not want to replace the current routing for standard frontend requests… but what about the others? I think the possibility at least exists that a different type of router might be more performant for at least one of those other request types, no?
      
      It’s something to at least consider.
      - Mike Schinkel 2:31 am on May 18, 2017
        
        Charlie: Good points. I would agree with that, especially if we could use that router to provide clean and logically organized URLs in the adminadmin (and super admin).
  - charliespider 5:19 am on February 23, 2017
    
    Ya sorry for jumping the gun, but this is exciting stuff.
    
    That said, I would like to pinpoint PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 5.2 as a problem 😀
John James Jacoby 10:47 pm on February 22, 2017
My issues with WordPress in this regard are summed up in #37646.
- Drop-ins and early-init’er that can’t hook in (caching, apps, etc…)
- CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. decisions that cannot be overridden (post types, taxonomies, database schemas, etc…)
- Core APIs that are not pluggable (rewrite rules, main WP_Query, user roles, etc…)
- Unpredictable action-order nested unclearly (functions calling functions executing actions before `init`, users, languages, etc…)
Personally, I care less about the tooling WordPress is wrapped inside of, and trust that professionals like @schlessera who know and care more about that will guide the project in the proper direction.

George Stephanis made a joke about the Cathedral and the Bazaar a few weeks ago, and it’s ideas like this that make that feel very true. Whatever we do, I hope it’s sincerely in the best interests of keeping WordPress an approachable project for everyone to continue to contribute to.

—-

TL;DR – Olympians continue to raise the bar, but most of us will never jump that high. WordPress is best when anyone can win.
- charliespider 5:17 am on February 23, 2017
  
  George Stephanis made a joke about the Cathedral and the Bazaar a few weeks ago, and it’s ideas like this that make that feel very true. Whatever we do, I hope it’s sincerely in the best interests of keeping WordPress an approachable project for everyone to continue to contribute to.
  —-
  TL;DR – Olympians continue to raise the bar, but most of us will never jump that high. WordPress is best when anyone can win.
  
  Not everyone needs to monkey with the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. bootstrapping to win though right? Your comments sound like every line of code needs to accommodate the lowest common denominator, which is just completely untrue. I’m not a betting man but I would wager that the vast majority of WordPress developers have never had the need to monkey about with the core bootstrapping process (ie: the bulk of theme and pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developers). Those that do however, are likely skilled enough that anything happening as a result of this proposal would not be beyond their capabilities.
  
  In fact, cleaning up some of the chaos in core and replacing it with a solid framework following modern day best practices would likely make it easier for developers to interact with the bootstrapping process, without the fear of taking down the card house. Replacing the core bootstrapping with a series of do_actions() makes it way too easy for some non-Olympian to do something really bad because there is no structure or constraints in place to keep the train on the tracks. Whereas following modern day best practices, combined with well proven structures, and using interfaces to define all interactions, can bring structure AND flexibility to the process.
  
  TL;DR – Olympians can raise the bar higher than most can jump, but the rest of us can still benefit because it’s licensed under GPLGPL GNU General Public License. Also see copyright license. and we can download it for free ;D
  - Jon Brown 9:40 am on February 23, 2017
    
    FWIW, I’ve been around WP for 10 years now and I still more often confused by WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s “archaic PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher” (ie. 5.2 legacy) than I am by “modern PHP” patterns I see every else.
    
    Frequently I go to someone and say “why the heck are they doing it like _that_?” and get told, oh that’s just how you had to do it back in PHP 4/5.2.
    - Alain Schlesser 9:45 am on February 23, 2017
      
      Haha, I can totally relate.
      
      Of all the systems/frameworks I use regularly, WordPress is the only one I still need to constantly check through both the docs and the source code, and I often feel silly for needing to do that, having myriads of code intelligence tools at my disposal.
      
      But, I’m afraid that changing around the bootstrapping process will not change much about that. That is another day’s battle… 😉
    - Mike Schinkel 2:34 am on May 18, 2017
      
      Jon: I think the operative phrase there is “I’ve been around WP for 10 years now.” Wouldn’t you agree you are in the extreme percentile (99+%) of expertise in the WordPress community? 🙂
  - Alain Schlesser 9:55 am on February 23, 2017
    
    Without going into too much technical details for now, I want to say that I totally agree. There’s no reason why a more flexible, modular, intelligent bootstrapping process could not just provide the exact same interface and sane defaults as the current one does. For example, having the possibility to change the order of things does not mean that everyone is forced to change that order just to get started.
    
    I deal with this type of work a lot, where you want to replace an old architecture (of varying quality and complexity) with a new one. Not only are there a lot of techniques for making the switch without breaking the existing stuff, but in general, the resulting system is easier to use, easier to extend and more reliable.
Ansel Taft 1:02 am on February 23, 2017

If you do this thing the community will have no choice but to erect a statue in your honor. Say, how do you feel about bronze? No reason.
Mike Schinkel 5:10 am on February 23, 2017

This is so open-ended, it’s hard to come here with a complete list of concerns. I feel I will need to run into many of these issues again in the future before I can bring them up (as recognition is far more effective than recall.)

But to start, the fact that database configuration cannot be accessed without either running the entire page loader via index.php or wp-load.php or by writing a parser for wp-config.php that will fail on common edge cases, is a big problem. Would love to see those moved to a .ENV file or similar so that other code that needs access to credentials can access it.

Similarly, it would be really nice if we could implement a standard pattern for loading configuration for dev, test, staging and production in a manner that can easily be ignored by version controlversion control A version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories. but still be able to commit a fallback/example.

And I’m not holding out hope for this, but a standard method for multi-tenancy would be great (completely separate DBs with shared code-base).
- charliespider 5:23 am on February 23, 2017
  
  Similarly, it would be really nice if we could implement a standard pattern for loading configuration for dev, test, staging and production
  
  ooo ya nice
- Jon Brown 9:36 am on February 23, 2017
  “Clean” handling of different environments would be nice. I use and love this:
```
# Database Configuration
if ( file_exists( dirname( __FILE__ ) . '/wp-config-local.php' ) ) {
    include( dirname( __FILE__ ) . '/wp-config-local.php' );
} else {
	define( 'DB_NAME', 'database' );
	define( 'DB_USER', 'database_user' );
	define( 'DB_PASSWORD', 'database_pass' );
	define( 'DB_HOST', 'localhost' );
	define( 'DB_CHARSET', 'utf8' );
	define( 'DB_COLLATE', '' );
        define( 'WPLT_SERVER', 'Production' );
        define( 'WPLT_COLOR', ' GREEN' );
}
$table_prefix = 'wp_';
```
  but I’d be totally happy with .ENV files as well…
  - Mike Schinkel 2:41 am on May 18, 2017
    Jon:
    I have used wp-config-local.php for a while because it is how Pantheon does things. But I have recently wanted to move to configuration files that are tied to the domain of multiple configurations files can coexist in the GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. repo, e.g.:
    
    config-www.example.com.php
    
    config-qa.example.com.php
    
    config-feature.example.com.php
    
    config-example.dev.php
    
    This would allow tweaking settings for different pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party that expect constants to be defined on a per staging site basis.
    
    BTW, the way I use the above is they return an array to the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher file that require()s them.
- Alain Schlesser 9:57 am on February 23, 2017
  
  I do think that this will not be completed in a weekend or two, so you’re welcome to add anything that comes to your mind for the foreseeable future! 🙂
  
  Thanks for this list already, very valid points!
  - charliespider 2:30 am on February 24, 2017
    
    this will not be completed in a weekend or two
    
    not with that attitude 😉
Alain Schlesser 6:04 pm on February 25, 2017

For those of you who wish to share a specific use case that might be of interest to the Bootstrap/Load discussion, please fill out the following survey:

https://goo.gl/forms/DnehDv6pYZDl8gEU2
Paul Biron 1:56 am on March 18, 2017

Here’s a bootstrap problem I just spent over an hour tracking down.

I was getting a “white screen of death” on wp-activate.php.

The theme for the site in question relies on a “site-specific pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party” (that registers custom post types, custom taxonomies, etc). One of the methods defined in that plugin is called in the theme’s header.php.

And it came as quite a shock to me that the bootstrap process initiated by wp-activate.php does NOT load plugins.

This is because wp-activate.php begins with define( 'WP_INSTALLING', true );, which results in wp_get_active_and_valid_plugins() returning an empty array 🙁

And to make matters worse, when WP_INSTALLING == true, then @ini_set( 'display_errors', 0 ); even though WP_DEBUG == true…so I wasn’t even getting any PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher error messages on screen as to why the bootstrap process was dying before finishing to load the theme’s header.php 🙁

The workaround was simple, once I finally figured out the cause: have the theme hook into activate_header and load the site-specific plugin myself.

So, please 1) consider this as input to the Discovery phase of this project, 2) add documentation on the workaround (or document a better workaround) and 3) in the Design phase, make wp-activate.php‘s bootstrap no different than a “regular” front-end page load.