MD Systems blog: Current status of Media in Drupal 8 core and next steps

Planet Drupal - Mon, 2017/01/09 - 9:44am
The Media team finished the exciting and successful year 2016 with a Drupal 8 core media sprint in Berlin and we were part of it. Now, what are the next steps?

Web Omelette: Choose your theme dynamically in Drupal 8 with theme negotiation

Planet Drupal - Mon, 2017/01/09 - 9:00am

Have you ever needed to render certain pages (or groups of pages) with a different theme than the default one configured for the site? I did. And in this article I'm going to show you how it's done in Drupal 8. And like usual, I will illustrate the technique using a simple use case.

The requirement

Let's say we have a second theme on our site called gianduja since we just love the chocolate from Torino so much. And we want to apply this theme to a few custom routes (the content rendered by the respective controllers is not so important for this article). How would we go about implementing this in a custom module called Gianduja?

The solution

First, we need a route option to distinguish these routes as needing a different theme. We can call this option _custom_theme and its value can be the machine name of the theme we want to render with it. This is how a route using this option would look like: path: '/gianduja/info' defaults: _controller: '\Drupal\gianduja\Controller\GiandujaController::info' _title: 'About Gianduja' requirements: _permission: 'access content' options: _custom_theme: 'gianduja'

Just a simple route for our first info page. You can see our custom option at the bottom which indicates the theme this route should use to render its content in. The Controller implementation is outside the scope of this article.

However, just adding an option there won't actually do anything. We need to implement a ThemeNegoatiator that looks at the routes as they are requested and switches the theme if needed. We do this by creating a tagged service.

So let's create a simple class for this service inside the src/Theme folder (directory/namespace not so important):

namespace Drupal\gianduja\Theme; use Drupal\Core\Routing\RouteMatchInterface; use Drupal\Core\Theme\ThemeNegotiatorInterface; /** * Our Gianduja Theme Negotiator */ class ThemeNegotiator implements ThemeNegotiatorInterface { /** * {@inheritdoc} */ public function applies(RouteMatchInterface $route_match) { $route = $route_match->getRouteObject(); if (!$route instanceof Route) { return FALSE; } $option = $route->getOption('_custom_theme'); if (!$option) { return FALSE; } return $option == 'gianduja'; } /** * {@inheritdoc} */ public function determineActiveTheme(RouteMatchInterface $route_match) { return 'gianduja'; } }

As you can see, all we need to do is implement the ThemeNegotiatorInterface which comes with two methods. The first, applies(), is the most important. It is run on each route to determine if this negotiator provides the theme for it. So in our example we examine the Route object and see if it has the option we set in our route. The second, determineActiveTheme() is responsible for providing the theme name to be used in case applies() has returned TRUE for this route. So here we just return our theme name. All pretty straightforward.

Lastly though, we need to register this class as a service in our file:

services: theme.negotiator.gianduja: class: Drupal\gianduja\Theme\ThemeNegotiator tags: - { name: theme_negotiator, priority: -50 }

This is a normal definition of a service, except for the fact that we are applying the theme_negotiator tag to it to inform the relevant container compiler pass that we are talking about a theme negotiator instance. Additionally, we are also setting a priority for it so that it runs early on in the theme negotiation process.

And that is pretty much it. Clearing the cache and hitting our new route should use the gianduja theme if one exists and is enabled.

Using this example, we can create more complex scenarios as well. For one, the theme negotiator class can receive services from the container if we just name them in the service definition. Using these we can then run complex logics to determine whether and which theme should be used on a certain route. For example, we can look at a canonical route of an entity and render it with a different theme if it has a certain taxonomy tag applied to it. There is quite a lot of flexibility here.

Categories: 2016, The Year We Won PHP

Planet Drupal - Mon, 2017/01/09 - 2:00am

First, a joyous and productive 2017 to you all. 2016 was really great for us as a growing company and the new year is a great time to look back and share with you, our dear clients and community, our journey.

The title of the post is audacious, very possibly a hyperbole. There are bigger players than us out there. We don’t claim the highest market share. We claim we have become an obvious choice for ambitious projects. Let me make the case.

Over the course of last year, the leading vendors in the PHP enterprise space Magento, eZ Platform, Typo3, and most recently Symfony - the PHP framework of frameworks - announced their cloud platform to be on Since its inception two and a half years ago, has already become a leader in the whole PHP space. How did this come about?


