A lot of people have setup WordPress, and obviously each organization needs to set it up a specific way to fit their needs. Nevertheless, learning how different libraries set up their CMS is something I have found useful in the past, so I thought it might be helpful for someone else if I shared the way I decided to set up WordPress at my work.
The Install
As we have more than one site, it was an obvious choice to use the MultiSite flavour of WordPress. We set it up to use the directory structure option since we would be under a subdomain already, we decided against having sub-subdomains.
We installed it on its own virtual server through our central IT. We discovered in the process, however, that by default, a lot of modules are disabled by IT, so we had to request a number of them to be installed. For the core, the only one was:
- GD Support – required for creating the different image sizes (i.e. thumbnail, medium, large)
Various plugins uses PHP modules that are part of the standard PHP install, so may not point out the need for enabling them. For plugin requirements, I’ll note them in the plugins section.
Setting Up The Sites
Creating the sites were simply a click of a button of course, but a lot of settings had to be changed. While most of the defaults were fine, I did change a number of settings. In particular, one of the settings was only accessible (through the Dashboard) by manually entering into the address bar, options.php
image_default_link_type = ‘none’
For most of our sites, there is no advantage to linking to the attachment page or a full size version of the image. Additionally, the images that are uploaded are usually close to the size that is being used on the page. The one exception I made was for the Archives & Special Collections site.
We also do not allow users to set up their own sites, so staff have to contact a network administrator.
Making The Themes
The lengthiest part of the process was making the custom themes. I won’t actually go into details here, but will later post details on the creation of the library’s theme. I have already talked about the options I implemented in the post about Branding the Library Website.
I will note that we avoided making a ‘mobile’ theme by making the themes responsive. They’re not the prettiest, but at least they work.
I did have to make a standard template to use for our non-WordPress sites, including the ILS, Special Collections, and ColdFusion stuff.
Roles & Capabilities
All the sites use the default Roles & Capabilities, except for the main site. Using the Advanced Access Manager plugin, I changed the permissions so that:
- Administrators: Due to the Carousel plugin, some staff were made administrators, but with restrictions at the user (rather than role) level to have similar permissions as editors.
- Editors: have unfiltered html (using the Unfiltered MU plugin)
- Authors: can also edit/publish pages and delete own pages, moderate comments to own posts
- Contributors: can edit/publish pages (instead of posts) and delete own pages, and add/edit/delete own media
Pages that have JavaScript or custom CSS are also locked down so that only editors and administrators have access.
Migrating the Existing Sites
We migrated from static HTML sites and single install WordPress blogs (I don’t know why this wasn’t a MultiSite to begin with).
WordPress Sites
For WordPress sites, I used the standard export/import that you have to install, but is integrated into the core. The one problem is that in MS, if you import images, it will copy the images over with the metadata, but will not update the links in the posts themselves (see ticket #16404). To solve this problem, I used the Search and Replace plugin to change all the old links to the new ones in one go.
HTML Sites
We settled on using the HTML Import 2 plugin. It worked well, especially since it supports Dreamweaver templates, which were used with most of our pages. It didn’t catch all the links, so we had to update some of them manually, but using the Search & Replace plugin helped a great deal.
The other thing that took a bit of time was to replace thumbnail images with the WP version and delete the original thumbnails. My coworker also uploaded all the images with the thumbnail crop option on, so I used the AJAX Thumbnail Rebuild plugin to force WordPress to recreate all the thumbnails.
Updating the Site
As with any move, it’s a good opportunity to update the site. Unfortunately, we had too tight a timeline to update the content and organization of the site (except for some minor changes). As a result, the site looks more or less the same, but I updated and coordinated the updating of a lot of the code.
I consolidated the CSS files, updated the template to use HTML5 and meet WCAG2.0, and most time intensive of all, got rid of all layout tables (with some other staff helping).
Plugins
Here is the list of the plugins I ended up with including those to help with migration:
For reasons why I may have chosen some of these plugins, take a look at my other posts on WordPress plugins.
Oh The Time
So, the most time intensive part really is sifting through WordPress plugins and updating content.