From Word to WordPress

This is a big challenge. If I want to take advantage of all the features of Digress.it (like the auto-created table of contents), and create a nicely formatted site, then I need to publish the 130+ page thesis into post size chunks.

The brute force way is to begin cutting and pasting, but I want to see if I can be a bit more elegant than that.

I remember experimenting a few years back with publishing from Word to WordPress using  XML-RPC, so thought I would test this option out. A few setting adjustments in both WordPress and Word to enable XML-RPC publishing and a successful test post has me thinking I am on the right track.

Splitting a 130 page Word document

Still, while this looks promising, I can’t just hit the publish button in Word and magically expect my 130+ page thesis to automagically be sliced up and posted into separate posts. In fact, publishing the thesis this way will end up creating a single blog post of 40,000 words. Not ideal. So, I need to figure out how to split my single long Word document into smaller documents, and then try to publish each of those smaller documents as individual posts.

Surely, there must be a way in Word to split a long document into smaller ones. And sure enough, there is via a Word feature known as sub-documents, which allows a user to split a large document into smaller pieces.

Using the headings and sub-headings of my thesis as the logical starting point for dividing up the content, I split the original Word document into 56 documents based on chapters, headings and sub-headings.

I did have a few formatted tables and images in my thesis and was worried about how they would publish to the site directly from Word. There was some formatting that I need to do to clean up the formatting, but, for the most part, they came over clean and intact, complete captions and legends.

I was also a bit worried about how the participant quotes would translate. Being that this was qualitative research, the analysis draws heavily on participant quotes to support the findings and these quotes needed to be correctly formatted using the correct blockquote tags.

In fact, the only real issue I had (and it was quite minor) was that the posts had extra paragraphs tags at the beginning and the end of the posts, so that needed a bit of editing.

Next steps

So, now that the content is in, I could just stop and call it a self-published thesis. But I want to be able to do a bit more with it. My next tasks will include:

• See if there is a way I can structure the TOC a bit better to have headings and subheadings formatted different from chapter headings. Rught now it’s a pretty long list with no visual hierarchy.
• Setting up a way for people to download the entire thesis as an ebook, probably using the Anthologize plugin.
• Add in a plugin or two to generate metadata, specifically for adding content to a citation manager like Zotero or Mendeley. Perhaps the COinS plugin
• Look at ways to generate hyperlinks within the document to my references and citations. Something like the KCite or Zotpress plugin.

I’d also like to take a crack at some of the CSS and clean up some of the CSS around how tables and data are displayed. But these are all projects for another day.

The new image editor has some basic image editing functionality. You can crop, resize or rotate a photo. I couldn’t get the crop working after working with it for the better part of an afternoon. At first, how to crop wasn’t fully intuitive to me and it wasn’t until I read this blog post that the (admittedly dim) light bulb went off. Oh, I have to hit the crop button again. D’oh. Then when I went to insert the cropped image into the post, the aspect ratio of the image got skewed as the cropped image took up the entire dimensions of the original image. I also couldn’t save the cropped image back to my media library, but as others have pointed out, these issues may have more to do with folder permissions and settings in my PHP libraries than with the WP image editor, so I’ll be taking a closer look at those as I play more with image editing.

One other little thing about the image editor – it seems to be available only when you first insert an image into a post. If you try to go back and edit the image after it has been instered, the editor doesn’t appear as an option in the pop-up. You have to delete the image from the post and reinsert the image to enable the editor again.

Okay, that aside, the oEmbed support is a killer feature, especially for someone who finds themself supporting novice users. Embedding content from another site has never been so easy. If you want to embed content from another oEmbed enabled site (and a number of the big ones like YouTube, Flickr, Scribd and blip.tv are oEmbed capable), all you pretty well have to do is copy and paste the url of the content you want into the body of your post (make sure it is on it’s own line and not hyperlinked) and you are good to go. Good stuff.

What I would like to be able to do is allow the user to simply create a site specific backup file of all the necessary files for their site. Everything wrapped in one nice little package, with the bow on top being the ability for the user to schedule and forget their backups. Once a day/week/month it would just run, grab everything they would need to restore their site (at least their posts/pages AND uploaded files) and all is good. But I am realizing this may be a tall order without setting it up behind the scenes.