jordanpagewhite: Drupal 8 Front-End Architecture

Planet Drupal - Mon, 2017/01/09 - 1:00am

I recently read Front-End Architecture for Design Systems by Micah Godbolt (BK1). It is a fantastic evaluation of front-end architecture and strategy. The book isn’t specifically for Drupal developers, but the concepts laid out in the book are relevant to all front-end developers and they are easily applicable to Drupal 8 projects. In this post, I want to build a couple of components and discuss different front-end architecture approaches for Drupal 8 projects, specifically using the concepts in Godbolt’s book.


jordanpagewhite: Add region modifier class to menu

Planet Drupal - Mon, 2017/01/09 - 1:00am

I asked this in the DrupalTwig slack channel a couple days ago:

Categories: HTTP/2 Support Announced!

Planet Drupal - Sun, 2017/01/08 - 1:00am

All the fastness just got faster. A couple of days ago we finished 2016 in beauty, announcing PHP 7.1 which allows you to do some incredibly fast PHP apps with stuff like ReactPHP for example.

Let’s start 2017 with some more fastness juice flowing. HTTP/2 is now supported on all public regions.

What do you need to do to benefit from the incredible performance gains this will give your site?

Nothing. It just works (as long as you have HTTPS enabled, which you should anyway).


Janez Urevc: Join us at the next Drupal Media sprint at the Mountain camp in Davos!

Planet Drupal - Fri, 2017/01/06 - 11:19pm
Join us at the next Drupal Media sprint at the Mountain camp in Davos!

Are you excited about the recent improvements in Drupal core Media? Would you like to join us at one of the next sprints and help us reach our goals? Now you can!

Drupal Mountain Camp 2017 will happen between 16th and 19th February in the lovely Davos. Drupal, code community, snow, fondue, outdoor activities and much more. Definitely something that should not be missed!

And the best part? There will be Media sprint going on throughout the event. Eager to join? Simply add yourself to the sprint attendance list and show up. We promise you the best sprint ever!

slashrsm Fri, 06.01.2017 - 23:19 Tags Drupal Media Sprint Enjoyed this post? There is more! Results of the Drupal 8 media sprint Presentations about various Drupal 8 media modules Call for Drupal 8 media ecosystem co-maintainers Drupal dev environment on Docker

Drupal Blog: Moving the Drupal 8 workflow initiative along

Planet Drupal - Fri, 2017/01/06 - 6:49pm

Republished from

Nine months ago I wrote about the importance of improving Drupal's content workflow capabilities and how we set out to include a common base layer of workflow-related functionality in Drupal 8 core. That base layer would act as the foundation on which we can build a list of great features like cross-site content staging, content branching, site previews, offline browsing and publishing, content recovery and audit logs. Some of these features are really impactful; 5 out of the top 10 most requested features for content authors are related to workflows (features 3-7 on the image below). We will deliver feature requests 3 and 4 as part of the "content workflow initiative" for Drupal 8. Feature requests 5, 6 and 7 are not in scope of the current content workflow initiative but still stand to benefit significantly from it. Today, I'd like to provide an update on the workflow initiative's progress the past 9 months.

The top 10 requested features for content creators according to the 2016 State of Drupal survey. Features 1 and 2 are part of the media initiative for Drupal 8. Features 3 and 4 are part of the content workflow initiative. Features 5, 6 and 7 benefit from the content workflow initiative.

Configurable content workflow states in Drupal 8.2

While Drupal 8.0 and 8.1 shipped with just two workflow states (Published and Unpublished), Drupal 8.2 (with the the experimental Content moderation module) ships with three: Published, Draft, and Archived. Rather than a single 'Unpublished' workflow state, content creators will be able to distinguish between posts to be published later (drafts) and posts that were published before (archived posts).

The 'Draft' workflow state is a long-requested usability improvement, but may seem like a small change. What is more exciting is that the list of workflow states is fully configurable: you can add additional workflow states, or replace them with completely different ones. The three workflow states in Drupal 8.2 are just what we decided to be good defaults.

Let's say you manage a website with content that requires legal sign-off before it can be published. You can now create a new workflow state 'Needs legal sign-off' that is only accessible to people in your organization's legal department. In other words, you can set up content workflows that are simple (like the default one with just three states) or that are very complex (for a large organization with complex content workflows and permissions).

