A Challenging Move from Drupal to WordPress

At a Drupal meetup earlier this year, I was talking with a Drupal veteran who worked with me on a client project. I told him the client had decided to move their websites from Drupal to WordPress. He was surprised and told me about his another client who had made a move away from Drupal. One of the client’s Senior VP had challenged the team in a meeting: "Why not use WordPress, it is so easy to build a website. My nephew just graduated from college and built a site.. It looks great." The team found it difficult to highlight the technical difference between the nephew’s site and the one my colleague’s company was producing.

This is the story of what happened to that company - a publicly traded company - as they migrated away from Drupal.. They have a dedicated architecture team. The team spent couple months to evaluate among CMSes. In the end, they found WordPress a better choice for the company. They suggested building an army of plugins with the intent to reuse them on the other 50+ company-owned sites. It sounded like a reasonable approach, but there didn’t seem to be appreciable difference between those plugins and thousands of contributed Drupal modules. Anyway, WordPress is easy to use with friendly user interface. It has its charming features.

With high expectations, a group of developers rolled up their sleeves and started the WordPress project. It is a medium complexity project. There are two backend developers, three front-end developers, a designer, and a QA person in the team. There was a standup meeting every morning. In meetings, each team member reported what they had done on the previous day and what they will do next. Other than team member in the meetings, there are directors, a scrum master, backend team leader, frontend team leader and QA managers and different levels of managers every day. There was a weekly demo meeting to showcase what they had achieved. The team was working hard. It seemed to be okay to meet the release date target.

As the project got into the development stage, some technical difficulty started emerging. After thousands of commits and dozens of git feature branches, the project was progressing slowly and the project go-live had to be postponed. When it was finally released, the developers and client noted that the implementation was “messy and quite buggy”.

In my opinion, building a website based on the requirements of the project would have been easier in Drupal. The site could have built the site with a smaller team and launched on schedule. So with this case as an example, why was it so difficult to build in WordPress?
Content Types vs. Post Types

First, the content type is something fundamental for site building. It is easy to set up in Drupal from the main admin interface, but WordPress, you need to write code to create a content type (post type). Like the cornerstones of a cathedral, content types are an essential part of data modeling and site architecture.. In Drupal, content types usually take a couple hours to set up, but In WordPress, you write your code, test and maintain it later on.

Secondly, due to the nature of the business, a significant part of the site’s content were videos hosted on Comcast’s MPX video platform (https://www.comcasttechnologysolutions.com/our-portfolio/video-platform/mpx). .. it was crucial to have a seamless connection between the videos service and the website. In Drupal, there is a mature, dedicated module (https://www.drupal.org/project/media_theplatform_mpx)  that helps map videos into Drupal video file entities. For those who have not taken the file entity dive,, we can think the entity as a deep level of a content type. The content types are a part of it. The free contributed Drupal module is easy to set up and comes with functionality that would take weeks or maybe months to build from scratch.. With the community contributed module’s functions, rendering, categorize, sorting and search videos is easy to set up as eating a piece of cake.

For WordPress, you know what to do - write your code. Building the same module is almost impossible. Not only due to the limited budget but also because WordPress does not lend itself to the development of like-functionality. Without a tool to connect with the MPX video service, they had to fall back on directly scraping an RSS feed. Developer expected features like selecting video by category or sorting videos by episode and season number couldn’t be accomplished within WordPress - add the client’s expectation to the mix and you have a general headache for the development team.

Last but not least, there isn’t a WordPress plugin comparable to the Drupal Views module. Views helps build complex database queries  without having to manually code PHP or write MySQL queries. When we need to display content in different ways, as pages or blocks, we can use a single module to render our data and. build the displays on the fly. In WordPress, It’s a bit more complicated. You end up writing your own MySQL database query in PHP. Additionally, Views will not only fetch data from a database, but also query the videos that we imported from the contributed module. In WordPress, we are back to writing the database query or, in my friend’s case, consuming the RSS feed.

Without proper tools in WordPress, it was tough to build superior features as the project went. Developers had pushed thousands of code commits and sixty live feature branches. With so many git branches, both developers and team leaders were under a lot of stress. The project became complicated and messy. The Drupal ecosystem has an abundance of free,  contributed modules to extend site functionality without a critical mass of additional custom code. Writing WordPress plugins on this project meant reinventing the wheel. The development team could have used Drupal’s contributed modules, spent less time and money, and been less stressed to build their website.

Share This