Another test article with XML-RPC

So this is again a test post with XML-RPC, currently from my own wp-edit application what I mentioned previously.
This article is a bit other than the older one, where I converted my mark-down written text to XML and copied it to WordPress manually.

Currently I am at the stage of development, where I can send posts to wordpress. And this is great if you ask me.

That’s why I created the first release of WP-Edit and added it to the PyPI where you can download and use it. The version released is 0.2 because I am not fully done yet however I feel the current state worth for a second minor release.


To start using the application firs you have to create a configuration file where you define the XML-RPC endpoint of the blog you are writing to, the username and password.

The application looks per default for this file under your home folder (Unix like systems it is “~””, for Windows it should be something like “C:\Users\your_name”), with the name wpedit.conf.
The application ships with an example configuration you can copy and fill.

If you are curious and want to have a look at the configuration, here you go:

# Simple configuration file to set your XML-RPC endpoint and username - password combination
# Comments start with a hash like this line
# String parameters have to be quoted between single quotes ('') or double quotes ("")

# the endpoint of the XML-RPC host, a string, for example ''
endpoint = ''
# the username of the endpoint, a string, for example 'UserName'
username = ''
# the password of the endpoint, a stirng, for example 'SecretPassword'
password = ''

As you can see, the configuration handles Python comment lines (lines tarting with #) as comments.

Naturally you can overwrite the default configuration look-up with a command line argument provided to the application. In this case you have to enter the full path of the file holding your configuration.


The usage is simple. After the app is installed you can execute the wpedit python script. [-h] [-c CONFIG] [-m MDCONF] post_file

positional arguments:
    post_file               The full path of the input file to send to WordPress.

optional arguments:
    -h, --help              show this help message and exit
    -c CONFIG, --config CONFIG
                            The full path of the configuration file storing the
                            XML-RPC endpoint, username and password. Per default
                            the application looks at your home folder and searches
                            for wpedit.conf
    -m MDCONF, --mdconf MDCONF
                            The full path of the md-to-xml conversion-extension

That’s it. It is really easy to use the tool and it gives some sort of configuration.

Current features

This is the initial version, currently 0.1 released (however I am right on the way to release 0.2) and there are some extra features which makes my application a bit different from others.

Source code block

You can add a source code block with a “dictionary” of parameters you want to pass along to WordPress (see some explanation later).

This is one crucial thing for me because I write a lot of code I want to share. So I want to be able to add code offline too — without much conversation at the end.

“Read more”-tag

This is one of the most valuable features of a blog post: I especially do not like when I load a blog and I have to look through whole articles on the landing page. It is more readable if you include a “read more” tag after the introduction of your article. And for this I enable the feature to add the HTML markup for this tag in the markdown text.

Pre-formatted text

The 3rd-party library Markdown handles pre-formatted text a way other than I (and WordPres) would expect so I added another way to format text as pre-formatted. Currently I am fighting with the reverse conversion of pre-formatted texts to markdown because the tool I am using will convert these the same way as it should be come from a “normal” markdown language.

Further steps

As I already mentioned, I am not done yet. There are some features I want to implement in the near future to be more usable (so you have to make less editing after uploaded the contents to WordPress for example).

Parametrized source code blocks

Now if you enter a source code block you have to edit the parameters like title, language, line-highlight and so on, in WordPress after uploading. This is a real need for me to enable the configuration in the mark-down file because I use source code blocks really often and it can be a pain in the neck to do the configuration later on.

In the mean time (between two times writing this post) I updated the sources and now I am able to add language to the source files.
There were many solutions which came into my mind and I implemented one. In this I convert the parameters to a python dictionary and use this dict to write the configuration of the code block.

Converting a string to working Python code is not complicated:

dictionary_string = "{'language':'python', 'light':'true'}"
dictionary = eval(dictionary_string)

The code block above converts the string to a dictionary with keys “language” and “light”.

Exception handling

If you encounter an error while using the application, you get a simple Python exception stack-trace. And this is not the best thing you can have because if you are not a Python developer, you have to find out the reason why the application crashed. For this I will cover a big part of possible exceptions to report a user friendly text if something bad happens.

Getting drafts

For advanced users I plan a feature where you can synchronize draft posts between WordPress and your computer.
However synchronizing will be really wood-cutter at the beginning: downloading the posts and convert them to markdown in the special wpedit format. If one draft already exists at your computer, it will be overwritten, so no automatic merging possible.


What is a good application without tests? It is a bad application.
Tests help to ensure the quality of the code. I think this is essential too to have a good test coverage because I can break the functionality with some further development changes.
But if I am hones I do not like to create tests when I have so much development tasks offen which are more interesting 🙂 However I will give it a try and include some tests somewhere along version 0.2 or 0.3.

In the mean time I started to write tests. And I have to tell you it is not the best thing I can imagine. That’s because I do not have those tools which would enable testing as smooth as I have in Java. For example distutils does not have a default testing mechanism, so I had to find an MIT licensed solution which enables testing with distutils too.

Release and sources

As for the release, you can find it here, the sources are as always at the GitHub repository, where in the master branch you can see the actual development version, the PyPI releases are tagged and can be found under releases.