This functionality was already available in Drupal 7 thanks to the contributed modules like the Workbench suite. Moving this functionality into core is useful for two reasons. First, it provides a much-requested feature out of the box – this capability meets the third most important feature request for content authors. Second, it encourages contributed modules to be built with configurable workflows in mind. Both should improve the end-user experience.

Support for different workflows in Drupal 8.3

Drupal 8.3 (still in development, planned to be released in April of 2017) goes one step further and introduces the concept of multiple types of workflows in the experimental Workflows module. This provides a more intuitive way to set up different workflows for different content types. For example, blog posts might not need legal sign-off but legal contracts do. To support this use case, you need to be able to setup different workflows assigned to their appropriate content types.

What is also interesting is that the workflow system in Drupal 8.3 can be applied to things other than traditional content. Let's say that our example site happens to be a website for a membership organization. The new workflow system could be the technical foundation to move members through different workflows (e.g. new member, paying member, honorary member). The reusability of Drupal's components has always been a unique strength and is what differentiates an application from a platform. By enabling people to reuse components in interesting ways, we turn Drupal into a powerful platform for building many different applications.

Drupal 8.3 will support multiple different editorial workflows. Each workflow can define its own workflow states as well as the possible transitions between them. Each transition has permissions associated with them to control who can move content from one state to another.

Workspace interactions under design

While workflows for individual content items is very powerful, many sites want to publish multiple content items at once as a group. This is reflected in the fourth-most requested feature for content authors, 'Staging of multiple content changes'. For example, a newspaper website might cover the passing of George Michael in a dedicated section on their site. Such a section could include multiple pages covering his professional career and personal life. These pages would have menus and blocks with links to other resources. 'Workspaces' group all these individual elements (pages, blocks and menus) into a logical package, so they can be prepared, previewed and published as a group. And what is great about the support for multiple different workflows is that content workflows can be applied to workspaces as well as to individual pieces of content.

We are still in the early stages of building out the workspace functionality. Work is being done to introduce the concept of workspaces in the developer API and on designing the user interface. A lot remains to be figured out and implemented, but we hope to introduce this feature in Drupal 8.5 (planned to be released in Q2 of 2018). In the mean time, other Drupal 8 solutions are available as contributed modules.

An outside-in design that shows how content creators could work in different workspaces. When you're building out a new section on your site, you want to preview your entire site, and publish all the changes at once. Designed by Jozef Toth at Pfizer.

Closing thoughts

We discussed work on content workflows and workspaces. The changes being made will also help with other problems like content recovery, cross-site content staging, content branching, site previews, offline browsing and publishing, and audit logs. Check out the larger roadmap of the workflow initiative and the current priorities. We have an exciting roadmap and are always looking for more individuals and organizations to get involved and accelerate our work. If you want to get involved, don't be afraid to raise your hand in the comments of this post.

Thank you

I tried to make a list of all people and organizations to thank for their work on the workflow initiative but couldn't. The Drupal 8 workflow initiative borrows heavily from years of hard work and learnings from many people and organizations. In addition, there are many people actively working on various aspects of the Drupal 8 workflow initiative. Special thanks to Dick Olsson (Pfizer), Jozef Toth (Pfizer), Tim Millwood (Appnovation), Andrei Jechiu (Pfizer), Andrei Mateescu (Pfizer), Alex Pott (Chapter Three), Dave Hall (Pfizer), Ken Rickard ( and Ani Gupta (Pfizer). Also thank you to Gábor Hojtsy (Acquia) for his contributions to this blog post.


DrupalCon News: DevOps:  The Philosophical Movement

Planet Drupal - Fri, 2017/01/06 - 5:47pm

As Gene Kim, American entrepreneur and founder of Tripwire, says, DevOps is “not yet a precise collection of practices, descriptive or prescriptive.”[1]  Similarly, as Drupal enters its own era of philosophical movement towards Drupal 8, what more fitting time to focus around how we can bridge the gap between Developers and Operations to further improve our DevOps workflows.

In the DevOps Track Description, we drew comparisons between Development and Operations being like Peanut Butter and Chocolate.  Some people might think this analogy is stretching the limits or just an easy way to justify having a bunch of Peanut Butter Cups on my desk but the correlation between Peanut Butter and Chocolate is the same sort of philosophical relationship we look for between Development and Operations teams.  This philosophical relationship is what we hope to explore during the DevOps track at DrupalCon Baltimore.


