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

Propose PRs for the projects that are now patched ad-hoc #91

Open
adamziel opened this issue Dec 16, 2022 · 4 comments
Open

Propose PRs for the projects that are now patched ad-hoc #91

adamziel opened this issue Dec 16, 2022 · 4 comments

Comments

@adamziel
Copy link
Collaborator

Let's start Pull Requests to improve the projects WordPress Playground is currently patching ad-hoc:

These patches are not specific to the WordPress Playground project, they enable either WebAssembly compatibility or browser compatibility.

@eliot-akira
Copy link
Collaborator

eliot-akira commented Dec 17, 2022

About the WordPress SQLite plugin, I heard people have started work on integrating it directly into WP core. From the following article:

Let’s make WordPress officially support SQLite

The comment thread at the bottom links to the newest development, which is the SQLite Integration module in the Performance Lab plugin.

Implement new experimental SQLite integration module #547

The code for the SQLite implementation was copied from https://github.com/aaemnnosttv/wp-sqlite-db/blob/master/src/db.php, which is a fork of the original work on the sqlite-integration plugin. It was then refactored a bit, coding-standards were applied, and an integration with the plugin was built.

I'm guessing the code under wp-includes/sqlite will be eventually moved into core.


Just for curiosity, I checked what the current patch in Playground does to the SQLite plugin; then searched for the corresponding lines in the new SQLite module.

https://github.com/WordPress/performance/blob/239c3688cf1d8726ed44d20b920d11ebd4128c3d/modules/database/sqlite/wp-includes/sqlite/class-perflab-sqlite-pdo-engine.php#L996-L998

So when this SQLite support does get into core, I imagine the patch can be made into a pull request there (instead of the plugin which will be obsolete at that point).

@adamziel
Copy link
Collaborator Author

adamziel commented Jan 30, 2023

An overview of the patches applied by WordPress Playground: #119 (comment)

@adamziel
Copy link
Collaborator Author

The srcDoc patch may need to forever remain a Playground-applied patch.

For Gutenberg, we'd need to replace <iframe srcDoc="<!DOCTYPE html>"> with <iframe src="doctype.html"> around here:

https://github.com/WordPress/gutenberg/blob/d6a482edca22349d61b54b16b71ffc21d6d64c16/packages/block-editor/src/components/iframe/index.js#L243-L248

Otherwise we have to patch it ourselves:

/**
* Pair the site editor's nested iframe to the Service Worker.
*
* Without the patch below, the site editor initiates network requests that
* aren't routed through the service worker. That's a known browser issue:
*
* * https://bugs.chromium.org/p/chromium/issues/detail?id=880768
* * https://bugzilla.mozilla.org/show_bug.cgi?id=1293277
* * https://github.com/w3c/ServiceWorker/issues/765
*
* The problem with iframes using srcDoc and src="about:blank" as they
* fail to inherit the root site's service worker.
*
* Gutenberg loads the site editor using <iframe srcDoc="<!doctype html">
* to force the standards mode and not the quirks mode:
*
* https://github.com/WordPress/gutenberg/pull/38855
*
* This commit patches the site editor to achieve the same result via
* <iframe src="/doctype.html"> and a doctype.html file containing just
* `<!doctype html>`. This allows the iframe to inherit the service worker
* and correctly load all the css, js, fonts, images, and other assets.
*
* Ideally this issue would be fixed directly in Gutenberg and the patch
* below would be removed.
*
* See https://github.com/WordPress/wordpress-playground/issues/42 for more details
*/

The problem is: The block-editor Gutenberg package gets shipped in npm and also merged to WordPress, and then it can be used in many different ways:

  • Loaded in WordPress from the default /wp-content URL you'd expect
  • Loaded in WordPress by a script concatenator or some cache plugin
  • Bundled outside of WordPress with a bundler that doesn't include HTML files in the build
  • Loaded from unkpg
  • ...probably way more

Which means there's no easy way to replace srcDoc with src. We can do it in this project, because we can fix the loading sequence in place, but it doesn't sound like a great idea for a generic Gutenberg package.

adamziel added a commit that referenced this issue May 22, 2023
Gutenberg loads the site editor using <iframe srcDoc="<!doctype html>"
to force the standards mode and not the quirks mode:

WordPress/gutenberg#38855

This commit patches the site editor to achieve the same result via
<iframe src="/doctype.html"> and a doctype.html file containing just
`<!doctype html>`. This allows the iframe to inherit the service worker
and correctly load all the css, js, fonts, images, and other assets.

More details: #91 (comment)
adamziel added a commit that referenced this issue May 22, 2023
Gutenberg loads the site editor using <iframe srcDoc="<!doctype html>"
to force the standards mode and not the quirks mode:

WordPress/gutenberg#38855

This commit patches the site editor to achieve the same result via
<iframe src="/doctype.html"> and a doctype.html file containing just
`<!doctype html>`. This allows the iframe to inherit the service worker
and correctly load all the css, js, fonts, images, and other assets.

More details:
#91 (comment)
@adamziel
Copy link
Collaborator Author

srcDoc got replaced for src in WordPress/gutenberg#50875 (comment)

Pookie717 added a commit to Pookie717/wordpress-playground that referenced this issue Oct 1, 2023
Gutenberg loads the site editor using <iframe srcDoc="<!doctype html>"
to force the standards mode and not the quirks mode:

WordPress/gutenberg#38855

This commit patches the site editor to achieve the same result via
<iframe src="/doctype.html"> and a doctype.html file containing just
`<!doctype html>`. This allows the iframe to inherit the service worker
and correctly load all the css, js, fonts, images, and other assets.

More details:
WordPress/wordpress-playground#91 (comment)
@adamziel adamziel added this to the Zero Crashes milestone Feb 29, 2024
@adamziel adamziel moved this to Future work in Playground Board Jun 30, 2024
@adamziel adamziel removed this from the Zero Crashes milestone Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants