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.
Leave a Reply