Leaving the current drama around WordPress.org aside for now, I believe that there is a use case for WordPress that is heavily underutilized: Using WordPress as a platform for self-hosting.
When people think WordPress, they think publishing platform. And, of course, that’s its nature. It was built for expressing yourself publicly on the internet. But as we have seen over the years, it is also a pretty good framework on which—through its plugin system—almost anything can be built on top of it.
This is especially interesting considering that you can get WordPress hosting easily and for cheap. Even NAS systems like Synology or QNAP support installing WordPress on them.
There are so many services on the internet that have self-hosting options. An interesting website about this is selfh.st. It’s a compilation of different apps, amongst others:
A downside of this plethora of self-hosting apps is that they each have their unique software stack and requirements. While this complexity can be alleviated with virtualization solutions like Docker, it means that with every additional app, the hardware requirements for your host go up.
When using WordPress as a basis for self-hosting, the software requirements for all plugins are about the same, namely PHP and MySQL. This means as soon as you have WordPress hosting, you have your basis for self-hosting, without having to go through software requirements.
Unfortunately, as I mentioned earlier, WordPress out of the box is open and public. Thus, if you want to self-host just for yourself (and friends and family, i.e. logged-in users), the first step needs to be to install a “Private WordPress” plugin.
Then, also, there are not yet many plugins that provide a self-host experience. While I am only doing this on the side (for now), I am working on changing this by building more of these plugins.
I recently realized that this was a big part of what I am trying to do with my Friends plugin. While it even has a public component (you might reblog what you read in it), I framed it as the center of your online activity.
From a self-host perspective, it’s a combined RSS Reader with a publishing platform that has ActivityPub support (thus making it a full Mastodon instance), e-mail and keyword notifications, post format support, etc.
Additionally, its independence from major third-party social networks is equivalent to the goals of self-hosting. It can’t be shutdown on you because the service was bought or turned out to be not profitable enough. Also, you can choose where to host it.
So what does WordPress offer for self-hosting yet? Maybe let’s just revisit what I build and am using myself. These are all WordPress plugins:
For Bookmarking, I also have ported my old project thinkery.me to a Thinkery WordPress plugin, hopefully I’ll have time to give it the finishing touches.
I would love to store my family’s recipies in such a WordPress environment, too.
While self-hosting photo management also sounds tempting, I actually think that a private family blog is a superior alternative. We’re drowning in photos and videos, but being able to keep them along with a title and a story is much better than the endless streams in Google Photos and the like.
I don’t know whether WordPress will ever offer as large a selection of self-hosted apps as WordPress plugins. But I do think that it’s a path worth following. It might not be a nerd’s favorite choice, but easy hosting and administration could allow WordPress to democratize self-hosting next.
Have you ever hesitated to install a new WordPress plugin, worried about whether it would meet your needs? Likely, many potential users of your plugins feel the same way.
Of course, it was always possible to test a plugin before installing it on my own blog: I would have a dedicated testing site somewhere, later there were services like TasteWP where you could get a “throwaway WordPress” for a few days to install a plugin.
Take a look at the screenshot below to see what the “Live Preview” button looks like in the plugin directory. Have you already seen one or even tried it? Unfortunately, currently only a small number of plugins offer it. Let’s change that–I encourage you to make your plugins one of them!
So, why doesn’t the plugin directory offer the Live Preview option by default? When the feature was first introduced, it actually did. But there was significant pushback because many plugins require specific configuration to be properly showcased—similar to how a theme needs to be set up to “look like the demo.”
Live Preview = Commit a blueprint.json + Enable It
Create a Blueprint and commit it to SVN in the location assets/blueprints/blueprint.json
In the Advanced section of your WordPress.org Plugin page, go to the Toggle Section and enable it:
Creating a Blueprint
A Playground blueprint—though the name may change, as Matt Mullenweg mentioned at WordCamp Europe—is a JSON file that configures WordPress Playground in a certain way before it becomes available to the user.
As a developer, likely JSON is not an unfamiliar format which you can just create in your editor. A JSON schema is available to validate your blueprint.json, and a Blueprint Builder offers an in-browser text editor with autocompletion.
I think of the available Blueprint Steps as if they were machine code. They are quite generic and powerful but it can be hard to understand what you can actually achieve with them.
Thus, the Step Library offers “virtual steps” that do more sophisticated things and “compile” to existing blueprint steps.
The ability to use these more complex operations with a single step can inspire you about what you can achieve with a blueprint. Here are some examples:
addFilter: Add code to filter a hook provided by WordPress or a plugin.
addPage: Save the content of a page and optionally set it as the homepage.
addPost: Create a post with a certain post type and optionally register that post type at the same time.
fakeHttpResponse: Respond to a wp_remote_request with arbitrary data inside playground.
showAdminNotice: Can be used to explain to the user what’s going on.
You don’t need the Step Library for any of these but it makes it very convenient and accessible. In the resulting blueprint you can also see how it achieves the tasks if you are curious and need to adapt them to your needs.
Provided with these tools, let’s continue to actually creating a blueprint.json for your plugin. What should you focus on?
Tip 1: Provide a landingPage URL
Even if your plugin doesn’t need a lot of setup, likely it has a settings page or some other page where you first explain what your plugin is for. By default, a blueprint will take you to the site’s front page, so you should change the landing page it to the page where your plugin shows it’s call to action.
{
"landingPage": "/friends/",
[...]
}
In the Step Library, you can use the setLandingPage step to set it. A good way to get the URL is to open your plugin in Playground and navigate to the right page. Playground will show you the URL you need to use in its fake address bar.
Tip 2: Add Demo Data and Dependencies
It heavily depends on what your plugin does, but similarly to when you take screenshots of your plugin they become meaningful when you show data.
If your plugin needs another plugin to run, you can use the installPlugin step to do so before installing yours.
Tip 3: Overcome Playground Limitations
Communication with Your Servers
Because WordPress Playground runs inside your browser, it is limited by the security restrictions of JavaScript. For example, you can only make cross-domain requests when the endpoint supports CORS.
So if your plugin needs to talk to your servers, you could enable CORS on those endpoints. But possibly this is not desirable to you, for example because you depend on user credentials.
Another solution is to use the fakeHttpResponse of the step library: Just by using WordPress hooks, it will respond to an HTTP request with the desired (demo content) response.
As it can be a bit tedious to identify which HTTP requests need a fake response, the fakeHttpResponse will report in the error log what it did not fake because it had no respective response available.
So to start off, you can just add an empty fakeHttpResponse step and then look at the error log for which requests you need to supply.
If you have to fake large HTTP responses, or a large number of them, you can use a ZIP file to supply the responses as TXT files outside of the blueprint (with the filename being the URL with .toLowerCase().replace( /[^a-z0-9-_]+/gi, '-' ).replace( /-+$/g, '' )).
Replay Your Own Configuration
Sometimes your user needs to go through a setup wizard before they can actually see the functionality. Maybe this is desireable because you also introduce the user to what the plugin does.
On the other hand, you are asking a user who is likely still in “passive mode” to do more than just click around in your plugin. Thus, it can make sense to rather provide a blueprint that already has the plugin configured. Just how?
Of course, you could figure out all the things that your plugin does during setup (like the options it sets etc), or you could use the blueprintRecorder step of the Step Library. It installs my blueprint recorder plugin alongside your plugin which will log all SQL inserts and updates made as you interact with your WordPress. Then, via the Blueprint menu item, you can see the blueprint it needs to bring back WordPress to the current state.
Bonus Tip: Provide Multiple Blueprints
Although the WordPress.org Plugin Directory only supports one blueprint.json for Live Preview at the moment, it can make sense to work creating a few of them that showcase different parts of your plugin.
For example, in Translate Live there is already support for this: with a dropdown on the top right you can choose between all available blueprints for the plugin being translated. Especially for that use case, it can be very useful not to have to go through configuration before you can actually translate the plugin using inline translation.
A Welcome PageAn already configured plugin
I think of Blueprints of interactive screenshots. You can use Playground links with different blueprints already today from your own product pages.
I hope that the WordPress.org Plugin directory will support multiple blueprints at some point. But to do that, many more plugins should show what a great way it is to showcase themeselves!
If you have a plugin listed in the WordPress.org directory, I encourage you to take a few minutes to create a blueprint and enable Live Preview. Not only will you enhance your plugin’s listing, but you’ll also empower users to easily try it out!
