Getting Staff on Board and Using a CMS: Moving to WordPress

The hardest part of moving any website is getting staff trained and changing their workflow to actually use the CMS. We previously had a static HTML type site, so everyone would email changes to one or two people. It was a big shift to suddenly have people take care of their own content.

As part of the training session, I briefly reviewed why we moved the website to a CMS and more importantly, how it benefits our patrons. It covered the usual, shifting resources and staff time, less maintenance, keeping content current, etc.

Tutorials

I found the best WordPress tutorials for staff were the WordPress.com support articles related to creating content. The only differences come from the plugins that are installed, but in our case, this only affects the “Upload/Insert” section above the editing area.

We also have access to lynda.com video tutorials, so I suggested the relevant sections (5 + 6) of the WordPress Essential Training.

I also wrote up a short blurb on how to check for broken links in a more visual way (and for our non-WordPress pages). I basically referred them to install and use LinkChecker (a Firefox plugin).

Content Guidelines

In addition to training staff on the actual CMS, I wrote two sets of guidelines for them to follow.

  1. General Guidelines on ‘Writing for the Web’
  2. Using WordPress to Make Content Accessible (to come in a future post)

To make it easy for staff to use, I wrote it as a page on the intranet (with anchor links for a short table of contents), and also made a PDF version for them to easily print it off.

Making Staff Responsible

I think the most important step in shifting web content management from a single team to the entire staff is assigning responsibility. If no one “owns” a page, it will not be regularly reviewed. If you assign ownership, at least it increases the chance of that happening. Here are the short blurb I wrote on staff’s responsibility of content:

Page Ownership Responsibilities

While you may delegate the task of creating or updating content on any page you own, you are ultimately responsible for it. This includes:

  • Content is up to date
  • Content, especially audio/visual, conform to Accessibility Guidelines
  • Copyright is cleared for all content (if applicable)
  • Transferring ownership when needed (long term leave, end of term)

Please Note: When links are found to be broken, you will automatically be notified via e-mail. However this is not a full-proof system as many broken links will not be “marked” broken. See the ‘How to Check for Broken Links’ page for more information.

Assigning Ownership

We explicitly mention that editing of pages can be delegated, because we decided that librarians would be responsible for pages. We identified and changed each page’s author to the librarian who would become the owner.

We still have about a dozen pages outstanding in which our team maintains as needed, but we also expect that staff may edit it if they find mistakes.

The Result

So far, it’s been fairly successful (yay!). While I get calls on occasion for help, staff seem to be finding it easier to use than Drupal (which we have for our intranet), and most seem to have no problems using it.

Content on a lot of pages are being updated, though as always, it really depends on the owner. One of the problems is that we migrated the existing pages, and there’s a lot of overlap in information, which we really need to consolidate. So, making the website better as a whole will take a bit more time, but at least content is now being updated on a more regular basis.

WordPress Development: Lessons Learned & Downsides

After 8 months, I have finally finished with WordPress development. I definitely learnt a lot, especially in terms of how the back end works and some more PHP.

Lessons Learned

The most important one:

know more PHP than I did.

Admittedly, I knew very little. While I have some experience programming, I only took a 2 day course in PHP. Not having to look up every little thing would have saved me invaluable time.

The other big one was definitely:

know more WordPress.

The documentation is obviously written for programmers (in most cases, those familiar with WordPress). So once again, I spent a lot of time looking things up. In this case, it was even more difficult because I usually had to rely on a couple of different tutorials and piece things together, making things work through trial and error.

Of course, I didn’t have much choice. And if there is one really good way to learn something is to be thrown into it, and make it happen.

Plugins

WordPress could really use some improvements though. One area is definitely in the plugins area. There is little to no cooperation between plugin authors, so there may be anywhere from zero to fifty plugins that do similar things, but all work differently and are of varying quality.

One of the reasons I’ve been posting a lot of plugins review is not only for my own records, but in the hopes that it’ll save other people time from looking through the mass amount of plugins. Unfortunately, because plugins come and go like the wind, plugin reviews become out of date very quickly.

Search

The one other thing I wish WordPress would improve is their search. While the site search uses Google, the plugin search is pretty bad and so is the internal built-in WordPress search. For the plugin search, you cannot refine your search in any way, and the sorting doesn’t seem to work properly.

The built-in WordPress site search (and dashboard pages/posts search) is also pretty bad. It’s organized by date and there is a plugin that allows you to sort by title, but it does full text searching and does no relevance ranking whatsoever. If it even did the minimum of “do these words match words in the title, if yes, put those higher” then that alone would be a huge improvement.

Conclusion

While I think WordPress is a great platform (and it’s open source!), there is definitely room for improvement and may not be the right platform for everyone. In comparison, for example, I get the impression that Drupal has a more cooperative and supportive community with better plugin support and development. On the other hand, I find WordPress easier to teach users.

If I had to do it again, I would definitely have taken the time to learn more about the overall WordPress framework and how different parts fit into the puzzle before diving into making the theme.

