Drupal Planet

KnackForge: How to update Drupal 8 core?

3 miesiące 1 tydzień hence
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

Amazee Labs: Defining work - Amazee Agile Agency Survey Results - Part 6

6 godzin 14 minutes ago
Defining work - Amazee Agile Agency Survey Results - Part 6

This is part 6 of our series processing the results of the Amazee Agile Agency Survey. Previously I wrote about team communication & process. This time let’s focus on defining work. Who is involved in defining work and which tools are essential for organising your work?

Josef Dabernig Tue, 12/12/2017 - 10:50 Defining work

When asked about who is involved in defining work, we asked about which roles would be included in different phases of the ticket process.

  • “Creating tickets” is performed by these roles ordered by a number of selections: “PM / PO Proxy”, “Any Developer”, “Lead Developer”, “Client / Product Owner”, “UX/Design” and finally “The entire team together”.

  • “Refining/grooming/specifying tickets” is performed mostly by “Lead Developer”, “Any Developer” and “PM / PO Proxy” rated equally high, then “Client / Product Owner” and “The entire team together” rated equally high and finally “UX/Design”.

  • “Estimating tickets” is done by “The entire team together” followed by “Lead Developer” or “Any Developer” rated equally often, then “UX/Design”, “Client / Product Owner” and finally “PM / PO Proxy.”

It looks like there is an apparent tendency for Developers or Lead Developers to be involved in all parts of defining the work. It also makes sense that Clients / Product Owners or the internal counterparts in the agency PM / PO Proxies do participate in defining the work but don’t participate in estimating.

For us at Amazee, having the entire team estimate is essential to make sure there is common knowledge about the problem space and that we can get multiple views to validate our understanding of the client’s requirements. Any of our developers can take a leadership position in a particular project, that person would then be tasked to specify tickets together with the Project Owner (PO) or the client directly, and get estimated by the team later on.

Survey contestants also shared some additional insights about defining work/tickets. I’d like to quote a few of them.

"We have in each team an estimation engineer, scrum master and an architect. Everyone is responsible for doing architectures and estimations, bit the QA goes through these roles. The scrum master is responsible for the 2 weekly process while also being part of the development team."

"Involvement across ticket lifespan evolves as project matures."

"Being the most verbose possible."

"You have not mentioned Acceptance Criteria. This is written in collaboration between our QA and Stakeholders client side, ideally the product owner."

"Again - depending on the project/the client and the PM. We had clients that created and defined tickets together with the PO at our side, so that they could be specified during planning and then estimated by the devs. Sometimes PM is doing it, and sometimes this is done by the lead dev (if PM/PO isn't able to do it). Estimation depends a bit on the time pressure and the team size. If possible we estimate with the whole team. But sometimes we only have the lead dev and the dev who is going to implement the feature estimate."

Organizing work 

We also asked which tools were how important when it comes to organizing work. As shown in the illustration above, the ones that had the most apparent tendency towards their importance were “Sprints”, “User stories”, “Acceptance criteria” and “Tasks”, whereas the graph looks more indifferent when it comes to “Epics”, “Definition of Done”, “Definition of Ready” and “Releases/Versions”.

For us at Amazee, two-week sprints are a crucial instrument for planning and deciding about the priorities of our work. We don’t use User Stories all the time but feel like they are a good way of allowing clients to explain their requirements to the team effectively. Acceptance criteria (AC) are a must for anything that the team will implement - this can be on the user story level or the task level. Our teams also follow a definition of done to make sure that everything is in the right place when it comes to browser testing or on which environment results should be available. Recently, we started using Epics to group requirements that we had earlier on put into components in Jira. This allows to easily track the progress per Epic which is a neat feature in Jira. Releases/Versions aren’t used too much in the teams I work with.

How do you define your work? Please leave us a comment below. If you are interested in Agile Scrum training, don’t hesitate to contact us.

Stay tuned for the next post where we’ll look at estimations.


Dries Buytaert: Accelerate Drupal 8 by funding a Core Committer

18 godzin 49 minutes ago

We have ambitious goals for Drupal 8, including new core features such as Workspaces (content staging) and Layout Builder (drag-and-drop blocks), completing efforts such as the Migration path and Media in core, automated upgrades, and adoption of a JavaScript framework.

I met with several of the coordinators behind these initiatives. Across the board, they identified the need for faster feedback from Core Committers, citing that a lack of committer time was often a barrier to the initiative's progress.

We have worked hard to scale the Core Committer Team. When Drupal 8 began, it was just catch and myself. Over time, we added additional committers, and the team is now up to 13 members. We also added the concept of Maintainer roles to create more specialization and focus, which has increased our velocity as well.

I recently challenged the Core Committer Team and asked them what it would take to double their efficiency (and improve the velocity of all other core contributors and core initiatives). The answer was often straightforward; more time in the day to focus on reviewing and committing patches.

Most committers don't have funding for their work as Core Committers. It's something they take on part-time or as volunteers, and it often involves having to make trade-offs regarding paying work or family.

Of the 13 members of the Core Committer Team, three people noted that funding could make a big difference in their ability to contribute to Drupal 8, and could therefore help them empower others:

  • Lauri 'lauriii' Eskola, Front-end Framework Manager — Lauri is deeply involved with both the Out-of-the-Box Experience and the JavaScript Framework initiatives. In his role as front-end framework manager, he also reviews and unblocks patches that touch CSS/JS/HTML, which is key to many of the user-facing features in Drupal 8.5's roadmap.
  • Francesco 'plach' Placella, Framework Manager — Francesco has extensive experience in the Entity API and multilingual initiatives, making him an ideal reviewer for initiatives that touch lots of moving parts such as API-First and Workflow. Francesco was also a regular go-to for the Drupal 8 Accelerate program due to his ability to dig in on almost any problem.
  • Roy 'yoroy' Scholten, Product Manager — Roy has been involved in UX and Design for Drupal since the Drupal 5 days. Roy's insights into usability best practices and support and mentoring for developers is invaluable on the core team. He would love to spend more time doing those things, ideally supported by a multitude of companies each contributing a little, rather than just one.