Now, each WP site does have an Export option, which is simple and straightforward, but was never intended as a backup utility, but rather a utility to move posts from one WordPress install to another. As such, it is not a comprehensive backup and doesn’t include files, images or multimedia you might have uploaded to your site.

This is a problem I have found with most community developed backup plugins as well – they all concentrate on backing up the database tables and not those extra files that will no doubt be uploaded by users looking to use the platform as a CMS. In order to backup both the database (where the posts and pages are stored), and the associated files, you need at least two separate  plugins.

The two I have been working with are WordPress Backup and WordPress Database Backup. So far I haven’t been able to get these two to do exactly what I want, and using them both makes things a tad confusing for end users.

For one, there are now 2 backup options in their site navigation, located in different sub-menus. Natural instinct for a user to ask why is there 2 backups, and anytime a question is asked there is confusion. So a bit of support is needed to explain the differences between the two to the users. Not a huge deal, but a barrier.

What is very handy is that both backup plugins let you automatically schedule backups to happen at regular intervals. These files are zipped up and can automatically be moved to archive folders on the server or, if you want, emailed directly to the users, which some users might find comforting. The downside is that there are 4 separate zipped files that go along with each site – a database files (generated by the WP Database backup) and 3 backup files generated by the second backup plugin, one with your uploaded files, themes and plugins. One packaged folder would be nicer.

But the major problem I have with using the WordPress Database plugin with WPMu is that the interface does not limit the database tables to backup to just the site requesting the backup. It exposes ALL the tables to the entire WP instance, meaning that any site owner could backup and download any other site users content. Not cool.

I do like and appreciate the work that has gone into these plugins. I use them on this blog and they work great. But in a multi-user environment, I can’t really say this is the silver backup bullet I was hoping they would be. So, I am still searching for a backup system that users can initiate that is simple and straightforward for the end user that will allow them to control their own backups.

Why are we doing this?

For the past 7 (or so) years, FrontPage has been the web authoring tool we have supported for faculty at Camosun. At the end of 2006, Microsoft discontinued FrontPage. Since then we have been experimenting with other platforms to replace FrontPage for faculty who wish to have stand alone (ie: outside our LMS Desire2Learn) websites and haven’t really been happy with the tools we have found, finding them either costly, overly complicated, or limiting. Ever since our Office 2007 rollout last year, faculty who are still using FrontPage have been reporting problems, so IT Services was also anxious to have us find another solution for faculty websites. So the main purpose for piloting WordPress for us is to see if we can use it primarily as a CMS to replace FrontPage.

Armed with some good feedback from Brian Lamb at UBC, Grant Potter at UNBC, and  Audrey Williams at Pellissippi State (who have all been involved with the UBC,  UNBC and Pellissippi State WPMu installs), I put together a pilot document for our IT Services, who agreed to support the project. At the beginning of November, the pilot began.

The journey so far…

We’ve done a lot in a few weeks. Installation was quick and smooth. The network admin I have been working with (who has also installed Drupal, Joomla, LifeRay and a few other CMS type systems) remarked that the LDAP integration with Active Directory was the easiest he has ever done. He literally had us integrated with our authentication system in 20 minutes.

For my part, I recruited a half dozen faculty for a pilot group and did some initial training. They are now set up with their own websites – and I use that term website intentionally. I’ve avoided using the word blog when I refer to these sites. I’ve found that the term blog carries with it preconceived notions, both good and bad. So, in order to avoid the whole “I don’t want a blog, I want a website” circular logic wheel that I have witnessed when people talk about WP as a CMS, I have been using the term website when talking about our pilot sites. I really want our users to focus on WP as a tool to manage a website, not a blog and try to proactively nip that semantic bud. These are just websites.

The faculty will be playing with their sites between now and January. In January when the new term starts, they will be using them as their primary website and posting whatever content it is they want their students to have access to.

Some early technical stuff

In keeping with that “website, not blog” philosophy, we launched with a minimum number of themes, trying to pick pretty simple ones that handle pages and nested pages well.

As for plugins, again, I’ve started with a small set of plugins and will be adding and testing functionality during the pilot (which runs until the end of June, 2010). Specifically, the plugins we have installed to begin with are:

