This is a talk that I gave on January 11, 2012 to the Harvard ABCD WWW group, which is a series of monthly meetings organized by Harvard staff to share ideas about the web and web technology. I had a great time preparing, giving the talk, and having a couple drinks afterward. (Thanks, Donna for inviting me.) Unfortunately, I tried to pack too much information into a 90 minutes talk, so if you have any questions let me know.
Description
For basic content publishing needs, the ease-of-use of WordPress shines. Unfortunately, once a project exceeds 500 pages, using WordPress is much less straightforward. How has Boston University made it work? From a technical standpoint, building relationships between content objects and creating simple to use UIs for managing the relationships is key. Once established, the semantic relationships can be coupled with bits of meta data to construct menus, indexes, facets, filters, and so much more. Using code examples, this talk will highlight essential parts of the WordPress API and demonstrate various techniques used in BU plugins and themes that help us build better large websites.
The slides from the presentation and a link to code for the proof-of-concept are below:
Hey Greg, thanks again for the talk. I was wondering if you could go a little more into your plugin choice process? How do you decide if a third-party plugin is ok to adopt? Also, do you use anything for plugin management?
See my response to Kristen for a few thoughts on how plugins are chosen.
All code that is deployed to our production servers is committed to Subversion. We use vendor branches for code that comes from a third-party, so that we can keep track of any patches that we apply. Code is deployed from the version control system, not through the WordPress administration interface. Is that what you mean by plugin management?
Thanks Greg. That helps with most of my question.
By Plugin management I meant what you use to distribute plugins to various sites. By default you “network activate” plugins and then activate within each site. Is this how you handle it? Or do you use a layer on top of that?
We use the mu-plugins directory for plugins that must be loaded on all sites. For example, the plugin that integrates our single sign-on solution is installed as a mu-plugin. We also use PHP constants, theme_supports(), and post_type_supports() to control whether a particular feature is enabled without having to manual change the configuration. Traditional plugins are enabled/disabled only by the super admins. Normal users must submit a request to the help desk asking that a particular plugin be enabled. There are other tricks that you can employ, but I think it is better to follow the WordPress conventions whenever possible. The conventions are usually well thought out.
Slidehare doesn’t seem to be working right…
http://www.slideshare.net/gcorne/wpbuildingbetterrelationships
Link is fixed now.
Hi Gregory,
Thanks so much for a great presentation yesterday — you really know your stuff! I did have a couple questions I didn’t get a chance to ask:
1) Roughly what percentage of your plug-ins are 3rd party vs. custom?
2) How do you select which plug-ins to use?
3) Who does upgrades?
4) Do you have a support contract with Automattic?
Thanks!
Kristen
1) Roughly what percentage of your plug-ins are 3rd party vs. custom?
About 15%.
2) How do you select which plug-ins to use?
Plugins are chosen using various criteria. I think the biggest factors are value to the BU community, a code review, a review of the UX, ease of integration, the professionalism of the plugin author (including the author’s stature in community), and the plugin’s popularity.
3) Who does upgrades?
IS&T handles all upgrades. Before the production installation is upgraded, substantial testing is done to minimize impact. Currently, upgrades are done yearly. If a security issue is fixed in a later release, we will back port the patch. We would like to automate some of our testing so that we can upgrade more frequently. Unfortunately, test-driven development is not common among WordPress developers, including us.
4) Do you have a support contract with Automattic?
Not currently, but we have had discussions about purchasing one.
Hey Greg,
How do you manage blogs vs regular websites? Do you have more than one WordPress install? Or do you use some creating domain mapping?
Right now, BU maintains a separate installation for blogging at blogs.bu.edu. There are plans to consolidate, but we haven’t done the work. Since the BU Blogs installation does not get a lot of attention, folks have started adding sites that incorporate blogs within the CMS installation if the blog is for an official university entity. Public Relations runs a few more traditional blogs.
We use the Networks for WordPress plugin to create multiple networks in the same installation. Our CMS installation has quite a few networks including a network that we use for staging sites prior to their public launch. The two largest networks are http://www.bu.edu and http://www.bumc.bu.edu.