Planet Drupal

How to update Drupal 8 core?

Let's see how to update your Drupal site between 8.x.x minor and patch versions. For example, from 8.1.2 to 8.1.3, or from 8.3.5 to 8.4.0. I hope this will help you.

  • If you are upgrading to Drupal version x.y.z

           x -> is known as the major version number

           y -> is known as the minor version number

           z -> is known as the patch version number.

Sat, 03/24/2018 - 10:31
Drupalcon mentored core sprint - part 2 - your experience as a sprinter 12.05.2018 Michael Lenahan Body:  Drupalcon mentored core sprint - part 2 - your experience as a sprinter

Hello! You've arrived at part 2 of a series of 3 blog posts about the Mentored Core Sprint, which traditionally takes place every Friday at Drupalcon.

If you haven't already, please go back and read part 1.

You may think sprinting is not for you ...

So, you may be the kind of person who usually stays away from the Sprint Room at Drupal events. We understand. You would like to find something to work on, but when you step in the room, you get the feeling you're interrupting something really important that you don't understand.

It's okay. We've all been there.

That's why the Drupal Community invented the Mentored Core Sprint. If you stay for this sprint day, you will be among friends. You can ask any question you like. The venue is packed with people who want to make it a useful experience for you.

Come as you are

All you need in order to take part in the first-time mentored sprint are two things:

  • Your self, a human who is interested in Drupal
  • Your laptop

To get productive, your laptop needs a local installation of Drupal. Don't have one yet? Well, it's your lucky day because you can your Windows or Mac laptop set up at the first-time setup workshop!

Need a local Drupal installation? Come to the first-time setup workshop

After about half an hour, your laptop is now ready, and you can go to the sprint room to work on Drupal Core issues ...

You do not need to be a coder ...

You do not need to be a coder to work on Drupal Core. Let's say, you're a project manager. You have skills in clarifying issues, deciding what needs to be done next, managing developers, and herding cats. You're great at taking large problems and breaking them down into smaller problems that designers or developers can solve. This is what you do all day when you're at work.

Well, that's also what happens here at the Major Issue Triage table!

But - you could just as easily join any other table, because your skills will be needed there, as well!

Never Drupal alone

At this sprint, no-one works on their own. You work collaboratively in a small group (maybe 3-4 people). So, if you don't have coding or design skills, you will have someone alongside you who does, just like at work.

Collaborating together, you will learn how the Drupal issue queue works. You will, most likely, not fix any large issues during the sprint.

Learn the process of contributing

Instead, you will learn the process of contributing to Drupal. You will learn how to use the issue queue so you can stay in touch with the friends you made today, so that you fix the issue over the coming weeks after Drupalcon.

It's never too late

Even if you've been in the Drupal community for over a decade, just come along. Jump in. You'll enjoy it.

A very welcoming place to start contributing is to work on Drupal documentation. This is how I made my first contribution, at Drupalcon London in 2011. In Vienna, this table was mentored by Amber Matz from Drupalize.Me.

This is one of the most experienced mentors, Valery Lourie (valthebald). We'll meet him again in part 3, when we come to the Drupalcon Vienna live commit.

Here's Dries. He comes along and walks around, no one takes any notice because they are too engaged and too busy. And so he gets to talk to people without being interrupted.

This is what Drupal is about. It's not about the code. It's about the people.

Next time. Just come. As a sprinter or a mentor. EVERYONE is welcome, we mean that.

This is a three-part blog post series:
Part one is here
You've just finished reading part two
Part three is coming soon

Credit to Amazee Labs and Roy Segall for use of photos from the Drupalcon Vienna flickr stream, made available under the CC BY-NC-SA 2.0 licence.

Schlagworte/Tags:  planet drupal-planet drupalcon mentoring code sprint Ihr Name Kommentar/Comment Kommentar hinzufügen/Add comment Leave this field blank

We are thrilled to bring you the most exciting event of this year Drupal Camp Goa 2018! You would be ecstatic to be a part of something really big that’s happening in India’s most sought-after destination, Goa. It’s a shoutout for all of you who love developing and would like to extend their immense support to the web’s leading content management system (CMS), Drupal!

Why should Drupalers have all the fun!

This time it is not just Drupal, we are exploring beyond it. Join us to share your knowledge on topics like...

Matt and Mike talk with the Drupal Association's Tim Lehnen and Neil Drumm about the changes to's tooling.

When adding a social media (SoMe) feed or "some wall" like here on the right bottom corner to your webpage the big question is: Why would you put it to your site? Why is it there?

If the answer is something like "to get some content to your site." - consider again. The SoMe feed might benefit you or harm you depending how you manage it.

Here are some points to consider:

Social media SoMe Drupal 8 SoMe wall Planet Drupal
The problem: XDebug doesn't work for Composer scripts

PhpStorm is quite convenient to debug scripts with XDebug (do you support Derick for giving us XDebug ?): just add a "Run/Debug configuration", choosing the "PHP Script" type, give a few parameters, and you can start debugging your PHP CLI scripts, using breakpoints, evaluations, etc.

Wonderful. So now, let's define such a configuration to debug a Composer script, say a Behat configuration generator from site settings for some current Drupal 8 project. Apply the configuration, run it in debug mode, and ....

...PhpStorm doesn't stop, the script runs and ends, and all breakpoints were ignored. How to actually use breakpoints in the IDE ?

read more

Netflix Eureka is a REST service that is primarily used in the AWS cloud for locating services. It comes with a Java-based client. But if you need a PHP-based client - welcome under the cut.
Read more »

Over the past few months, I've been test-driving various Docker-based local development environments with two goals in mind. First, as my "daily driver" for consulting work - I've been a long-time MAMP Pro user and I've been feeling for a long time that I need to modernize my local development tools. Second, I'm trying to figure out what is the most ideal local development environment for students of both our 12-week Drupal Career Online class (starts March 19) and our 6-week Mastering Professional Drupal Development Workflows with Pantheon (starts February 26) courses. 

One of the necessary skills for a professional Drupal developer (one who codes either modules or themes) is to be able run a solid debugging tool. As part of my evaluation of Lando, I decided to figure out how to set up local PHP debugging with Xdebug and PhpStorm on Mac OS X.

This process described below is largely based on a comment in an issue thread in the Lando issue queue by David Hunt - thanks, David!

My local setup includes:

  • Mac OS X Sierra 10.12.6  
  • Lando v3.0.0-beta.21  
  • Google Chrome with the Xdebug helper extension 
  • PhpStorm 2016.1.1  
Starting point

This tutorial assumes that you have a local Drupal site up-and-running in Lando and set up as a project in PhpStorm. In this example, my local site is using the Lando "Pantheon" recipe, but as you'll see in a bit, any recipe can be used. Also - my local site is based on the standard Drupal project composer template (with a nested docroot).

Enable Xdebug in Lando

The first step is to enable Xdebug in Lando - this is easily done by modifying the local site's .lando.yml file. In my case, I added the following:


If your .lando.yml file is defining a custom appserver service, then you should be able to just add the "xdebug: true" bit to the appserver definition. 

Once added, you'll need to perform a "lando rebuild" - this will rebuild your environment based on your .lando.yml, including adding Xdebug. The documentation page for the "rebuild" command includes a caution about how there's no guarantee that data will persist between rebuilds. In my experience, I haven't had any issues with losing my database. If you're concerned, then you may want to perform a "lando db-export" prior to rebuilding.  

Configuring PhpStorm

Here's where some magic comes in. Admittedly, I don't fully understand the details of some of the configuration necessary in PhpStorm to get debugging working, but I can confirm that following these steps, it has worked every time for me so far.

The first step is to add the Lando recipe folder as an "Include path" in your PhpStorm project. Open Preferences > Languages & Frameworks > PHP, click the "+" button at the bottom of the list, and manually type in the name of the folder of the Lando recipe you're using. On my machine it is: /Users/michael/.lando/services/config/pantheon. If you're using the standard "Drupal8" recipe, then it would be: /Users/michael/.lando/services/config/drupal8. Unless your username is also "michael", you'll want to update the path.


Then, go to Preferences > Languages & Frameworks > PHP > Servers

If no server for your project exists (it might be called “appserver”), then enable PhpStorm to listen for Xdebug connections, load a page from your local site in your browser and PhpStorm will prompt you to accept the incoming connection. In my case, it didn’t matter if the Xdebug helper is set to debugging or disabled at this point.