• Akismet spam filter and Akismet credit inserter to automatically insert a “Spam prevention powered by Akismet”
• pageMash page management plugin which allows you to drag-and-drop the pages into the order you like.
• COinS Metadata Exposer makes your blog readable by Zotero and other COinS interpreters. As a student who is actively using citation management tools like Zotero on a daily basis, I truly appreciate when this metadata is exposed to accurately capture citations from a webite.
• Unfiltered MU to allow users to embed content from other sites.
• Smart YouTube plugin to make embedding YouTube videos even easier. Yes, even easier.
• Active Directory Integration for, uh, Active Directory integration
• New Blog Defaults lets you customize certain default settings for new blogs.
• WordPress Backup and WordPress Database Backup. I’ll have more to say about backing up WPMu sites in a separate post. Suffice to say, it is not an easy thing to do using the standard WordPress interface.
• PDF and PPT Viewer looks like an interesting plugin that I have only started to test out. It could be very useful, considering that most faculty still post a lot of  PDF and PPT files on their sites. In a nutshell this plugin leverages Google Docs Viewer to create an embeddable view of a PPT or PDF document – no additional software or plugin required.

I’ll be elaborating about these plugins, and on administering WPMu, but I’ll save that for future posts. In the meantime, we now have a WPMu install up and running at Camosun and ticking along just fine.

Why alternatives? Well, it’s not that I think the standard WordPress interface is bad or poorly designed – far from it. But I am looking at alternative, streamlined ways of getting content into a site that may be more familiar to non-WordPress users.

Over the past few days I’ve been playing with alternative ways to publish content to a WordPress site, and here are 4 that I have come up with.

Using Word 2007
I really like this method, not because it is the best tool in this list, but because it is the most familiar interface for the faculty I support. Everyone is comfortable using Word and, while it won’t give you all the functionality of the web interface, it gets the job done with some nice functions in an interface that users are familiar with.

Setup is easy and straightforward and you can insert text, links tables and images, including WordArt, Symbols, Shapes and SmartArt. Blog management and organizational options are pretty minimal, but include the ability to post as a draft, and choose an existing blog category for the post. You can also open previous posts from your blog to edit.

A lack of headings in the toolbar is a frustration I have with the interface, and the reason why the subheadings for this post are appearing as 14 POINT (???) headings and not h3 tags as I would prefer. Microsoft has instead decided to put bigger and smaller buttons on the interface. This is something Microsoft has done with other html editors I’ve come across (yeah SharePoint, I’m looking at you) and it is an annoyance I find maddening. Not only is this semantically incorrect (let me make a heading a heading and a paragraph a paragraph please), but it also overrides the set CSS in the WordPress themes. It would be far better if they just left the text options as standard html tags, which would be semantically correct and would also ensure consistency in design.

That said, in terms of something my faculty will find easy to use, the Word interface seems like an early winner. And anything that helps people move away from posting links to their Word documents and posting in html is a winner with me.

By Email

Another familiar interface for my users, you can post to a WordPress blog from any email client. While this does require a bit more technical work to initially set up, you again get a composing environment that is really user friendly and familiar, especially for the slightly technophobic faculty.

This is bare bones in terms of functionality. The subject line will be used as the title of the post with the body of the email as the content of the post. All html in the email will be stripped out, and it does not support uploading attachments or images. You also cannot choose what category you want your post to appear in with the post appearing in whatever the blog default category is. This does not have the functionality of Posterous, but in terms of getting content onto the web quick and painlessly, it’s a fine alternative.

ScribeFire

ScribeFire is a FireFox plugin that lets you post to your blog from within FireFox. This is a full featured alternative to the native web interface that has tons of features. I’ve used this in the past and, while I like it, I have found that the formatting sometimes goes a bit wonky when the post is published and the post doesn’t always look like I would expect it to with the underlying html code getting rewritten. Still, you can pretty well do anything with this tool that you can with the WordPress interface. It’s handy when you come across something on the web that you want to blog about quickly, or if you have no eb access but still want to compose a post to publish when you reconnect.

Google Docs

Cole Camplese sent me scurrying down this path a few days ago when he tweeted a test post (which looks like it has since been deleted). So I gave it a shot and found out that you can post directly to WordPress from Google Docs. In the example from a few days ago, I included an image pulled from my Flickr account and a drawing done in Google Docs. Connecting was pretty straightforward, however there was no specific WordPress API hook. Instead, I used the Moveable Type API, which connected, but may explain why when I posted the post showed up on the blog sans title.

Have you used any of these tools? Are there any other ways to create content outside of the WordPress user interface? If so, I’d love it if you let me know.