Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 15 hours 13 min ago

Deeson: Highlights from DrupalCamp London 2018

5 March 2018 - 8:43am

Over the weekend, several of us in the tech chapter at Deeson attended DrupalCamp London 2018. It’s always a great event, and one our own Tim Deeson helped co-found in 2013.

For me, returning to DrupalCamp was a chance to immerse myself in the community again, to catch up with some old friends, and put faces to people I’d only met on Twitter.

The Deeson developers attending the event had different levels of Drupal knowledge, so we didn’t stick together the entire time. Due to my relatively limited knowledge of Drupal 8 I attended two very informative, low level development talks about the internal workings of D8 and how the approach differs to that I already know well with D7.

The first was Drupal 8 Services and Dependency Injection, an introduction to creating custom services to use within your own modules. I also attended Let’s take the best route - Exploring Drupal 8 Routing System, which showed me that while the change to Symfony makes the code very different, it’s actually straightforward and consistent once you get into it.

A particular highlight was seeing our Lead Developer Mike Davis in action. He spoke about Warden – an open source solution Deeson built to allow in-house development teams and agencies to keep track of the status of multiple Drupal sites hosted on different platforms.

Here are a few of our other favourite sessions and highlights from the event…

“Hello User, I’m Drupal!”

This session from Gabriele Maira introduced Chatbot API – A Drupal module which enables site builders to serve their content via chat.

We’ve been speaking about conversational interfaces and chatbots for a while at Deeson, and it was really interesting to learn about the tools available for Drupal site builders. With Alexa and Dialogflow support out of the box, Chatbot API module is one to keep an eye on.

Katy Ereira, Senior Developer

Drupal in the era of Microservices.

I attended a talk by Wunder's CTO Florian Lorétan, where he discussed the ideas around using Drupal with Microservices. This is an interesting idea particularly where larger projects are concerned as it opens up the potential for large teams to collaborate more effectively. 

We currently use Docker as part of our own build process (which could be considered a microservice) and I wanted to see how this could be extended further and what other benefits could be yielded as a result.

It was very interesting to learn that automated tests, benchmarking, security testing and monitoring could all be done as mircroservices with Drupal and how the speed of deployment could be rapidly increased by using this approach.

Whilst this is relatively new, it's great to see people within the Drupal community exploring how microservices could be used with Drupal to speed up the development process, and I'm really looking forward to seeing what the future holds in this area. 

Rowan Blackwood, Developer

Building a contribution culture in a Drupal agency.

I've joined Deeson within the past year, and one of the key qualities that drew me to Deeson in the first place was its commitment to open source and support for contributing back to the community. So I was keen to hear a little more about how other companies foster their own contributions culture and have the opportunity to compare our own culture with another.

In his session @hussainweb reiterated the added value that you can create for yourself by making contributions to open source projects, and how his company has found ways to actively encourage individuals to make contributions.

What really stuck with me is the following three items:

  1. Open source contributions create Social Capital, and that's an investment you can recoup in other ways.
  2. Contributions are not just about actual code contributed - it's also about bug reporting, documentation, testing, speaking and writing, which are just as valuable efforts, and they should also be tracked, encouraged and rewarded.
  3. Don't be intimidated from extending open source projects. If you use it, treat it as your own upstream code and not a project that cannot be touched. Lose the fear of the project and contribute! 

James Ford, Senior Developer

Categories: Drupal

Droptica: Droptica: How to add new button (plugin) to CKEditor pt. II

5 March 2018 - 4:15am
In one of our previous articles, we showed you how to configure CKEditor in Drupal 8. This time, we are going to demonstrate how you can expand the editor’s functionality on your own.   In the case of many websites, the basic functions of CKEditor are more than enough.  However, there are projects where clients demand expanding the functionality of the content editor. With CKEditor, you can do that using plug-ins – all of them are available on the official website.  Adding a new plug-in to the website based on Drupal 8 is very simple compared to the way it was done in the previous version of Drupal. All you need is to create a simple module.  
Categories: Drupal

DrupalEasy: All the favicons on your Drupal 8 site

4 March 2018 - 6:18am

Every Drupal 8 site should have a custom favicon that helps to reinforce the site's brand - of this there is really no argument. But, over the past (more than a few) years, the role of the lowly favicon has grown from just the little icon on a browser tab. These days, favicons are also used on mobile devices as the gateway to your site. Keeping your brand strong in all contexts is more important than ever.

