Building a website on any content management system will always introduce unique challenges to be conquered, because every CMS has its good, its bad and its ugly—WordPress is no different. 


On the recently launched redesign for Lafayette College, the…

Building a website on any content management system will always introduce unique challenges to be conquered, because every CMS has its good, its bad and its ugly—WordPress is no different. 

On the recently launched redesign for Lafayette College, the development teams at Fastspot and Lafayette collaborated to harness the full potential of a multisite WordPress installation. We had a chance to speak with members of both teams to gain insight into the collaborative development process, the challenges that WordPress posed, and the solutions that led to a great website and a successful launch.

When and why was the decision made to use WordPress as Lafayette’s CMS?

Ken We had been using Dreamweaver way back in the day, and it was very, very difficult to support. This was in 2009. For our previous redesign five years ago, we decided to go with WordPress. The user interface is very easy and people had no trouble using it. It was one of those things where you could sit down and show someone how to use WordPress, and five minutes later they’d be off and running. That’s why we started using it five years ago, and we just had a lot of luck with it ever since.

Were there any restrictions or specific requests coming into this project?

Ben So, the biggest restriction would be WordPress. [Laughter]

Matt I think the biggest existing thing to adapt to was the fact that there was already a multisite environment in place. Any time we needed to share the same content across different theme bases, we had to take one extra step to make it available. We used a plugin to return a JSON feed of all the data that we needed from a particular set of pages or content fields and display it on another of the sites.

Ken—your last site redesign was structured as a multisite installation, which you wanted to maintain for this project. Why?

Ken I think the primary advantage to multisite is scalability. We have a very distributed content management model at the College, where each of the different departments and divisions is responsible for maintaining their own content. With multisite, you can very easily create different subdomain sites and have each person manage the rights and permissions, maintaining their content without having to interfere with anybody else’s.

"Advanced Custom Fields and Custom Post Type UI—two major plugins that will make it into our official WordPress toolkit—work together to allow you to have the ultimate flexibility in WordPress."

Are there any disadvantages to such a setup?

Ken It works well for our group because we know WordPress and we’re comfortable with maintaining WordPress and keeping it current. For people who are less tech-savvy, it might not be an ideal choice unless you’re willing to outsource it or invest in the people to actually keep it up and running. But multisite’s come a long way, and has been very stable. It works really well for us. It allows us to easily distribute plugins — we can just turn on a plugin and everybody gets it.

Matt Git was very helpful. We had each theme within its own submodule, so that we could keep the whole WordPress installation in a single repository but maintain the themes individually.

Loading ACF Field Groups

How did you feel about the collaboration between Lafayette’s development team and Fastspot’s development team?

Ken I think it worked beautifully! We didn’t have any problems pushing code back and forth. Fastspot was very knowledgeable in terms of being able to branch and being able to push us code without breaking our own internal workflow.

Matt The Lafayette team is on top of their game. They’re equal parts chill and knowledgeable, and they worked with us to make sure that if we needed help with anything, they gave it to us.

Ben We went up to Easton and met with Ken's team early on during our discovery phase, about six months before we started production on the project. So we knew what we were getting into, and had a bit of lead-up time to start looking at some plugins.

"The primary advantage to multisite is scalability. With multisite, you can very easily create different subdomain sites and have each person maintaining their content without having to interfere with anybody else’s."

Were there any specifically code-related barriers to spinning up the project?

Ben I think one of our bigger barriers was the WordPress code sniffer. The internal team at Lafayette follows the WordPress code standards pretty strictly and we try to be as accommodating to the client's workflow as possible. That was another technical requirement of the project—to make sure the code met those standards.

Matt That was kind of a happy accident, as it helped us keep everything consistent. We incorporated it to our regular grunt tasks so that we could run the sniffer when we were wrapping something up. It gives you the ability to make sure that every commit is nice and clean.

Ken We hadn’t worked with the WordPress API previously, which is a third-party plugin. We had to figure out the best way to configure and set that up, and come up with a new dedicated WordPress instance to provide the photos for the photo galleries. I think debugging that was a challenge. [laughter]. Especially when we originally decided to go with a beta version of that plugin, but then realized that was introducing new complexities that we didn’t need. So we fell back to the original version.

Ben I’m glad Ken mentioned that. Moving data around using the WP-API was the other big code barrier we ran into. That’s what exposes a JSON REST API of the content from a WordPress site. Basically, you can query posts between sites. On a child theme or on another site, we would use transient caching to reduce the number of overall requests. Every time a gallery is updated it doesn't need to be fetched at page load, instead it’s called every five minutes, reducing the overall latency.

"What’s really nice about Custom Post Type UI and Advanced Custom Fields is that any changes to content types, post types and forms are all stored and versioned in code, so you don’t have to manually sync a large database from development to production."

Customization and scalability are two aspects where WordPress is often unfavorably compared to other CMSs. Did you encounter any major challenges to building a large, customized site?

Matt I think that the Advanced Custom Fields and Custom Post Type UI plugins—two major helpers that will make it into our official WordPress toolkit—help create a less restrictive environment inside WordPress.

Custom Post Type UI allows you to create the custom post types easily, and Advanced Custom Fields helps you with a wide variety of content field types to build out the posts and pages. They work together to allow you to just have the ultimate flexibility in WordPress.