Funding a Core Committer is one of the most high-impact ways you can contribute to Drupal. If you're interested in funding one or more of these amazing contributors, please contact me and I'll get you in touch with them.

Note that there is also ongoing discussion in Drupal.org's issue queue about how to expose funding opportunities for all contributors on Drupal.org.

Metal Toad: Sluggish Drupal 8 Adoption Lags Even D6

21 godzin 15 minutes ago
Sluggish Drupal 8 Adoption Lags Even D6 Metal Toad Mon, 12/11/2017 - 18:49

We're just past the second anniversary of 8.0.0. To see how D8 is doing compared to prior releases, we put together the chart above, based on Drupal's usage stats page.

For versions 5.x, 6.x, and 7.x, each new release brought dramatically accelerated growth.

Comparatively, D8 has dropped off a cliff. Adoption is far below that of D7, and even behind D6.

Roy Scholten: Thanks to Dropsolid, my first Drupal contribution sponsor

1 dzień ago
11 Dec 2017 Thanks to Dropsolid, my first Drupal contribution sponsor

Creating time and space to do the work

DropSolid in Belgium are the first organisation to sponsor some of my time to work on Drupal core.

It is very liberating to set apart dedicated time for tackling bigger chunks of Drupal core work instead of sneaking in bits and pieces at the edges of the day.

In the time available I was able to:

Many thanks to Nick Veenhof for reaching out and to DropSolid for supporting my work to help design a better Drupal!

I’m open to more organisations sponsoring me to work on the ux and product side of Drupal core. If that is something you are interested in, let me know.

Tags drupalplanet

Ixis.co.uk - Thoughts: Last Month in Drupal - November 2017

1 dzień 1 godzina ago
November saw the Drupal Association bring us the Q2 2017 Financial state summary. We were provided with an update as to what is new on Drupal.org, this included information regarding the community page being given its own place to live, it has now been given a proper section with its own blog.

Spinning Code: A Process to create a Drupal 8 module’s Config

1 dzień 21 godzin ago

One of the best practices for Drupal 8 that is still emerging is how to create modules with complex deployable configuration. In the past we often abused the features module to do this, and while that continues to be an option, with Drupal 8’s vastly improved configuration management options and the ability to install configuration easily I have been looking for something better. I particularly want to build modules that don’t have unnecessary dependencies but I can still reliably include all the needed configuration in my project. And after a few tries I think I’ve struck on an effective process.

Let’s start with a quick refresher on installing configuration for a Drupal 8 module. During module installation Drupal will load any yaml files that match configuration patterns it already knows about that are included in your module’s config/install directory. In theory this is great but if you want to include configuration that comes with other modules you have to figure out what files are needed; if you want to include configuration from core modules you probably will need to find a fairly large collection files to get all the required elements. Finding all those files, and copying them quickly and easily is the challenge I set out to solve.

My process starts with a local development sandbox site that is just there to support this development work, and I create a local git repository for the site’s configuration (I don’t need to connect it to a remote, like Bitbucket or GitHub, or handle all of the site’s code since it’s just to support finding changes to config files). Once installation and any base configuration is complete I export the site’s config to the directory covered by the repo (here I used d8_builder/config/sync, the site itself was at d8_builder/pub), and make sure all changes in the repository are committed:

Now I create my module and a second repository just for it. The module’s repository is linked to a remote since this is the actual product I’m creating.

With that plumbing in place I can to make whatever configuration change I need included in the module. Lately I’ve been creating a custom moderation workflow with several user roles and edge cases that will need to be deployed on a dozen or so sites, so you’ll see that reflected below, but this process should work for just about any project with lots of interrelated configuration.

Once I have completed a set of changes, I export the site’s configuration again:  drupal config:export

Now git can easily show which configuration files were changed, added, or removed:

Next I use git, xargs, and cp to copy those files into your module (hat tip on this detail to Andy Gregorowicz):
git ls-files -om --exclude-standard --exclude=core.extensions.yml |  xargs -I{} cp "{}" pub/modules/custom/fancy_workflow/config/install/

Notice that I skip the core.extensions.yml file. If your module had dependencies you’ll still need to update your module’s info.yml file to list them.

These files are great except for one detail: they all start with the UUID for the sandbox site, which will cause break imports. So I hop into the module’s config/install directory and use sed to remove those lines:
sed -i '/^uuid/d' *

Now a quick commit and push of the changes to the module’s repo, and I’m ready to pull the module into other projects. I also commit the builder repo to ensure it’s easy to track any future changes.

This isn’t a replacement for tools like Configuration Installer, which are designed to handle an entire site, this is intended just for module development.

If you think you have a better solution, or that I’m missing something important please let me know.

DrupalEasy: DrupalEasy Podcast 200 - Ryan's Drumroll

1 dzień 22 godziny ago

Direct .mp3 file download.

The three original hosts of the DrupalEasy Podcast, Andrew Riley, Ryan Price, and Mike Anello take a look back at episode 1 of the podcast, the last 9 years of Drupal, and what the next 5 years may bring.

Discussion DrupalEasy News Sponsors
  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.
Upcoming events Follow us on Twitter 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.