3 things every WordPress developer should know about Drupal
Sometime back in the mid to late 2000s when most web developers/designers began seeing the writing on the wall when it came to content management systems, most of us bit the bullet and also decided try one out. After all, our clients were pushing for it and it’s what all the cool kids were doing, so we begrudgingly fit it into our workflow.
Open-source CMS's drew the most attention, especially the ‘big three’ — Joomla, WordPress and Drupal.
Naturally, I was curious about each so I evaluated all three, which usually involved installing one and then attempting to figure out how to make it look a specific way by the end of an afternoon. I’m a visual designer and was working on my own in those days, so if I couldn’t quickly and easily get things to look the way I wanted, it wouldn’t work for me.
I’ll freely admit that I’m an avid reader of CSS-Tricks.com and that Chris Coyier has a definite affinity for WordPress. Although I’d like to say I made my decision on which CMS to use based on my own trial and error, the truth is that I needed to get up and running quickly, so Chris’ teaching style hooked me. Drupal and Joomla quickly fell by the wayside and I’d made my choice.
Now fast forward seven years. After using WordPress for almost every purpose under the sun, and for the most part enjoying it, I started working at Texas Creative, which is notoriously Drupal focused. I knew this upon coming in and was excited to see what Drupal was capable of. Entering the Drupal world with a WordPress perspective taught me three things that were very surprising.
No Loop
In WordPress, we live and die by the loop, but Drupal functions differently. As a matter of fact, what surprised me most in the first six months of working in Drupal was that I hadn’t written a single line of PHP and precious little HTML. Granted, we have very talented Drupal developers on staff at Texas Creative and I’m primarily a UI designer. Still, after working as a WordPress themer for seven years, I was used to opening up page.php to hack out loop variables and opening the CSS to style what I’d written. So imagine my surprise when I realized how Drupal was so different in these aspects, specifically:
- Drupal manages primarily through the admin UI, so are you adding a chunk of random content (block) to a sidebar? No PHP needed.
- Want to sort all your products and expose filters to your user? No PHP needed.
- Need to create dozens of image styles for your users to upload in different areas of the site? No PHP needed.
No more functions.php.
The beauty of this approach, in my opinion, is that the admin UI allows the client (who’s managing content) to make multiple changes to their site without needing to understand the code that powers the CMS. Which is what a CMS is suppose to do, right?
Now, you’ll get VERY familiar with the Drupal ‘views’ module, which will at times have you wishing you could just hack it out in PHP, but in reality, this non-reliance on straight PHP speaks to the maturity inherent to the Drupal experience. It’s much less "fly by the seat of your pants" in many ways, which can be both good and bad.
Incredible Drupal Images Styles
WordPress developers are familiar with thumbnails, medium and small image styles, and the ability to create custom styles. But what if you could upload ONE image for an article and display that image in any number of ways?
- Convert photos to black and white
- Define a focus area so auto cropping comes out nicely
- Desaturate an image
- Round corners
- Increase brightness
- Add a watermark
All on the fly!
We used the ‘area of focus’ cropping tool for the Tobin Center’s website we recently launched. The user simply uploads one show photo and Drupal automatically creates a banner image, a featured image for the box office and two thumbnails — one color and one black and white.
I’m certain this functionality could be reproduced in WordPress, but would it be worth it? How much plug-in hacking would be required? In Drupal, only a few key modules are required and then the image styles are ready to roll.
Content Types, not Posts or Pages
When was the last time you built a site in WordPress and had something other than a traditional post or page? I don’t think I’ve ever built one of those. It seems like the client always wants calendars, slideshows, advertisements, testimonials, etc. Now, you can tack those onto pages and posts in WordPress, create custom post types or use advanced custom fields, but it’s not always easy and the implementation isn’t always consistent.
Drupal solves this issue by forcing you to make all content a content type from the get-go. Need a calendar? Create an event content type and a calendar view that pulls from that content type; then when a user creates an event, it’s woven into the site wherever that content type is displayed (as long as it meets the criteria defined for that particular display). It can be used in a calendar view, an individual event (node) view, etc. You could even relate events to one another and display related events in the sidebar of each individual event.
No more short codes to include a calendar on a particular page.
These are three quick things that distinguish these two very popular CMS's. At the end of the day, I love both and believe each has its specialty. Agree or disagree with any of my insights? Let's talk about it in the comment section.