Rails to WordPress

Development

We had a legacy website built with Ruby on Rails. It got the job done. But it was constantly causing friction—the marketing team wanted to move quickly on things, but relied on a preoccupied dev team to make updates. At some point the team tried papering over the problem by adding in Butter CMS, but it still required a developer for most changes to the website. Eventually the team got fed up and decided to migrate the website over to WordPress with the aim of empowering the marketing folks to be able to own their website and move quickly when needed.

Strategy

I started this project with a rough idea in my head about how I wanted to approach it.

Initially my expectation was that it would take a couple weeks. After all the site wasn’t too massive—probably under 200 pages, and nothing seemed too particularly complex. But after spending a day taking stock of everything, it was clear this project would take closer to two months. In the end, after frequently getting pulled away to work on other projects, this effort stretched out to an entire year.

Gutenberg Editor

I began work on this project right around the time the Gutenberg Editor was rolling out. I remember being quite worried about the possibility that I was building my site based on assumptions that could easily change. Fortunately I never ran into any problems like that. There were some minor hiccups along the way in terms of bugs, but that was also kind of cool to be able to contribute to the conversation on GitHub issues, and feel like I was helping make the editor better for everyone.

As a side note: one of my favorite things after completing the project was training folks how to use WordPress and to just see the concept of Blocks click with people.

Hindsight is 20/20

There were some key things I glossed over at the project outset that I wish I’d have taken more time to consider. For one, #devops. Developing for WordPress is pretty fun in my opinion, but setting up a streamlined process to go from a local machine to a staging server to production takes some time getting right. We ended up choosing a managed hosting solution that definitely wasn’t optimized for this sort of flow.

Another major stumbling block was underestimating the complexity of our custom software. We had a homespun, signup process, a complex price estimation system, and lots of other small, quirky custom things.

The last big morass was third party integrations. I assumed very wrongly that most of the services we were using would be simple. In the end, I learned way more than I’d care to about Google Tag Manager triggers. Who knew handling a referral program’s verification process would take a week? Fraud detection, Google Maps marker clustering, using the YouTube API… it all added up.

Some other smaller things I should’ve factored more carefully:

Conclusion

The project was completed. It took longer than we anticipated, but yikes I learned a lot—more than I ever thought I’d need to at the outset. Ask me about hashing keys in PHP… or don’t. ;) Ultimately the effort was worth it. It gave the marketing team the autonomy to move quickly on decisions and freed the dev team from perpetual context switching.


Posted January 7, 2020