Tag: WordPress

Presentation: Making Accessible Content and Websites in WordPress

Presented at the Cowichan Valley WordPress August 2018 Meetup. This presentation was all about web accessibility, thinking about the users affected, technology involved, creating accessible content in WordPress, and finally, choosing accessible themes and plugins.

The first part of the presentation is pretty much a rehash of previous presentations, the second part on content is similar but focuses specifically on WordPress. The last part is almost all new content specific to WordPress.
Continue reading “Presentation: Making Accessible Content and Websites in WordPress”

Building Community by Providing Great Experiences

Over the weekend, I decided to change my theme from the WordPress TwentyThirteen to TwentyFifteen. I switched mainly because I wanted a more accessible theme, and also because I was getting tired of looking at the Thirteen one. Another nice feature was the menu and sidebar integration. It may actually take up more space, but it also forced me to re-evaluate what I thought was important and what I could simply leave out. (I now have 1 widget as opposed to 5.)

Anyway, that’s not the reason I’m writing. The reason for that is that over the weekend I found a bug, filed it, and it was closed in 22 hours! Continue reading “Building Community by Providing Great Experiences”

Update to TwentyTwelve & Child Theme: Accessible Submenu

A quick update. I’ve previously written on developing an Accessible TwentyTwelve Child Theme. Recently, a new version of the parent theme (TwentyTwelve) was released, so I had to update the Child Theme to reflect the changes in the parent. Continue reading “Update to TwentyTwelve & Child Theme: Accessible Submenu”

Tips on Making Your Gravity Forms as Accessible as Possible

I’m currently using gravity forms and struggling with the accessibility of it. It sounds like there are no plans to make it accessible, but I know a lot of people use this plugin, so let’s make the best of it. Continue reading “Tips on Making Your Gravity Forms as Accessible as Possible”

Developing the WordPress Theme: Making Changes to TwentyTwelve

So last week, I posted about making an accessible child theme of TwentyTwelve, but left out the details on why I chose to make some of the layout and aesthetic changes. Continue reading “Developing the WordPress Theme: Making Changes to TwentyTwelve”

Accessible WordPress Theme: Creating a Fully Accessible TwentyTwelve Child Theme

To make up for the lack of post last week (apologies, things have just been too busy), a special post this week. Before working on the new website, I once again did some searching for an accessible WordPress theme. Unfortunately, I found little that would meet my needs as I required WCAG (Web Content Accessibility Guidelines) level AA at the minimum, but preferably something that would be as accessible as possible.

Continue reading “Accessible WordPress Theme: Creating a Fully Accessible TwentyTwelve Child Theme”

Setting up WordPress CMS for an Academic Library

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.

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.