-
Notifications
You must be signed in to change notification settings - Fork 304
Export just wp-content instead of full WordPress #780
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
Conversation
7316553
to
66001e8
Compare
c626cbb
to
9d48969
Compare
...ound/blueprints/src/lib/steps/apply-wordpress-patches/wp-content/mu-plugins/0-playground.php
Outdated
Show resolved
Hide resolved
b0ffb5d
to
015ece2
Compare
...ound/blueprints/src/lib/steps/apply-wordpress-patches/wp-content/mu-plugins/0-playground.php
Outdated
Show resolved
Hide resolved
...ound/blueprints/src/lib/steps/apply-wordpress-patches/wp-content/mu-plugins/0-playground.php
Show resolved
Hide resolved
}); | ||
</script> | ||
<?php | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there enough of a warrant to move this into the service worker? or would that leave out CLI Playgrounds?
or perform it on render output from PHP to ensure that we don't miss it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only relevant for the web version so you're on to something here.
The main challenge with doing it outside of WordPress, like in the service worker or the PHP rendering pipeline, is deciding whether the output is meant to be a document displayed by the browser. There may be static HTML files, XHR queries, HTML-like files, CSS files, binary blobs etc, but we only ever want to add this code snippet to UI rendered by WordPress.
packages/playground/blueprints/src/lib/steps/import-wp-content.ts
Outdated
Show resolved
Hide resolved
The importFile step, which allows developers to import WordPress content bia WXR and WXZ files, got accidentally removed in Pull Request #780. This commit restores that step. Testing instructions Go to the following localhost URL and confirm the WordPress reflects the non-standard content it imported from WordPress theme unit tests data: http://localhost:5400/website-server/#{%22steps%22:[{%22step%22:%22login%22},{%22step%22:%22importFile%22,%22file%22:{%22resource%22:%22url%22,%22url%22:%22https://raw.githubusercontent.com/WordPress/theme-test-data/master/themeunittestdata.wordpress.xml%22}}]} In particular, the menu should say twitter.com, facebook.com etc As the Playground codebase starts supporting using WordPress in unit tests, let's add a test case for this step. Closes #833
The importFile step, which allows developers to import WordPress content bia WXR and WXZ files, got accidentally removed in Pull Request #780. This commit restores that step. Testing instructions Go to the following localhost URL and confirm the WordPress reflects the non-standard content it imported from WordPress theme unit tests data: http://localhost:5400/website-server/#{%22steps%22:[{%22step%22:%22login%22},{%22step%22:%22importFile%22,%22file%22:{%22resource%22:%22url%22,%22url%22:%22https://raw.githubusercontent.com/WordPress/theme-test-data/master/themeunittestdata.wordpress.xml%22}}]} In particular, the menu should say twitter.com, facebook.com etc As the Playground codebase starts supporting using WordPress in unit tests, let's add a test case for this step. Closes #833
The importFile step, which allows developers to import WordPress content bia WXR and WXZ files, got accidentally removed in Pull Request #780. This commit restores that step. ## Open questions `importFile` sounds ambiguous. What if it was split into two distinct steps called `importWxr` and `importWxz`? Then, the new `importWpFiles` step could be called `importWpContentDirectory` instead. ## Follow-up work The importFile step uses `DOMParser` which isn't available in Node.js. It could, instead: * Call the appropriate import-related PHP functions directly, or... * Use the HTML Tag Processor available in WordPress 6.3+ (and polyfill it in the older WordPress versions). ## Testing Instructions Go to the following localhost URL and confirm the WordPress reflects the non-standard content it imported from WordPress theme unit tests data: http://localhost:5400/website-server/#{%22steps%22:[{%22step%22:%22login%22},{%22step%22:%22importFile%22,%22file%22:{%22resource%22:%22url%22,%22url%22:%22https://raw.githubusercontent.com/WordPress/theme-test-data/master/themeunittestdata.wordpress.xml%22}}]} In particular, the menu should say twitter.com, facebook.com etc As the Playground codebase starts supporting using WordPress in unit tests, let's add a test case for this step. Closes #833 CC @eliot-akira @aplamada
Description
This PR modifies the Playground import/export feature to focus on the wp-content directory instead of the entire WordPress installation.
wp-content
directory without Playground artifacts like thesqlite-database-integration
plugin or the0-playground
mu-pluginwp-includes
,wp-admin
, and thewp-content
directories. Thewp-content
directory gets a special treatment in that Playground artifacts such as thesqlite-database-integration
and the0-playground
mu-plugin are restored.Rationale
Exporting the full WordPress from Playground doesn't make much sense. It's an optimized bundle that's missing some files, it locks you in in an outdated WordPress version, and it inflates the zip size. What matters is the
wp-content
directory. This should enable easy GitHub-based management of WordPress core feature showcases.Remaining work
Other changes
replaceSite
step. SourceGraph suggests it wasn't used in any public repo 🤞 Use the newimportWordPressFiles
step instead.Testing
wp-content
directory