One of the sites I currenty help maintain at work is a private community site for employees of one of the largest restaurant franchises in the world. For the first year, our resident copy writer was the blogger. But recently, the client decided to hold a competition among it’s restaurant employees to become the next blogger.
Now, this community site was developed before I came on board. It was developed by several different developers, under a ridiculous timeline, around a CMS that turned out to be horrible. At the risk of pissing off an entire community, I am comfortable saying that Typo3 is one of the worst CMSs I’ve ever come across. The code is absolutely atrocious. I know WordPress’ abuse of global variables is bad, but that’s nothing compared to Typo3’s globals. You should see this thing eat through the memory on a dedicated server with only a handful of concurrent users and caching turned on. A few months ago, I picked on Textpattern and how it invented another templating language. That was such a minor offense compared to the scripting language that Typo3’s developers decided to come up with. These “Typoscripts” are modified in the backend, are stored in the database, are parsed and loaded into a global array, then used at run time. It kind of resembles Javascript but as the Typo3 docs repeatly say, it isn’t a programming language. It doesn’t have any of the control structures that Javascript does. I could go on and on about Typo3’s bewildering features, but the main point here is that the backend is not user friendly; especially for blogging.
So, naturally being the resident “WordPress expert” (a title I’ve been given) I was tasked with getting the Typo3 backend ready for the new blogger. I started exploring my options. I had discussions with my office mates about migrating the data to WordPress, but we decided that it would be too much work because we would also have to create WordPress templates and migrate the design. This was just not possible given the timeline. So, I started exploring Typo3 to see if it could be used to allow the user to easily upload files and write posts as easily as WordPress. No luck. I then decided to start adding a custom piece to the Typo3 Task Center, using TinyMCE and adding an upload utility, much like WordPress. But as I rebuilt a big piece of WordPress’ backend under a tight deadline, I realized there was a way to use WordPress itself.
A blog post is a pretty generic data structure. It turns out that Typo3’s blog post data structure is pretty much identical to that of WordPress. I could write a WordPress plugin that would push the blog post data to the Typo3 database when a user saves a post in WordPress. Then, because the post is in the Typo3 database, it would just simply show up on the Typo3 blog. We wouldn’t have to create templates and migrate the design just yet.
So that’s what I did. I wrote a WordPress plugin that would push the data from WordPress to the Typo3 database when a WordPress post was saved. Rather than also creating a plugin for Typo3 to push data from Typo3 to WordPress and dealing with merging, I decided to make a policy whereby we only manage posts on the WordPress backend and lock down the Typo3 backend. So now, all I had to do was write a script to do a one-time import of all the posts from the Typo3 database into WordPress and I was done. In the end it was a simple, elegant solution that got us a little closer to abandoning Typo3.
Although this plugin is specific to our implementation, was written for WordPress MU, and is a bit of a mess, I’m sharing it anyways. At the very least, it is a good reference for someone wanting to take a first step away from Typo3.