Luckily, the Responsive Favicons module, combined with Favicon Generator makes it pretty easy to keep your site's branding consistent across multiple platforms. 

Assuming you have a relatively square-ish version of the site's logo, making this all happen is pretty easy.

First - head to Favicon Generator, upload the site's logo, then review/tweak the settings for the various contexts. You'll be asked for the "App name" (usually the site's name), suitable background colors (I selected a nice pear-color for the DrupalEasy logo - you can see it in the iOS mockup above), as well as image overrides (optional) for each context. For the "Favicon Generator options", select the "I will place favicon files at the root of my web site" option (at the recommendation of the Responsive Favicons module maintainers). At the end of the process, you'll get a zipped file full of all the necessary icons and meta data. 

Next, download and install the Responsive Favicons module. Head to its configuration area (/admin/config/user-interface/responsive_favicons) and complete the form. For the "Path to responsive favicon files", I just used "favicons". The "Favicons tags" section is provided at the end of the Favicon Generator's process. Finally, point the zip file generated by the Favicon Generator to the final form field. Click to "Save configuration" and you should be all set!

Lessons like this (and much, much more) are taught during our 12-week, 3x/week Drupal Career Online course. Learn more and register for our free Taste of Drupal webinar to dive into the details of the course.

Categories: Drupal

agoradesign: Using add to cart links instead of forms in Drupal Commerce 2

3 March 2018 - 11:13am
Today I'm introducing you to a new contrib module, I've created for allowing "add to cart" (or wishlist) buttons as links instead of forms. This helps to circumvent some unfortunate Drupal core limitations, when you want to build overview pages or blocks.
Categories: Drupal

Ashday's Digital Ecosystem and Development Tips: Drupal Search: Solr vs Search Module

2 March 2018 - 2:09pm

Drupal isn’t known as a particularly lightweight content management system and that is one of the reasons we love it, right? It is meant to handle large amounts of complex content. A problem occurs when you have a site that is just flush with content of different types, how do you get users to it? Navigation can only get you so far sometimes. We have personally seen this on everything from large-scale publishing sites to medical practice sites.

Categories: Drupal

Jeff Potts: Quick look at Acquia Reservoir, a Headless Drupal Distribution

2 March 2018 - 1:00pm

Drupal is a very popular open source Web Content Management system. One of its key characteristics is that it owns both the back-end repository where content is stored and the front-end where content is rendered. In CMS parlance this is typically called a “coupled” CMS because the front-end and the back-end are coupled together.

Historically, the coupled nature of Drupal was a benefit most of the time because it facilitated a fast time-to-market. In many cases, customers could just install Drupal, define their content types, install or develop a theme, and they had a web site up-and-running that made it easy for non-technical content editors to manage the content of that web site.

But as architectural styles have shifted to “API-first” and Single Page Applications (SPAs) written in client-side frameworks like Angular and React and with many clients finding themselves distributing content to multiple channels beyond web, having a CMS that wants to own the front-end becomes more of a burden than a benefit, hence the rise of the “headless” or “de-coupled” CMS. Multiple SaaS vendors have sprung up over the last few years, creating a Content-as-a-Service market which I’ve blogged about before.

Drupal has been able to expose its content and other operations via a RESTful API for quite a while. But in those early days it was not quite as simple as it could be. If you have a team, for example, that just wants to model some content types, give their editors a nice interface for managing instances of those types, and then write a front-end that fetches that content via JSON, you still had to know a fair amount about Drupal to get everything working.

Last summer, Acquia, a company that provides enterprise support for Drupal headed up by Drupal founder, Dries Buytaert, released a new distribution of Drupal called Reservoir that implements the “headless CMS” use case. Reservoir is Drupal, but most of the pieces that concern the front-end have been removed. Reservoir also ships with a JSON API module that exposes your content in a standard way.

I was curious to see how well this worked so I grabbed the Reservoir Docker image and fired it up.

The first thing I did was create a few content types. Article is a demo type provided out-of-the-box. I added Job Posting and Team Member, two types you’d find on just about any corporate web site.

My Team Member type is simple. It has a Body field, which is HTML text, and a Headshot field, which is an image. My Job Posting type has a plain text Body field, a Date field for when the job was posted, and a Status field which has a constrained list of values (Open and Closed).

With my types in place I started creating content…

Something that jumped out at me here was that there is no way to search, filter, or sort content. That’s not going to work very well as the number of content items grows. I can hear my Drupal friends saying, “There’s a module for that!”, but that seems like something that should be out-of-the-box.

Next, I jumped over to the API tab and saw that there are RESTful endpoints for each of my content types that allow me to fetch a list of nodes of a given type, specific nodes, and the relationships a node has to other nodes in the repository. POST, PATCH, and DELETE methods are also supported, so this is not just a read-only API.

Reservoir uses OAuth to secure the API, so to actually test it out, I grabbed the “Demo app” client UUID, then went into Postman and did a POST against the /oauth/token endpoint. That returned an access token and a refresh token. I grabbed the access token and stuck it in the authorization header for future requests.

Here’s an example response for a specific “team member” object.

My first observation is that the JSON is pretty verbose for such a simple object. If I were to use this today I’d probably write a Spring Boot app that simplifies the API responses further. As a front-end developer, I’d really prefer for the JSON that comes back to be much more succinct. The front-end may not need to know about the node’s revision history, for example.

Another reason I might want my front-end to call a simplified API layer rather than call Drupal directly is to aggregate multiple calls. For example, in the response above, you’ll notice that the team member’s headshot is returned as part of a relationship. You can’t get the URL to the headshot from the Team Member JSON.

If you follow the field_headshot “related” link, you’ll get the JSON object representing the headshot:


The related headshot JSON shown above has the actual URL to the headshot image. It’s not the end of the world to have to make two HTTP calls for every team member, but as a front-end developer, I’d prefer to get a team member object that has exactly what I need in a single response.

One of the things that might help improve this is support for GraphQL. Reservoir says it plans to support GraphQL, but in the version that ships on the Docker image, if you try to enable it, you get a message that it is still under development. There is a GraphQL Drupal module so I’m sure this is coming to Reservoir soon.

Many of my clients are predominantly Java shops–they are often reluctant to adopt technology that would require new additions to their toolchain, like PHP. And they don’t always have an interest in hiring or developing Drupal talent. Containers running highly-specialized Drupal distributions, like Reservoir, could eventually make both of these concerns less of an issue.

In addition to Acquia Reservoir, there is another de-coupled Drupal Distribution called Contenta, so if you like the idea of running headless Drupal, you might take a look at both and see which is a better fit.

Categories: Drupal

Mediacurrent: Friday 5: 5 Ways to Secure Your Drupal Site

2 March 2018 - 8:23am

Happy Friday Everyone! On the eve of the Drupal Drive-in, happening tomorrow in Charolette North Carolina, we welcome Mark Shropshire to the show to talk about his favorite topic, Drupal Security!

Categories: Drupal

orkjerns blogg: Updating to Drupal 8.5 with composer

2 March 2018 - 4:03am
Updating to Drupal 8.5 with composer admin Fri, 03/02/2018 - 12:03

If you are like me, you might have already started planning the upgrade to Drupal 8.5, now that the first release candidate is out. It's awesome by the way, among other things, thanks to the incredible work done with layout builder. And if you are more like me, you are managing your sites with composer. Then, depending on the rest of your project, you might (also like me), have encountered some initial problems upgrading to Drupal 8.5

Having hit my fair share of composer oddities with running the composer monitor and upgrade service, I wanted to compile a couple of error messages along with solutions, to the folks struggling with this out there.

Installation request for webflo/drupal-core-require-dev (locked at 8.4.5, required as ~8.4) -> satisfiable by webflo/drupal-core-require-dev[8.4.5].

If you have installed an out of the box version of, this might be an error message you encounter. Full error message, for reference:

./composer.json has been updated > DrupalProject\composer\ScriptHandler::checkComposerVersion Loading composer repositories with package information Updating dependencies (including require-dev) Your requirements could not be resolved to an installable set of packages. Problem 1 - webflo/drupal-core-require-dev 8.4.5 requires drupal/core 8.4.5 -> satisfiable by drupal/core[8.4.5] but these conflict with your requirements or minimum-stability. - webflo/drupal-core-require-dev 8.4.5 requires drupal/core 8.4.5 -> satisfiable by drupal/core[8.4.5] but these conflict with your requirements or minimum-stability. - webflo/drupal-core-require-dev 8.4.5 requires drupal/core 8.4.5 -> satisfiable by drupal/core[8.4.5] but these conflict with your requirements or minimum-stability. - Installation request for webflo/drupal-core-require-dev (locked at 8.4.5, required as ~8.4) -> satisfiable by webflo/drupal-core-require-dev[8.4.5]. Installation failed, reverting ./composer.json to its original content.

The reason this fails is that the project you have created is depending on the dev packages for drupal core, which are tied to a specific version of core. So to update core, we also need to update the dev packages for core.

The solution to this is pretty simple:
Open your composer.json file and replace the lines for drupal/core and webflo/drupal-core-require-dev with the following:

"drupal/core": "~8.5" // ...and "webflo/drupal-core-require-dev": "~8.5"

Afterwards you can go ahead and run:

composer update drupal/core webflo/drupal-core-require-dev --with-dependencies Installation request for symfony/config (locked at v3.2.14) -> satisfiable by symfony/config[v3.2.14].

This probably comes from the fact that you also have some other packages depending on this specific Symfony package in your project. Like drush or drupal console. Here is a full error message, for reference:

Loading composer repositories with package information Updating dependencies (including require-dev) Your requirements could not be resolved to an installable set of packages. Problem 1 - Conclusion: don't install drupal/core 8.5.0-rc1 - Conclusion: don't install drupal/core 8.5.0-beta1 - Conclusion: don't install drupal/core 8.5.0-alpha1 - Conclusion: don't install drupal/core 8.6.x-dev - Conclusion: remove symfony/config v3.2.14 - Installation request for drupal/core ~8.5 -> satisfiable by drupal/core[8.5.0-alpha1, 8.5.0-beta1, 8.5.0-rc1, 8.5.x-dev, 8.6.x-dev]. - Conclusion: don't install symfony/config v3.2.14 - drupal/core 8.5.x-dev requires symfony/dependency-injection ~3.4.0 -> satisfiable by symfony/dependency-injection[3.4.x-dev, v3.4.0, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2, v3.4.1, v3.4.2, v3.4.3, v3.4.4]. - symfony/dependency-injection 3.4.x-dev conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0-BETA1 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0-BETA2 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0-BETA3 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0-BETA4 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0-RC1 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0-RC2 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.1 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.2 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.3 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.4 conflicts with symfony/config[v3.2.14]. - Installation request for symfony/config (locked at v3.2.14) -> satisfiable by symfony/config[v3.2.14].

The solution here is to indicate you also want to update this package, even if it's not specifically required. So if the failing command was the following:

composer update drupal/core --with-dependencies

Go ahead and change it to this:

composer update drupal/core symfony/config --with-dependencies

If you have other error messages, I would be glad to help out with a solution, and post the result here.


Thanks to zaporylie for looking into this with me, and to Berdir for pointing out the fact that core is not the package that requires symfony/config.

Let's finish this post with an animated gif of a composer

Categories: Drupal

Wim Leers: API-First Drupal: what's new in 8.5?

2 March 2018 - 3:11am

Now that Drupal 8’s REST API 1 has reached the next level of maturity, I think a concise blog post summarizing the most important API-First Initiative improvements for every minor release is going to help a lot of developers. Drupal 8.5.0 will be released next week and the RC was tagged last week. So, let’s get right to it!

The REST API made a big step forward with the 5th minor release of Drupal 8 — I hope you’ll like these improvements :)

