-
Notifications
You must be signed in to change notification settings - Fork 273
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
adamziel
merged 11 commits into
trunk
from
remote-html-install-wordpress-if-not-installed-yet
May 20, 2024
Merged
Remote.html: Install WordPress if it isn't installed yet #1425
adamziel
merged 11 commits into
trunk
from
remote-html-install-wordpress-if-not-installed-yet
May 20, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Testing instructions will come with a non-minified build PR
adamziel
added
[Type] Enhancement
New feature or request
[Package][@wp-playground] Remote
labels
May 18, 2024
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
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
force-pushed
the
remote-html-install-wordpress-if-not-installed-yet
branch
from
May 20, 2024 08:33
c286a63
to
a669b5a
Compare
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
This is great. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.