A friend of mine recently asked me of how to best (thereby meaning most easily) distribute content on to several WordPress blogs, and that motivated me to dive into this blogpost.
There are two basic methods for distributing, quite opposite methods in fact, and they each have their pros and cons. Both require a bit of setting up on your WordPress installation, but a lot of that can be automatized in the creation process.
The PUSH method – XML-RPC
By enabling XML-RPC Remote Publishing on your WordPress blog, you can from a central software control a theoretically limitless range of WordPress installations. This sounds interesting, but there are indeed a few major setbacks. Let me explain.
The good things
The bad things
Firstly it opens a security threat on your WordPress blog. I am unaware of the actual stability and security of the XML-RPC protocol, it is arguably another open “hole” into your WordPress blog.
It takes time to set up. For each and every blog you make you need to both enable XML-RPC in your blogs settings, you also need to store this information in your central software for which you use to control your millions of WordPress blogs.
You can also get automatic content via this method.
I would recommend to create a new user in your WordPress installation with the role of “Author” for this. Why? Well, you’d be a nutter if you share your administrator password with anyone. Trusted or not.
* Yeah, I know. The “pros” section is empty. I simply can’t find a good reason to use this method, in comparison with the second method:
The PULL method – The RSS feed
Each WordPress installation has built-in RSS handling support for reading RSS feeds, and those who do not want to re-invent the wheel and code from scratch, there are already a few good plugins written to handle content creation via RSS feeds such as WP-o-Matic.
Easy to maintain – One central server containing all your content. Easy.
Expandable – Need more space? Need more speed? Upgrade a single server. Easy.
Faster to set up. No need to enter the details for each blog in a central site. Easy.
Flexible – You can communicate with the RSS feed via parameters, so with a bit of technical skill you can gradually start to scale. Read below in the section named “So exactly how does this work?”.
Bonus benefit: Forced output structure = backwards compatibility. The strict structure of the RSS feed forces you to follow the RSS standards, otherwise the code is not able to understand your feed.
Hence, if you add additional features in the future, such as new parameters and their handling, you are forced to keep the same structure of the output and that means all previous installations will still be able to communicate with the content server.
Lack of tracking
Being practical, I also use my centralized feed server for checking my slaves scattered around the internet, but doing this using a PULL technology requires extra effort and coding on your behalf.
The first method (XML-RPC) arguably has an advantage in this area, by immediately knowing if a blog fail to respond and time out when attempting to publish and alerting us to that.
However, you can achieve the same benefit from adding additional code to your feed script, which stores incoming visits from referring urls, checks the incoming urls at specified intervals and reports any blogs not responding. This makes it a minor con, since it requires extra effort in setting up. The first time.
Valuable tip: Add a bit of sanity!
If you choose to add the checking module, you would be wise to add a buffer for responsiveness. Simply because a blog is not responding at the time your code checks it, it could simply be slow in responding at that moment, the pathways on the internet is clocked, or a range of other things.
It should instead be noted and rechecked at least a couple more times before sending an alert to you, such as an email, a text message to your cellphone, or whatever you can think of…
I also recommend to aggregate alerts to a few times a day.
You REALLY don’t want a piece of code going mental and sending you text messages every 15 seconds for some reason, starting at 2:32 am.
It will usually happen when you are away on vacation somewhere without decent internet connection or time to fix it… Trust me.
An actual con however is the potential cost. I am a sucker for lowering my costs as much as reasonably possible, and I know of several places that offer only decent service, and for low prices. But the single important part in this setup is the server, and it should be as secure and stable as you need and can afford.
Depending on your kind of nerves and wallet-size, I highly recommend investing in a secure, stable, well-backed-up server, with 24/7 support. It costs more, but it makes you sleep peacefully at night.
If you want a stable and smooth running website, remember to check out my WordPress Optimization Checklist.
So how exactly does it work?
Well, if you want to start off simple, you set up a range of WordPress Blogs with some RSS-to-content handling code, that checks a fixed RSS feed at random intervals such as twice daily, weekly or even monthly. The RSS feed will contain content controlled from the central server, and the local code will handle creating any new content into blogposts.
The central feed url, let’s say http://networkhq.com/feed.php, will return content from a database (or even a range of databases).
At it simplest, it simply returns random content delivered from a database. A more advanced version which you can develop at your leisure should/could contain several more features such as:
Security – Add a parameter with a specific key, and fail to return anything if that parameter is missing. Example:
Keyword content – Add a parameter for keyword searching. Imagine having a centralized database of hundreds of thousands of articles, news and stories about “health” for instance. If you set up a range of blogs related to a specific keyword phrase, I can simply add
&kw=acne and output only content related to acne.
Sorting method – You can output the content randomly if you want to fill up a blog gradually with content, or you can force the output returned by the server to display the latest first.
Limiting – Limiting your output is always a good idea. It can be a way of controlling how much content is added to your blog at a time. Some RSS-handling scripts I have tested do not have a limiting feature, and you could end up getting 50 blogposts created every hour if you don’t keep some control and limitations.
There are several other things that can help you and increase the flexibility of the system, bring forth some of your own ideas in the comments, I would love to hear what you can think up.