Add Live Preview Blueprint for WordPress.org

[adamziel]

Hi! I noticed that EWWW Image Optimizer doesn't have a Live Preview button on its WordPress.org page yet, so I created a blueprint configuration for it.

About Live Preview

The Live Preview feature allows users to try plugins directly in their browser without installing anything, powered by WordPress Playground. This can significantly increase user engagement and conversions.

Learn more:

• Plugin Handbook - Previews and Blueprints
• WordPress Playground Documentation

What's Included

This PR adds .wordpress-org/blueprints/blueprint.json which configures the preview to:

• Install and activate EWWW Image Optimizer
• Log users in automatically
• Direct them to the EWWW Image Optimizer settings page
• Pre-configure optimization settings (WebP conversion, lazy loading, auto-optimization, etc.)

Testing the Blueprint

You can test this blueprint right now in WordPress Playground (before merging):

This lets you see exactly how users will experience the Live Preview!

How to Enable

After merging this PR, you'll need to manually deploy the blueprint to your WordPress.org SVN repository:

Step 1: Deploy Blueprint to SVN

The .wordpress-org directory needs to be deployed to the SVN assets directory:

# Check out your plugin's SVN assets directory
svn co https://plugins.svn.wordpress.org/ewww-image-optimizer/assets svn-assets
cd svn-assets

# Create the blueprints directory if it doesn't exist
mkdir -p blueprints

# Copy the blueprint from your Git repository
cp /path/to/ewww-image-optimizer/.wordpress-org/blueprints/blueprint.json blueprints/

# Add and commit to SVN
svn add blueprints/blueprint.json
svn ci -m "Add WordPress Playground blueprint for Live Preview"

Step 2: Enable Live Preview on WordPress.org

Once the blueprint is in SVN:

1. Log in to your WordPress.org account
2. Go to your plugin's Advanced page
3. Scroll to "Toggle Live Preview"
4. Set the preview to "public"

The Live Preview button will then appear on your plugin page!

You can also test before enabling publicly by adding ?preview=1 to your plugin URL: https://wordpress.org/plugins/ewww-image-optimizer/?preview=1

Optional: Automate Future Deployments

To avoid manual SVN steps in the future, you could:

• Add the .wordpress-org directory to your existing deployment process
• Create a deployment script that syncs both the plugin and assets to SVN
• Use GitHub Actions with the WordPress Plugin Deploy Action

Customization

Feel free to customize the blueprint to better showcase your plugin's features. You can:

• Change the landing page
• Add demo content or sample data
• Configure specific PHP/WordPress versions
• Add setup steps

See the Blueprint documentation for all available options.

---

Let me know if you'd like any adjustments to better showcase EWWW Image Optimizer!

[nosilver4u]

Hi @adamziel, I've tested EWWW IO on Playground before and never had much luck. Perhaps things have changed, but as-is, this blueprint still doesn't work to test the basic image compression functionality of EWWW IO, nor does WebP conversion seem to work.

To my knowledge, it's impossible to make the binaries work for "local" compression, so then compression would require using our API. For WebP Conversion, imagick is missing, and the version of GD supported on playground isn't high enough (needs at least 2.2.5), so that also needs the API.
We do make that freely available for lossless JPG compression and also for WebP, but something still seems to block communication with our API.

I wonder if the blueprint just needs networking enabled? I noticed from a post elsewhere that someone used this to try and get wp_remote_post to work:

"phpExtensionBundles": [
    "kitchen-sink"
],
"features": {
    "networking": true
},

Since it seems you work on playground, hopefully you have more insight on how we could make that work better? FYI, the error we get from wp_remote_post is quite strange:
"Missing header/body separator"

[adamziel]

@nosilver4u thank you for sharing this! I'm looking into upgrading GD to the latest version. Imagick missing is weird as phpinfo shows it's installed with WEBP support:

EWWW also seems to be indicating imagick support in wp-admin:

EWWW\Base::imagick_supports_webp()
EWWW\Base::imagick_support()
yes it does

What did you notice was missing?

To my knowledge, it's impossible to make the binaries work for "local" compression, so then compression would require using our API

I'm curious to learn more – what do you mean by impossible? I see EWWW recommends jpegtran, optipng, and gifsicle extensions. Would shipping them solve it? Or does that go deeper?

As for the networking error – yeah, the error message is unfortunate but it indicates networking is disabled. I've updated the Blueprint to enable it, and the request seems to pass through to https://optimize.exactlywww.com/verify/ now. The server returns {"status":"expired","error":"expired","t":"exceeded","banned":"ip"}, though, so perhaps it observed a larger traffic from the CORS proxy already and blocked it. Would you be open to allowlisting the https://wordpress-playground-cors-proxy.net/ server?

[nosilver4u]

Huh, I see Imagick w/ WebP also, so I wonder what was going on? I didn't keep the debug log, but from what I remember, the WebP conversion with Imagick was failing. It isn't failing now though, but optimization still seems to have failed somehow.
Interestingly, background/async mode seems to be working, which is surprising.

Thanks for making those changes for networking too! I'll dig into it more later and see what is going on with the optimization side of things.

With the binaries, they run via exec() and the architecture returned via PHP is 'wasm32'. I had assumed exec() simply couldn't function, but it seems it tries to, but for some reason (the value of PHP_OS most likely) EWWW IO installs the Linux versions of the binaries.

I'm not sure what actual sort of command-line environment is available inside of WebAssembly, does it mimic the host OS perhaps? If so, then we'd need to have a way to detect that and install the correct binaries and see if that works at all. Or like you said, if it were possible to somehow compile and ship those inside of the playground environment, that should work also.

I admit I've just assumed there isn't enough of an actual OS inside there to make local (non-API) optimization happen, but I'd be happy to be proved wrong!

[nosilver4u]

Ugh, and I forgot you mentioned the CORS proxy was being blocked, which is likely why optimization is failing! I'll check the logs and see why that is happening.

[nosilver4u]

Alright, the proxy issue should be resolved now, as I'm not seeing any more banned IP entries in our logs. The IP wasn't actually banned, but we had an issue parsing IPs when multiple proxies were involved.
Unfortunately, I'm still getting "optimize failed: Missing header/body separator" even though the settings say networking is enabled. I just used your original "Try it in Playground" link, but that should work, right?

[nosilver4u]

Well, I don't know what's going on. I thought I'd test it out again to see if we can get this rolling, but I can't hardly upload an image or do anything on there. It's all super slow and glitchy right now, certainly not something I'd want our users to experience.