Ben What’s really nice about those two plugins is that you can actually export the configuration to code so that it isn’t stored in the database. The updates—any changes to content types, post types and forms—are all stored and versioned in code, so you don’t have to manually sync a large database from development to production. 

Ken I think Advanced Custom Fields is probably the single biggest change to our toolkit. It introduces a tremendous amount of flexibility to WordPress, because you have a whole lot more fields to be able to add content and to make your page a lot more modular in terms of its display and function. We had fairly straightforward custom content types previously that did not have nearly as many display options. Now we have a heck of a lot more. It’s providing us with exactly the sort of flexibility people are looking for.

Matt Some objects like news and calendar events can be limiting if you’re using WordPress out-of-the-box, but with these plugins you can customize any kind of post. So, it still feels pretty extensible.

Ben As for scalability, I guess it was really about randomization. If a feature needed to be a random item of a set of five and you’re performing the randomization server side, then the single result gets cached. Then for the lifetime—three minutes, five minutes, whatever—that’s all you’ll see.

We ended up going with W3 Supercache as a caching layer. That’s another plugin that Lafayette was already familiar with. We had to make few tweaks when we actually flipped on Supercache, but nothing crazy. 

Matt We also found a page-tree plugin that displays the pages like a real page hierarchy. That seems like a huge upgrade over WordPress's typical page list, where everything appears to be on the same level of hierarchy.

WordPress is built to have a handful of pages and a ton of posts, and we’re turning that on its head by having a ton of pages with a ton more custom post types. I think little enhancements like that can give WordPress a nicer administrator experience. Because it is well designed, and with a couple of small improvements, you can really help it get out of its own way.

Loading Template Partials from Repeater Field

"WP-API exposes a JSON REST API of the content from a WordPress site. Basically, you can query posts between sites. On a child theme or on another site, we would use transient caching to reduce the number of overall requests."

Security concerns are often brought up in arguments against WordPress. Are those concerns warranted, and if so, what have you done to ensure a high level of security?

Ken WordPress, like any other popular open-source project, has its share of people who are trying to hack it. It’s certainly a target, but everybody else is also a target. We have defense in depth, so we’re not relying on any one thing to protect us from malevolent individuals. We have internal tools that we use to both detect and prevent intrusions. Our approach for WordPress is the same as it is for Drupal and for Moodle—two other open-source projects we use—which is: having good code review practices, following code standards and keeping the site current!

Ben I think it’s good to keep in mind that no code is perfect and you have to stay up on new releases. Having a dedicated team that will apply security patches and bug fixes is important for any project.

WordPress is often cited as being a top CMS choice for web designers and content creators and managers, but not necessarily for developers. Do you feel that this distinction of its strengths and weaknesses is accurate?

Ken I think that was more true five years ago than it is today. I think WordPress has come a tremendous way since we first started using it five or six years ago. It used to be that there was a very clear distinction between Drupal and WordPress in terms of complexity and what you could do with it. I think it’s still true, but WordPress has come very far in terms of the robustness that they’re offering.

Matt WordPress was built as a blogging engine, so that’s what it does best. They’ve certainly been working to make it more friendly for run-of-the-mill website building, but it really takes some extension to get it to behave like some other CMS’s that are more tailored more to general site-building.

Ben WordPress feels like it’s trying too hard to be readable, which is probably why designers like it. Rather than straightforward naming conventions that you might expect coming from another system, code reads like a sentence. It's good and bad—it’s easy for non-developers, but it ends up getting in your way sometimes. I do find certain parts of the code base really nice. The transient caching system is really well thought out.

The documentation could also use some work. The basic loop is really well-documented, but if you’re trying to dig into the query language or a random function hook, it’s usually not as clearly documented, if it's documented at all. 

Working with the Transient Cache API

"We were able to create a WordPress site that doesn’t look like a WordPress site."

What kind of feedback have you gotten from content creators and content managers about using WordPress, and how heavily did their concerns factor into this redesign?

Ken Generally speaking, WordPress has been very easy for our community to use. And that’s truly been its greatest strength. I think it handles 90% of our use cases beautifully. So in terms of the web redesign, we wanted to retain that ease of use.

Our old design was very structural and focused on being consistent, but it didn’t have a lot of flexibility. People definitely wanted flexibility. That was one of the things we heard about going into the redesign, is they wanted to be able to have more options. So now we’re giving folks more options, but the challenge will be teaching them how to use those options.

As a final thought, what’s your biggest positive takeaway from this project?

Matt Sometimes people won't bother with a lot of customization, they just find something that works for them. We built something from not exactly the ground up, but pretty close. All of the markup structure, for the most part, and all of the styles—it’s all custom just like we always do at Fastspot.

Ben I think we were able to create a WordPress site that doesn’t look like a Wordpress site. 

Ken I think the presentation looks beautiful. I love the big images. I like how it transforms when it goes responsive and it moves through tablet and phone breakpoints. I think it’s nice to have something that flows very elegantly between those different states.

It’s great to come in and to have it there in front of you. It’s a welcome change!

GALLERY OF DESIGNS FOR THE NEW LAFAYETTE.EDU

Share on Twitter or Facebook Published September 24th 2015