org2blog: publishing to WordPress from an Org mode buffer

A blog editor that is really an Org mode buffer

The package describes itself as the most advanced WordPress blog editor and manager available, and then makes the case for itself in a way that is worth reading for what it reveals about the design. The argument is that you should edit and save in plain old text with Org mode markup instead of flaky WYSIWYG editors, and the rest of the feature list follows from that. The features include a distraction free workspace, built-in spell checking, grammar tools, a user interface where hitting =h= gives help so no manual is required, first-class Unicode support so you can write in any language, export to PDF, Word and more, automatic image uploading, and support for Pages as well as posts. The audience is a writer who has already chosen Org mode as their working format and wants the same file to be the source of truth for both their editor and their blog. The licence is GPL-3.0 and the last push to the repository was on 2026-09-25.

Writing offline and publishing when you choose

Two design decisions shape the whole package. The first is that you can write posts with or without an Internet connection, because they are simply saved locally until you decide to post them, and the README says you can store them on your computer, in Dropbox, or in your favourite version control system. The second is that the unit of work is a buffer, not a web form. A post is an Org subtree or a buffer, and it can be edited, saved, published and tracked as a file. The README has a section on coming back for seconds, describing your second buffer post and your first buffer page, which tells you the workflow is buffer centric. There is a whole chapter on storing multiple entries in one file, covering using subtrees and using narrowing, so several posts can live in one Org file and be published independently.

Publishing over MetaWeblog and XML-RPC

The mechanism underneath the whole thing is the older generation of WordPress APIs, and the repository layout makes that explicit. At the top level there is metaweblog.el, the MetaWeblog client, and ox-wp.el, the XML-RPC client, alongside the main org2blog.el, and the Makefile downloads both as dependencies. The download targets pull xml-rpc.el from a Launchpad URL for the xml-rpc package, and metaweblog.el from the raw GitHub source of the punchagan/metaweblog project, along with the latest Org mode tarball from orgmode.org.

download-xml-rpc :
	$(CURL) '$(XML_RPC_URL)' > '$(WORK_DIR)/$(XML_RPC).el'

That dependency choice is the main thing to weigh before adopting the package. The modern WordPress REST API is what current plugin and theme work targets, and this package is built on the two APIs that came before it. The practical consequence is that your WordPress installation, or whatever is in front of it, has to allow those endpoints, and that is worth checking before you invest an afternoon in setting the thing up.

The README is the manual, and it is an Org file

The unusual thing about this project is that the documentation is the product documentation. The README is README.org, a fully structured Org document with properties, a table of contents generated from the headings, custom IDs, and dozens of sections linking into the same file. The table of contents alone shows the scope: making your first post in less than 5 minutes, the 7 most important next steps, helping yourself to the basics, writing more after you have settled into the software, creating your writing room, making room to write, finding and saving your voice, why writing requires good characters and Unicode, spell checking, having you heard your new post, just writing, automatically configuring your environment, defining custom keybindings, logging in faster, decorating your room, coming back for seconds, your second buffer post, your first buffer page, storing multiple entries in one file, using subtrees, using narrowing, automatic image uploading, supported properties, tying it all together, global and blog specific configuration, inserting things, confirming things, raw HTML creation, source blocks, plain source box format, LaTeX support with amsmath, WordPress LaTeX, MathJax, migrating Org mode files to Org2Blog files, exporting WordPress to Org, using entry templates, tracking entries, doing things after saving and publishing, parent pages, publishing and sharing with everyone, the huge power of customizations, sample posts, a changelog, credits, testimonials, and a closing section on when things go wrong or could go even better.

The build system fetches its own dependencies and runs literate tests

The Makefile is small but it explains how the project is developed and tested. The test target depends on clean, then for every *-tests.org file in the tests directory it runs Emacs in batch mode with the xml-rpc library, the metaweblog library and a file named cl loaded, evaluates Org babel languages for emacs-lisp and python, and then runs ert, the Emacs test framework, in batch mode excluding interactive tests. The tests are written as literate Org files, which is a neat trick: the test suite is a set of Org documents rather than a set of Elisp fixtures. The download-deps target chains the three downloads together, and the clean target removes the downloaded .el files from the tests directory, which tells you the dependencies are deliberately not vendored into the repository.

Where org2blog is the wrong choice

The limits are clear enough to state. First, the publishing APIs are the constraint. If your WordPress front end blocks MetaWeblog and XML-RPC, which plenty of hardened installations do, this package has no path to your blog, and the README does not document a REST based alternative. Second, the whole model assumes you are comfortable in Emacs and in Org mode syntax, and the value comes precisely from that, so a writer who wants a rich text editor will find the workflow strange. Third, the package has no GitHub releases, so there is no version history to point at and no changelog other than the one inside the Org document, which means upgrades are a matter of pulling master and reading that section. The alternative worth naming is the WordPress block editor with a Markdown plugin, which gives you most of the plain text benefit inside the web interface, or a static site generator that produces the blog from the same Org files, which removes the API dependency entirely at the cost of giving up editing published posts from anywhere but your own machine. For a writer who already lives in Emacs, the trade is worth it; for anyone else, a static generator is the more durable choice.

Customisation, entry templates and the long tail of blog chores

The last third of the documentation is where a package like this proves its worth, because publishing is more than writing text. There is a chapter on the huge power of customizations, one on global and blog specific configuration, and one on inserting things, which in this context means pulling content into a post from elsewhere. There is a chapter on confirming things, which is the step where the package shows you what it is about to send to WordPress before it does, and one on raw HTML creation for the cases where Org markup is not enough. Source blocks are covered in two flavours, plain source box format and the syntaxhighlighter-evolved path, with a separate section asking what to do when syntaxhighlighter-evolved is broken, which is a fair sign of how the project handles its own dependencies. There is LaTeX support in three flavours, amsmath, WordPress LaTeX and MathJax, entry templates for consistent post structure, tracking entries so you know what has been published, a chapter on doing things after saving and publishing for chaining actions, parent pages for organising a post under a section, and a final section on publishing and sharing with everyone in whatever format you want. The existence of a section on when things go wrong or could go even better is the part of this list that most improved my impression of the project.

Editorial conclusion

Adopt org2blog if you already write in Org mode and want your WordPress posts to live in the same plain text files, edited in Emacs, rather than in a web editor. Do not adopt it if you want a visual editor, or if you are on a hosted platform that does not expose the MetaWeblog or XML-RPC API. Verify first which publishing API your WordPress install allows, since the package supports both and the modern REST API path is the one the README covers least.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. org2blog/org2blog on GitHub
4. Project website
5. README