Drupal Planet

Subscribe to Drupal Planet feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 21 hours 48 min ago

OSTraining: How to Use the New Media Module Features in Drupal

February 23, 2018 - 03:35

Since the release of Drupal 8.4 in late 2017, Drupal has contained new media handling features.

For many years, Drupal has shipped with almost no media handling. This was the most commonly requested feature whenever we did Drupal training.

In this tutorial, we'll walk you through how to use Drupal's new media options. We'll update this post as soon as Drupal 8.5 is available.

Elevated Third: WATCH E3 Takeaways: Drupal 8 Works for SaaS

February 23, 2018 - 02:29
WATCH E3 Takeaways: Drupal 8 Works for SaaS WATCH E3 Takeaways: Drupal 8 Works for SaaS Zach Ettelman Thu, 02/22/2018 - 12:29

In this edition of E3 Takeaways Business Development Strategist, Zach, talks Drupal 8 and why its flexible workflows, ability to integrate, and internationalization suite of modules work so well for the SaaS industry.



Hello there, I'm Zach Ettelman, Business Development Strategist here at Elevated Third. Today I'm going to talk about why Drupal is a good fit for software as a service companies. 


Takeaway #1: The old adage "content is king" is not dead and that means companies are still having to create a ton of content. With so many content cooks in the kitchen that means there are many approval layers to even get the smallest piece of content onto your site. Thanks to Drupal's content authorization workflow, we can personalize and customize it to meet the needs of your team. 


Takeaway #2: In today's digital world, virtually every SaaS organization is serving an international audience. Thanks to Drupal 8's internationalization suite of modules, we can now translate and localize content based on where the product's services are available for your offerings. 


Takeaway #3: SaaS companies leverage a multitude of tools in their digital arsenal to get daily business operations done, including CRM, marketing automation tools, and inventory management tools. Drupal 8 specifically is built API first making it easy to handle all these third-party integrations. Thanks to contributed modules and custom modules, we can keep up with your daily business operations and connect them to your digital website. 

Need more about Drupal 8? Download our D8 whitepaper. 

Download asset

Hook 42: January Accessibility (A11Y) Talks

February 23, 2018 - 01:42

In January, we were happy to have Ashley Bischoff as our guest speaker. Ashley talked about embracing plain language for better accessibility. Ashley is an accessibility expert and copy editor for The Paciello Group.

Writing reports and documentation is nothing new for many of us — we write them all the time. But even though we may do our best to write clearly, those who receive our reports and documentation might not be as familiar with accessibility as we are.

At the end of the day, no matter how technically correct a document may be, our words won't do much good if those who are reading them can't understand what we're trying to say. But writing isn't a black box — there are straightforward techniques that we can use to help ensure that our writing remains accessible.


OSTraining: Check Out the New Page Builder in Drupal 8.5!

February 23, 2018 - 01:42

The Release Candiate version of Drupal 8.5 was released today.

At this point we can see the final features that will be in the official release of 8.5 on March 7.

In this blog post, I'll give you an introduction to 3 of the main new features you can look forward to in 8.5.

This is "Day 1" post giving my quick reactions. We'll improve and expand on this post in the days before the final release.

Drupal blog: Drupal 8.5.0-rc1 is available for testing

February 23, 2018 - 01:28

The first release candidate for the upcoming Drupal 8.5.0 release is now available for testing. Drupal 8.5.0 is expected to be released March 7.

Download Drupal-8.5.0-rc1

8.5.x makes the Media module available for all, improves migrations significantly, stabilizes the Content Moderation and Settings Tray modules, serves dynamic pages faster with BigPipe enabled by default, and introduces the new experimental Layout Builder module. The release includes several very important fixes for workflows of content translations and supports PHP 7.2. Finally, 8.5.0-rc1 also includes the same security updates that are provided in 8.4.5.

What does this mean to me? For Drupal 8 site owners

Drupal 8.4.5, a security update and the final release of the 8.4.x series, has also been released this week. 8.4.x sites should update immediately to 8.4.5, but going forward, 8.4.x will receive no further releases following 8.5.0, and sites should prepare to update from 8.4.x to 8.5.x in order to continue getting bug and security fixes. Use update.php to update your 8.4.x sites to the 8.5.x series, just as you would to update from (e.g.) 8.4.2 to 8.4.3. You can use this release candidate to test the update. (Always back up your data before updating sites, and do not test updates in production.)

If you're an early tester who is already running 8.5.0-alpha1 or 8.5.0-beta1, you should update to 8.5.0-rc1 immediately. 8.5.0-rc1 includes security fixes (the same fixes that were released in Drupal 8.4.5).

Site owners should also take note of the fact that Drupal 8's support for PHP 5 will end in one year, in March 2019. PHP 7.2 is now the best recommended PHP version to use with Drupal 8.

For module and theme authors

Drupal 8.5.x is backwards-compatible with 8.4.x. However, it does include internal API changes and API changes to experimental modules, so some minor updates may be required. Review the change records for 8.5.x, and test modules and themes with the release candidate now.

For translators

Some text changes were made since Drupal 8.4.0. Localize.drupal.org automatically offers these new and modified strings for translation. Strings are frozen with the release candidate, so translators can now update translations.

For core developers

All outstanding issues filed against 8.4.x were automatically migrated to 8.5.x. Future bug reports should be targeted against the 8.5.x branch. 8.6.x will remain open for new development during the 8.5.x release candidate phase. The 8.5.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.

Your bug reports help make Drupal better!

Release candidates are a chance to identify bugs for the upcoming release, so help us by searching the issue queue for any bugs you find, and filing a new issue if your bug has not been reported yet.

Aten Design Group: Capturing Webhooks in Drupal 8

February 22, 2018 - 23:45

When using traditional APIs your application is typically requesting or pulling data from an external service, requiring a request for fresh data if you want to see recent changes. When using webhooks, that process is reversed: data is pushed from an external service in real-time keeping your application more up to date and your project running more efficiently. Here are a few examples:

  • Facebook - Receive an alert anytime a message is read
  • Stripe - Get alerted anytime a transaction comes through
  • Eventbrite - Get alerted if an event is created or updated

This of course is not an exhaustive list; you'll need to check the application you are integrating with to see if they are implementing webhooks. A Google search like "Stripe Webhooks" is a good first step.

Implementing a webhook in your application requires defining a URL to which your webhook can push data. Once defined, the URL is added to the application providing the webhook. In Drupal 8, controllers are a straightforward way to define a path. See the complete code for an example.

When the webhook is fired it hits the defined URL with applicable data. The data that comes from a webhook is called the payload. The payload is often a JSON object, but be sure to check the application’s documentation to see exactly what you should be expecting. Capturing the payload is straightforward using the Request object available in a controller like this:

public function capture(Request $request) {
  $payload = $request->getContent();

If your payload is empty, you can always try some vanilla PHP:

$payload = file_get_contents("php://input");
Inspecting the Payload

Debugging webhooks can be a bit challenging if you are developing locally because your local environment typically does not have a public URL. Further, some webhooks require that the receiving URL implement SSL, which can also present challenges locally. The following options can help you navigate debugging webhooks locally.


When capturing the payload, you can log it in Drupal. This option requires pushing your code up to a publicly available URL (a dev or staging environment).

$this->logger->debug('<pre>@payload</pre>', ['@payload' => $payload]);

Once you know what the payload looks like, you can copy it, modify it and make your own fake webhook calls locally using Postman. Feel free to checkout the importable Postman example in the repo.

Most Flexible

There is a utility called ngrok that allows you to expose your local environment with a publicly available URL; if you anticipate a lot of debugging it is probably worth the time to set up. Once ngrok is in place, you use the same logging method as above or use XDEBUG or something similar to inspect the payload. Ngrok will give you a unique, public URL which you can register, but which forwards to a server you have running on localhost. You can even use it with a local server that uses vhosts, such as yoursite.test with the command:

ngrok http -host-header=rewrite yoursite.test:80
Capturing and Processing the Payload

I'm a big fan of Drupal's queue system. It allows quick storage of just about anything (including JSON objects) and a defined way to process it later on a CRON run.

In your controller, when the payload comes in, immediately add the payload to your defined queue rather than processing it right away. This will make sure it is always running as efficiently as possible. You can of course process it right away if you choose to do so and skip the rest of this post.


Later when the queue runs, you can process the payload and do what you need to do, like create a node. Here is an example from the queue plugin (see ProcessPayloadQueueWorker.php for the full code):

 public function processItem($data) {   
   // Decode the JSON that was captured.
   $decode = Json::decode($data);
   // Pull out applicable values.
   // You may want to do more validation!
   $nodeValues = [
     'type' => 'machine_name_here',
     'status' => 1,
     'title' => $decode['title'],
     'field_custom_field' => $decode['something'],
   // Create a node.
   $storage = $this->entityTypeManager->getStorage('node');
   $node = $storage->create($nodeValues);

Once a queue is processed on CRON, the item is removed from the queue. Check out Queue UI module for easy debugging.


As when building any web application, security should be a major consideration. While not an exhaustive list, here are a few things you can do to help make sure your webhook stays secure.

  • Check your service's webhook documentation to see what authentication protocols they provide.
  • Create your own token that only your application and the webhook service know about. If that is not included, do not accept the request. See the authorize method in the controller.
  • Instead of processing the payload and turning it into a node, consider doing an API call back to the service using the ID from payload and requesting the data to ensure its authenticity.
  • You should consider sanitizing content coming from the payload.

Once you implement a Webhook, you'll be hooked! Here's all the code packaged up.

There are of course Drupal contrib modules around webhooks. I encourage you to check them out, but if you have specific use cases or complex needs, rolling your own is probably the way to go.

Commerce Guys: What's the plan for Commerce Kickstart on Drupal 8?

February 22, 2018 - 15:28

When Commerce Guys raised $5m in 2012 to grow Drupal Commerce and its ecosystem, we invested a big chunk of it in improving our user experience for both customers and administrators. With competing platforms like Shopify and Magento really coming into their own, we knew it was essential to provide a solid out-of-the-box experience. While Drupal Commerce was and is truly unique as an eCommerce framework natively extending and deeply integrated into a CMS, it turns out "flexibility" doesn't pitch nearly as well as a polished demo.

Investing in Drupal Commerce adoption

The product we developed to address that need is Commerce Kickstart, by far the most popular Drupal distribution ever built. I named it such to underscore the fact that we intended it to be an accelerator, both for Drupal Commerce's own adoption but also for newcomers wondering how to demo and develop with the software. At its height, we supported over 13,000 sites reporting in to drupal.org, and we continue to see new sites launch with it to this day.

Building the distribution proved to be a fantastic learning experience. The project drove improvements that worked their way into many contributed modules and Drupal core itself (e.g. contributions to Views, VBO, Entity Reference, Inline Entity Form). Its broad appeal also gave us a platform to invite Technology Partners to invest in the community in a way that Drupal hadn't seen before, many of whom continue to invest in Drupal today (e.g. Authorize.Net, PayPal, Avalara).

It was a ton of work, but Bojan, Jonathan, and their team accomplished everything we set out to do and more. With the release of Commerce 2.0 last fall, we now find ourselves regularly fielding the question, "What's the plan for Commerce Kickstart on Drupal 8?" The reality is, porting Commerce Kickstart as it is to Drupal 8 would be both too costly for our team today and a poor strategy for the way the Drupal market is developing. We're doing something new again.

Accelerating adoption today

Another frequent question we field is, "Why does Drupal Commerce require Composer?" Composer is often highlighted as a barrier to Drupal 8 adoption, and I can understand why. I always felt the same way about drush. I had a UI; why did I need a CLI? I had my process and never had to battle the command line to make sure drush worked, was up to date, and did what I expected. I always felt that way ... until I buckled down and learned it. Now I can't imagine using Drupal without it.

I felt the same about Composer at first, but I was determined to learn how to use it as I learned Drupal 8 and modern PHP in general. I know I'm not the only person suffering from tool fatigue (cf. Dries ; ), so we're doing what we can to help you ease into using Composer on your own terms.

We started by releasing Ludwig last summer, a Drupal project that lets you manage Composer dependencies similarly to the familiar Libraries module. We also expanded and documented a Composer project template that lets you create a new Commerce 2.x site with composer create-project, and we then began planning how to let users customize a project template via the browser while prototyping a GUI for Composer.

With today's release of the new CommerceKickstart.com, developed in partnership with Acro Media (thanks to Shawn McCabe, Mike Hubbard, et al), we're taking the next step!

Commerce Kickstart for Drupal 8

What you'll find there is that Commerce Kickstart has been reimagined for Drupal 8 rather than rebuilt on Drupal 8. The quickest way to get up and running with Drupal Commerce today is not through a distribution as it was 6 years ago, it's through Composer. This is the tool for modern PHP developers, and we see prioritizing Composer while also making it simpler to use as essential to growing Drupal Commerce adoption both from without and within the Drupal community.

While still in its infancy, CommerceKickstart.com presents a form that lets you construct a Composer JSON file ready-made to support Commerce 2.x and the contributed modules you specify. Module categories include payment and shipping providers, product catalog and search tools, data migration, and more. As with Commerce Kickstart 2.x, it features Technology Partners whose modules we have integrated into Commerce 2.x, and we expect the selection to continue expand.

Future plans for the tool include clarifying and improving the tool's usability, adding additional modules and Technology Partners, and evolving it to continue to lower the barrier to entry for new Composer users. If you give it a whirl, we'd love to hear your ideas as well in the Commerce Kickstart issue queue.

Appnovation Technologies: Simple website approach using a Headless CMS: Part 3

February 22, 2018 - 15:00
Simple website approach using a Headless CMS: Part 3 This is the last post of my quick Headless journey, in the first one I approached the concept of Headless and presented some solutions like Drupal, GraphCMS, Contentful and Cockpit CMS. In the second one, I extended those concepts by detailing Cockpit CMS, mostly due to the simplicity of the admin interface and the way that we de...

Roy Scholten: Idea: a data & content modelling UX sprint

February 22, 2018 - 08:19
22 Feb 2018 Idea: a data & content modelling UX sprint

During this weeks UX meeting we explored what it would mean to redesign the core Field UI. It’s definately in need of an update.

Currently all mashed together in a couple of tabs on Field UI:

  • Data modelling – Define data types and storage formats for individual fields & their relationships
  • Content modelling – Compiling individual fields into appropriate content (entity) types and configuring the input form for creating content items
  • Display modelling – Configuring different ways to display these created content items

One of the first steps towards a new and improved user interface for Field UI would be to unbraid these different types of tasks. Take it apart and put it together again in more user friendly ways.

Would be nice to kick this off with some kind of (virtual) UX design sprint, no?

Tags Drupal content modeling drupalplanet

Lullabot: The Myth of the Forklift Migration and the Lipstick Redesign

February 22, 2018 - 07:19

As the digital landscape evolves, brands have to continuously give their website users richer experiences to stay competitive. They also have to consider their internal users who create and publish content to ensure their CMS actually does the job it was designed to do. This often requires migrating to new platforms that enable new functionality or redesigning a website so that it delivers the deep user experiences consumers expect.

For better or worse, website redesign combined with CMS re-platforming can be an enormous undertaking. As a result, one of the most common themes we hear during the sales process is the desire to change one major aspect of the site while leaving the others intact. This usually comes in one of two variants: 

  • “We want to migrate from [CMS A] to [CMS B] but we don’t want to change anything else on the site” (The “Forklift Migration”)
  • "We want to do a site redesign, but we don’t want to change anything on the backend” (The “Lipstick Redesign”)

With the instability of budgets and increasing pressure to show a return on investment visibly and quickly, it’s easy to understand why clients ask for these types of projects. Restricting scope means a faster turnaround and a smaller budget right? What’s not to love? Unfortunately, these projects rarely work out as planned. In this article, we will examine the problems with this approach and some solutions that may mean more upfront work but will result in a CMS implementation that pays greater dividends in the long term.

Redesigns Change Content

What can appear to be a simple design change can often have an enormous impact on back-end functionality and content structure. For instance, consider the following design change.


In the example above, the decision was made to begin showing author credits on articles. While this appears to be a simple addition to the design, it has a ripple effect that spreads into every aspect of the system. Some examples:

  • Content created prior to this will not have an author attached, so either that content will remain un-attributed or those authors will have to be added retroactively.
  • Will this just be a text field, or will an actual author entity be created to centralize author information and increase consistency? If the latter, what will this entity look like and what other functions will it have?
  • Will this author name be a clickable link which leads to an author profile page? If so, what is the design of that page, what information will it show, and how will that information be gathered?
  • Will authors be able to edit their own information in the CMS? If so, what is the process for getting those logins created? What access rights will those authors have? If the CMS is behind a firewall, how will they access it?

This is just a small portion of the questions that such a small change might evoke, especially when adding items to a design. Another common example is when a site’s navigation is changed as part of a redesign. Once again, depending on the implementation, this can have several side effects.

  • For sections that are added to the navigation, there will need to be appropriate content added or moved so that clicking on the navigation item doesn't result in no content.
  • For sections that are removed, the content associated with those sections will have to be reviewed in order to determine what sections it should move to, or if it should be archived. 
  • For more complex changes, some combination of the above may need to happen, and the more complex the changes, the more far-reaching the content review behind them.

An existing design is the embodiment of a million decisions, and changing that design means revisiting many of those decisions and potentially starting up the entire process again. This is why a “lipstick redesign” is rarely successful. If you multiply the seemingly simple design choices described above by 100 or more, you can see that most clients quickly come to realize that a more extensive upgrade is necessary.

Migrations change design

Similarly, migration between CMSes (or between versions of the same CMS) often involves content changes that have an impact on the design. This is because a site’s design is often a careful balance between the look and feel, theming system, and CMS-provided functionality.

As an example, every CMS has its own layout and theming system, and the capabilities of these systems can be radically different from CMS to CMS. A design optimized for one system’s advantages may be extremely difficult to implement in another. Even if you could build it, it may be difficult to maintain over time because the new CMS isn't built around the same paradigms as the previous ones. In these cases, it is usually cheaper (in both time and money) to adjust the design than to rebuild the needed functionality in the new system. 


This can even be a problem when doing major upgrades from one version of the same CMS to the next. A theme or module you relied on for layout or theming in Drupal 7 may not be available for Drupal 8, or it may have been deprecated and added to Drupal core. This means that the affected functionality will either have to be replicated to meet the existing design, or the existing design will have to change to work with the new functionality. Either way, there’s work to do.

If, as we said above, an existing design is like the embodiment of a million decisions, then cloning that design onto a new system means you have answers to all your questions, but they may be suboptimal ones in the new context. Given that, once you open the door to tweaks, you are opening a world of new questions and starting that process again whether you want to or not.

Functionality happens

In addition to the technical issues behind the these projects, there are organizational pressures that are commonly brought to bear as well. In the end, we always find that stakeholders will receive or create pressure to add new functionality on top of the forklift. The reality is that spending real money on a project that results in no functional improvements for end users is a very tough sell in any organization. Even if that approval does come, it very rarely sticks, and once new functionality gets introduced into the middle stages of a project, the impact on schedule and budget are always far greater than if they had simply been accounted for from the start.

Additionally, most re-platforming projects require a significant amount of time to go through planning, architecture, design, and implementation. During that time your business is not at a standstill, it is moving forward and developing new needs every single day. It is unrealistic to think that your entire business can pause while a migration is performed, and this is another reason why new features have a tendency to creep into projects that were originally envisioned to just forklift from one platform to another. New business needs always pop up at the most inconvenient times in projects like this.

In almost all cases, this new functionality will impact the design and content in ways that will return the affected components back to the design/revise/approve stage. This can be extremely time-consuming, as it often takes months or years just to get the initial designs approved in the first place. Additionally, if development has already started, it may need to be redone or adjusted, wasting valuable developer hours and affecting the schedule even more.

I know what you’re thinking. You’ve got this planned out all the way down the line and everyone has signed off on it. We have heard it a hundred times, and in the end, these plans always fall apart because as everyone sees the time and money being spent, they just can’t resist getting something more out of it than they planned for. When your scope, budget, and schedule are as limited as these projects tend to be, those additions can end up being much more costly than on other projects.

How to avoid these pitfalls

Having shown that these forklift projects don’t always proceed as originally envisioned, what can you do to prepare? Thankfully, there is a lot you can do to avoid these problems. 

Get your goals and priorities straight.

While a project is in planning and development, it is too easy to be swayed into adding or removing features based on an assumed “need” when they don’t actually add a lot of value. If someone comes in with a new idea, ask yourself “How will this help the site achieve its goals? Where does this fit in my priorities?” Sometimes an addition to the site’s functionality can help increase ease of use, other times you may look to give up some design elements that don’t really add value but will increase scope. Always weigh these decisions against your goals and priorities to make sure the functionality you’re building will have the highest possible impact. 

Know your content.

Perform a full content inventory before you begin; it’s an essential step in planning your migration. Without a content inventory, you won’t have the answer to questions like “What is the longest article we need to allow for?” or “How are our articles allocated into different topics and tags?” These questions come up all the time in the migration and redesign process, and having the answers at your fingertips can really help move things along. An inventory will also help to highlight content that is miscategorized, unused, or out of date. This allows you to start planning for how to deal with these items early rather than trying to force them to fit somewhere at the last minute.

Plan for added functionality from the beginning of your project.

This is best achieved by bringing all your teams together, discussing priorities, and building a wish list. With this list in hand, you can now have a discussion with potential vendors about what is and isn't doable within budget and schedule constraints. Typically the list will be required items (“We have to migrate from Drupal 7 to Drupal 8”, “We have to refresh the site’s design to make it more modern and mobile-friendly”) as well as additional functionality you’ll want to add as part of that process (“We need to improve the editorial experience around media management”, “We need a better way to organize our content that reflects real-world use cases”). 

Work with a vendor that can provide both design and development services

Many companies will get their designs done at a standard design firm, then bring those designs to a development agency for their site build. Unfortunately, most design agencies are not well-versed in CMS implementation as a concept, and especially not for the specific quirks that each individual CMS might bring to the table. This often results in designs that are difficult or even impossible to implement. Working with an agency that does both design and development ensures that your new theme can stand up to real-world implementation, and streamlines the inevitable process of tweaking the designs as changes occur throughout the project.

Be agile and prepare for the unexpected.

While everyone wants to know exactly what they’re going to get at the end of a year-long project, the fact is that real life always intrudes at just the wrong moment. This can come in the form of unplanned functionality from higher up the ladder, technical issues that turned out to be more complex than predicted, or even personnel changes within the organization. While there are things you can do to streamline these situations and make them easier (such as choosing a full-service agency as described above) to some extent you just have to embrace the chaos and accept that changes will always be happening, and you need to deal with them and roll with the punches. Working within an agile methodology can help with this, but we find that more often than not the key is more in the state of mind of the stakeholders than it is in any structure that they might apply to the project.


Whether you are embarking on your own “Forklift Migration” or “Lipstick Redesign”, it’s critical to recognize the inherent connection between your front-end design and back-end CMS functionality. Navigating the interplay between the two of these concerns can be tricky, especially in organizations where product and technology are the responsibility of separate teams with discrete management. 

Joachim's blog: Regenerating plugin dependency injection with Module Builder

February 22, 2018 - 04:52

Dependency injection is a pattern that adds a lot of boilerplate code, but Drupal Code Builder makes it easy to add injected services to plugins, forms, and service classes.

Now that the Drupal 8 version of Module Builder (the Drupal front-end to the Drupal Code Builder library) uses an autocomplete for service names in the edit form, adding injected services is even easier, and any of the hundreds of services in your site’s codebase (443 on my local sandbox Drupal 8 site!) can be injected.

I often used this when I want to add a service to an existing plugin: re-generate the code, and copy-paste the new code I need.

This is an area in which Module Builder now outshines its Drush counterpart, because unlike the Drush front end for Drupal Code Builder, which generates code with input parameters every time, Module Builder lets you save your settings for the generated module (as a config entity).

So you can return to the plugin you generated to start with, add an extra service to it, and generate the code again. You can copy and paste, or have Module Builder write the file and then use git to revert custom code it’s removed. (The ability to insert generated code into existing files is on my list of desirable features, but is realistically a long way off, as it would be rather complex, a require the addition of a code parsing library.)

But why stop at generating code for your own modules? I recently filed an issue on Search API, suggesting that its plugins could do with tweaking to follow the standard core pattern of a static factory method and constructor, rather than rely on setters for injection. It’s not a complex change, but a lot of code churn. Then it occurred to me: Drupal Code Builder can generate that boilerplate code: simply create a module in Module Builder called ‘search_api’, and then add a plugin with the name of one that is already in Search API, and then set its injected services to the services the real plugin needs.

Drupal Code Builder already knows how to build a Search API plugin: its code analysis detects the right plugin base class and annotation to use, and also any parameters that the constructor method should pass up to the base class.

So it’s pretty quick to copy the plugin name and service names from Search API’s plugin class to the form in Module Builder, and then save and generate the code, and then copy the generated factory methods back to Search API to make a patch.

I’m now rather glad I decided to use config entities for generated entities. Originally, I did that just because it was a quick and convenient way to get storage for serialized data (and since then I discovered in other work that map fields are broken in D8 so I’m very glad I didn’t try to make then content entities!). But the ability to save the generating settings for a module, and then return to it to add to them has proved very useful.

Tags: drupal code buildermodule builder

myDropWizard.com: Drupal core security update for SA-CORE-2018-001 (including Drupal 6!)

February 22, 2018 - 01:37

Today, there is a Critical security release for Drupal core to fix multiple vulnerabilities. You can learn more in the security advisory:

Drupal core - Critical - Multiple Vulnerabilities - SA-CORE-2018-001

What makes this release special, is that some of these issues also affect Drupal 6! So, we're also making a Drupal 6 Long-Term Support (D6LTS) release of Drupal core.

Drupal 6 core security update

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

The following vulnerabilities mentioned in the security advisory affect Drupal 6:

  • JavaScript cross-site scripting prevention is incomplete - Critical

  • jQuery vulnerability with untrusted domains - Moderately Critical

  • External link injection on 404 pages when linking to the current page - Less Critical

Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Drupal Console: Drupal Console 1.6.1

February 21, 2018 - 23:19

Drupal Console 1.6.1 is out. The latest release contains bug fixes. Also no longer required dependencies removed from the project and development dependencies added as suggested packages.

Acro Media: Drupal Commerce 2: How to Add a Payment Gateway

February 21, 2018 - 23:10

Drupal Commerce 2 comes with a payment gateway system that allows for all kinds of payment methods to be added into your ecommerce site. Many of the standards you're used to seeing, Authorize.net, PayPal, Stripe, etc., are already good to go. On top of that, Commerce 2 has a fantastic API making it easy for developers to connect new gateway plugins.

What if you also want to allow your customers to pick up their order in-store? Or maybe you want to accept email money transfers or some other manual payment method. No worries! Drupal Commerce 2 is so adaptive that setting up these methods is also easy to do.

In this Acro Media Tech Talk video, we user our Urban Hipster Commerce 2 demo site to show how you can add, and manage, your payment gateways. 

Its important to note that this video was recorded before the official 2.0 release of Drupal Commerce, and so you may see a few differences between this video and the current release. The documentation is also evolving over time.

Urban Hipster Commerce 2 Demo site

This video was created using the Urban Hipster Commerce 2 demo site. We've built this site to show the adaptability of the Drupal 8, Commerce 2 platform. Most of what you see is out-of-the-box functionality combined with expert configuration and theming.

More from Acro Media Drupal modules in this demo

Mediacurrent: Mediacurrent to Present 6 Sessions at Drupalcon Nashville

February 21, 2018 - 22:24

Selected sessions for Drupalcon Nashville have just been announced! Mediacurrrent will be presenting five sessions and hosting a training workshop. 

From exploring new horizons in decoupled Drupal to fresh perspectives on improving editorial UX and achieving GDPR compliance, check out what the Mediacurrent team has in store for Drupalcon 2018:

Mediacurrent: Mediacurrent to Present 5 Sessions at Drupalcon Nashville

February 21, 2018 - 22:24

Selected sessions for Drupalcon Nashville have just been announced! Mediacurrrent will be presenting five sessions and hosting a training workshop. 

From exploring new horizons in decoupled Drupal to fresh perspectives on improving editorial UX and achieving GDPR compliance, check out what the Mediacurrent team has in store for Drupalcon 2018:

Sooper Drupal Themes: Drupal 8 Release Candidate For All Products and Demos!

February 21, 2018 - 20:20
Drupal 8 SooperThemes: After nearly a year of work we're almost there! It has taken us twice as long as we originally estimated. Drupal 8 itself has had its delays so maybe there is no surprise that updating our complex Drupal 7 theming and drag & drop platform with 15 unique theme designs and 1000+ demo content items is delayed. We now have a feature-complete stable version or Release Candidate for all our products ready for you to test! Besides that, we just moved to a new server that has all the infrastructure upgrades in place for our Drupal 8 launch.Migrating 15 Demos With 1000+ Content Items

The past 6 weeks have been spent mostly on migrating all demo content and designs to the Drupal 8 framework. This work mostly consisted of copying, manually testing, and re-exporting pages, images, menu links, configuration etc. The glorious result of this painstaking work can be seen here: https://demo.sooperthemes.com/

Can I start using this on production?

Not just yet, we recommend to hold off for the stable release before taking this puppy to production! However, the RC1 will be easy to upgrade to the upcoming stable release so I suggest you can start building your Drupal 8 project using our theme or builder, report any issues on our support forum, and launch it when we launch our stable release.

Having spent the last year just coding away at the Drupal 8 product line I now have to quickly put on my documentation and marketing hat and start churning out content and documentation updates for the website. We will spend the coming 2-3 weeks to update our website and then immediately put out a stable release for all products.

What's Next?

Of course we won't get bored after completing this monumental update. To SooperThemes the D8 release is a major milestone that brings us to the next chapter in the life cycle of our business. After the Drupal 8 release we will start paying a lot more attention to documentation, customer support, and marketing. We're excited to now have a product that exceeds everyone's expectations both in capability and now compatibility. We're going to keep developing our products, and also work on making ourselves more known inside and outside the Drupal community. 

Get Testing!

If you're already on board with Sooperthemes.com you now have access to all Drupal 8 downloads in the Downloads page. If you want to help testing, or if you just want to get started with your Drupal 8 project head on over!

Open Source Contributions

Now that we have our core business covered with our Drupal 8 products, we're going to continue making live easier for the Drupal community at large with our awesome free theme and module contributions. We want to make the free version of our theme the best Drupal 8 and 7 theme on Drupal.org. Of course our premium theme will retain some features that will remain exclusive to our patrons but even if we slice the feature count in half we probably still have the most loaded, flexible theme on drupal.org. Since our free Glazed theme is also the default theme for our Glazed CMS Drupal distribution, we also intend on having the best looking distribution our on Drupal.org. Stay tuned for updates! 

Agiledrop.com Blog: AGILEDROP: Top 6 Drupal websites released in 2017

February 21, 2018 - 08:07
There have been many sites build in Drupal in the year 2017, so we have made a list of some example worth highlighting. Check them out.    First one on the list is a website of National Athletic Trainers' Association made by Skvare. You can read a case study here. NATA is the professional membership association for certified athletic trainers and others who support the athletic training profession.   We continue our list with a website of the University of Minnesota. The site was built by Palantir. They’ve written a case study, check it out here. The University of Minnesota has almost 70… READ MORE

Drupal.org blog: What's new on Drupal.org? - January 2018

February 21, 2018 - 04:34

Read our Roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community.

In January the Drupal Association kicked off the new year with our Winter Staff Retreat, where the whole organization came together to review the past 6 months and lay out our strategy for the new year. In addition to taking a big picture look at our upcoming priorities, we also made some great improvements this past month.

Before we dive into those, we'd like to welcome Dhanya Girish to the Drupal Association team. Her time has been generously sponsored by Zyxware and she joins us as a skilled engineer. Please welcome Dhanya!

Drupal.org Updates Celebrating Drupal's 17th Birthday

To celebrate the 17th birthday of Drupal, we've embedded a wonderful video on the home page, celebrating some of the incredible things that have been built with Drupal. Drupal has grown from being a dorm-room experiment to being the driver for some of the most powerful digital experiences on the web. We can't wait to see what the next 17 years bring.

Proposed new initiatives for collaboration with Core

The Drupal Association engineering team meets monthly with the Drupal Core committers to align our goals and ensure that we're on the same page about what the project needs moving forward. At the beginning of this year we outlined some new proposed initiatives that, in collaboration with Core, we believe could be a tremendous value to the project.

None of these initiatives can be accomplished quickly, nor can they be moved forward without the collaboration of key contributors and the core committers, but we strongly believe they will be important next steps for the future of Drupal.

Refresh of the Hosting Listings program

A major focus in January was the refresh of our hosting listings program. The new hosting listings now display all providers on the primary view, with a series of filters to help users find exactly the right hosting partner. This update also brings a much needed visual refresh to the listings. New filters and search facets will help end-users find the hosting partner that is right for their needs, industry, and budget, and will enable users to identify and support those platforms that support the project.

Promoting industry solutions in the marketplace

Over the last year, we've been focused on pushing a message about crafting the perfect solution for particular industries with Drupal. We link to this information off of the front page, but we've also added a contextual block in the sidebar that will appear whenever users filter the marketplace by the relevant industry.

These efforts are an ongoing part of better serving the various personas who come to Drupal.org. Look forward to hearing about even more changes on this front as we approach DrupalCon Nashville in April.

In-context issue tag explanations

One of the cornerstones of Drupal.org contribution and issue management is our issue tagging system. However, it's been difficult in the past to understand what each tag is used for, especially for tags that are carefully monitored and curated by project maintainers or the core committer team. We've enhanced the tagging system by providing in-context hover-states that describe what tags are used for.

Infrastructure Updates Implemented PerimeterX for increased protection from DDOS, crawlers, badbots etc.

Would you believe that Drupal.org is the target of a bad crawler or outright DDOS attack at least once every two months? The team does an incredible job reducing the impact on end users of Drupal.org, but to make that job easier, we've partnered with PerimeterX for bad bot protection integrated with our CDN. PerimeterX integrates closely with Fastly, our CDN, and so can provide intelligent logic and protection at the edge.

We're starting off using this system simply for greater introspection into the nature of traffic patterns and the attacks of bad actors. We're gradually enabling the protection as we tune the system for Drupal.org's unique needs. We want to thank PerimeterX for supporting the project, and for helping to make Drupal.org a better place for our community.

DrupalCI: Support for yarn-based core tests

We've added a yarn build-step plugin to DrupalCI, allowing us to support new testing types, including nightwatch javascript tests in core and contrib. We want to provide a special thanks to community contributors who helped: justafish, dawhener, and mile23.


As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who make it possible for us to work on these projects. In particular we want to thank:

  • PerimeterX - *NEW* Signature Technology Supporting Partner
  • publicplan - *NEW* Premium Supporting Partner
  • WebEnertia - *NEW* Premium Supporting Partner
  • Electric Citizen - *NEW* Classic Supporting Partner
  • Factorial - *NEW* Classic Supporting Partner
  • One Shoe - Renewing Classic Supporting Partner
  • DRUD - Renewing Classic Hosting Supporter

If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.

Follow us on Twitter for regular updates: @drupal_org, @drupal_infra