Upgrading A Drupal 7 Module to Drupal 8 - Adding Routing and Menu Links

Posted by CU Boulder - Webcentral on February 13, 2017 at 7:10pm
Invite Users Page Users Overview Page Invite Management Page Invite Configuration Form Invite Config Form Menu Link

When planning to upgrade a module from Drupal 7 to Drupal 8, I was originally going to start out doing TDD and unit testing before I wrote any code for this module, but since I know very little about OOP practices and Drupal 8 changes, I figured it would be easier to start out with the simplest test I could think of: visiting a path and getting a 200 response code. 

In my module, an action link is added to "admin/people" in order for users to navigate to the form where they invite new users to the site. To test if the path exists and returns a 200 HTTP response, I have to create that part of the module first.

Learn By Example

I've mentioned before that my module depends on the Token module and that I would be using examples in that codebase when I need guidance...which is all the time currently :) So, I looked in that module's routing file to copy an example route. 

If you don't know anything about how Symfony's routing system works, then you should read up on Drupal's documentation for routing. To start, you need to create a ".routing.yml" file. My user_external_invite.routing.yml file started out like this:

  path: '/admin/people/invite/invite'
    _controller: '\Drupal\user_external_invite\Controller\UserInviteController::inviteUsers'
    _title: 'Invite Users'
    _permission: 'invite users'
  path: '/admin/people/invite/operations'
    _controller: '\Drupal\user_external_invite\Controller\UserInviteController::manageInvites'
    _title: 'Manage Invites'
    _permission: 'invite users'
  path: '/admin/config/people/invite'
    _form: '\Drupal\user_external_invite\Form\InviteSettingsForm'
    _title: 'User External Invite Settings'
    _permission: 'administer users'

As you can see, at the top level you start out with the route name which will be your module's machine name and the purpose of the route. I only have three routes for my module: the page where you can invite users, the page where you can manage invites that have been sent out, and the configuration page for admins. 

Adding A Controller

The part of the routing file that is most different, at least for me, is the "_controller" parameter. In Drupal 7, the "page callback" part of hook_menu() essentially acted as the controller; however, the function specified generally ended up in the same .module file making it simple to connect the two parts together.

By placing the controller file in a certain directory structure, Drupal will automatically load that class and call the method you specify. The exact structure of your file placement is kind of arbitrary, but it is common to separate different functionality into different folders. So, I have "src/Controller/" for controller classes and "src/Form" for forms. Entities, Plugins, and Event Subscribers are other examples of other types of things that might warrant their own directories; however, you can place all your files directly in the "src" directory if you were lazy and wanted to do so. Don't be lazy, though; I won't pick you to join my Drupal dodgeball team if you are.

class UserInviteController extends ControllerBase {

