I finally got around to upgrading our WPMU instance to to 2.9 (2.9.2 to be exact) and playing with some of the new features. So far the image editing has been a bit of a disappointment, but the oEmbed feature is, quite simply, awesome. Somehow, embedding content in now even easier than before.
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.
I’ve bee working on setting up some backup systems in our instance of WPMu and have been struggling a bit. While I certainly appreciate that creating backups for WPMu can be fairly straightforward to setup when using tools like phpMyAdmin and gzip (as outlined nicely in a recent post at WPMU Tutorials), there really isn’t a simple way for individual site owners to do site backups from the WordPress interface.
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.
A few weeks ago, we launched a WordPress Multi-User pilot project at Camosun. Here are a few thoughts early on in the process.
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.
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.
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:
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.
I’ve been a WordPress user since the b2 days, but only lately have I begun to explore different methods of posting content to a WordPress blog. In the past, I have used the standard web interface for creating posts, with the occasional foray into using the FireFox ScribeFire plugin (more on that in just a moment).
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.