Then, once a server for your local site exists (remember, it might be called "appserver”), select it and ensure that "Use path mappings" is checked, and ensure that your project folder is mapped to "/app" for the "Absolute path on server". Also ensure that the "Absolute path for the server" for the “include path” is "/srv/includes".


Give it a try!

At this point, we should be ready for debugging! As a test, open up the site's index.php in PhpStorm and place a breakpoint.

Then, using the Xdebug Helper extension, enable debugging. Also ensure that PhpStorm is still set to listen to incoming Xdebug connections. 

Finally, load your local site's home and watch how PhpStorm will pause code execution at your breakpoint in the index.php file.

Warning - performance will suffer

While Xdebug is a powerful tool and will absolutely save you loads of time, there's a dark side. Performance will suffer. I recommend disabling Xdebug in your .lando.yml - by setting "xdebug: false" - (and rebuilding) when you're not using it. You can leave it enabled and gain back some (but not all) performance by disabling PhpStorm's listener as well. 

Final thoughts

In case you're wondering where some of the configuration settings come from, here's what I've figured out so far:

  • "appserver" is the name of the Lando service that contains the codebase. 
  • "/app" is the absolute path of the codebase in the "appserver" Docker container. 
  • "/srv/includes" is the absolute path to a Lando-provided "prepend.php" file in the "appserver" Docker container. As far as I can tell, this file defines and sets a bunch of environment variables depending on the recipe used.
In this episode, Matthew Tift talks with Tom Grandy, who oversees websites for 23 school districts. Tom describes himself as a journalist, a teacher, and a non-coder who helps out with documentation and marketing for Backdrop. He describes his experiences using proprietary software, finding Drupal, his involvement with Backdrop, and the challenges of using free software in K-12 education. Tom shares why people working in schools make decisions about technology most often based on cost, but that he believes we should also considers software licenses, communities, and other more philosophical factors.
GraphQL for Drupalers - part 4 - fetching the entities

GraphQL is becoming more and more popular every day. Now that we have a beta release of the GraphQL module (mainly sponsored and developed by Amazee Labs) it's easy to turn Drupal into a first-class GraphQL server. In this series, we'll try to provide an overview of its features and see how they translate to Drupal.

Blazej Owczarczyk Mon, 01/29/2018 - 10:47

In the last post we talked about the basic building blocks of every GraphQL query - the fields. We've discussed their types and traits as well as described the rules according to which Drupal fields turn into GraphQL fields. This week we were going to expand the topic further and cover field creation, but Daniel Noyola asked an interesting question in the comment below one of the recent articles:

How can I filter the results in a nodeQuery? Like I would in a normal View or with the "where" clause in a SQL Statement. I noticed that it receives a NodeQueryFilterInput but I don't see how to use it.

Fetching entities based on a filter or a set of filters is a common use case, so let's focus on that first.


There are two ways to query the entity repository. First one would be through the entityQuery fields which are shipped with the core module but are limited in functionality. They only allow us to filter by base fields and there's no way to use an operator other than equals to. The other approach is much more powerful, as it's based on Views. It requires an additional module - graphql_views - to be installed though. Let's start with the built-in way.

The nodeQuery

Each entity type in the system gets its own query field. Let's see in the explorer how it looks like for nodes:

So it's a field (blue) with 3 arguments: offset, limit and filter (purple) which returns a value of type EntityQueryResult (all types are in yellow).

The first two arguments, offset and limit, are for paging and they work the same way as in SQL. Both are integers and both have default values of 0 and 10 respectively (green). Arguments that have default values can be omitted. We'll use this feature in a while.

The last argument - filter - is of a complex type NodeQueryFilterInput. Let's click it:

So it comprises all the base fields of the entity type that is being queried. It's not enough to issue arbitrary queries but it will suffice for a simple use case. This is how we could fetch a list of articles created by a given user:

We haven't specified the offset nor the limit, so they'll get their default values. It means that the output will contain at most 10 results, starting from the result number 0.

That's cool, but what if we wanted to order the articles by node id (nid) to only show the latest articles? Or filter by tags? Or fetch the title text of an image that is attached to a media entity that is connected with the first event that starts after the article's release date?

Use The Views

The answer is: we can do it like we'd normally do it in Drupal - with a view. Views integration has been moved to a separate project, so it has to be downloaded with composer (composer require drupal/graphql_views), from or from github.

With graphql_views enabled we can add a GraphQL display to any view in the system.

Now we can sort the results, filter based on content fields and add relationships. We also have the option to return either the full entities, just a selection of fields, or even search results taken straight from a search server.

Contextual filters set in the view will automatically turn into the arguments of the GraphQL field. Let's see an example:

This field represents a simple view showing nodes. It has one contextual filter - Content: Authored by - so the corresponding input type consists of just one field:

and its row type is set to Entity (as pictured on the screenshot above), so the result will be of type NodeArticle:

We can use the filed like this:

Views integration is a pretty broad topic, so in the next post we might try to cover it in more detail. There are quite a few more interesting aspects like sorting, exposed filters, and attaching views to entities, so we'll focus on that in an attempt to fully answer Daniel's question. For those interested in the back-end side of things I'd recommend the great Extending GraphQL series by Philipp Melab. The first post that explains how to create fields is here: Extending GraphQL: Part 1 - Fields.

P.S. GraphQL Views is not stable yet. In fact, two issues were spotted and fixed in the process of writing this article. If you spot a bug please report it on github  or let us know in the #graphql channel at Drupal slack.

Other posts in the series

What our clients are saying