Drupal

KnackForge: How to update Drupal 8 core?

Planet Drupal - 23 March 2018 - 10:01pm
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
Categories: Drupal

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

Planet Drupal - 7 hours 35 min 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.

Categories: Drupal

Pocket API

New Drupal Modules - 10 hours 59 min ago

The Pocket service allows users to manage a list of web pages that can be synchronized to a variety of devices and apps.

This module provides a client that can push URLs to Pocket, potentially allowing users of a Drupal site to connect their Pocket account and automatically receive newly published content. [Very much a work In progress.]

This module is not affiliated with Pocket or the Mozilla Corporation.

Categories: Drupal

Сontact Mail

New Drupal Modules - 17 hours 17 min ago
Categories: Drupal

PhpMail alter

New Drupal Modules - 17 hours 19 min ago
Categories: Drupal

Commerce PayTabs

New Drupal Modules - 9 December 2017 - 9:07pm

This module integrates PayTabs with Drupal Commerce.
This is an offsite payment gateway. It provides credit card payments only, so far.

Installtion instructions:
* You can install this module via Composer (recommended), or
* clone it from drupal.org Git repo, or
* Download the module from drupal.org

Make sure to enable the 'Telephone' core module after installtion since this gateway requiers a phone number. A telephone field is added to the customer profile created by commerce.
This module may use external libraries in its future versions.

Categories: Drupal

Freelock : A custom quantity price discount for Drupal Commerce

Planet Drupal - 9 December 2017 - 1:01pm

We're in the midst of a Commerce 2 build-out for a client, and a key requirement was to preserve their quantity pricing rules. With thousands of products, and different pricing rules for each one, they need the price for each item in the cart adjusted to the appropriate price for the quantity purchased. When validating our plan for Drupal Commerce 2, we stumbled upon some examples of a custom price resolver, and knew this would work perfectly for the need.

Drupal 8Drupal CommerceDrupal PlanetField API
Categories: Drupal

Buster

New Drupal Modules - 9 December 2017 - 6:49am

Appends a cache buster to URLs generated by the public stream wrapper so that they will be cache busted by CDNs etc. when the contents of the file changes.

Categories: Drupal

Drupal useful tools

New Drupal Modules - 9 December 2017 - 5:38am

Drupal useful tools is a collection of tools which help with and simplify site building and development.

Components Views:

Provides "Theme" option inside "Advanced" column in Views UI. This option was in Drupal 7 and not ported (#2362413: Where to find "Theme information" - template suggestions in Views UI).
Fixes twigs problem with displaying view's theme suggestions.

Categories: Drupal

Contact Onlinepbx

New Drupal Modules - 9 December 2017 - 1:06am
Categories: Drupal

Wim Leers: API-First Drupal — really!

Planet Drupal - 8 December 2017 - 1:54pm

This blog has been quiet for the last year and a half, because I don’t like to announce things until I feel comfortable recommending them. Until today!

Since July 2016, API-First Drupal became my primary focus, because Dries felt this was one of the most important areas for Drupal’s future. Together with the community, I triaged the issue queue, and helped determine the most important bugs to fix and improvements to add. That’s how we ended up with REST: top priorities for Drupal … plan issues for each Drupal 8 minor:

If you want to see what’s going on, start following that last issue. Whenever there’s news, I post a new comment there.

But enough background. This blog post is not an update on the entire API-First Initiative, it’s about a particular milestone.

100% integration test coverage!

The biggest problem we encountered while working on rest.module, serialization.module and hal.module was unknown BC breaks 1. Because in case of a REST API, the HTTP response is the API. What is a bug fix for person X is a BC break for person Y. The existing test coverage was rather thin, and was often only testing “the happy path”: the simplest possible case. That’s why we would often accidentally introduce BC breaks.

Hence the clear need for really thorough functional (integration) test coverage2, which was completed almost exactly a year ago. We added EntityResourceTestBase, which tests dozens of scenarios3 in a generic way4, and used that to test the 9 entity types, that already had some REST test coverage, more thoroughly than before.

But we had to bring this to all entity types in Drupal core … and covering all 41 entity types in Drupal core was completed exactly a week ago!

The test coverage revealed bugs for almost every entity type. (Most of them are fixed by now.)

Tip: Subclass that base test class for your custom entity types, and easily get full REST test coverage — 41 examples available!

Guaranteed to remain at 100%

We added EntityResourceRestTestCoverageTest, which verifies that we have test coverage for all permutations of:

  • entity type
  • format: json + xml + hal_json
  • authentication: cookie + basic_auth + anon

It is now impossible to add new entity types without also adding solid REST test coverage!

If you forget that test coverage, you’ll find an ASCII-art llama talking to you:

Good people of #Drupal, I present unto you the greatest method of all time. https://github.com/drupal/drupal/blob/8.5.x/core/modules/rest/tests/src/Functional/EntityResource/EntityResourceRestTestCoverageTest.php#L141 pic.twitter.com/TiWLPt7duH

— webcsillag (@webchick) December 8, 2017

That is why we can finally say that Drupal is really API-First!

This of course doesn’t help only core’s REST module, it also helps the contributed JSON API and GraphQL modules: they’ll encounter far fewer bugs!

Thanks

So many people have helped! In random order: rogierbom, alexpott, harings_rob, himanshu-dixit, webflo, tedbow, xjm, yoroy, timmillwood, gaurav.kapoor, Gábor Hojtsy, brentschuddinck, Sam152, seanB, Berdir, larowlan, Yogesh Pawar, jibran, catch, sumanthkumarc, amateescu, andypost, dawehner, naveenvalecha, tstoeckler — thank you all!5

Special thanks to three people I omitted above, because they’re not well known in the Drupal community, and totally deserve the spotlight here, for their impressive contribution to making this happen:

That’s thirty contributors without whom this would not have happened!

And of course thanks to my employer, Acquia, for allowing me to work on this full-time!

Next

What is going to be the next big milestone we hit? That’s impossible to say, because it depends on the chains of blocking issues that we encounter. It could be support for modifying and creating config entities, it could be support for translations, it could be that all major serialization gaps are fixed, it could be file uploads, or it could be ensuring all normalizers work in both rest.module & jsonapi.module

The future will tell, follow along!

  1. Backwards Compatibility. ↩︎

  2. Nowhere near 100% test coverage, definitely not every possible edge case is tested, and that is fine↩︎

  3. Including helpful error responses when unauthenticated, unauthorized or just a bad request. This vastly improves DX: no need to be a Drupal expert to talk to a REST API powered by Drupal! ↩︎

  4. It is designed to be subclassed for an entity type, and then there are subclasses of that for every format + authentication combination. ↩︎

  5. And this is just from all the per-entity type test issues, I didn’t look at the blockers and blockers of blockers. ↩︎

  • Acquia
  • Drupal
Categories: Drupal

cowsay

New Drupal Modules - 8 December 2017 - 9:56am
Categories: Drupal

Composerize

New Drupal Modules - 8 December 2017 - 9:10am

Provides a Drupal Console command which can generate a composer.json from your installed Drupal code base, which can be used to regenerate that code base by running composer install. Embrace the future!

To use, install Drupal Console. Then install this module, and run this command from inside your Drupal root:

$ drupal make:composer

This will output the contents of the generated composer.json. To save it to a file, pipe it:

Categories: Drupal

Paragraphs View Modes

New Drupal Modules - 8 December 2017 - 9:05am

This module contains a behavior plugin for the Paragraphs module. This plugin allows you to select a different view mode for the paragraph in the content add/edit form.

Categories: Drupal

LakeDrops Drupal Consulting, Development and Hosting: 3 minutes: Starting Drupal 8 project with a composer template

Planet Drupal - 8 December 2017 - 8:11am
3 minutes: Starting Drupal 8 project with a composer template Jürgen Haas Fri, 12/08/2017 - 17:11

Starting a new Drupal 8 project with the LakeDrops composer template only takes less than 3 minutes. And in that short period of time you're note only getting the code base but also a number of extra benefits:

Categories: Drupal

Colan Schwartz: Ægir Turns 10!

Planet Drupal - 8 December 2017 - 7:09am
Topics:  This blog post has been re-published from Aegir's blog and edited with permission from its author, Christopher Gervais.

My tenure with the Ægir Project only dates back about 7 or 8 years. I can’t speak first-hand about its inception and those early days. So, I’ll leave that to some of the previous core team members, many of whom are publishing blog posts of their own.

New look for www.aegirproject.org

As part of the run-up to Ægir’s 10-year anniversary, we built a new site for the project, which we released today. It will hopefully do more justice to Ægir’s capabilities. In addition to the re-vamped design, we added a blog section, to make it easier for the core team to communicate with the community. So keep an eye on this space for more news in the coming weeks.

Ægir has come a long way in 10 years

When I first tried to use Ægir (way back at version 0.3), I couldn’t even get all the way through the installation. Luckily, I happened to live in Montréal, not too far from Koumbit, which, at the time, was a hub of Ægir development. I dropped in and introduced myself to Antoine Beaupré; then one of Ægir’s lead developers.

One of his first questions was how far into the installation process I’d reached. As it turns out, he frequently asked this question when approached about Ægir. It helped him gauge how serious poeple were about running it. Back then, you pretty much needed to be a sysadmin to effectively operate it.

A few months, Antoine had wrapped the installation scripts in Debian packaging, making installation a breeze. By that point I was hooked.

Free Software is a core value

Fast forward a couple years to DrupalCon Chicago. This was a time of upheaval in the Drupal community, as Drupal 7.0 was on the cusp of release, and Development Seed had announced their intention to leave the Drupal community altogether. This had far-reaching consequences for Ægir, since Development Seed had been the primary company sponsoring development, and employing project founder and lead developer Adrian Rossouw.

While in Chicago I met with Eric Gundersen, CEO of DevSeed, to talk about the future of Ægir. Whereas DevSeed had sold their flagship Drupal product, OpenAtrium, to another company, Eric was very clear that they wanted to pass on stewardship of Ægir to Koumbit, due in large part to our dedication to Free Software, and deep systems-level knowledge.

Community contributions are key

Since then Ægir has grown a lot. Here is one of the more interesting insights from OpenHub’s Ægir page:

Very large, active development team Over the past twelve months, 35 developers contributed new code to Aegir Hosting System. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Open Hub.

To help visualize all these contributions, we produced a video using Gource. It represents the efforts of no less than 136 developers over the past 10 years. It spans the various components of Aegir Core, along with “Golden” contrib and other major sub-systems.

Of course, many other community members have contributed in other ways over the year. These include (but aren’t limited to) filing bug reports and testing patches, improving our documentation, answering other users’ questions on IRC, and giving presentations at local meetups.

The Future

The core team has been discussing options for re-architecting Ægir to modernize the codebase and address some structural issues. In the past few months, this activity has heated up. In order to simultaneously ensure ongoing maintenance of our stable product, and to simplify innovation of future ones, the core team decided to divide responsibilities across 3 branch maintainers.

Herman van Rink (helmo) has taken up maintenance of our stable 3.x branch. He’s handled the majority of release engineering for the project for the past couple years, so we can be very confident in the ongoing stability and quality of Ægir 3.

Jon Pugh, on the other hand, has adopted the 4.x branch, with the primary goal of de-coupling Ægir from Drush. This is driven largely by upstream decisions (in both Drupal and Drush) that would make continuing with our current approach increasingly difficult. He has made significant progress on porting Provision (Ægir’s back-end) to Symfony. Keep an eye out for further news on that front.

For my part, I’m pursuing a more radical departure from our current architecture, re-writing Ægir from scratch atop Drupal 8 and Ansible with a full-featured (Celery/RabbitMQ) task queue in between. This promises to make Ægir significantly more flexible, which is being borne out in recent progress on the new system. While Ægir 5 will be a completely new code-base, the most of the workflows, security model and default interface will be familiar. Once it has proven itself, we can start pursuing other exciting options, like Kubernetes and OpenStack support.

So, with 10 years behind us, the future certainly looks Bryght*.




* Bryght was the company where Adrian Rossouw began work on “hostmaster” that would eventually become the Ægir Hosting System.

Categories: Drupal

Amazee Labs: Amazee Agile Agency Survey Results - Part 5

Planet Drupal - 8 December 2017 - 6:51am
Amazee Agile Agency Survey Results - Part 5

Welcome to part five of our series, processing the results of the Amazee Agile Agency Survey. Previously I wrote about forming discovery and planning. This time let’s focus on team communication and process.

Josef Dabernig Fri, 12/08/2017 - 15:51 Team Communication

When it comes to ways how to communicate, the ones that got selected with the highest rating of “mostly practised” where “Written communication in tickets”, “Written communication via (i.e. Slack)” as well as “Group meetings for the entire team”. The options that most often got selected as “Not practised” where “Written communication in blog or wiki” and “Written communication in pull requests”.

For us at Amazee Labs Zurich, a variety of communication channels is essential. Regular 1-on-1 meetings between managers and their employees allow us to continuously talk about what’s important to either side and work on improvements. We communicate a lot via Slack where we have various team channels, channels together with clients related to projects, channels for work-related topics or just channels to talk about fun stuff. Each morning, we start with a short team stand-up for the entire company where we check in with each other, and that’s followed by a more in-depth standup for the Scrum teams where we talk about “What has been done, What will be done and What’s blocking us”. Written communication happens between the team and customers in Jira tickets. As part of our 4-eyes-principle peer review process, we also give feedback on code within pull requests that are used to ensure the quality of the code and train each other.

Process

We talked about iteration length in part 1 of this series. Now let’s look into how much time we spend on which things.

According to the survey, the majority of standups take 15 minutes, followed by 5 minutes and 10 minutes with a few ones taking up to 30 minutes.

This also reflects ours: we take 10 minutes for the company-wide stand up amongst 24 team members and another 15 minutes for the Scrum Team specific stand-ups.

For the review-phase, teams equally often selected 2 hours and 1 hour as the top-rated option followed closely by 30 minutes. 4 hours has been chosen by a few other teams, and the last one would be one day. For the retrospectives, the top-rated option was 30 minutes, followed by 1 hour. Much fewer teams take 2 hours or even up to 4 hours for the retrospective. For planning, we saw the most significant gap regarding top rated options: 30 minutes is followed by 4 hours and then 2 hours and 1 hours were selected.

In the teams I work with, we usually spend half a day doing sprint review, retrospective and planning altogether. Our reviews typically take 45 minutes, the retrospective about 1.5 hours and the planning another 30 minutes. We currently don’t do these meetings together with customers because the Scrum teams are stable teams that usually work for multiple customers. Instead, we do demos along with the clients individually outside of these meetings. Also, our plannings are quite fast because the team split up stories already in part of grooming sessions beforehand and we only estimate smaller tasks that don’t get split up later on as usually done in sprint planning 2.

When looking at how much time is being spent on Client work (billable, unbillable) and Internal work we got a good variety of results. The top-rated option for “Client work (billable)” was 50-75%, “Client work (unbillable)” was usually rated below 10% and “Internal work” defaulted to 10-25%. Our internal statistics match these options that have been voted by the industry most often.

I also asked about what is most important to you and your team when it comes to scheduling time? Providing value while keeping our tech debt in a reasonable place has been mentioned which is also true for us. Over the last year, we started introducing our global maintenance team which puts a dedicated focus on maintaining existing sites and keeping customer satisfaction high. By using a Kanban-approach there, we can prioritise timely critical bugs fixes when they are needed and work on maintenance-related tasks such as module updates in a coordinated way. We found it particularly helpful that the Scrum-teams are well connected with the maintenance-team to provide know-how transfer and domain-knowledge where needed.

Another one mentioned, “We still need a good time tracker.” At Amazee we bill by the hour that we work so accurate time tracking is a must. We do so by using Tempo Timesheets for Jira combined with the Toggl app.

How do you communicate and what processes do you follow? 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 defining work.

   
Categories: Drupal

Inline Advertising Entity

New Drupal Modules - 8 December 2017 - 6:18am

This module allows ad entities to be inserted within formatted text fields. Ad entities can be inserted every X number of paragraphs (<p>) using the field formatter.

Categories: Drupal

DevDocs

New Drupal Modules - 8 December 2017 - 5:37am
Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal