Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remote.html: Install WordPress if it isn't installed yet #1425

Merged
merged 11 commits into from
May 20, 2024

Conversation

adamziel
Copy link
Collaborator

@adamziel adamziel commented May 18, 2024

What is this PR doing?

Runs the WordPress installation process in remote.html when the loaded WordPress instance isn't installed yet.

This is to enable the official WordPress release .zip to just work in Playground. Currently it doesn't because remote.html expects a pre-installed WordPress build with a pre-populated SQLite database already baked-in. This PR, in conjunction with #1425 and #1426, remove that requirement.

Related to Boot Protocol

Testing Instructions

Confirm the CI checks pass.

adamziel added a commit that referenced this pull request May 18, 2024
…ld (without the SQLite integration plugin)

Uses Playground CLI to produce a minified WordPress build, replacing the custom bash-based WordPress installation flow that relied on wget, unzip, sed, wp-cli etc.

This is to dogfood Playground CLI and put the boot protocol to a practical use. With this PR, CLI Playground produces a minified WordPress version that is later used to boot the web Playground.

Depends on #1423 #1423 #1425

 ## Testing instructions

Rebuild the latest WordPress with

```shell
rm -rf packages/playground/wordpress-builds/public/wp-6.5
npx nx bundle-wordpress:major-and-beta playground-wordpress-builds
```

Then run npm run dev and confirm the local Playground loads without any issues.

Related: #1398
adamziel added a commit that referenced this pull request May 18, 2024
Replaces a series of custom steps meant to unzip and configure WordPress with passinf the build zip as a preferredVersion.

To test, go to the WordPress PR previewer locally and try previewing one of the recent PRs. Confirm the installed WordPress versions is indeed not the latest stable.

Do not merge until these PRs are merged:

* #1423 
* #1424 
* #1425 
* #1426 
* #1427
Base automatically changed from remove-php-set-php-ini-entry to trunk May 20, 2024 08:18
@adamziel adamziel requested a review from a team as a code owner May 20, 2024 08:18
adamziel added a commit that referenced this pull request May 20, 2024
…if there's no custom db.php inside wp-content (#1424)

This PR always preloads the SQLite plugin in remote.html, even if the
provided WordPress already ships one. The preloaded plugin will only be
used if no `wp-content/db.php` drop-in plugin is found in the
filesystem. This change sets the stage for:

* #1426, which ships a minified WordPress build without the SQLite
plugin baked-in.
* #1425, which runs the WordPress installation wizard if the site isn't
installed yet

Related to [Boot
Protocol](#1398)

## Problem solved

We want the official WordPress release `.zip` to just work in
Playground. Currently it doesn't because remote.html expects a
pre-processed build with the SQLite plugin already baked-in. This PR, in
conjunction with #1425 and #1426, remove that requirement.

## Testing Instructions

Confirm the CI checks pass.
@adamziel adamziel force-pushed the remote-html-install-wordpress-if-not-installed-yet branch from c286a63 to a669b5a Compare May 20, 2024 08:33
@adamziel adamziel merged commit b7dac82 into trunk May 20, 2024
5 checks passed
@adamziel adamziel deleted the remote-html-install-wordpress-if-not-installed-yet branch May 20, 2024 08:43
adamziel added a commit that referenced this pull request May 20, 2024
…) utility (#1427)

Moves the WordPress.zip extraction logic to a common utility function
called `unzipWordPress` and living in the `@wp-playground/wordpress`
package. This allows both `remote.html` and Playground CI to boot
consistently.

This and #1425 unlocks providing WordPress ZIP bundles in Blueprints via
`{ "preferredVersion": { "wp": "<URL>" } }`.

## Implementation details and follow-up work

The goal of `unzipWordPress()` is to extract a zipped WordPress
installation at a specified location in VFS. This isn't a trivial task
as WordPress might exist at a root of the zip file, at a nested
`/wordpress` directory, in another `wordpress.zip` file living inside
the initial `wp.zip` archive, or in any subdirectory of the above. The
current implementation covers a few basic cases, but nothing beyond
that.

Looking forward, we should:

* Move that logic to the [PHP Blueprints
library](https://github.com/WordPress/blueprints-library/)
* Either:
* Make it "just work", e.g. by traversing nested zips and directories in
search for WordPress
* Don't guess anything and allow the developer to specify the exact
"coordinates" of their zipped WordPress
* Only accept a few variations, throw an error when an unsupported zip
is provided, document it thoroughly and provide a very informative error
message

## Testing instructions

Confirm the E2E tests pass
@brandonpayton
Copy link
Member

This is to enable the official WordPress release .zip to just work in Playground.

This is great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants