Estimating what you can build with Drupal 8

The final release for Drupal 8 is just around the corner - for some it might feel way too early to think about using Drupal 8 to actually build sites, others already do so. It’s never too late to get started and here is how we approach figuring out, what we can already achieve for our clients with Dupal8. Having launched 7 sites on Drupal 8 already, here at Amazee Labs we are working with it on a daily basis. This continuously exposes us to adventures with a fresh ecosystem that our developers love to work with and our clients also appreciate for better usability and forward-thinking technologies. It also gives them a leap ahead in the every-day evolving web.

A FRAMEWORK FOR ESTIMATION

In this blog post, I’d like to share with you some insights into how & why we decide to build certain websites using Drupal 8. Which feature will be ready when? Will it cost a different amount if built with D8 and when should I migrate? I certainly won’t be able to predict the future, but provide a framework that works very well for us so far to estimate new projects and their feasibility with Drupal 8.

FROM REQUIREMENTS TO EPICS

Our offers consist of a rough estimate based on line items, which map to functionality the client probably wants. As we are doing more and more agile projects, the granularity of specification is kept to a minimum, providing a good understanding for the client on what to expect but giving the team flexibility on the go to account for change requests and gained, additional knowledge about the requirements throughout the project. From the requirement, we’ll derive a line item that can be seen as an Epic in Scrum terminology. Examples are Setup Drupal, Content Editing, Notification System, Media Library or Search.

PRIORITIZE WHAT CAN BE DONE USING DRUPAL 8 CORE

There are currently 32'315 contributed modules available on Drupal.org. This great amount of extensions isn’t yet available to Drupal 8 sites. On the other hand, Drupal 8 core itself got a lot more powerful. 23 modules alone have been integrated into Drupal 8 core; such as Ckeditor enabling full WYSIWYG editing out of the box, Views for dynamic listing or important field types such as Entity Reference, Link or Email Field. Together with other improvements such as View & Form modes, they make the site building experience out-of-the-box already so much more powerful than it was with Drupal 7. So instead of relying on dozens of contributed modules, we try to achieve more with Drupal core and the few contributed modules that exist at the moment. This is also a great opportunity to design website content first - of course with great designs in front, but without the “featuritis”. We have seen too many sites out there that just combine a hundred modules because “there is a module for that” and create technical debt by doing so. 

FROM EPICS TO DRUPAL MODULES

Of course, there are cases where Drupal core itself doesn’t make the cut. Let’s look at the example of a “Notification System”. In Drupal 7, we usually recommend to use the Rules module for that purpose. It allows building powerful notification systems that are easily adaptable by clients. As a client admin can modify notification texts through the administrative interface, we reduce the need to ask one of our developers when the client wants to adapt such texts. Thus, implementing a full notification system as we are used to in Drupal 7, would require us to wait for the Drupal 8 version of the Rules module. 

CHECKING THE STATUS FOR THOSE MODULES

But wait, how can I know that I still need to wait for the Rules module to being ported? And if there is a Drupal 8 release available, is it safe to being used? As I’m one of the organizers of the #d8rules initiative, figuring out the current development status is a no-brainer, but for the average person interested in using a module, here is what you should do:

• **Does the module page lists a stable release for the module I want to use? **When you check here you will note, that for Drupal 8 there is only an unstable release available by today: 8.x-3.0-unstable5. While there are modules with good alpha or beta releases out there, this is not a good sign for stability of a module.
• Do the statistics linked from the module page look promising? If we compare the Drupal core statistics with those for the Rules module, we’ll find out that as of October 25, there are 44,863 active Drupal 8 installations and only 84 of them have the Rules module installed. That’s less than 0.1% - while in Drupal 7 the adoption rate is above 25%. Not a sign that the module is usable already in Drupal 8.

If you are looking for an overview of contributes modules in D8, the following resources should be helpful:

