WordLand on self-hosted sites
Herve Family
3
Posts
2
Posters
16
Views
-
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!
-
Why not offer both options? Access WordLand.social and any connected sites with or without WordPress.com and Jetpack.
And what about Gravatar as the gateway to federated WordPress and the whole Fediverse/open web?
Technically a Gravatar account also comes with a WordPress.com account, “but it does not require you to have a WordPress site, or use any other services from WordPress.com or Automattic.”
The optics of independence are better and more manageable with the Gravatar brand — even better if the .com requirement is minimized and clarified.
-
Why not offer both options? Access WordLand.social and any connected sites with or without WordPress.com and Jetpack.
And what about Gravatar as the gateway to federated WordPress and the whole Fediverse/open web?
Technically a Gravatar account also comes with a WordPress.com account, “but it does not require you to have a WordPress site, or use any other services from WordPress.com or Automattic.”
The optics of independence are better and more manageable with the Gravatar brand — even better if the .com requirement is minimized and clarified.
@dpknauss Yep, I agree we could have both options.
I don’t know if Gravatar is a good alternative to WordPress.com as a login system, though. As you mentioned, Gravatar and WordPress.com are ultimately the same thing ; it’s a different brand but the same logging system in practice.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@lmorchard wrote a great post, I relate to a lot of what he’s saying in there. It’s hard to pick one part to quote in particular, so I would encourage you to go read the whole thing!
I think recognizing which kind of grief you’re feeling is the actually useful thing here. If you’re mourning the loss of the craft itself—the texture of writing code, the satisfaction of an elegant solution—that’s real, and no amount of “just adapt” addresses it. You might need to find that satisfaction somewhere else, or accept that work is going to feel different. Frankly, we’ve been lucky there’s been a livelihood in craft up to now.
If you’re mourning the context—the changing web, the shifting career landscape, the uncertainty—that’s real too, but it’s more actionable. You can learn new tools. You can push for the web you want, even if it’s a small web. You can grieve and adapt at the same time.
Grief and the AI Split
-
There’s a certain type of blog post I sometimes save for later. Not because I want to re-read it right away, but because it’s worth revisiting in six months to see how things actually played out.
“Migrating PerezBox From WordPress to Flat PHP in 90 Minutes” is one of those posts.
I actually migrated perezbox.com from a full WordPress installation to a flat PHP site with zero external dependencies.
No database. No frameworks. No build tools. No package managers. No node_modules. No Composer. No plugins. Just PHP, HTML, CSS
The “I migrated away from WordPress to something simpler” post is a classic of the genre. I understand the appeal, it can be tempting. In fact, I have tried migrating away from WordPress in the past. About fifteen years ago I tried Jekyll, as a way to experiment and try something new. I came back to WordPress. Twelve years ago I tried Ghost, partly for the same reasons. I came back again. And I published another reaction post 10 years ago, responding to a post saying WordPress was doomed, static site generators were in.
I won’t try to convince you not to try alternatives to WordPress. In fact I think you should, from time to time. It’s healthy to look at what’s on the other side of the fence from time to time, it’s always a good learning experience. I do, however, think we should always be honest with ourselves about the trade-offs.
Whether it makes sense depends a lot on the type of site you’re running and how often your content or design actually needs to change. For the right project, a flat-file setup can be a good fit.
Here are a few questions I would ask, 6 months from now.
Are you still using your custom solution?WordPress is much more than a post editor ; it’s an ecosystem. And it’s easy to underestimate everything you take for granted until it’s gone. Galleries, embedded content types, archive pages, category views, comments, all the little things that just work. And that’s not even taking plugins into consideration, and the myriad of other features they can bring to WordPress. A few months in, when you need one of those things, you’ll have to build it from scratch or accept that your site won’t support that.
WordPress comes with so many little things that come bundled with the software, we don’t even think about them. A good example may be responsive images. It may sometimes seem like bloat to see so many different image sizes generated every time you upload a new image to WordPress, but those can be useful in so many different places.
It may not be a feature you’d put in a comparison table. But it’s one of hundreds of small things the platform does for you without you ever having to think about it.
Are you still publishing?This one matters even more to me. When your publishing flow changes, when it’s no longer a matter of opening a familiar editor (on desktop or on mobile) and hitting publish, the friction adds up. And in a lot of cases like this, people just… publish less.
That’s obviously less of an argument with AI: AI can help you with that flow, can publish / push for you, can write your posts for you. AI does change things, for building sites as much as for everything else.
Generating code has become (too?) easy. You can reinvent the wheel for every project if you want to ; no need for a library, a plugin, or a third-party service when you can just ask an AI to build you a custom one.
But it cuts both ways. You can’t say your site has “zero external dependencies” and then build your entire publishing pipeline around Claude. That is a dependency, a significant one. It’s a paid service, you don’t control it, it can unreliable at times, it can change its pricing tomorrow. You can certainly do without it and edit files the old fashioned way, but then we’re back to the problem I mentioned above. It becomes considerably harder to publish than it ever was with WordPress.
So the real questions become: once the site is live, how easy is it to maintain? If updating it requires leaning on AI every time, are you comfortable with that trade-off? Is that really simpler than what you had before, or just a different kind of complexity? Did you trade one dependency for another?
I am really curious to see what the future has in store for us, and for WordPress as a whole. I’ll check back in six months I guess 🙂
-
WordCamp Bretagne revient !
C’est maintenant officiel, WordCamp Bretagne est de retour en 2026, le 18 septembre, encore une fois à Rennes, encore une fois au Couvent des Jacobins.
Marquez la date dans vos calendriers, on se donne rendez-vous là-bas !
-
What kind of customizations did you have in mind? What would you like your site to look like?
I’ve learned to really appreciate the flexibility of the block-based themes in WordPress ; they offer a lot that was previously only available to folks comfortable with PHP. That said, this is mostly about layout and display. If you want to display custom data, you may still have to dive into code to get what you need. That is, unless someone else already developed it 🙂
The ActivityPub plugin includes more and more blocks that can help bring Fediverse functionality to your site, to create real Fediverse profiles for authors. If you have ideas of more things we could implement, please let us, either in the WordPress.org support forums for the plugin, on GitHub, or right here (you can ping @pfefferle or me any time!)
-
Notre commune a un site officiel qui sert beaucoup. Toutes les annonces officielles y sont publiées, et sont ensuite partagées sur les réseaux sociaux, essentiellement Facebook, mais aussi LinkedIn. YouTube aussi est de plus en plus utilisé ; les réunions du conseil y sont streamés en live, puis donc disponibles sur le long terme, et mises à disposition sur le site (et donc dispo par RSS aussi). De nombreuses catégories peuvent être suivies via des flux différents, ce qui est très utile.
Certaines communications sont encore seulement publiées sur Facebook malheureusement, mais le pense que les choses se sont améliorées de ce côté là. On peut maintenant se tenir au courant d’une grande majorité des nouvelles de la commune sans se rendre sur Facebook. Bon, on est loin de la présence sur le Fediverse tout de même 🙂
Toute cette présence est à mon avis le résultat de beaucoup d’éducation et de discussions, et pas quelque chose de forcément naturel pour chacun des élus. Il y a un grand contraste avec les communications de tous les partis se présentant aux élections, y compris le parti de la majorité, qui communiquent essentiellement via Facebook, ont des sites qui ne sont pas à jour, ont leurs programmes disponibles sur Facebook et pas sur le site, …
-
One vaut, 4 main folders (using the PARA method), many (too many) subfolders. I think it could be better, but I haven’t found a better way yet. I’m not too worried about it though, I rely on search, bases, and internal links to navigate across my vault and it works.
-
I’ve been building an RSS reader for the past year. No unread counts, no inbox to clear. Just a river that flows at its own pace.
Today it’s live on iPhone, iPad, and Mac. I wrote about everything that went into it.
Current, an RSS Reader, by @tgCurrent is a new RSS reader that takes a really interesting approach to how we consume feeds. Instead of treating your subscriptions as a to-do list with an ever-growing unread count, it presents your feeds as a river; articles flow in, linger for a while, and eventually fade away on their own.
Although the app is mac / iOS only, and paid, it’s not completely closed. You can hook it up to existing RSS backends like Feedbin or Miniflux.
The completionist part of me does miss the idea of reaching “inbox zero.” For me, inbox zero was never about obsessive consumption (or at least I like to think so); it was the permission to walk away. When I’ve read everything, I’m done. I can close the app and move on with my day. I wouldn’t want my RSS experience to turn into a TikTok-like endless scroll where I just keep going without thinking. Current isn’t exactly that though, and that’s where its velocity system gets really interesting.
Each feed gets assigned a half-life that determines how long its articles stay visible. Breaking news fade away faster than blog posts for example. This means the app naturally surfaces content proportionally to its nature; a prolific news site won’t drown out the small blogs you actually care about. The pace of consumption adapts to the pace of creation, which feels much more respectful of both the reader’s attention and the author’s intent.
On top of that, Current watches your reading patterns and offers suggestions to help you “quiet” noisy sources. If a feed floods your timeline with 18 articles in one day, or if you keep skipping posts from the same source, it’ll nudge you to rate-limit or mute it.
I would give the app a try, but it’s iOS and mac-only so far, so I guess I’ll have to wait! 🙂
-
Could you check that the ActivityPub plugin is still active on your site? You seem to be using the Friends plugin but the ActivityFun plugin itself seems disabled.
You can also post in the plugin’s support forums if that doesn’t help ; we’ll be happy to help!
