Export and Import Playground instance

[adamziel]

Phase 1: Let's enable exporting the current Playground, including all the filesystem and database changes, as a downloadable file. Let's enable importing that bundle later on.

Phase 2: Let's include the current cookies, the open page, forms state, and even the scroll position.

This would open doors to:

• Retaining the playground state after a page refresh
• Bug reports with a reproduction attached
• Tactically embedding Playgrounds with a specific WordPress state, e.g. as a preview in a translation editor
• Building a site in the Playground and exporting it to a web host
• Turning your existing site into a Playground to play with changes

Prior art:

• Woo import/export plugin
• WordPress WXR export format
• WordPress WXZ export plugin

[adamziel]

Also relevant: https://github.com/WordPress/wordpress-playground/issues/19

[danielbachhuber]

@adamziel Following up our thread:

Out of curiosity, what was the reasoning behind the decision to use the WordPress Importer, versus exporting whatever state file could be created to also address https://github.com/WordPress/wordpress-playground/issues/19

WordPress importer is interoperable with regular non-Playground WordPress sites – you can move sites between offline and in-browser in both directions.

Just so it's stated, highlighting a few downsides we may run into: uploaded media files won't be included, installed plugins won't be included, and options/users won't be included.

Any idea how to close that gap without building a dedicated Playground Importer plugin?

I don't think there's a silver bullet, unfortunately. 😞

The most common paths for WordPress export -> import workflow are:

1. WordPress WXR - includes content from the database (posts, pages, navigation items, terms, etc.) but doesn't include uploaded media files, anything related to the options table (installed plugins, plugin configuration), or users.
2. Database + wp-content directory ZIP - includes everything but can be quite large, contain data you don't actually want to include, and the exported database will overwrite whatever you already have in the database.

Worth noting some other challenges:

• A full database export can include API secrets, etc.
• The plugin references stored in the options table don't necessarily correlate with WordPress.org plugins. A custom or premium plugin may have the same <plugin-directory>/<plugin-file>.php as a WordPress.org plugin. If you don't include the actual plugin file on the export, reinstalling the plugin can be difficult.

A long time back, I started a project to provide a solution in-between WXR and database + wp-content: https://github.com/boxuk/dictator

I stopped working on it because I didn't want to continue down the rabbit hole of abstracting the options table to YAML files. It also didn't solve the problem of media uploads.

To me, as a naive layperson, it seems like we could solve both this and #19 by creating a way to "dump" or "stash" all of the browser session-specific data into an archive, and then initiate a new browser session from that file. Even cooler is if we could store the user's current page, scroll position, etc., so you could "1 click" launch exactly where they were at.

[adamziel]

@akirk shared this with me:

• Export WXZ will have WordPress generate WXZ files as export.
• WordPress Importer (branch import-wxz) will add WXZ support to the importer plugin

[adamziel]

One more from @danielbachhuber: VersionPress – it's for versioning the database. It creates a filesystem representation of the WordPress database, writes a copy of the database to the filesystem with this abstraction, and uses native Git for version control.

Also:

Only MySQL holds all of the data. WXR is widely adopted.

[adamziel]

More thoughts: This issue has different import/export goals than WordPress core. WordPress Playground imports:

• Must import quickly. Therefore they won't be large or split between multiple export files.
• (phase 2) Won't contain large media files for performance reasons. Those should be statically hosted and referenced by a URL.
• (future) Should be composable. I'd like to build a blog+ecommerce Playground by combining a blog export file and a Woo export file.

[adamziel]

Export/import for full site alworks for some time already. As for composability, Blueprints now allow that - including importing WXZ and WXR files. Let’s close this higher level issue and use smaller ones for any missing features that come up.