Are you familiar with WordLand? I’ve mentioned it on this blog a few times: it’s a WordPress editor, designed for writers.

@davew built WordLand using the WordPress.com REST API, thus making the app available to everyone with a WordPress.com account. Once you’re logged in, you can pick any WordPress site connected to your account. It can be a WordPress.com site. It can also be a site hosted on another platform but using the Jetpack plugin to allow it to communicate with WordPress.com.

It works really well. It allows you to log in only once, to manage and publish on multiple sites from a central editor dashboard. This was one of the ideas behind the WordPress.com REST API when it was first built.

Of course, this means the WordLand app is only available to folks with a WordPress.com account, and using a site that’s either hosted on WordPress.com or where they’re able to install plugins like Jetpack.

If WordLand were to drop that requirement, it would be immediately usable by more people. It would open it to authors on sites where they don’t have permissions to install plugins, for example.

In this post, Dave outlined his idea for making WordLand available for self-hosted WordPress sites.

I’ve thought a bit about what that switch would mean in practice. I thought I’d share my first ideas here, for you Dave to consider as you start working on this project.

In my mind there are a few things to consider to get WordLand to work with self-hosted WordPress sites.

Mapping endpoint requirements

Self-hosted sites ship with a REST API and endpoints, listed here.
Those endpoints allow viewing, publishing and editing posts, which is the base of what WordLand does. They also allow listing and editing categories, uploading media,…

A first step may be to map the WordPress.com API endpoints used by WordLand with their equivalents on self-hosted sites.
The REST API docs will be a big help there. I am thinking you may have all WordLand needs with the endpoints available on all self-hosted WordPress sites today.

As part of that mapping project, you’ll see that the expected schema is different for the 2 APIs. Although similar, there are differences. You’ll find the biggest differences may be in how categories are handled for example, since they are different from site to site. That’s something worth mapping as well, since it will mean making changes to the app accordingly.

Authentication

Once you have the endpoints figured out, you’ll need to tackle what’s probably going to be the hardest part: authentication.

With self-hosted sites, there is no centralized way to handle authentication. Folks will need to authenticate for each site where they want to publish. Application passwords are probably the best approach to take. They are available for all self-hosted sites and don’t require site owners to install anything. You’ll need to build a flow where site owners start by providing a site URL instead of clicking a log in button. That site URL, when passed to WordLand, allows the app to hit the REST API for that site, get the authentication URL, and redirect the site owner there so they can log in and go through the flow to create an application password and then come back to WordLand with that password.
They’ll need to repeat that for every new site they want to use with WordLand.

A WordLand.social account for everyone?

Another alternative may be to first offer every WordLand user an option to log in to an account created with WordLand. The different connections and authentication information for one or more sites would be stored in that account. It would allow WordLand.social to keep working like it does today, as a central platform from which you can publish to multiple sites.

And the extra

Keep in mind that Jetpack and WordPress.com also provide more than just the REST API endpoint and the authentication layers. They also provide other features you rely on in WordLand, like markdown support.

That’s all what comes to mind at first. Hopefully it helps you get started!