Andrew Dunkle is the CTO of Go Overseas. Go Overseas is a platform that strives to help people find meaningful travel experiences abroad. They often describe themselves as the Yelp or Airbnb of study abroad programs. Volunteers, recent high school graduates, or anyone who is looking to travel in a more impactful way can use the site to find opportunities. Andrew and his business partner, Mitch, co-founded the company in 2008, while teaching together in Taiwan. They recognized the need for a platform to provide information and encouragement about taking the opportunity to go overseas and give back at the same time.
How long have you been working with Drupal and what version did you start with?
When we first started thinking about how to create this platform and what tools to use, I did a lot of research. What was out there already? Should we use WordPress? I somehow stumbled upon Drupal. We initially started with Drupal 6, when it was in its early stages. I think Drupal appealed to us - specifically me - because it was really flexible.
I don't have a tech background, I'm entirely self-taught. You can do lots of interesting and cool things with Drupal; but, at the same time, you could do it all through the UI. You can build out a really powerful website without actually having to really touch the code, if you didn't want to, need to, or know how to.
When did you think about migrating the site from Drupal 6 to Drupal 8 and how long did that take to implement?
We started with Drupal 6 during its early stages and we were pretty happy on that platform for a couple years. But, as we grew, there were certain things we wanted to be able to do that Drupal 6 didn't offer. Drupal 7 was released, and it was a big improvement on the Drupal 6 platform. We had started to hear about how Drupal was really going to flip things on their heads, so to speak, with Drupal 8. It was going to adopt more of an object-oriented approach and integrate with different PHP projects, mainly Symfony. We made the decision to not migrate to Drupal 7 knowing that Drupal 8 was going to be such a big change.
When Drupal 8 finally did come out, the end of November of 2015, we still wanted to wait and let it stabilize - let the core team work out the bugs before we adopted it. I'd say we started that process in May or June of 2016. That's when I really started to dive into the Drupal 8 platform - really try to learn how it was different and start thinking about what it would take to migrate to that. We kicked it off in August of 2016 and started working with Hook 42 full-time. We launched the site February 4th, 2017. It took about eight month from start to finish.
Why did you choose Drupal 8 over Drupal 7 or some other CMS?
Drupal 7 felt like an extension, and while it had improvements over Drupal 6, it still fell within the functional programming paradigm. Drupal 8 felt more modern and had some long-term stability, so we decided to skip Drupal 7. We did consider other CMSs, but that discussion ended quickly. So much of our data architecture is very Drupal. Migrating it to a different data structure would have been problematic and not really helpful. If we went down the route of using full Symfony (or other PHP frameworks) it would have had certain advantages obviously, but we'd be responsible for building out everything: the UI, the different tools, permissions and routing... Drupal 8 already provides those things and it didn't really make a lot of sense to give up all that for the other advantages.
How was the migration? When you started, Media was still in development and the configuration management and composer workflow wasn't yet defined. When those improved, how did that affect your workflow?
The configuration stuff actually wasn't so bad during the development process. We had waited six or seven months after the launch of Drupal 8. I think we started with Drupal 8.1 or maybe 8.2. The config stuff was alright, the things that were bothersome with config back then, are still bothersome. When more than one person ends up working on the same config at the same time, somebody basically wins and somebody else loses. I think there's no real easy way to merge that stuff.
I think the bigger challenges we faced was the layout management at that time. In Drupal 6, we been using Panels pretty extensively; but, by the time we were working with Drupal 8, Panels was still in alpha and was not stable enough. We made the switch over to Display Suite, it was a little bit of a change. I didn't really like it at first; but, the more I started working with Display Suite the more I liked it. I don't like the UI so much, I think the Panel's UI is better than the Display Suite UI - I think it is really just extending Drupal 8 core. Dealing with the layouts was definitely a challenge for us. I think - for certain content on our site - we just had to do big globs of HTML, just to kind of get things migrated over and pushed.
What were some of the challenges when starting with Drupal 8 and how has the Drupal 8 project evolved since the site launched?
I think the organization of the code of Drupal 8 is a big advantage and something else to get used to. It's obviously different from Drupal 6 or 7. It took me about a month or so. I took some online classes and I went to a DrupalCon LA and took some Symfony classes. Once you get it and think "actually this totally makes sense", it speeds up your development. There's more structure to the projects themselves. So, it's easier for other developers to get involved, because everyone's projects end up looking the same. There's a standardization that makes things a lot easier.
The user stuff is all there; it makes it a lot easier for permissions and authentications. Drupal 8 is little bit harder grasp at first, but it's also incredibly extendable. For example, when you're working with contrib modules and want to change something in the way that module works, or you need to do something with some particular class - you can swap classes out and services out. You don't have to necessarily patch modules to add or alter functionality in core and contrib. I think that is pretty powerful; but, arguably, it can be challenging. You have to know Drupal 8 pretty well to do any of those things.
If you could improve something in Drupal 8 what would it be?
Config management certainly solves a lot of problems. But, it can also generate lots of problems, particularly with Git flows. Most - sometimes all - of my issues with config revolve around Git and just dealing with conflicts.
You used to have the ability, when working with a View, that if you messed up the view, somehow you could revert it back to its prior state in the code. For some reason that seems to be lost in Drupal 8, or at least I don't know how to do it yet. If I mess up a View or I don't like it anymore, I don't know exactly how to revert that particular view back to its original state without messing up all my config at that point.
The whole headless Drupal craze which lots of people talk about... there are competing methodologies about how to best utilize that. We've been experimenting with Vue.js a lot and started to integrate that into our project. It is really neat, but there doesn't really seem to be a consistent way to add Vue.js to the projects. You can do it a variety of ways, which all work, but I'm left wondering, "If they change something then I have to go back and change all these other things."
Or you can also build processes. All these JavaScript frameworks require something pretty heavy - web pack and JavaScript build processes - to generate all of this JavaScript code. There are a lot of build processes that you could figure out on your own, but at the same time, there seems to be competing interests about how to best do it. When a company like us is looking for stability, we want to make a decision that's going be stable for years to come. We can go down this route or the other route, but if we choose the wrong route, it could cause trouble down the line.
What are your favorite things about working with Drupal 8?
Mostly the code organization, I do really like class structures. I would say they are a big help for me. I would tell this to anyone wanting to learn Drupal 8 - get PhpStorm, or something similar, and get really good at it. It is such a powerful tool and it also allows you to really learn how to Drupal 8 works internally. The tool helps you to bounce around classes and methods, so you can go up the tree and see how it all works. It's also self-documenting, some complaints about Drupal - this is Drupal in general, not just Drupal 8 - are that the documentation isn't the greatest. Finding information can be a challenge if you're just looking through the docs, but I find that I can just bounce around in PhpStorm and look at the code that's there. That has helped me understand how Drupal 8 works, what's possible, and what I need to know to extend a certain class or method.
Do you have any advice for people thinking to migrate to Drupal 8?
Have your data architecture down hard. I think that was the biggest challenge for us. Really nail down your nodes and your fields, have your site building really tuned in, know "this field is going map to this field." We had a huge Google Doc that mapped everything over with all the field names, and the data types. The earlier in the process you do that, the better and faster it will go. We thought we had everything mapped over but we had forgotten about something; at the end the project that caused a lot of headaches. During the migration process, you're just migrating data, there's really nothing more important than that. The actual representation of that data, Drupal 8 can handle all that. Particularly at this point, we're coming up on Drupal 8.6 and it's pretty stable. A lot of the core and contrib modules have been ported over to Drupal 8 and they are pretty stable.