In a series of earlier posts, I noted that I am currently using WordPress to implement a new website for the University of Illinois Archives. Over the past several months, I have intermittently worked to choose a theme and begin customizing it.  In addition, Angela Jordan has help me move content into the theme system.

At this point, I have a functional website in place, and by early August, we will be enabling the site.  At the same time Jameatis Johnson, our new Archivist for Outreach and Engagement, will begin a round of iterative usability testing on the site.    Before we begin that project, I would like to describe the rationale for the decisions taken to date, as well as to outline some of the basic work that has been completed to set up the site.

Firs, a bit of review:  In my first post, I described the rationale for attempting to run an archives website as Content Mangement System powered by WordPress. My second post covered the basics of WordPress installation.  After I had installed the site, I decided to blow it away, and to reinstall with WordPress enabled for a multisite installation; I covered this topic in my third post. Finally, I gave some background on the WordPress Hooks  system, since understanding hooks is a necessity if you want to do serious customization work with WordPress.

Now it is time to discuss theme selection.

It is easy to pick an off the shelf theme, install it, and to never look back.  However, the real power of wordpress emerges if you are able to customize the theme to your own liking.  Furthermore, you can get a much slicker and user friendly web presence if you implement a good theme.  This is particularly true for if you plan to run WordPress as a CMS.

Several themes support CMS like features out of the box.  On the paid side, the Thesis and, especially, the Genesis Frameworks are particularly good.  I investigated both of them, but ultimately decided not to buy either one of them.   Why?  First, I am cheap, and don’t like paying for something or going through the hassle of getting approval, processing the invoice, etc.  Second, both of them use quite a few theme-specific hooks or functions.  Any functionality I build on top it might run a big risk of theme lock-in.  But most importantly, I ran a usability analysis using the University of Illinois Functional Accessiblity Evaluator on the output of some Thesis and Genesis implementations.  I was very concerned that neither theme included good web design practices to make the pages easily useful for people with disability.  (Not only is it Illinois Law that University sites provide good usability, it is in our interest and is just plain the right thing to do.)

Therefore, I started looking at some free/open source themes, browsing the free themes repository for a theme that was a) CMS-friendly, b) reasonably friendly to people with disabilities, c) easily customized, and d) flexible.   Suffusion seemed to be a good option, since much customization could be done via a graphical interface, and one librarian had a lot of success with it. (Here is a link to a book about using WordPress as a CMS.)  I did install suffusion, and had some luck customizing it.  However, I found that it was very difficult to predict how the changes made in the graphical theme editor would affect the output.  I also had trouble making some changes without editing core source files in the theme–a bad idea since any changes would need to be updated next time.  Finally, I was again concerned that if I chose the theme, I’d be locked in to it for life, since it makes extensive use of theme hooks and extensions.  While many of these extend core functions in wordpress, some of them seemed likely to be theme specific, so that features integrated on the site would not necessarily translate to a new version of  wordpress.  Therefore, I uninstalled Suffion.

About this time, I began looking at themes that would allow me to develop my own child theme.  Child themes work by referencing a ‘parent’ theme.  The parent theme does the heavy lifting of laying out the page and plopping content into it.  However, any elements of the parent theme can be modified in the custom theme, while running minimal risk that updates to the parent theme will break the child theme or the site as a whole.

After investigating several options, I settled up on the Thematic Framework. There are several reasons:

  • Out of the box, the theme is very plain, in the best sense of the word.  The pages are laid out in well-labeled, logical <div> elements, and no colors are applied, allowing me as the developer to apply styles very easily.
  • The theme is very friendly to people with disabilities.  Its output passes the functional accessibly evaluator tests.  For example, the menus it produce include a hidden link to allow people using screen readers to skip to the main portion of the site.
  • The themes ‘back end’ files are laid out in a very logical, easy to understand way.  (A screenshot of the overall organization is below this bullet.)  If I need to understand where a certain style is applied or function is located, I can find it easily, study its content, and then replace or extend the code in the child theme.  As you can see, there is a simple list of php pages that produce the output of a post/page, as well as a master css file, then libraries which include all of the functions, page layouts, substyles, etc.

  • Quite a few people are using Thematic, and there are a wide range of resources for understanding the theme and for implementing it.  I’ll have a list in my next post.
  • It is developed by Automattic, the developers of WordPress itself.
  • It is very rich on features and lean on bloat; very unlikely that any functions introduced in it will not mesh well with WordPress as a whole.
  • In my test of the theme, I found it very, very easy to make simple modifications to the output.  Every change I made (whether it was to page layout, colors, etc) required only a few changes in the sample child theme supplied with the theme.  I was even able to tap into the theme functions and to modify them via the child theme, without any real trouble, after reading a bit of the documentation. The changes had the expected results, and I was able to roll them back without any problems.
  • The fact I would be developing a child theme allowed for the possibility to share my work with the WordPress free themes project, as well as to use it as the basis for sub-sites within our WordPress multisite installation.

Next post, I’ll walk through my initial customization of the site by explaining how I developed the basic child theme.

 

Tagged with:  

Comments are closed.