Blog

When you create a Playground instance using Quick Playground and the Pro extension, you will see Save Playground as a menu option on the black admin bar at the top of the screen. This option only appears when you are logged into the website.

The content saved from the Playground is saved on your live web server, but not in the WordPress database. Instead, snapshots of your posts, pages, metadata, and settings, are saved to a
wp-content/uploads/quick-playground directory on your server. Note that this content is potentially publicly accessible. Don’t record sensitive information like API keys (unless they’re specifically “sandbox” keys) within your playground and save them in this way.

The Playground Sync function of Quick Playground Pro makes it possible to read in this data and selectively apply updates to your live website. For example, I’ve made changes to a block theme such as altering the header template part and imported those changes to my live site.

Images Saved to a Playground Are Also Saved to Your Website

Quick Playground Pro detects when an image has been uploaded into the Playground and near-simultaneously tries to upload a copy of it to your website.

An API endpoint receives these images and stores them to your website, using the WordPress sideload function.

This means they are accessible through the Media screen of your WordPress dashboard, even though they may not be associated with your live content.

If you then import a blog post with a featured image, that image and the associated “attachment” document will be waiting on your live server.

To keep the file uploads to a manageable size, I take advantage of the automatic resizing WordPress does automatically when you upload a large image, such as a photo taken straight from your phone or camera.

To be uploaded over a REST API, the image needs to be converted to base64 encoding and unpacked on the server. After much experimentation, I’ve found this works best for images of 750 kilobytes or less. Typically, the thumbnail, medium, medium-large, and large versions of the image will be saved, along with one larger version.

In most cases, when you embed an image in a page or blog post, WordPress will default to using the “large” or “medium” version anyway. On the other hand, you may find that the big, beautiful featured image or cover image you uploaded in the Playground is less high-resolution when you come back for your next Playground session, or if you import that content into your live website. Still, it will be there for placement, and you can always replace the version on your live website with the original image.

The ability to save images from the Playground is turned on by default for Quick Playground Pro instances, with the exception of those you configure as demos. It should be reasonably secure, but if you don’t trust it you can disable it with a toggle at the bottom of the Playground Builder form.

Featured Image by Hafijur Rahman from Pixabay

Like any WordPress site, particularly one hosting custom software, WordPress Playground instances can crash. The crash might be the result of including a plugin that doesn’t work well in the Playground environment (I’ve found this to be true of certain performance optimization plugins) or a bug in my own Quick Playground code.

That’s one reason Quick Playground handles some content import tasks with a series of “Loading x images” messages that appear after the initial Playground landing page has loaded. That’s as opposed to handling them as “steps” defined in a Playground blueprint.

If something goes wrong within a Playground blueprint step, the options for debugging the problem are very limited. Playgrounds do have an error log you can view, but it doesn’t always capture the relevant details.

If it’s possible one of the plugins you’re including is glitching, here’s where you can check the log for any errors that reference the plugin by name.

If a bug crops up in the data import process, it tends to be easier to track down the cause.

Loading images is a step where I encountered a series of hard-to-debug crashes. So the final step of defined in the blueprint, the one that gets a basic version of the website ready to load, imports the HTML and block content.

I found it’s not necessary to download load all the images referenced on a page — letting them continue to point to your live website is just fine — but for post thumbnails / featured images, WordPress seems to expect the image to be local and associated with a document that has the “attachment” post type. This is also true for your site icon and site logo.

Do you think the Quick Playground takes too long to load? Optimizing that process is certainly high on my todo list. I’d appreciate suggestions or code contributions.