WordPress Plugin: Publicize or Automatically Post to Facebook & Twitter

So, I recently discovered the WordPress Jetpack plugin set, which does a lot of the things I had previous looked for WordPress plugins to do, including custom css, share buttons, and extra widgets you’ll find on the .com version. The only thing I really wanted that was missing, was the “Publicize” feature to post to social media, such as Twitter.

Requirement

The one requirement I had was that one plugin should be able to post to multiple social networks instead of having separate ones for each social network. This mostly has to do with making it easier to use and maintain. While we only need Facebook and Twitter right now, we may need others in the future, especially something like G+, so I preferred to already have something installed instead of having to find yet another plugin later.

Results

  • Network Publisher: This plugin probably supports the most social media sites and even includes stats. I didn’t actually really test this one because it required signing up for an API key. From the plugin page, it seems to at least work though.
  • SocialPublish: This one also required creating an account, but I still don’t understand why this is necessary.
  • NextScripts Social Network Auto Poster & WP-AutoSharePost: These required setting up apps on each of the sites, which is fine but not what I was looking for.
  • Social by MailChimp: This only does Twitter and Facebook, which was my minimum requirement, but it works. Not the nicest interface ever, but I like that you can edit the messages individually before they’re posted. I disabled the comment display, so I’m not sure how well that works, but it’s not something we wanted.

So in the end, Social was the only that did what I wanted easily (i.e. without all the dev apps stuff) and without the requirement of creating an account elsewhere first. Still need to properly test it on a multisite setup, but it’s the closest thing I can find to WordPress’ Publicize.

UPDATE: WordPress JetPack now includes Publicize! Yay~

Branding the Library Website: Making a Flexible WordPress Theme

In moving our website to WordPress, I wanted to create a theme that could be used by our staff when working on online projects which would sit outside our main website, but in which we would host. Obviously they have the option of using other themes, but then someone (likely from our team) would have to make sure it meets accessibility guidelines, and as there are very few of those, I thought it best to just make our theme flexible.

No CLF

This is just a disclaimer that the main reason we could even do this is because we do not have a Common Look & Feel policy from the university administration, which most universities do. On the flip side, that’s one reason I wanted to do it. I would like that the library “products” are recognized as such. Doing it through a theme would also provide a more consistent user experience across the sites that use the library’s theme.

The Header

Our existing site already used a consistent header. However, it also includes the “Ask Us” logo, which would take you to the “Ask Us” page with all the myriad ways to contact the library for help. For other sites, it’s more likely that they will want to list specific contact instead, so I added an option to remove it.

new site header
New Header with Custom Menu and Google Search Bar

In addition, of course, for any sites using the theme, they will want the name of their site in the header, so I added a text box input for that in the options page and used font-face to pick a different font to make it stand out a little more.

The Menu

The navigation was built into the original theme so that you can either use a custom menu or it will fallback to using pages. However, the way our sites are made, some of the subpages menus would have been so long as to go past the end of the page, so I added the option to take out submenus.

new header with subsite title
Header with Subsite Title, Fallback Menu, and WordPress Search

Finally, the original website search bar redirects the user to the university’s Google search of the library’s directory, so I made the option to change it to the standard WordPress search bar to search within the current site.

The Footer

Since each site may have different links in the footer, I also made an option to include custom links in the footer, such that the ‘Home’ link is the only hard-coded link (which is always the link of the home page of the site you’re on).

new full footer
Full Site Footer with Custom Links and Social Media Icons

While it’s possible to make the social media buttons customizable, until there is a demand or need, I decided to simply put in the option to take them all out.

new basic footer
Hardcoded Part of Footer

The rest of the footer (copyright) is always there. Again, unless there is a demand or need, I didn’t make the copyright holder changeable.

Templating

As many sections of our website (e.g. catalogue/OPAC, Research Guides) are not part of the CMS, I am currently working on taking the WordPress template (minus the options) and creating a plain HTML and then a ColdFusion template to use in those sections.

New Site: Moved to WordPress CMS

We moved our site this morning to a new domain and it’s now running on WordPress. After a few issues with the redirect that central IT had to fix, it seems to be running smoothly.

There is still a lot of work to be done in terms of cleaning up content, especially since there are still many pages using tables for layout purposes (insert big cringe here). I also still need to finish going through the accessibility reports (only did the front page so far), and writing guidelines for staff. Training has still yet to happen for staff as well (since we focused on getting the site up first).

Spot the Differences

The website has actually changed very little on the front end. Think you can spot all the differences?

old home pagenew home page

I’ve made an answer key if you care to play (red = added/removed, blue = moved, orange = small difference).

Rationale

I think most people will understand the rationale in going to the CMS. The move in this case was much more for internal reasons, primarily so that staff can update pages. Of course, this actually should have a positive impact (at least in theory) as staff will be assigned pages and be responsible for keeping them current. Putting this system in place should also free up time of those involved in maintaining the website to do other things.