Thanks to everyone who contributed!

  1. text fields’ computed processed property exposed #2626924

    No more need to re-implement this in consumers nor work-arounds.

    "body":{ "value":"<p>Hi!</p><script>alert('foo')</script>", "format":"basic_html" }

    "body":{ "value":"<p>Hi!</p><script>alert('foo')</script>", "format":"basic_html", "processed":"<p>Hi!</p>" }
  2. uri field on File gained a computed url property #2825487

    "uri":{"value":"public://cat.png"} ⬇ "uri":{"url":"/files/cat.png","value":"public://cat.png"}

  3. Term POSTing requires non-admin permission #1848686

    administer taxonomy permission ⬇ create terms in %vocabulary% permission

    Analogously for PATCH and DELETE: you need edit terms in %vocabulary% and delete terms in %vocabulary%, respectively.

  4. Vocabulary GETting requires non-admin permission #2808217

    administer taxonomy permission ⬇ access taxonomy overview permission

  5. GET → decode → modify field → encode → PATCH → 403 200 #2824851

    You can now GET a response, modifying the bits you want to change, and then sending exactly that, without needing to remove fields you’re not allowed to modify. Any fields that you’re not allowed to modify can still be sent without resulting in a 403 response, as long as you send exactly the same values. Drupal’s REST API now implements the robustness principle.

  6. 4xx GET responses cacheable: more scalable + faster #2765959

    Valuable for use cases where you have many (for example a million) anonymous consumers hitting the same URL. Because the response is not cacheable, it can also not be cached by a reverse proxy in front of it. Meaning that we’ll have hundreds of thousands of requests hitting origin, which can bring down the origin server.

  7. Comprehensive integration tests + test coverage test coverage

    This massively reduces the risk of REST API regressions/changes/BC breaks making it into a Drupal 8 release. It allows us to improve things faster, because we can be confident that most regressions will be detected. That even includes the support for XML serialization, for the handful of you who are using that! We take backwards compatibility serious.
    Even better: we have test coverage test coverage: tests that ensure we have integration tests for every entity type that Drupal core’s stable modules ship with!
    Details at API-First Drupal — really!. Getting to this point took more than a year and required fixing bugs in many other parts of Drupal!

