WordPress Poster is an application I developed to manage most of the example queries and scripts in the T-SQL section of this website. The program adds new blog posts to this site when I create them on my PC and includes logic to determine if it should apply updates to the scripts I’ve already posted. It was written in C# with a SQL Server database and uses WordPressSharp to connect to this site via the WordPress API.
The WordPress status setting has an important significance with WordPress API. There are several possible WordPress status settings. The ‘draft’, ‘publish’ and ‘trash’ statuses are pretty self explanatory. A status of ‘future’ means that the blog post has a publish date in the future and a status of ‘auto-draft’ indicates that the post is a copy of another blog post that was automatically saved while being edited in the WordPress backend.
The first challenge I faced dealt with becoming familiar with the WordPress API and how to connect to it using WordPressSharp. These technologies were completely new to me.
Since I started this project using a free WordPress blog from WordPress.com, I needed to ensure that the XML-RPC WordPress API was available to me and that the same API would be exposed on the version of WordPress that’s hosted by BlueHost, the company I selected to host the site. If anything was different, I wouldn’t be able to port the same code from my sandbox (i.e. my free WordPress.com blog) to production (i.e. my paid WordPress blog at BlueHost).
It turns out that the XML-RPC WordPress API is available on all WordPress installations, regardless of hosting provider. The code I wrote to connect to my free WordPress blog is exactly the same as the code I use to connect to the WordPress installation that’s professionally hosted by BlueHost.
WordPressSharp is a library that connects C# code with the XML-RPC WordPress API. It’s not very well documented and the The documentation is sparse, there are few code examples, and certainly no end-to-end tutorials to demonstrate WordPressSharp usage, which was cause for concern in the beginning. It warranted spending a couple weeks on that part alone. Once you’ve got some examples worked out, there are some minor unexpected quirks, like strings that you’d expect to be Int32 and Int64 where you’re expect Int32, but for the most part, it was easy to use WordPressSharp.
Many of the questions posted on the developer’s forum and on GitHub are actually from people who are also new to the technology, but are not actual bugs.
Probably the most difficult part of this project was figuring out how to maintain a link between the T-SQL script on my development machine and the HTML version that was uploaded to WordPress.
This was necessary because I wanted to have a way to update my website after making changes to the original T-SQL script that’s stored on my development machine. I also needed to know which scripts have already been posted.
The solution was to add an watermark to the bottom of every script containing a GUID identifier for the SQL script it contains. Since this GUID appears in the the T-SQL which is posted in the blog post, I was able to use this to identify the originating script that produced every HTML file on my site.
I also needed to be able to review, edit and approve the content that this application posts to WordPress before it’s actually viewable on my site. I don’t want to spend time editing content, only to have my edits overwritten the next time the program runs, so the first thing WordPress Poster does is connect to the WordPress API to import all of the published content on this website into a SQL Server database.
The database contains all of the data that’s exposed by the WordPress API for every page on this website. WordPress Poster can use this information to determine if a post has already been sent to WordPress. If so, it can decide whether to re-generate and overwrite the blog post in WordPress with fresh content.
To determine if a blog post can be written to the server, the blog post’s WordPress status is used. If the post has a status of ‘draft’, it gets updated. If not, it gets skipped. After I’ve edited a post, I simply switch the WordPress status to anything other than ‘draft’.
If I’ve started editing a post that I’m not ready to publish, I can switch the post’s WordPress visibility to ‘Private’ and its status to ‘Published’ so the page won’t be overwritten by WordPress Poster, but also won’t be displayed to anyone except administrators. Another option is to change the published date to some date in the future. This would give the post a WordPress status of ‘future’.
The SQL Server database has the added benefit of providing a backup of my website. There are additional options available on any version of WordPress, such as exporting your site into an XML file, but that has two disadvantages. First, the backup is not automatic. Second, it doesn’t backup your site’s images.
If you've needed to parse or construct a URI in C#, you've likely done it…
The second installment in my series of C# basics illustrates the proper use of access…
This page details the coding style I've adopted for C# code in my applications. You…
For the new C# section of my website, I wanted to post some notes that…
There are some pretty compelling reasons to lock down your LinkedIn account now. We bet…
We bet you didn't know that your full name, picture, work history, and more may…