What’s It Like For A Developer Moving To Wagtail From Drupal?
Why switching to Wagtail after 5 years as a Drupal developer was a good idea.
Since writing my last post 6 things I learned while moving a Drupal 8 site to my first Wagtail site, I’ve got my feet wet, well soaked actually, with Wagtail and now is a good time to pause and expand on why I thought switching to Wagtail after 5 years as a Drupal developer was a good idea.
As a developer, I’m always trying out new frameworks and technology, but I usually have a solid foundation to fall back on. For a long time, Drupal was my nucleus of development and I’ve been working with it for over 5 years, from front end to back end. Sure I would use new technology like AngularJS or Vue.js, but I never considered a totally new framework. I’ve been using Drupal for a long time so why would I change a solid foundation like that? Well, turns out it’s not that solid…
I’ve been working for Torchbox, creators of Wagtail, for over a year on Drupal 7 and 8 projects. Upcoming changes to core for Drupal 8 included moving towards decoupling, utilising existing PHP libraries like Symfony, a smoother publishing workflow, and better code management. I hate to say it but, for me, the delivery of these changes fell somewhat short of the mark. While the community of Drupal developers did get big changes, the cost was massive. The changes, specifically bringing Symfony in, were a good decision but the result was that in a matter of months skilled Drupal developers were faced with learning a new way of working with Drupal. And they had to learn it fast. This left developers, clients, and specifically ‘Drupal site builders’ scratching their heads more than usual. In the limbo of changing from Drupal 7 to Drupal 8, my curiosity for alternatives increased. Was it time to learn something new? Is there something I can adopt which does more than build websites?
Compared to Drupal, Wagtail is young, but it’s grown up fast. If you consider Drupal 8 as a new CMS (as I do) they’ve been around a similar amount of time, but the Django framework that Wagtail itself is built on is nearly as old as Drupal. This gives us some good signs… It’s here to stay, it has a core team of contributing developers, and it has documentation. So, after moving a Drupal site to Wagtail and seeing the immediate benefits, why have I decided to stick with it?
- Wagtail has a community you can easily get involved in.
- For developers, Wagtail is a great tool to add to your toolbox for creating web applications but also, learning Python is a whole new toolbox because It’s used across a range of industries, not just web development. This is really positive for your career as a developer
- The list of organisations worldwide who have independently selected Wagtail for major projects is pretty impressive, and it’s quickly growing. Google, Nasa, and Oxfam to name a few.
PHP to Python 🐍
The first thing to come to terms with is actually writing Python and just how much code you will be writing. You won’t be ‘building’ things in the UI anymore. This opens you up to many new aspects of development and will be different depending on your skill level, but for me, I was never really exposed to traditional development concepts because Drupal handles a lot of this for you and you never really see it. After learning the basics of the language I found some great tools to help me write better code.
Wagtail asks that all contributions adhere to the PEP8 style guide. So, a good habit to get into is writing code that meets this standard. Realistically, I’m not about to read and memorize a new coding standard fresh off the PHP boat with semi-colons for shoes. A colleague of mine (Rich) suggested setting up a pre-commit git hook which uses Flake8 to check the code against PEP8 standards, it catches things like line length errors (E501 if you’re interested) and unused imports. I can’t stress how good this is, mostly because without knowing it you start a little game of trying to beat Flake8 which leads to better code. In VSCode you can also configure PEP8 to run when saving a file, and errors are shown in the output. Personally I prefer the git hook, because you won’t be able to commit until it’s fixed, and while at pressured times this is annoying, it’s like having a better you tapping you on the shoulder saying “Now now, I know you’re busy but let’s get this right”.
Wagtail (Django) Apps are like Drupal Modules
You probably know this already, but when compared with Drupal 8, this is easier to understand. Drupal 8 uses Symfony, Wagtail uses Django. More specifically, Wagtail is built on the Django web framework. So when working with Wagtail, you will be working with Django. I like to think of community apps for Wagtail and Django as Drupal modules. They are community-built solutions for use on your project but when your Wagtail project starts getting more custom and complex, you will more than likely be utilising the Django part of your project. There are lots of Django apps out there you can use but there are also Wagtail apps too… just check this awesome list out from Springload.