Want more nuance and detail? See the REST: top priorities for Drupal 8.5.x issue on

Are you curious what we’re working on for Drupal 8.6? Want to follow along? Click the follow button at REST: top priorities for Drupal 8.6.x — whenever things on the list are completed (or when the list gets longer), a comment gets posted. It’s the best way to follow along closely!2

The other thing that we’re working on for 8.6 besides the REST API is getting the JSON API module polished to core-worthiness. All of the above improvements help JSON API either directly or indirectly! More about that in a future blog post.

Was this helpful? Let me know in the comments!

Thanks to Ted for reviewing a draft of this blog post! And sorry for not changing the title to API First Drupal in 8.5.0: Amazing progress because of tedbow’s work on setInternal properties!!!!!!!!! even though that would’ve been totally accurate :D

For reference, historical data:

  1. This consists of the REST and Serialization modules. ↩︎

  2. ~50 comments per six months — so very little noise. ↩︎

  • API
  • Acquia
  • Drupal
Categories: Drupal

OPTASY: From Drush Clear Cache to... Rebuilding Cache in Drupal 8: What's the Difference?

2 March 2018 - 2:45am
From Drush Clear Cache to... Rebuilding Cache in Drupal 8: What's the Difference? radu.simileanu Fri, 03/02/2018 - 10:45 From "remorsefully clearing all Drupal cache using Drush, to actually... rebuilding them in Drupal 8? Why the change? How will the new “cache-rebuild” concept impact your Drupal development process? All your troubleshooting and site updating sessions?
Categories: Drupal

