Last year in Amsterdam at the DrupalCon, after the first official Drupal 8 beta release we were sitting enthusiastically and felt the courage to offer Drupal 8 to a client.
Views is in core and there will be an upgrade path between beta releases -- at least we thought at the time. So what could go wrong? Well we know that anything :) So we tried to be careful.
The client was selected carefully
- Our client Gravity Research & Development is known by its recommendation engine. They are an innovative IT service company so choosing an innovative platform for their new website is a good fit.
- We already maintained the client's legacy Drupal 7 site so their needs were well-known for us.
- Does this mean that we charge the client with our learning process? No! From the beginning we counted with a large investment on our side + we were generous when it came to change requests.
- We created the wireframes and the graphic design too, so we had chance to discuss these with the developers.
- The scope of the new site was very limited: a one page site with a couple of additional simple subpages (by the end this had changed a lot)
- 1 language only
We set some principles for the project
- Using only Drupal core and no contrib modules
- Trying to minimize custom module development
The start: Drupal 8 beta6
- When we started the actual development, Drupal 8 was in beta 6 and we realized that no official beta to beta upgrade path will be available. No panic, we will only upgrade to the stable release. (There is a contrib module which has upgrade path from beta9, but we haven't tested it yet)
- On our weekly internal training sessions we focused on Drupal 8. This way not only the 2 involved developers had to solve the issues, but the whole team was there to help and to learn at the same time.
What worked well
- TWIG template engine and template debugging.
- Core configuration management. Works like a charm on the admin UI and it has drush support as well.
Custom module development
A views plugin to handle custom navigation tabs (note that there are tabs below the content area too). We will show this in a separate post later.
Drupal 8 custom modul development
Struggle with simple things
Bye-bye drupal_goto(), hello RouteSubscriberBase!
The nice thing with using new technologies is that even the easiest thing can become a real pain.
But in Drupal 8 the good old drupal_goto() doesn't exist anymore. We had to figure out the Symfony way and ended up with two files (classes) as we had to override the NodeViewController and the RouteSubscriberBase instead of that single drupal_goto. We will show a working example on this in a separate post.
In Drupal 8 a lot of declarative things (info files, menu hooks etc.) are placed in YML files and this is good. But the current IDEs (we use PHPStorm and Netbeans) the Drupal 8 - YML support is limited and it can take really a long time till you find out that you made a typo somewhere in your YMLs. I hope that this will get better with time.
Our next Drupal 8 project?
Gravityrd.com is up and running, but we still don't recommend Drupal 8 for complex projects. Most of the documentation on the web is obsolete, things are still changing and there are a lot of critical issues left. On the other hand we believe that this is the future so it's worth it to invest time to learn and adapt early. We are already planning our first headless Drupal 8 project, so that we can benefit from its in-built webservice support.
Last week we hosted the Drupal User Group meetup in Budapest, where we shared our experience with the local community. Check out the presentation slides about creating the first production Drupal 8 client site in Hungary.