ThinkShout: Using Google Docs and Migrate to Populate Your Drupal Site, Part 1

Planet Drupal - Fri, 2017/01/06 - 5:00pm

The problem:

Content management systems are extremely powerful, in that they let developers focus on what they do best – build the infrastructure of a site, while allowing content editors to do what they do best – create content.

But this can be a problem when building a new feature. How often have you heard something to this effect:

Developer: “That blank spot right there will be a neat slideshow, once you build it.”

Client: “I thought I was paying you to build it.”

The separation between content and development can lead to missed edge cases, unfounded assumptions, and wasted time for everyone involved.

There are a few workarounds to this problem. We often prototype our sites with dummy content (insert your favorite Ipsum here). But this, without fail, leads to some nasty surprises when the client starts entering real content. It’s suddenly much longer (or shorter) than the designer or developer intended. Or maybe the images are far too big. Or they’re all portraits where we expected landscapes. In short, the arguments made against using Lorem Ipsum in designs go doubly once you start actually implementing fields on your Drupal site.

So what about more meaningful content – maybe exported from another source? Modules like Default Content allow developers to export certain content for import during the initial site build. But that content has the disadvantage of requiring a developer’s intervention. The more of a nuisance it is to update the content, sync the database, change the fields, etc, the less likely you are to keep the content up-to-date.

At ThinkShout, we want to populate our client’s sites with content as soon as possible.

It doesn’t need to be the final content…

But it should be real content.

It shouldn’t necessarily be exactly what’s on the old site…

But it ought to be close…

In other words, our initial content needs to be easy to change – easy enough that the client can do it. Easy enough that the developers don’t have to take a walk around the block to calm down when they find out the fields are changing (again). Easy.

Our Solution Part 1: Migrate

“But isn’t Migration to Drupal hard?” I hear you saying.

It certainly was in Drupal 7, where the Migrate module had a (deserved) reputation for being difficult to use. Migrating from one Drupal site to another, or even from Wordpress to Drupal was relatively smooth, but if you really wanted to do something unusual, like migrate from a less-common CMS to Drupal, you were going to be writing a lot of custom code “glue” to get it all working.

In D8, Migrations have been moved to core. This means a few things. First, it means the core concept of entities is baked right in. In D7 migrations, you often had to hunt around for a plugin, hoping someone had written a Destination Handler for your favorite oddball entities, like Redirects, or Addresses, or the dreaded Field Collections. In D8, an entity is an entity.

As such, with a solid knowledge of the helpful migration plugins and two essential contributed modules, Migrate Tools and Migrate Plus, you can write a robust migration of both content and config entities without writing code more complicated than a few .yml files. If you don’t believe me, I encourage you to try upgrading your D6 or D7 site to D8 on a local or dev environment to see how much of your data is already in there.

That being said, what if I don’t have an existing site? Or what if I want to implement a new content strategy to go along with my fancy new site?

Our Solution Part 2: Google Sheets

Throw that new content into a Google Doc!

Yes, spreadsheets are old school, but let’s take a minute to appreciate what they give us.

  • Spreadsheets are familiar. When it comes right down to it, spreadsheets are the universal language of business. Putting content into little boxes gives us the ability to move those boxes around, highlight them, and sort them – few UX experiences can get you so much information so quickly.

  • Spreadsheets are dynamic. It doesn’t take hours of database planning to get information into a spreadsheet. Nor does it take hours of testing to rearrange or remove items from a spreadsheet. It doesn’t demand anything of your data architect other than “organize things by columns and rows.”

  • Spreadsheets are sharable. We can enable a Google spreadsheet and share it with the client in a few minutes. Clients can start entering their data from day 1 (alright, maybe day 2 or 3). And they can update content as needed – take it out of the sheet, update things, and change them.

  • Google spreadsheets have revisioning built in. If someone really messes up a Google Doc, you can go back through its history and revert it. It’s a nice compromise between committing all your initial content to source control or just letting it live freely.

Ready to give it a shot?

Stay tuned for Part 2 of this series, where I go into detail about how to set up your own Google sheet Drupal 8 migration.

Can’t wait? Check out the Migrate Google Sheets module now! We’ve even set up a sample site where content comes entirely from an external spreadsheet to help you get started.