Hook 42: Hook 42 in the Windy City!

1 March 2018 - 9:37am

We are excited to have Adam Bergstein joining our team as Vice President of Engineering! Better yet? He’ll be speaking at the upcoming Midwest Drupal Camp in Chicago about his journey from engineer to technical leader.

MidCamp is March 8th - 11th, 2018 at DePaul University Lincoln Park Campus, Chicago.

Categories: Drupal

Acquia Developer Center Blog: The Web Is Changing: Introducing Experience Express

1 March 2018 - 8:17am

At no point in the history of digital content has there ever been such a dizzying proliferation of devices in our lives, and experiences we encounter and consume. Long the most critical element of an organization’s digital presence, the website is increasingly treated as just a single facet in a kaleidoscope of content channels and form factors. Many of today’s users, in the course of acquiring content or data, never touch a desktop web browser at all.

Tags: acquia drupal planet
Categories: Drupal

Deeson: Talking security at DrupalCamp London 2018

1 March 2018 - 5:48am

We’re strong believers that contributing to open source and sharing what we’ve learnt benefits both our agency and the wider community. It’s one of the reasons we offer our team paid conference tickets and support for public speaking.

In particular, we've been key supporters of the European Drupal community since 2007, with the largest team of Acquia certified developers in Europe. We're proud to be in the top 30 of companies contributing to the project globally.

On 3rd March 2018, I’ll be speaking at DrupalCamp London – an event which our own Tim Deeson helped co-found in 2013. It brings together Drupal developers of all levels and from all over Europe to engage in learning and discussion about the project.

Effortless security updates for your Drupal sites.

The title of my session is Warden - Helping Drupal Agencies Sleep at Night. It’s critical to keep your sites up to date with the latest security releases. But it’s a time consuming task to check each site manually. We built Warden to solve this problem.

Warden is an open source solution that allows in-house development teams and agencies to keep track of the status of multiple Drupal sites hosted on different platforms. I’ll explain how Warden makes managing the security of all your sites much more manageable.

This session is for you if you:

  • have a large number of sites hosted with multiple hosting companies that you need to keep track of.
  • have sites that may need security updates but you don’t have the time to investigate.
  • wish there was a central dashboard reporting which of your sites needed security updates applied.

I’ll demonstrate how Warden works and show you how easy it is to see which sites need security updates, saving your team time to focus on other important work. I’ll also discuss best practice for site security and the importance of making sure that all your developers are aware of it.

Come and talk to us.

Quite a few of us from the development team will be at DrupalCamp London this year. Look out for our Technical Director John Ennew, and ask him about job opportunities at Deeson. We’re currently hiring for several roles across the tech chapter, including developers at all levels and development managers.

There are lots of reasons we’re a great agency to work for, including:

  • Flexible and remote working.
  • Paid time to contribute to open source.
  • Transparent pay scales and a fair pay guarantee.
  • £500 annual personal budget for hardware, software or accessories.
  • Mandatory 5 week paid sabbatical every 5 years.

Check out our careers page for more, and don’t forget to follow us on Twitter @deesonlabs for updates throughout DrupalCamp London. We’ll see you back here next week with our highlights!

Categories: Drupal

Specbee: Why Is Drupal CMS a Key To Success For Enterprise Websites In 2018?

1 March 2018 - 5:20am

Do you know how much enterprise companies spend on their website annually? What makes their website great? I mean there is obviously the high traffic, better bounce rates and over the top numbers, but is that all?

Categories: Drupal

Drupal Europe: It’s your turn

1 March 2018 - 3:16am

We are organizing the biggest Drupal event in Europe in 2018 with a group of community volunteers in collaboration with the Drupal eV (German Drupal Association) and the Drupal Europe Foundation. We’d like to update you on our progress and turn to you for input.

Mark your calendars for September 10–14, 2018 when Drupal Europe will be held in the beautiful Darmstadtium in Darmstadt, Germany. This is a great venue for the conference and only a 20 minutes’ drive from Frankfurt Airport. We just had our second walkthrough last week discussing details with the venue and were impressed.

Photo by Baddy Breidert @baddysonjaBuy your Early Supporter ticket now!

We are now selling Early supporter tickets for 380 EUR (including VAT). Only 300 of these tickets are available, and only for a limited time. Buy now at

A new logo

Thanks to all designers we worked with who came up with such great ideas for our branding! We are delighted to release our final logo proudly crafted by sixeleven. Drupal Europe stickers (pictured here) will be available at various Drupal events where our team shows up in the coming months.

Latest on the conference schedule

We are continually looking at how to structure the biggest Drupal event in Europe, and based on exploratory discussions with community members, we believe we are on the right track.

First of all we strongly believe contribution is at the heart of the Drupal project. Figures show that over 44% of Drupal contributors are in Europe. Therefore, in our programme we want to give you more time to contribute by making both Monday and Friday contribution days (formerly called sprints). Mentors will be available on both days to help those new to Drupal contribution.

We are structuring the rest of the event between Tuesday and Thursday on the successful summit model that has worked well at the start of DrupalCons and other regional events. Topics will include government, education, publishing, technology, and community. We are looking for sponsors for each to make possible to put them on.

And the great news is that your single Drupal Europe ticket will give you access to all these workshops, panels and discussions.

We want to hear from you

Although we have plenty of ideas, we realize that this is your conference.

DrupalCON Amsterdam Group photo

Please help us understand you, our audience, better by completing our survey. It should only take 8 minutes or so and still give us lots of valuable insight. While not all questions are mandatory, we added a few open questions to get to know you better.

Thank you, and please share our survey with all your Drupal friends and colleagues to help us make Drupal Europe a success.

See you in September!

Categories: Drupal

Lullabot: The Simplest Path to a Drupal Local Environment

28 February 2018 - 8:17am

After my article about Drupal Development Environments, we had some discussions about the differences junior developers see when using Drupal and PHP applications locally, compared to React and other front-end tools. Someone mentioned how easy it was for them to get started by running yarn serve in a React project, and I was curious how close to that we could get for Drupal.

