Skip to content

Add @wp-playground/wordpress package – a new home for WordPress builds #837

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

Merged
merged 25 commits into from
Dec 5, 2023

Conversation

adamziel
Copy link
Collaborator

@adamziel adamziel commented Dec 2, 2023

Description

Important

Don't be scared by the File Changed: 5,000+ message at the top. This PR can be reviewed just fine.

Most of the updates refer to moved WordPress static assets. The actual relevant changes proposed in this PR are small configuration updates in about 50 files.

Moves WordPress data modules to a new dependency-free module @wp-playground/wordpress. Now every Playground module may import WordPress data modules and, e.g., use them in unit tests.

Before this PR, WordPress data modules lived in the @wp-playground/remote package. They couldn't be easily imported, and even if they could, that would often create a circular dependency problem.

Related to #463

Implementation details

  • All WordPress bundling functions are updated to point to the newly created module.
  • The @wp-playground/remote public directory is now set to packages/playground/wordpress/public as that's where all the WordPress files live. The remote package ships no public assets of its own, except for the .htaccess file which is now handled by a dedicated plugin.
  • The new module also exports RecommendedPHPVersion = '8.0' to help avoid hardcoding a version number in unit tests shipped by other Playground packages.
  • @wp-playground/wordpress has a bundle-wordpress nx task that bundles WordPress. It's deliberately not called build so that nx does not mistake it for a build dependency (which would trigger it on every npm run dev).
  • Loading the data module from the filesystem is implemented in @php-wasm/node by implementing the getPreloadedPackage Emscripten handler. The handler runs a few safety checks and then reads the data module from the disk via readFileSync.
  • A new unit test for the setSiteOptions() Blueprint step has been added to confirm that WordPress is actually correctly loaded in Node.js.

Remaining tasks

  • Run the new bundle task to confirm it creates the correct WordPress files in the correct directories.
  • Add a unit test to the new module to explicitly test loading WordPress (instead of implicitly relying on the setSiteOption test)

Testing instructions

Confirm the CI tests pass. E2E tests will confirm the playground.wordpress.net website still loads all the supported WordPress versions, and the unit tests will confirm that WordPress is correctly loaded in Node.js.

@adamziel adamziel added [Type] Enhancement New feature or request Tests [Type] Reliability Playground uptime, reliability, not crashing labels Dec 2, 2023
@adamziel adamziel marked this pull request as ready for review December 3, 2023 12:30
@adamziel adamziel requested a review from a team as a code owner December 3, 2023 12:30
@adamziel adamziel changed the title Draft: Add wp-playground/wordpress module New @wp-playground/wordpress module for WordPress builds Dec 3, 2023
@adamziel adamziel changed the title New @wp-playground/wordpress module for WordPress builds Add @wp-playground/wordpress package to host WordPress builds Dec 3, 2023
@adamziel adamziel changed the title Add @wp-playground/wordpress package to host WordPress builds Add @wp-playground/wordpress package – a new home for WordPress builds Dec 3, 2023
@adamziel
Copy link
Collaborator Author

adamziel commented Dec 3, 2023

It seems to be working!

  • Local dev mode works
  • Tests are running
  • The built website works as expected

I'll let it sit for a bit. If noone spots any blockers, let's rebase and merge 🤞

@adamziel adamziel self-assigned this Dec 4, 2023
To use real WordPress in unit tests, we need to import it from
somewhere. At the moment, there is no easy way to do it without running
into a circular dependency problem. This PR adds a new module that has
no explicit import dependencies to solve that problem. It still does
have an implicit path-based dependency on the remote package, which
isn't ideal. Perhaps the build WordPress files could be moved to
yet another dependency-free module such as wp-playground/wordpress and
the remote package would use those files in its build process.
@adamziel adamziel force-pushed the add-wordpress-module branch from f4c8b2c to 3964449 Compare December 5, 2023 12:39
@adamziel adamziel merged commit 99114b6 into trunk Dec 5, 2023
@adamziel adamziel deleted the add-wordpress-module branch December 5, 2023 13:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Tests [Type] Enhancement New feature or request [Type] Reliability Playground uptime, reliability, not crashing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant