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

WordPress Build: Use Playground CLI to produce minified WordPress build (without the SQLite integration plugin) #1426

Merged
merged 41 commits into from
May 28, 2024

Conversation

adamziel
Copy link
Collaborator

@adamziel adamziel commented May 18, 2024

Uses Playground CLI to produce the minified WordPress builds:

$ bun \
    packages/playground/cli/src/cli.ts run-blueprint \
    --wp=https://wordpress.org/6.5.zip \
    --mount-before-install=./wordpress-site:/wordpress

Those new builds ships without the SQLite database integration plugin but with the SQLite database file containing all the data and tables created by a vanilla WordPress installation.

Advantages:

  • Less code to maintain – Playground CLI replaces a custom bash script relying on wget, unzip, sed, wp-cli etc.
  • More testing for our internal tools – we're dogfooding Playground CLI and the boot protocol in the critical code path.

Testing instructions

  • Confirm the CI checks passed – this is about as good of a testing as we can get.
  • Run npm run dev and confirm the local Playground loads without any issues.

Run bun packages/playground/cli/src/cli.ts server --login and confirm it loads an installed WordPress.

Related: #1398

…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 added a commit that referenced this pull request May 20, 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](#1398)

## Testing Instructions

Confirm the CI checks pass.
adamziel added 16 commits May 20, 2024 11:01
Removes the special MODE_EVAL_CODE in which the PHP code to evaluate
is fed to the interpreter as a string. Inline code snippets are now
written to a special file called `/internal/eval.php` and executed
as regular PHP files.

 ## Rationale

PHP does not correctly load the php.ini file when the code is passed as
a string.

This change also reduces the number of forks in the most cricitcal code
path in the project – PHP execution.

 ## Remaining work

* Rebuild all the PHP bundles, not just 8.0

 ## Testing instructions

Confirm the CI checks pass
This PR removes the duplicate PHP ZIP functions declarations. It only
leaves a single `unzip()` function declaration and a single `zipDir()`
function declaration. Furthermore, they're no longer imported across
modules but live where they're used.

 ## Testing instructions

Confirm the CI checks pass
@brandonpayton
Copy link
Member

brandonpayton commented May 21, 2024

@adamziel It looks like you are doing merges instead of rebasing within this PR to avoid rewriting history within the PR. Is that right? It's something I've been thinking about because force-pushing after rebasing makes it difficult to follow the progress of the PR over time because changes are hidden and conversations lost or made less visible.

@adamziel
Copy link
Collaborator Author

@brandonpayton I'm merging mostly because rebasing requires replaying this branch through all the recent trunk commits and often solving the same conflicts multiple times. There are trade-offs either way 🤷 e.g. the merge commits add noise and can disguise extra changes done during the conflict resolution.

@brandonpayton
Copy link
Member

Thanks for offering your thoughts, @adamziel ☺️

@adamziel adamziel requested a review from a team as a code owner May 23, 2024 02:07
@adamziel adamziel changed the base branch from trunk to playground-boot-protocol May 23, 2024 04:20
@adamziel adamziel changed the base branch from playground-boot-protocol to trunk May 23, 2024 04:21
@adamziel adamziel marked this pull request as draft May 23, 2024 16:35
@adamziel adamziel marked this pull request as ready for review May 23, 2024 17:48
Copy link
Collaborator

@bgrgicak bgrgicak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR breaks logging. You can test it using this blueprint.

Error: Could not write to "/wordpress/wp-content/mu-plugins/error.php": There is no such file or directory OR the parent directory does not exist.

@adamziel
Copy link
Collaborator Author

adamziel commented May 28, 2024

@bgrgicak with this change in, you have to create /wordpress/wp-content/mu-plugins before calling writeFile – that's consistent with the official WordPress release which does not ship the mu-plugins directory. A Blueprint, to work on both, would need to create that file. If we continue creating it for the user, it will mess with locally mounted WordPress installations.

@adamziel
Copy link
Collaborator Author

Let's ensure writeFile to mu-plugins would create the underlying directory under the hood to keep the existing Blueprints working. That workaround won't make it to the Blueprints v2 PHP library and we'll likely continue using this TypeScript code for maximum compat.

@adamziel adamziel merged commit daf9c52 into trunk May 28, 2024
5 checks passed
@adamziel adamziel deleted the produce-minified-wp-without-sqlite-plugin branch May 28, 2024 21:49
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.

3 participants