To make this a fair comparison, I’m not including managing MySQL databases and the like. Most React apps don’t use a database directly, and if you do need to run backend services locally, the complexity goes way up. In between writing and publishing this article, Stranger in a familiar land: Comparing the novice's first impression of Drupal to other PHP frameworks was published, which constrained itself to using the Drupal GUI installer. I think this guide shows that we can run Drupal locally in very few steps as long as we don't force ourselves to use a GUI.

I also wanted to see what the “new laptop” experience was like. I’ve been migrating my macOS setup between computers for nearly 15 years (if only Windows worked as well!), and it’s easy to forget what exactly is built in and what I’ve added over time. So, I installed a fresh copy of High Sierra in VirtualBox to ensure none of my terminal or Homebrew customizations were giving me a leg up.

Installing Composer

We need Composer to install Drush. Change to the drupal directory in the terminal (cd drupal), and run the Composer installation instructions to download composer.

When composer is done, you will have a composer.phar file in your Drupal directory.

undefined Installing Drush and Drupal

Drush is what will let us easily run Drupal using the built-in PHP webserver. It’s also required to do the initial site installation. Pull Drush into your Drupal site by running:

$ composer require drush/drush

This will not only pull in Drush, but it will also install all of the other libraries Drush needs at the same time.

Once Drush is installed, we have to use it to install Drupal. Drupal does have a graphical installer, but Drush won’t run the PHP webserver unless Drupal is already installed. The most important parameter is the database URL, which tells Drupal what database server to use and how to connect to it. We’re going to use SQLite, which is a simple single-file database. We don’t want the database file itself to be accessible from the web server (in case it’s ever exposed to respond to external requests), so we tell Drupal to put the database in a directory above our Drupal document root.

$ vendor/bin/drush site-install --db-url=sqlite://../drupal.sqlite


When the installation is done, Drush will tell you the administrator password. If you ever forget it, you can reset it by generating a login link with drush user-login.

Running the Drupal Web Server

To start the web server, use the run-server command:

$ vendor/bin/drush run-server

By default, the server will listen on Run vendor/bin/drush help run-server to see how to change these and other defaults.

Finally, open that URL in a browser. You should see the Drupal 8 home page and be able to log in with the administrator account shown earlier. Press CTRL-C in the terminal to shut down the web server.


The default macOS PHP configuration is pretty good, though it sets a very low limit of 2MB for uploaded files. If you need to raise it, copy /etc/php.ini.default to /etc/php.ini with:

sudo cp /etc/php.ini.default /etc/php.ini

Then, edit it with sudo nano /etc/php.ini to change settings as you see fit. You will need to restart the Drush web server after changing this file.

Bonus: Installing Git and Cloning Drupal

I like to use git even for basic testing because I can run git status at any time to see what files I’ve changed or added. I opened the Terminal and ran the git clone command copied from the Drupal project page.

$ git clone --branch 8.5.x

The first run of this command prompts to install the developer tools:


After they install, you need to rerun the git command again (which is accessible by pressing the up arrow on your keyboard).

When this initial clone is done, you will have a Drupal 8.5.x checkout in a folder called “drupal,” and you can go back to the earlier steps to install and run Drupal.

Next Steps

Now that you have a running Drupal 8 site, it’s easy to try out contributed modules or new experimental modules without worrying about breaking a real site. It’s easy to run a “clean” instance of Drupal 8 later, by reinstalling the current site with drush site-install, or by creating a new Drupal git clone separate from the first one. And, if you are evaluating Drupal and decide to use it for a real website, you can set up a better development environment without having to learn Composer and Drush at the same time.

Categories: Drupal

Drupal blog: Three ways we can improve Drupal's evaluator experience

28 February 2018 - 7:41am

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Last week, Matthew Grasmick stepped into the shoes of a developer who has no Drupal experience, and attempted to get a new "Hello world!" site up and running using four different PHP frameworks: WordPress, Laravel, Symfony and Drupal. He shared his experience in a transparent blog post. In addition to detailing the inefficiencies in Drupal's download process and end-user documentation, Matt also shows that out of the four frameworks, Drupal required the most steps to get installed.

While it is sobering to read, I'm glad Matthew brought this problem to the forefront. Having a good evaluator experience is critical as it has a direct impact on adoption rates. A lot goes into a successful evaluator experience: from learning what Drupal is, to understanding how it works, getting it installed and getting your first piece of content published.

