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

Blueprints: Define constants in auto_prepend_file, silence warnings related to redefining those constants #1400

Merged
merged 4 commits into from
May 15, 2024

Conversation

adamziel
Copy link
Collaborator

Changes the default meethod of defining PHP constants from rewriting
the define() calls in wp-config.php to pre-defining constants via
an auto_prepend_file.

Problem solved by this PR

Playground needs to define some WordPress constants like SITE_URL or HOME_URL.
Unfortunately, the site loaded into Playground may already have a
conflicting define() call in its wp-config.php. Historically, we'va
avoided PHP warnings by rewriting the define() calls in the wp-config.php file.

It works quite well, but when the wp-config.php file is mounted from a
local directory, Playground would change its contents. This is typically
not what the user wants. These changes would show up in git commit and
would be annoying at best, or get accidentally commited to the
repository at worst.

Implementation

Instead of rewriting the wp-config.php, this PR changes the default
behavior to defining the constants in a pre-loaded PHP file. This
triggers PHP warnings, but we're silencing them using a custom
error handler. As a result, Playground constants take precedence
over custom define() calls in a way that doesn't trigger warnings.

This is an easy and hacky way of implementing this. A better solution
would be a PHP.wasm-level patch to enable "warning-less constants" that
can't be redefined but the conflicting define() call fails silently.

Testing instructions

Confirm the unit tests pass

…elated to redefining those constants

Changes the default meethod of defining PHP constants from rewriting
the `define()` calls in wp-config.php to pre-defining constants via
an `auto_prepend_file`.

 ## Problem solved by this PR

Playground needs to define some WordPress constants like SITE_URL or HOME_URL.
Unfortunately, the site loaded into Playground may already have a
conflicting `define()` call in its `wp-config.php`. Historically, we'va
avoided PHP warnings by rewriting the `define()` calls in the `wp-config.php` file.

It works quite well, but when the `wp-config.php` file is mounted from a
local directory, Playground would change its contents. This is typically
not what the user wants. These changes would show up in `git commit` and
would be annoying at best, or get accidentally commited to the
repository at worst.

 ## Implementation

Instead of rewriting the `wp-config.php`, this PR changes the default
behavior to defining the constants in a pre-loaded PHP file. This
triggers PHP warnings, but we're silencing them using a custom
error handler. As a result, Playground constants take precedence
over custom define() calls in a way that doesn't trigger warnings.

This is an easy and hacky way of implementing this. A better solution
would be a PHP.wasm-level patch to enable "warning-less constants" that
can't be redefined but the conflicting `define()` call fails silently.

 ## Testing instructions

Confirm the unit tests pass
@adamziel adamziel added this to the Boot Protocol milestone May 15, 2024
@adamziel adamziel mentioned this pull request May 15, 2024
1 task
@adamziel
Copy link
Collaborator Author

E2E failures are consistent with trunk, everything else seems to work. @brandonpayton @bgrgicak does this change seem fine?

it('should not raise a warning when conflicting with a user-defined constant', async () => {
// Preload the warning-silencing error handler
await enablePlatformMuPlugins(php);
await preloadRequiredMuPlugin(php);
Copy link
Member

@brandonpayton brandonpayton May 15, 2024

Choose a reason for hiding this comment

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

nitpicking something that wasn't added in this PR:
Should this name be a plural preloadRequiredMuPlugins?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Perhaps! Also, I'm questioning whether these two functions should be separate :-)

Copy link
Member

@brandonpayton brandonpayton left a comment

Choose a reason for hiding this comment

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

I read through the changes, and this looks fine to me.

@brandonpayton
Copy link
Member

It looks good, in fact. :)

@adamziel adamziel merged commit afffbee into trunk May 15, 2024
4 of 5 checks passed
@adamziel adamziel deleted the define-constants-without-changing-wp-config branch May 15, 2024 15:21
@bgrgicak
Copy link
Collaborator

Looks great! I'm really glad we managed to move this to internals.

adamziel added a commit that referenced this pull request May 16, 2024
…e the original zip

Fixes a regression introduced in
#1400 that caused
the original zip file to be deleted.

Closes #1409
adamziel added a commit that referenced this pull request May 16, 2024
…e the original zip (#1412)

Fixes a regression introduced in
#1400 that caused
the original zip file to be deleted.

To test, confirm you can preview
WordPress/wordpress-develop#6318 on this branch.

Closes #1409
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

None yet

3 participants