  public function inviteUsers() {
    return array(
      '#markup' => 'Page Content...', 

Although my controller has a lot more going on in it, in order to get a working page up and running that we can browse to I had to write an "inviteUsers" function and return something in it. After adding that code and clearing the cache, I can navigate to "admin/people/invite/invite" and see the fruits of my labor. 

Invite Users Page


Action Links

While adding a link to that page of the module is all fine and good, I still have no way of having users know that can get to that page since it existed as an action link in Drupal 7 on the user overview page. 

If you remember the good ole days of hook_menu(), you could define an item as a "MENU_LOCAL_TASK" with a "MENU_DEFAULT_LOCAL_TASK" item to render a page with two or more tabs on it. In Drupal 8, those tabs have been split up into files for tasks and actions. The definitions for tasks and actions are very similar; the distinction is in where you want them placed on the page. 

  route_name: user_external_invite.invite_users
  title: 'Invite user'
    - entity.user.collection

For users to see the invite page from "admin/people" as it had been placed in Drupal 7, I had to create a "user_external_invite.links.action.yml" file. In it, I provided the route that matches the "Invite user" page and told Drupal what page the action link appears on. I ended up searching the User module's files in order to get the parent route to place in the "appears_on" key.

Users Overview Page


Local Tasks

To add tabs for the invite management pages, I had to create another file specifically for the local tasks, "user_external_invite.links.task.yml", a.k.a tabs. 

  route_name: user_external_invite.invite_users
  base_route: user_external_invite.invite_users
  title: 'Invite Users'
  weight: 1
  route_name: user_external_invite.manage_invites
  base_route: user_external_invite.invite_users
  title: 'Manage Invites'
  weight: 2

Instead of having duplicate entries to define the base path and the default tab, a "base_route" key is added to define link hierarchy. This key is essentially the same as the "appears_on" key for action items. For the default tab, the "base_route" and "route_name" are the same, and for any subsequent tabs, the base route will be the default tab's route name. Once you add that code and rebuild the cache, you should see tabs show up on your module's page. 

Invite Management Page



The last path I need users to get to for my module is a configuration form. In Drupal 7, you could use drupal_get_form() as a special callback to load a form at a path, and in Drupal 8, the "_form" key takes over that functionality. In "InviteSettingsForm.php", I have a class that extends "ConfigFormBase" giving me some useful functionality related to getting configuration objects to manipulate. 

class InviteSettingsForm extends ConfigFormBase {

   * InviteSettingsForm constructor.
   * @param \Drupal\Core\Config\ConfigFactoryInterface $config_factory
  public function __construct(ConfigFactoryInterface $config_factory) {

   * @param \Symfony\Component\DependencyInjection\ContainerInterface $container
   * @return static
  public static function create(ContainerInterface $container) {
    return new static(

   * {@inheritdoc}
  public function getFormId() {
    return 'user_external_invite_settings_form';

   * {@inheritdoc}
  protected function getEditableConfigNames() {
    return ['user_external_invite.settings'];

  public function buildForm(array $form, FormStateInterface $form_state) {
    $config = $this->config('user_external_invite.settings');
    // Days invite valid for.
    $form['user_external_invite_days_valid_for'] = array(
      '#type' => 'textfield',
      '#title' => t('Number of days invites are valid'),
      '#description' => t("Invites are set to expire so many days after they are created. If a user hasn't accepted the invite by that time, then you will have to send a new invite to grant that user a role."),
      '#default_value' => $config->get('user_external_invite_days_valid_for'),
      '#element_validate' => array('element_validate_number'),
      '#maxlength' => 3,

    // More form items...

    // Submit button.
    $form['actions'] = ['#type' => 'actions'];
    $form['actions']['submit'] = [
      '#type' => 'submit',
      '#value' => $this->t('Save configuration'),

    return parent::buildForm($form, $form_state);

The "getFormId()" and "getEditableConfigNames()" methods are required when extending "ConfigFormBase". The form ID can be arbitrary, but I made it resemble the machine name in the routing.yml file. The editable config name should correspond to the file you would have in "config/install" for default configuration settings.

Invite Configuration Form


After adding that code and clearing the cache, my form shows up at the right path. However, a user would have to know the exact path of the form in order to see it until I declare a menu link pointing to the form's route.

  title: 'User External Invite Settings'
  description: 'Configure roles to invite and invite message settings.'
  route_name: user_external_invite.settings.form
  parent: user.admin_index

The tricky part of adding "user_external_invite.links.menu.yml" is finding the parent route to link it to. For some reason, the "admin/config/people" route is different than all of the other routes on "admin/config" so to find out which parent route I needed to add, I used Drupal Console and the "drupal router:debug" command. When I grepped that command for config routes, every other top level section on "admin/config" had a route that started off with "system.admin_config_" while the people config section was "user.admin_index". Go figure. 

After adding that menu links file and clearing the cache, I can see the link to the config form in the people section.

Invite Config Form Menu Link


With those three links files and the routing file, you should be good to go setting up routing in your Drupal 8 module. Now comes the hard part of writing the code to fill out those pages you've just made links for.  

Developer Blog

Tips for Managing Drupal 8 projects with Composer

Posted by Jeff Geerling's Blog on February 13, 2017 at 6:12pm

It's been over a year since Drupal 8.0.0 was released, and the entire ecosystem has improved vastly between that version's release and the start of the 8.3.0-alpha releases (which just happened a couple weeks ago).

One area that's seen a vast improvement in documentation and best practices—yet still has a ways to go—is Composer-based project management.

Along with a thousand other 'get off the island' initiatives, the Drupal community has started to take dependency management more seriously, by integrating with the wider PHP ecosystem and maintaining a separate Drupal.org packagist for Drupal modules, themes, and other projects.

Webinar: How to Build Custom Search Pages in Drupal 8

Posted by Web Wash on February 13, 2017 at 5:13pm
The definition of "what a search page is" varies from project to project. Some clients are happy with the core Search module, others want a full blown search engine. Drupal offers a wide range of options when it comes to building custom search pages. You can create a basic search page using the core Search module or if you're looking for something advanced you could use Search API.

Drupal 8 Configuration Management for Multi-site

Posted by Evolving Web on February 13, 2017 at 3:17pm
Drupal 8 Configuration Management for Multi-site

Often, you develop a website to be installed and used once, by one organization. But sometimes, for larger organizations, you need to develop a series of websites that are very similar. This case is very common in big institutions with independent departments or branches, such as:

read more

DIY Drupal hosting: OpenDevShop

Posted by lakshminp.com on February 13, 2017 at 11:49am
DIY Drupal hosting OpenDevShop

Checkout introduction and part 1 if you haven't already.

Richa(all proper nouns changed to protect privacy), our QA, is doing the final testing of a client feature which will go live in a while. Its 4 PM and Friday Happy hour will start soon. Richa is testing a Drupal 7 site packed with tons of contrib and custom modules, and in case you are wondering, yes, we do deploy on Friday evenings at Acme Inc. Its like any other day here.

Agile Coaching: A guide for project managers stepping into a Scrum team – Health warnings!

Posted by Out & About On The Third Rock on February 12, 2017 at 11:26pm

This is first of a series of blogs to support traditional project managers I am coaching. To help get their bearings in deep and murky waters of Agile projects and Scrum teams. Before the scrum purists amongst you vehemently shake your heads or berate me on the title, consider being pragmatic. In the Professional Services world there […]

The post Agile Coaching: A guide for project managers stepping into a Scrum team – Health warnings! appeared first on Agile Transformation - Eradicating Poverty - Human Rights - Open Source - Random - Batman.

Why Open Source Will Dominate the Market

Posted by Vardot on February 12, 2017 at 10:24pm
Case Studies Read time: 7 minutes Open Source (OSS) will become more and more popular and dominate the market Introduction

How times have changed. In the old days, an article about open source software (OSS) typically starts off by defending OSS as a viable alternative to proprietary software. To make its argument, it would defer to the Apache web server and the Linux operating system, both OSS centerpieces. Back in those days, OSS is almost synonymous with nonprofit organizations such as the Apache Software Foundation, the Linux Foundation, and the Free Software Foundation. To justify the adoption of OSS to the skeptical world, one would focus on the return of investment and argues how OSS lowers the total cost of ownership.

This article is about the dawning of the new OSS generation. We argue that OSS will dominate the market, which is a far cry from just being a viable alternative.

A whole new horde of world-dominating OSS software has entered the picture. The new faces of OSS are Drupal and WordPress, LibreOffice and OpenOffice.


Open source software in 2017

New players have since entered the OSS market. The 2016 Future of Open Source survey, conducted with 1,300 companies across 64 countries, indicated that 65% of the respondents had increased the use of OSS in the past year.

World-class, for-profit companies, such as Amazon, Google, Microsoft, Facebook, and Twitter, are now major users and contributors to OSS. This is unthinkable back in the old OSS days, much like the teardown of the Berlin wall. These companies have open-sourced their own products, with the most notable being:

These 3 products share some common characteristics:

  1. They are all software frameworks.

A software framework is the software infrastructure for solving a general class of problems. Unlike Drupal and LibreOffice which are application programs, the aforementioned new OSS are software frameworks, specifically in the area of pattern recognition. Amazon uses DSSTNE to provide product recommendations for its online customers. Google and Microsoft use their respective products in speech recognition, text understanding and photo recognition.

  1. They are all core and mission-critical with their respective owner companies.

For an online retail business, product recommendation is unequivocally mission-critical. Yet, Amazon opted to open-source its product recommendation engine, DSSTNE. Not to be outdone, Google open-sourced TensorFlow, the pattern recognition component in its search engine business. Similarly, Microsoft open-sourced CNTK, the speech recognition engine that powers Windows and Skype applications.

  1. No feature or licensing handicap.

The pressure is on for software vendors to release OSS that is uncrippled, fully functional, and freely distributable. The first open-sourced version of TensorFlow did not support distributed processing: it can only run on a single host. Google subsequently released another version of the software that can run in parallel across multiple hosts. The first version of CNTK that Microsoft open-sourced was restricted to only non-commercial use. Later, the restriction was removed to allow commercial exploitation of the technology.

If the aforementioned products are core to their underlying businesses, we have to ask why their respective companies have chosen to open source them. The rest of this article elaborates on the benefits and the future of this new breed of open source software.

Open Source Software: The Ultimate List


Benefits of open source

Keep calm and use open software


Lowering cost is no longer the number 1 benefit. The new buzzwords for OSS are innovation, quality, and speed of adoption. If helpful, we will illustrate using the example of Drupal, an open source Content Management System (CMS).

Why Drupal is the Best CMS for Your Website



By definition, the source code for OSS is made available to everyone. This attracts a large, global community of committed contributors who share the passion and want to make the software better. The Drupal community claims to have over 1 million "developers, designers, trainers, strategists, coordinators, editors, and sponsors."

In traditional proprietary software development, one person (or a small group) determines the vision and direction of the software. In contrast, OSS is characterized by the free flow of ideas among members of a large community with diverse skillsets and experience. End decisions are made based on merit, not seniority. As a result, OSS is a much better nurturing ground for innovation than its proprietary counterpart.



Given that the source code is open, and that a large pool of developers is available to work on it, the development cycle for OSS is typically shorter. Product features are rolled out and bugs are fixed in frequent software updates. With more eyes on the problem, security holes can be spotted earlier and fixed sooner.

Members in the community who are not developers can contribute in their own ways to make a quality product. Writers and editors contribute by writing documentation. Everyone in the community is presumably a user, and can provide feedback to the team, and answer questions in the support forum.

Companies can customize open source software to satisfy their unique requirements. Subsequently, they can contribute the code back to the community to make the product even better. Drupal 8 represents the quality end result of work done collaboratively by 4,500 individual and corporate contributors. It has over 200 new and improved features, and is made available in 100 languages.



Most OSS is royalty free: you are not charged any money to use it. However, there are several different OSS licenses in the market. So, you must read the licensing terms carefully.

OSS is generally free because it is developed and supported by a community of volunteers. Drupal has a large repository of free modules (30,000+) and themes (2,000+). The development cost is close to nothing, unless you decide to customize a module or theme yourself.

Many companies do customize OSS to satisfy their own unique requirements. This adds to the total cost of ownership for OSS. Yet, the cost is largely constrained because you are not starting from scratch.

When you buy proprietary software, you are locked in to that particular vendor, and become susceptible to its pricing changes. For OSS, you can choose from a sufficiently large supply of contractors who do custom work for OSS. Because the source code is opened, you gain the freedom to switch vendors.

Overall, the total cost of OSS is still lower than that of proprietary software, making it more affordable.



If you use proprietary software, you are tied down by the company's product roadmap which may cater more to the fiscal reporting periods than to its technical merits. With its open platform, OSS development accelerates at Internet speed. The developer base and the installed base are distributed around the world. This means that requirements are gathered around the clock, features are designed and coded 24x7, and bugs are squashed non-stop.

Not only is OSS being developed at a breakneck pace, the scale of its adoption is nothing but phenomenal. Take Drupal and CMS as an example. Drupal has an installed base of over a million websites. With this many websites, a would-be customer can look at any number of them to find the right features to use in his own website.


Future of open source

Cloud computing

The future of OSS is in the cloud. 76% of all respondents in the above cited 2016 survey claimed that they had plans to use containers. The cloud is not just a repository where OSS contributors network and store their code and document artifacts. It will become the deployment platform of choice for open source software.



OSS is becoming a commodity in the world of software development. Companies will expect more and more enterprise software to be OSS. They will expect OSS to remain free and be of the highest quality. They will expect their ideas and feedback to be heard in the larger community, and readily included in the constant software updates which will continuously benefit them.


Open source is playing a bigger and bigger role every year, and there is no doubt that its future is full of possibilities. And which open software do you use? Share your thoughts with us in a comment section below.

Tags:  Design & User Experience Drupal Planet Title:  Why Open Source Will Dominate the Market

Turn your Drupal site into Google Home

Posted by Drupal @ Penn State on February 12, 2017 at 8:34pm

I’ve dreamed of a day when systems start to work like the home automation and listening (NSA Spying…) devices that people are inviting into their home. “Robots” that listen to trigger words and act on commands are very exciting. What’s most interesting to me in trying to build such systems is,… they really aren’t that hard any more. Why?

Ctools: custom argument plugin

Posted by fluffy.pro. Drupal Developer's blog on February 12, 2017 at 4:36pm
This time we will consider an argument plugin. Arguments are pretty similar to contexts. Actually arguments are context objects loaded from url. By default ctools provides a full set of needed arguments such as "Node: ID", "User: ID", "User: name" etc. But what if you've created a custom context? You might need to create a custom argument for your context (if you want to use your context as an argument of course). I advise you to read previous articles from "Ctools custom plugin" series such as "Ctools: custom access plugin" and "Ctools: custom context plugin". It's also required to read "Ctools: custom content type plugin" before reading this post because there I've described how to create a module integrated with ctools API which can contain ctools plugins.
Read more »

Cheering the Drupal Association Team as they start 2017 with a bang!

Posted by Unimity Solutions Drupal Blog on February 12, 2017 at 3:43pm

The Association staff have been doing wonderful stuff over the last few months.

Status page redesign in review

Posted by Roy Scholten on February 12, 2017 at 6:57am
Stylized screengrab with colorfull circles overlaid

The status page redesign got committed to core the other week. This is a good thing because it shows that we can actually get decent design work done in core.

Or is it, because it has become the longest issue on d.o. and took way too long and seems too much work for redesigning a single page. It shows we still can’t get good design work done in an effective way.

But if you look closer you’ll find that:

A first iteration was committed at ±60 comments in. This was 5 years ago. Then another 60 or so comments of discussion about what could be improved about that initial redesign.

“Only” 9 months ago, Bojhan kicked off a whole new redesign. That actual design was agreed on in a decent amount of time and discussion (35 comments, 2 months and 2 or 3 discussions of it in our UX meetings). We spent a lot of time with a first and maybe even second round of implementation approaches before settling on a core worthy architecture. Refining that approach still took a lot of effort to get right but not extremely so.

In summary:

  • 60 comments for the first iteration, this was a long time ago
  • 60 comments discussing additional details of that first iteration
  • 35 comments to agree on a whole new design (!)
  • 170 comments to arrive at a core worthy approach for the frontend code
  • 150 comments refining the code, reviewing it and fixing minor design issues
Some lessons maybe:
  • Restarting a whole new redesign in an already years old and fixed issue is not how we normally work. It might have been better to start a new issue for the redesign.
  • I think we’d now also choose to create and agree on the design in one issue and implement it in yet another. Although we really didn’t redesign by committee that much in this issue. 35 Comments to arrive at a whole new design is in fact a quite spectacularly short amount of time.
  • Learn to recognise when a design introduced new frontend patterns. Because we need expert guidance on how to implement it correctly.
  • Outline and agree on the architecture for implementation before starting to write code.
  • Getting good design done + changing a stable core feature is still lot of work. It needs visual design, interaction design and information architecture. It needs HTML, CSS, JavaScript and PHP code. It needs to be checked on correctness for each of those. And don’t forget about accessibility (we didn’t). Without breaking backwards compatibility because we were changing a stable core feature. That’s a lot of disciplines that need to be involved, which means it takes more people to complete.

I’m happy the issue got committed. I had mixed feelings about whether this is really is an achievement worth celebrating given the length of the issue. Looking back at how the process went, it shows that we did in fact manage to redesign a core feature in a reasonable amount of time. And despite the length and complexity the discussion never went off rails and tone remained civil at all times.

For the design part it has been very valuable to discuss things in our UX meetings where we can share screen and provide feedback while looking at the actual thing. Imagine that! :-)

Thank you Christina, Sumit, Chris, Joel, Lauriii, Gabor and everybody else who chipped in. Well done.

Tags: drupaldrupalplanetSub title: Not seven years but nine months in the making

Drupal core security release window on Wednesday, February 15, 2017

Posted by Drupal core announcements on February 12, 2017 at 4:28am
Organizers:  xjm cilefen Event type:  Online meeting (eg. IRC meeting)

The monthly security release window for Drupal 8 and 7 core will take place on Wednesday, February 15.

This does not mean that a Drupal core security release will necessarily take place on that date for any of the Drupal 8 or 7 branches, only that you should watch for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

February 15 is also the planned release date for Drupal 8.3.0-beta1. (See 8.3.0-alpha1 release notes for the recent alpha and the recent announcement about 8.3.0 for more information on the alpha and beta phases.)

There will be no bug fix or stable feature release on this date. The next window for a Drupal core patch (bug fix) release for all branches is Wednesday, March 01. The next scheduled minor (feature) release for Drupal 8 will be on Wednesday, April 5.

Drupal 6 is end-of-life and will not receive further security releases.

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

In-Page Navigation with Drupal 8 and Paragraphs

Posted by Isovera Ideas & Insights on February 12, 2017 at 2:42am
For a recent project, we had to build a site where some pages were very long and complex. In order to make it easier for visitors to find the information they want, we had to provide in-page navigation. We found a flexible solution using Drupal 8 and the Paragraphs module.

Ctools: custom context plugin

Posted by fluffy.pro. Drupal Developer's blog on February 11, 2017 at 10:40pm
In previous post we created an access ctools plugin which can be used as a selection or visibility rule in panels. It's time to learn how to create another important custom plugin - a context. It provides additional information for a panel page. For example if you've put a node context to the page you will be able to use node properties as substitutions for a page title. Moreover you will be able to put node fields as panes to a page. By default ctools module provides useful contexts (node, user, taxonomy_term, entity etc) but you can define your own. Please, read first post of "Ctools custom plugins" series before continue reading this. There we've created a module integrated with ctools.
Read more »

Profiling Drupal 8 Sites in Drupal VM with XHProf and Tideways

Posted by Jeff Geerling's Blog on February 11, 2017 at 2:30pm

XHProf, a PHP extension formerly created and maintained by Facebook, has for many years been the de-facto standard in profiling Drupal's PHP code and performance issues. Unfortunately, as Facebook has matured and shifted resources, the XHProf extension maintenance tailed off around the time of the PHP 7.0 era, and now that we're hitting PHP 7.1, even some sparsely-maintained forks are difficult (if not impossible) to get running with newer versions of PHP.

Enter Tideways.

Tideways has basically taken on the XHProf extension, updated it for modern PHP versions, but also re-branded it to be named 'Tideways' instead of 'XHProf'. This has created a little confusion, since Tideways also offers a branded and proprietary service for aggregating and displaying profiling information through Tideways.io. But you can use Tideways completely independent from Tideways.io, as a drop-in replacement for XHProf. And you can even browse profiling results using the same old XHProf UI!

Between the Cracks of Decoupled (Drupal) Architecture

Posted by OhTheHugeManatee on February 11, 2017 at 10:18am

In any decoupled architecture, people tend to focus on the pieces that will fit together. But what nobody ever tells you is: watch out for the cracks!

The cracks are the integration points between the different components. It’s not GraphQL as a communication layer; it’s that no one thinks to log GraphQL inconsistencies when they occur. It’s not “what’s my development environment”, it’s “how do these three development environments work on my localhost at the same time?”. It’s the thousand little complexities that you don’t think about, basically because they aren’t directly associated with a noun. We’ve discovered “crack” problems like this in technical architecture and devops, communication, and even project management. They add up to a lot of unplanned time, and they have presented some serious project risks.

A bit more about my recent project with Amazee Labs. It’s quite a cool stack: several data sources feed into Drupal 8, which offers an editorial experience and GraphQL endpoints. Four React/Relay sites sit in front, consuming the data and even offering an authenticated user experience (Auth0). I’ve been working with brilliant people: Sebastian Siemssen, Moshe Weitzman, Philipp Melab, and others. It has taken all of us to deal with the crack complexity.

The first crack appeared as we were setting up environments for our development teams. How do you segment repositories? They get deployed to different servers, and run in very different environments. But they are critically connected to each other. We decided to have a separate “back end” repo, and separate repos for each “front end” site. Since Relay needs to compile the entire data schema on startup, this means that every time the back end is redeployed with a data model change, we have to automatically redeploy the front end(s). For local development, we ended up building a mock data backend in MongoDB running in Docker. Add one more technology to support to your list, with normal attendant support and maintenance issues.

DevOps in general is more complicated and expensive in a decoupled environment. It’s all easy at first, but at some point you have to start connecting the front- and back-ends on peoples’ local development environments. Cue obvious problems like port conflicts, but also less obvious ones. The React developers don’t know anything about drupal, drush, or php development environments. This means your enviroment setup needs to be VERY streamlined, even idiot-proof. Your devops team has to support a much wider variety of users than normal. Two of our front-enders had setups that made spinning up the back-end take more than 30 minutes. 30 minutes! We didn’t even know that was possible with our stack. The project coordinater has to budget significant time for this kind of support and maintenance.

Some of the cracks just mean you have to code very carefully. At one point we discovered that certain kinds of invalid schema are perfectly tolerable to the GraphQL module. We could query everything just fine – but React couldn’t compile the schema, and gave cryptic errors that were hard to track down. Or what about the issues where there are no error messages to work with? CORS problems were notoriously easy to miss, until everything broke without clear errors. Some of these are impossible to avoid. The best you can do is be thorough about your test coverage, add integration tests which consider all environments, and document all the things.

Not all the cracks are technological; some are purely communication. In order to use a shared data service, we need a shared data model and API. So how do you communicate and coordinate that between 5 teams and 5 applications? We found this bottleneck extremely difficult. At first, it simply took a long time to get API components built. We had to coordinate so many stakeholders, that the back-end data arch and GraphQL endpoints got way behind the front-end sites. At another point, one backender organically became the go-to for everything GraphQL. He was a bottleneck within weeks, and was stuck with all the information silo’ed in his head. This is still an active problem area for us. We’re working on thorough and well-maintained documentation as a reference point, but this costs time as well.

Even project managers and scrum masters found new complexities. We had more than 30 people working on this project, and everyone had to be well coordinated and informed. You certainly can’t do scrum with 30 people together – the sprint review would take days! But split it out into many smaller teams and your information and coordination problems just got much harder. Eventually we found our solution: we have 3 teams, each with their own PO, frontender(s) and backender(s), who take responsibility for whole features at a time. Each team does its own, quite vanilla, scrum process. Layered on top of this, developers are in groups which cut across the scrum teams, which have coordination meetings and maintain documentation and code standards. All the back-enders meet weekly and work with the same standards, but the tightest coordination is internal to a feature. So far this is working well, but ask me again in a few months. :)

Working in a fully decoupled architecture and team structure has been amazing. It really is possible, and it really does provide a lot more flexibility. But it demands a harder focus on standards, communication, coordination, and architecture. Sometimes it’s not about the bricks; it’s about the mortar between them. So the next time you start work on a decoupled architecture, watch out for the cracks!

YAML formatting and Drupal 8 - making things readable

Posted by Jeff Geerling's Blog on February 10, 2017 at 9:01pm

As someone who loves YAML syntax (so much more pleasant to work with than JSON!), I wanted to jot down a few notes about syntax formatting for the benefit of Drupal 8 developers everywhere.

I often see copy/pasted YAML examples like the following:

  something-else: {key: value, key2: {key: value}}

This is perfectly valid YAML. And technically any JSON is valid YAML too. That's part of what makes YAML so powerful—it's easy to translate between JSON and YAML, but YAML is way more readable!

So instead of using YAML like that, you can make the structure and relationships so much more apparent by formatting it like so:

DrupalEasy Podcast 191 - Blewis is his name (Brian Lewis - Composer Workflows)

Posted by DrupalEasy on February 10, 2017 at 8:15pm

Direct .mp3 file download.

Brian Lewis (bjlewis2), front-end engineer for Four Kitchens, and founder of Modules Unraveled joins Ryan Price and Mike Anello to figure out if/when we should all be using Composer to manage our Drupal projects. Once that was figured out, there were some picks of the week, Drupal-y news, and Brian goes on the hot seat for five questions.

Interview DrupalEasy News Three Stories Sponsors Picks of the Week Upcoming Events Follow us on Twitter Five Questions (answers only)
  1. Slice and dehydrate my own beef jerky, with a homemade seasoning. So, all from scratch.
  2. Zeplin (for a client project) Docker for Mac (for me).
  3. Buying our first house! (We’re actually closing on the 17th!).
  4. My dog.
  5. When I was contracted to build the new website for the school district I was working in.
Intro Music Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Using Graph Databases in Popular Open Source CMSs

Posted by Pronovix on February 10, 2017 at 4:18pm

In a talk we did at FOSDEM ‘17, Tamás Demeter-Haludka and I discuss potential application areas of graph databases in existing open source CMSs like Drupal.

Remove the comment text area filter tips link in Drupal 8

Posted by David Lohmeyer's Blog on February 10, 2017 at 3:38pm

Sometimes you just want a cleaner comment entry box. Here's a quick Gist module that will remove your comment tip link beneath comment form body entries in Drupal 8. This uses a form alter to remove the filter help on the comment form.

If you wanted an even cleaner look, you could remove the other text below the comment box altogether by overriding filter-guidelines.html.twig and filter-tips.html.twig in your theme!


Subscribe with RSS Subscribe to Drupal.org aggregator - Planet Drupal