• **Drupal Contrib Tracker Kanban board **listing states as “No Port Active”, “Work Started”, Has Alpha/Beta”, “Has RC”, “Stable Release”, “In Core”, “Renamed/Obsolete” and “Blocked”. This is a great tool to get an overview of what’s going on.
• **D8 Module Status **on the other hand is a test-driven approach, which lists PHPUnit & Simpletest coverage & test statuses.

PROVIDING ALTERNATIVE OPTIONS

Continuing with our example about the notification system, the Rules module doesn’t seem to be available at the moment. So we’ll tell the client that, if we want the full flexibility, we should wait for the module and try to postpone the feature until a later sprint. If the notification system is really needed at an earlier stage of the project, alternatives should be looked at. Depending on the complexity of the module that is needed, it might make sense to invest into the porting process from Drupal 7 to Drupal 8. Some initiatives provide sprints, e.g. the media initiative or you can help by donating funds like for #d8rules. Let’s assume that for the Rules module and for this particular project, we don’t have the necessary resources of getting the module ported or time constraints apply. A common strategy is that we offer an alternative, interim solution. A “notification system light” could be implemented using custom code. This doesn’t give the client the flexibility of the Rules UI where notification mechanics & texts can be adapted through the user interface. But in the end, when the texts can be defined up-front, we can still implement a simple notification system that does the job. In a later phase of the project, the simple notification system based on custom code can then be replaced by a configurable notification system based on the Rules module. Let’s look at some examples:

• Content
  • Now: **Content basics **- we can already build great a content model based on content types, fields, view modes, CKeditor, ...
  • Later: **Advanced content workflows **- the workbench moderation module isn’t ready, yet
• Media
  • Now: **Basic file management **- Drupal 8’s basic file management is limited but works
  • Later: **Media library **- reusability of files from a central repository depends on the joined efforts within the media initiative
• Search
  • Now: **Basic search **- Both Drupal 8’s core search and Search API are ready to serve good basic search capabilities across contents of the website
  • Later: Extended search - Facet API has only recently had its first release, so at least we need some time to investigate the maturity of the module
• Layouts
  • Now: **Content layouts with Paragraphs **- we already used the paragraphs module on Drupal 8 to build great landing page authoring tools. Excitingly it also works great for multilingual site configurations
  • Later: **Content layouts with Panels **- the panels module only recently had its first alpha release for Drupal 8, so again there is potential but the maturity needs to be validated
• Metatag
  • Now: **Basic metatag functionality **- we already use the metatags module for content pages such as nodes, which works really well. In addition, some easy scenarios can be accomplished using custom code
  • Later: **Deeper metatags integration **- the metatag module doesn’t provide integrations like for example with Views or Panels
• Migration
  • Now: Migrations - the Migrate API is part of Drupal 8 core
• Forms
  • Now: **Basic forms **- using the Drupal 8 contact form module, we can provide solid forms for entering data & requesting information
  • Later: **User-customizable forms **- the web form module isn’t available for Drupal 8, yet

Of course, the above listing is a personal assessment & subject to change based on the experience that we gain with each project. We will feel more comfortable using some of the early-stage modules in Drupal 8 as soon as we have used them already on other projects. And, as Drupal 8 and its ecosystem is developing rapidly, this listing will probably be out-dated within a few weeks, already. Its up to all of us Drupal agencies to contribute to a sustainable development of Drupal core and its contributed modules to ensure that also in the future we can build on the shoulders of giants. At Amazee Labs, we sponsor Drupal events like DrupalCons and Camps as well as contribute to initiatives like the multilingual initiative or #d8rules. Also in our day-to-day business, we try to solve problems by improving existing solutions & creating patches rather than implementing everything in custom code.  In this article, I tried to give insights into our continuous process of evaluating new tools, testing them & actually providing them to clients. I have shown how we go from requirements to epics & prioritize what can be done using Drupal 8 core. Then we go from epics to Drupal modules, check statuses of those modules and finally provide alternative options. By showing, what we can do now and what probably should be done later, our clients are able to take informed decisions.