So how can we make some very necessary improvements to Drupal's evaluator experience?

I like to think of the evaluator experience as a conversion funnel, similar to the purchase funnel developed in 1898 by E. St. Elmo Lewis. It maps an end-user journey from the moment a product attracts the user's attention to the point of use. It's useful to visualize the process as a funnel, because it helps us better understand where the roadblocks are and where to focus our efforts. For example, we know that more than 13 million people visited in 2017 (top of the funnel) and that approximately 75,000 new Drupal 8 websites launched in production (bottom of the funnel). A very large number of evaluators were lost as they moved down the conversion funnel. It would be good to better understand what goes on in between.

As you can see from the image above, the Drupal Association plays an important role at the top of the funnel; from educating people about Drupal, to providing a streamlined download experience on, to helping users find themes and modules, and much more.

The Drupal Association could do more to simplify the evaluator experience. For example, I like the idea of the Drupal Association offering and promoting a hosted, one-click trial service. This could be built by extending a service like into a hosted evaluation service, especially when combined with the upcoming Umami installation profile. (The existing "Try Drupal" program could evolve into a "Try hosting platforms" program. This could help resolve the expectation mismatch with the current "Try Drupal" program, which is currently more focused on showcasing hosting offerings than providing a seamless Drupal evaluation experience.)

The good news is that the Drupal Association recognizes the same needs, and in the past months, we have been working together on plans to improve Drupal's conversional funnel. The Drupal Association will share its 2018 execution plans in the upcoming weeks. As you'll see, the plans address some of the pain points for evaluators (though not necessarily through a hosted trial service, as that could take significant engineering and infrastructure resources).

The Documentation Working Group also plays a very important role in this process. After reading Matthew's post, I reached out to Joe Shindelar, who is a member of the Drupal Documentation Working Group. He explained that the Documentation Working Group has not been meeting regularly nor coordinating initiatives for some time.

It is time to rethink our approach around Drupal's documentation. Adam Hoenich, a long-time Drupal contributor, recommends that documentation becomes a full-fledged core initiative, including the addition of a Documentation Maintainer to the Core Committer team. His proposal includes blocking commits to Drupal on documentation.

I've no doubt that we have to evolve our governance model surrounding documentation. It's hard to write world-class documentation by committee without good governance and Adam's recommendations are compelling. Drupal's API documentation, for example, is governed by the Core Committers; while there is always room for improvement, it's really well-maintained. Some of you might remember that we had an official Documentation Maintainer role in the past, filled by Jennifer Hodgdon. Reinstating this position could bring documentation back into clearer focus and provide the necessary governance. I also suspect that a stronger emphasis on coordination, governance and recognition for documentation work, would inspire more contributors to help.

Last but not least, this also affects the Drupal (Core) Contributors. Evaluators often spend hours trying to get their web server configured, PHP installed or their database setup. As a community, we could help alleviate this pain by deciding to have a single, recommended default installation environment. For example, we could maintain and promote a Docker container (including an official docker-compose.yml) that ships with the latest version of Drupal. It would simplify many of our documentation efforts, and eliminate many roadblocks from the evaluation process.

To narrow down my recommendations, I would propose the following three steps:

  1. A single, recommended default installation environment (e.g. Docker container) for evaluators or developers taking their first steps in Drupal development.
  2. Infrastructure budget and engineering resources for the Drupal Association so they can offer a true hosted "Try Drupal" service.
  3. A Documentation Maintainer who can focus on end-user documentation, is a member of the Core Committer team and is responsible for defining the scope of what should be documented. Given the amount of work this position would entail, it would be ideal if this person could be at least partially funded.

Of course, there are many other solutions, but these are the areas I'd focus on. As always, success depends on our ability to align on solutions, coordinate all the work, and allocate the time and money to implement the necessary improvements. If you think you can help with any of the proposed steps, please let us know in the comments, and we'll help you get involved.

Categories: Drupal

Hook 42: Using Lando for Drupal 8 Core Issue Patch Testing

27 February 2018 - 6:54pm

Drupal thrives with love and care from the community. We help move the Drupal project forward by mentoring, sharing knowledge, helping with (d.o) issues, and more. If you want to help in the d.o issue queues, you are very welcome! While there are many ways to help, one important piece is reviewing and testing code patches.

Categories: Drupal

Drupalize.Me: Symfony 4 and Drupal

27 February 2018 - 1:30pm
Categories: Drupal