drunken monkey: The problems with config entity overrides

Planet Drupal - Fri, 2017/04/07 - 5:31pm

TL; DR: Config overrides seem very handy, but can be pretty problematic when used for config entities. If you are using them in this way, you should make very sure that there aren't any unintended side effects. And if you maintain a contrib module that defines a config entity type, you should make sure they're safe to use with config overrides.

Fair warning: This blog post is mainly written for developers. While, ideally, site builders who want to use configuration overrides should also understand the inherent problems they come with, I don't feel it's possible to really explain those problems without getting pretty technical.

What are config overrides?

If you're not familiar with Drupal 8's concept of configuration overrides, I suggest you quickly read up on it in the documentation on drupal.org. In short, it allows you to define overrides for configuration (who would have thought?) in your settings.php, making it easy to have different settings for different environments – very common, of course, if you have separate development or testing environments.

The way those overrides work should be properly understood, though: the overrides exist solely in the code, are read into a global variable at the start of the page request and then, when a configuration item is accessed during a page request that global variable is checked for overrides to that specific configuration item. In other words, the config values in the database (or the config storage, if that's not the database in your case) should never contain the overridden values, those should only ever be present in settings.php.

To facilitate this, config items when normally loaded are always read-only – that way, the overrides loaded with them won't be written back to the database. If you want to edit some config values, you need to explicitly load the config item with \Drupal::configFactory()->getEditable('your_config.name'); to obtain a writable copy – which then will come without any overrides. This ensures that, as said before, no overrides will be written back to the storage.

Then what's the problem?

While this getEditable() requirement for editing configuration works pretty well, there is one big problem: this requirement, and whole "read-only" system, is just not there for config entities! When you load a config entity, even though it's basically just a config item with a class, it will always be writable – there isn't even a way to explicitly get a read-only version. There is loadOverrideFree() on ConfigEntityStorage, which you should absolutely use when making any chances to a config entity – but who really knows that? (I didn't, and I hope for reasons of vanity that I'm not the only one.)

The smart people working on Drupal Core of course quickly realized this. Their solution: on admin pages (which are already categorized as such to allow having an "admin theme"), where entities are usually edited, always load the override-free version of the entity for the route controller. That way, the edit will really only affect the values in the storage, and the overrides won't be touched at all. This leads to a slight UX WTF, but is generally a good solution, which works in a lot of cases. The problem, though, is that it's far from working for all of them. Also, since it's working in many cases, we might feel it's less urgent to point this potential problem out to contrib module developers and site builders.

So, what problems remain?

Nice of you to ask! In my opinion, there are still several remaining problems. While I'm not sure that all of them could even be fixed in Core, and it might certainly take a while (as it nearly always does – especially for such complicated issues), I think the main thing is to at least educate developers and site builders alike that these problems exist, and maybe how to spot them. Here is an overview of all problems I'm aware of:

Config entities aren't always edited on admin pages

While applying this fix for all admin pages is certainly a good heuristic, I'm pretty sure there are contrib modules out there that save config entities on non-admin pages. When that happens, the user will (unlike anywhere else in Drupal 8) actually see the overridden values while editing, and they will be saved back to the database/storage, which we don't want.

So, if you maintain a contrib module, be sure to always load the override-free version of a config entity before editing and saving it! This especially applies to Drush commands, where the generic fix for admin pages of course doesn't apply – unless you explicitly request it otherwise, you'll always get the overridden entity there.

Admin pages don't always load config entities just for editing

The reverse is also true: sometimes, admin pages will just show information about a certain config entity, not allow any editing. In this case, currently, the overridden values will not be displayed, potentially confusing users. In some cases, they'll not be able to see anywhere that the overridden values are actually applied correctly.

More of a problem, though, are other non-editing uses of config entities, which was one of the two main problems we faced in the Search API module (see Issue #2682369: Fix problems with overridden config entities): in our case, nearly all of the module's UI (except most searches) is actually on admin pages, and will therefore (as long as the config entity is loaded directly by the route controller – also a peculiar source of potential confusion, see next heading) use the override-free version. While this is great for the edit pages, it's disastrous for the other functionality available there – "Index now", "Clear indexed data", etc., would all use the entities without overrides. If you used config overrides to make the index read-only, or to attach them to a different search server, this would mean your production site's server could be corrupted or cleared by actions on your development site – not very good, in short.

Luckily, once you're aware of this problem, there's actually a pretty easy solution: you can just use the with_config_overrides parameter option in your MODULE.routing.yml file to get the overridden version of a config entity even on an admin page. That way, on pages where you want to do something else than edit/save the config entity, you'll get the correct version of the entity, with the effective values.

It's slightly more complicated on pages where you can both edit an entity and use it in some other way. In that case, simply choose one of the two to request via the route controller and then manually re-load the other version, with/without overrides, when appropriate.

Entities aren't always loaded by the route controller

It's important to note that the mentioned fix for admin pages is installed (please correct me here if I'm wrong) in the route controller. So, when the config entity in question is part of the URL (for instance, admin/structure/types/manage/<var>{node_type}</var>), it will (by default) be loaded without overrides, but loading it normally within a page callback or form builder method will yield the normal entity, with overrides. This is mostly not even a bug, but a feature: for most entity edit pages, the entity is in the URL, while (for instance) overview pages will do a bulk-load and get the overridden values.

However, in combination with the previous item, about displaying config entities on admin pages, it could lead to confusing situations for users: an overview page for the entities would use the overridden values, while clicking through to a "View" page for one of them would suddenly show the override-free version of that entity. And since (see the UX WTF above) we never actually show any indication in the UI about which values are overridden, the user could actually wonder which of them are the effective ones.

The really complicated problem

Up to now, the main problem was just being aware of the various problems that could occur. Once you're aware that they exist, they are all actually pretty easy to resolve – just see whether or not you save a config entity, and in either case make sure you load the appropriate version of it.

However, there is one last problem with overridden config entities, and this one is a real doozy – much too complex to put in a heading, for sure. I'd say that it will luckily only affect a minority of modules dealing with config entities, but where it strikes it's hard to spot, and might be even harder to fix. It's also what caused most of the work in the Search API issue mentioned above.

Let's take the Search API as the example and suppose you have an index with an overridden server: "server1" in the database, "server2" as the overridden value. Now, you edit the index and change something else – the description, for example. For editing, of course, the override-free entity version is used, all correct. Upon saving, though, the storage controller loads the previous entity version as the "original" – but this time with overrides. So, even though only the description was changed, from within hook_entity_update() and the entity's postSave() method it will look like the server was changed from "server2" to "server1". In this case, the Search API will remove all of the index's data from "server2" (where it should have remained) and initialize data structures for it on "server1" (where they won't be used), probably breaking all searches for that index to at least some extent (depending on backend).

Similar problems exist for "read-only" flags and other properties, and editing the actual property that is overridden of course leads to yet another set of problems. I'm happy to say that I'm confident we resolved all of these problems for the Search API (though, as mentioned before, I'd appreciate it if site owners who might be affected could thoroughly test this for their site, with the newest Beta release), but it's unfortunately very likely that there are other contrib modules that still have such problems, and might not even be aware of them.

The Core issue I created for this problem is this one: Issue #2744057: Inconsistencies when updating overridden config entities. However, I think it has actually centered more around the problem of reliably fixing the other problems listed above, by bringing the "immutable/editable" solution that's in place for normal config objects to config entities, too. (I might be mistaken, though – I frankly admit that the complexity of this issue gives me headaches.) Also important, sure, but it doesn't touch this last, actually hard problem, as far as I'm aware. (While the others are arguably also pretty hard to solve generically in Drupal Core, they are easy enough to work around in contrib modules using config entities, as long as you are aware of them.) I'm currently not even sure that a generic solution for this last problem is really feasible.

Therefore, it's all the more important for module developers, I think, to be aware that this problem exists and to carefully search their own code for places where something like this might happen. To quote swentel:

Damn, overrides are really not a safe thing at all.


I hope I could help at least some of you understand the complex problems with config entity overrides, and maybe in this way help discover and fix some bugs. In any case, many thanks to Alumei for first bringing this problem to my attention, patiently explaining it numerous times until I finally understood it, and even fearlessly tackling the Core issue to try and fix this for everyone else.

Image credit: showbiz kids


Liip: Advanced Drupal 8 Configuration Management (CMI) Workflows

Planet Drupal - Fri, 2017/04/07 - 1:59pm

After implementing some larger enterprise Drupal 8 websites, I would like to share some insights, how to solve common issues in the deployment workflow with Drupal 8 CMI.

Introduction to Drupal CMI

First of all, you need to understand, how the configuration management in Drupal 8 works. CMI allows you to export all configurations and its dependencies from the database into yml text files. To make sure, you never end up in an inconsistent state, CMI always exports everything. By default, you cannot exclude certain configurations.


If you change some configuration on the live database, these configurations will be reverted in the next deployment when you use

drush config-import

This is helpful and will make sure, you have the same configuration on all your systems.

How can I have different configurations on local / stage / live environments?

Sometimes, you want to have different configurations on your environments. For example, we have installed a “devel” module only on our local environment but we want to have it disabled on the live environment.

This can be achieved by using the configuration split module: https://www.drupal.org/project/config_split

What does Configuration Split?

This module slightly modifies the CMI by implementing a Config Filter (https://www.drupal.org/project/config_filter). Importing and exporting works the same way as before, except some configuration is read from and written to different directories. Importing configuration still removes configuration not present in the files. Thus, the robustness and predictability of the configuration management remains. And the best thing is: You still can use the same drush commands if you have at least Drush 8.1.10 installed.

Configuration Split Example / Installation Guide

Install config_split using composer. You need need at least “8.x-1.0-beta4” and > drush 8.1.10 for this guide.

composer require drupal/config_split "^1.0"

Enable config_split and navigate to “admin/config/development/configuration/config-split”

drush en config_split -y

Optional: Installing the chosen module will make the selection of blacklists / greylists way more easier. You can enable chosen only on admin pages.

composer require drupal/chosen "^1.0"

I recommend you to create an “environments” subfolder in your config folder. Inside this folder you will have a separate directory for every environment:

Now you can configure your environments:

The most important thing is, that you set every environment to “Inactive”. We will later activate them according to the environment via settings.php

Here is my example where I enable the devel module on local:

Activate the environments via settings.php

This is the most important part of the whole setup up. Normally, we never commit the settings.php into git. But we have a [environment]-settings.php in git for every environment:

settings.php (not in git) variables-dev.php (in git and included in the settings.php of dev) variables-live.php (in git and included in the settings.php of live) settings.local.php (in git and included locally)

You need to add the following line to the variables-[environment].php. Please change the variable name according to your environment machine name:

// This enables the config_split module $config['config_split.config_split.dev']['status'] = TRUE;

If you have done everything correctly and cleared the cache you will see “active (overriden)” in the config_split overview next to the current environment.

Now you can continue using

drush config-import -y drush config-export -y

and config_split will do the magic.

How can I exclude certain Config Files and prevent them to be overridden / deleted on my live environment?

The most prominent candidates for this workflow are webforms and contact forms. In Drupal 7, webforms are nodes and you were able to give your CMS administrator the opportunity to create their own forms.

In Drupal 8 webforms are config entities, which means that they will be deleted while deploying if the yml files are not in git.

After testing a lot of different modules / drush scripts, I finally came up with an easy to use workflow to solve this issue and give CMS administrators the possibility to create webforms without git knowledge:

Set up an “Excluded” environment

First of all, we need an “excluded” environment. I created a subfolder in my config-folder and added a .htaccess file to protect the content. You can copy the .htaccess from an existing environment, if you are lazy. Don’t forget to deploy this folder to your live system before you do the next steps.

Now you can exclude some config files to be excluded / grey-listed on your live environment:

webform.webform.* contact.form.*

Set the excluded environment to “Inactive”. We will later enable it on the live / dev environment via settings.php.

Enable “excluded” environment and adapt deployment workflow

We enable the “excluded” environment on the live system via variables-live.php (see above):

// This will allow module config per environment and exclude webforms from being overridden $config['config_split.config_split.excluded']['status'] = TRUE;

In your deployment workflow / script you need to add the following line before you do a drush config-import:

#execute some drush commands echo "-----------------------------------------------------------" echo "Exporting excluded config" drush @live config-split-export -y excluded echo "-----------------------------------------------------------" echo "Importing configuration" drush @live config-import -y

The drush command “drush @live config-split-export -y excluded” will export all webforms and contact forms created by your CMS administrators into the folder “excluded”. The “drush config-import” command will therefore not delete them and your administrators can happily create their custom forms.

Benefit of disable “excluded” on local environment

We usually disable the “excluded” environment on our local environment. This allows us to create complex webforms on our local machine for our clients and deploy them as usual. In the end you can have a mix of customer created webforms and your own webforms which is quite helpful.

Final note

The CMI is a great tool and I would like to thank the maintainers of the config_split module for their great extension. This is a huge step forward making Drupal 8 a real Enterprise CMS Tool.

If you have any questions, don’t hesitate to post a comment.



Third & Grove: Calling Drush from Another Drush Command

Planet Drupal - Fri, 2017/04/07 - 8:30am
Calling Drush from Another Drush Command josh Fri, 04/07/2017 - 02:30

OSTraining: PHP Notices, Warnings and Errors on Your Drupal Site

Planet Drupal - Fri, 2017/04/07 - 7:00am

Websites will run into problems. Whether you're using Drupal or any other software, there will be problems at some point.

Drupal runs on PHP and when PHP has problems, it reports them to you. However, often these errors will appear on your site and will be visible to visitors:

However, often these errors will appear on your site and will be visible to visitors:


Freelock : Drupal grows up, loses its innocence

Planet Drupal - Fri, 2017/04/07 - 2:16am

Extreme irony: the person most responsible for making Drupal a mature, stable, long-term platform has been ejected from a leadership role for reasons that are not entirely clear. As a result, the Drupal community itself is going through a painful crisis.

The heart of the matter is painfully unclear: Is Larry "Crell" Garfield being ejected merely for "thought crimes?" Or is there actual evidence of some sort of abuse, that the extremely tolerant inner circle of the Drupal Association and leadership could not tolerate?

Drupal PlanetDrupal 8Drupal upgrade

Cocomore: Recap: Drupal Developer Days 2017 in Seville

Planet Drupal - Fri, 2017/04/07 - 12:00am

We did it again: The annual Drupal Developer Days are a fixed program point in our event list and took place this year in our second home in Seville. As a gold sponsor, we were especially pleased about the lively rush and exchange within the ever-growing Drupal community. Behind us is an exciting week full of exciting impressions, new and longlasting acquaintances, interesting workshops and many ideas for future projects. We have summarized our highlights here.



Drupalize.Me: MidCamp 2017: We Attended, We Sprinted, We Ate Donuts

Planet Drupal - Thu, 2017/04/06 - 7:30pm

Last week Joe and Blake attended MidCamp 2017 in Chicago. We taught Drupal 8 theming, ate donuts, attended a bunch of sessions, and sprinted on documentation.


Acquia Developer Center Blog: ACSF + Lift: How to Prepare for the Future of Content and Site Management

Planet Drupal - Thu, 2017/04/06 - 7:27pm

This is part one of a four part series on Acquia Cloud Site Factory and Acquia Lift.

You can no longer think of your website as a summary of what your organization has to offer; it's less about you -- your products, services, etc. -- and more about the experience you are creating for your customers via unique, personalized content. If you are to succeed, you need to break out of the traditional website experience and focus on the digital experience.

Tags: acquia drupal planet

Cheeky Monkey Media: Working Towards a Consistent Local Environment

Planet Drupal - Thu, 2017/04/06 - 6:16pm
Working Towards a Consistent Local Environment john Thu, 04/06/2017 - 16:16 The Situation That Prompted Change

The monkey house (aka Cheeky Monkey Media) has been expanding a lot during the past few years. Our team has been growing. We’ve been working on more and larger projects, and we’ve been branching out to include more services.

As with any growth spurt, we’ve had to deal with a few growing pains.

The Challenge that Initiated Action: Lack of Consistent Working Environments

One of the things we noticed during this transition period was that we didn’t have have the best process for ensuring all developers were working in a consistent local environment. As a result, some developers were using MAMP, others XAMP or WAMP, others were even installing PHP and mysql separately.


Acquia Developer Center Blog: ACSF + Lift: Managing Multilingual and Global Sites

Planet Drupal - Thu, 2017/04/06 - 5:45pm

This is part four of a four part series on Acquia Cloud Site Factory and Acquia Lift.

Tags: acquia drupal planet

Valuebound: How to Create Configurable Block programmatically In Drupal 8

Planet Drupal - Thu, 2017/04/06 - 12:55pm

Blocks are the boxes of content that can be displayed in regions like sidebar first, sidebar second, content. This functionality is provided by the Block module in drupal 8. Here describing to creating Configurable Block programmatically in drupal 8 by using the drupal console.

Configurable Block module & skeleton files created by following drupal console commands:

$drupal generate: module

By using drupal console to generate configurable block module it create configure_block.info.yml file like,…


heykarthikwithu: Create a slideshow using the ImageField Slideshow module

Planet Drupal - Thu, 2017/04/06 - 9:30am
Create a slideshow using the ImageField Slideshow module

The Imagefield Slideshow makes it easy to create a slideshow from just an image field.
Imagefield Slideshow module will provide a field formatter for image fields, so that if multiple images are uploaded to that particular image field and this formatter helps you to render those images as a slideshow.
For more details check out the Imagefield Slideshow project page.

heykarthikwithu Thu, 04/06/2017 - 13:00

Dave Hall Consulting: Remote Presentations

Planet Drupal - Thu, 2017/04/06 - 8:02am

Living in the middle of nowhere and working most of my hours in the evenings I have few opportunities to attend events in person, let alone deliver presentations. As someone who likes to share knowledge and present at events this is a problem. My work around has been presenting remotely. Many of my talks are available on playlist on my youtube channel.

I've been doing remote presentations for many years. During this time I have learned a lot about what it takes to make a remote presentation sucessful.


When scheduling a remote session you should make sure there is enough time for a test before your scheduled slot. Personally I prefer presenting after lunch as it allows an hour or so for dealing with any gremlins. The test presentation should use the same machines and connections you'll be using for your presentation.

I prefer using Hangouts On Air for my presentations. This allows me to stream my session to the world and have it recorded for future reference. I review every one of my recorded talks to see what I can do better next time.

Both sides of the connection should use wired connections. WiFi, especially at conferences can be flakely. Organisers should ensure that all presentation machines are using Ethernet, and if possible it should be on a separate VLAN.

Tips for Presenters

Presenting to a remote audience is very different to presenting in front of a live audience. When presenting in person you're able to focus on people in the audience who seem to be really engaged with your presentation or scan the crowd to see if you're putting people to sleep. Even if there is a webcam on the audience it is likely to be grainy and in a fixed position. It is also difficult to pace when presenting remotely.

When presenting in person your slides will be diplayed in full screen mode, often with a presenter view in your application of choice. Most tools don't allow you to run your slides in full screen mode. This makes it more difficult as a presenter. Transitions won't work, videos won't autoplay and any links Keynote (and PowerPoint) open will open in a new window that isn't being shared which makes demos trickier. If you don't hide the slide thumbnails to remind you of what is coming next, the audience will see them too. Recently I worked out printing thumbnails avoids revealing the punchlines prematurely.

Find out as much information as possible about the room your presentation will be held in. How big is it? What is the seating configuration? Where is the screen relative to where the podium is?

Tips for Organisers

Event organisers are usually flat out on the day of the event. Having to deal with a remote presenter adds to the workload. Some preparation can make life easier for the organisers. Well before the event day make sure someone is nominated to be the point of contact for the presenter. If possible share the details (name, email and mobile number) for the primary contact and a fallback. This avoids the presenter chasing random people from the organising team.

On the day of the event communicate delays/schedule changes to the presenter. This allows them to be ready to go at the right time.

It is always nice for the speaker to receive a swag bag and name tag in the mail. If you can afford to send this, your speaker will always appreciate it.

Need a Speaker?

Are you looking for a speaker to talk about Drupal, automation, devops, workflows or open source? I'd be happy to consider speaking at your event. If your event doesn't have a travel budget to fly me in, then I can present remotely. To discuss this futher please get in touch using my contact form.


Drupal blog: Drupal 8.3.0 is now available

Planet Drupal - Thu, 2017/04/06 - 12:03am

Drupal 8.3.0, the third minor release of Drupal 8, is now available. With Drupal 8, we made significant changes in our release process, adopting semantic versioning and scheduled feature releases. This allows us to make extensive improvements to Drupal 8 in a timely fashion while still providing backwards compatibility.

What's new in Drupal 8.3.0?

This new version includes improvements to authoring experience, site administration, REST support, and a stable version of the BigPipe module. It also includes new experimental modules to abstract workflow functionality, to lay out content types differently (e.g. articles are two column vs. press releases are three column), and to provide a general layout API for contributed modules. Many smaller improvements for the experimental Content Moderation module are included as well. (Experimental modules are provided with Drupal core for testing purposes, but are not yet fully supported.)

Download Drupal 8.3.0

New and improved content authoring

Drupal 8.3 ships with the updated CKEditor 4.6, which contains a host of improvements, including better paste from Word, and a new default skin that better matches Drupal's Seven administration theme. We've also added the AutoGrow plugin, to better utilize larger screen sizes.

Quick editing images now supports drag and drop.

Site building and administrative improvements

Drupal 8.3 ships with a redesigned admin status report, to better surface important status messages for your site.

Other incremental enhancements include:

  • The Views listing page is now standardized with other administrative listings.
  • The "Allowed HTML tags" input has been converted to a textarea, which significantly improves the usability of HTML filter configuration (and thereby makes it easier to configure filters securely.)
  • The Content and People overview pages' Views filters have been rearranged to match the column order of the listing, for more intuitive filtering.
  • Image fields are now limited to only accepting images, so that users on mobile clients are not offered a confusing and non-functional video upload option.
BigPipe for perceived performance

The Drupal 8 BigPipe module (now stable!) provides an advanced implementation of Facebook's BigPipe page rendering strategy, leading to greatly improved perceived performance for pages with dynamic, personalized, or uncacheable content. See the BigPipe documentation.

The core BigPipe improvements introduced in 8.3.0 are also utilized by the Sessionless BigPipe contributed module to use the same technique for serving the first (yet uncached) response to anonymous visitors.

Platform features for web services

Drupal 8.3 continues to expand Drupal's support for web services that benefit decoupled sites and applications, with bug fixes, improved responses, and new features. It is now possible to register users from the REST API, 403 responses now return a reason why access was denied, for greatly improved developer experience, and anonymous REST API performance has been increased by 60% when utilizing the internal page cache. The REST API also got a massive overhaul of its test coverage.

Experimental: Choose different form and view display layouts for your entity types

The new experimental Field Layout module provides the ability for site builders to rearrange fields on content types, block types, etc. into new regions, for both the form and display, on the same forms provided by the normal field user interface.

Field Layout also uses the new the Layout Discovery module, which provides an API for modules or themes to register layouts as well as five common default layouts. By providing this API in core, we help make it possible for core and contributed layout solutions to be compatible with each other. The following contributed modules already have development versions that support the new API:

Experimental: Content moderation improvements

The Content Moderation module included with Drupal 8.2.x is now accompanied by a more abstract Workflows module that took over the underlying workflow functionality and API. This allows additional modules to apply workflows that do not deal with content publication, such as for users or products. The Workflows module provides a user interface to package states with their transitions in a workflow, which Content Moderation can then apply to content, making configuration much easier.

There are several other smaller improvements. It is now possible to moderate non-translatable entity types, entity types without bundles, and any entity type that supports publishing (not just nodes). Moderation states are also reverted when revisions are reverted.

What does this mean to me? Drupal 8 site owners

Update to 8.3.0 to continue receiving bug and security fixes. The next bugfix release (8.3.1) is scheduled for May 3, 2017.

Updating your site from 8.2.7 to 8.3.0 with update.php is exactly the same as updating from 8.2.6 to 8.2.7. Modules, themes, and translations may need small changes for this minor release, so test the update carefully before updating your production site.

Drupal 7 site owners

Drupal 7 is still fully supported and will continue to receive bug and security fixes throughout all minor releases of Drupal 8.

Most high-priority migrations from Drupal 7 to 8 are now available, but the migration path is still not complete, especially for multilingual sites, so you may encounter errors or missing migrations when you try to migrate. That said, since your Drupal 7 site can remain up and running while you test migrating into a new Drupal 8 site, you can help us stabilize the Drupal 7 to Drupal 8 migration path! Testing and bug reports from your real-world Drupal 7 sites will help us stabilize this functionality sooner for everyone. (Search the known issues.)

Drupal 6 site owners

Drupal 6 is not supported anymore. Create a Drupal 8 site and try migrating your data into it as soon as possible. Your Drupal 6 site can still remain up and running while you test migrating your Drupal 6 data into your new Drupal 8 site. Core now provides migrations for most Drupal 6 data, but the migrations of multilingual functionality, references, and dates in particular are not complete. If you find a new bug not covered by the known issues with the experimental Migrate module suite, your detailed bug report with steps to reproduce is a big help!

Translation, module, and theme contributors

Minor releases like Drupal 8.3.0 include backwards-compatible API additions for developers as well as new features. Read the 8.3.0 release notes for more details on the improvements for developers in this release.

Since minor releases are backwards-compatible, modules, themes, and translations that supported Drupal 8.2.x and Drupal 8.1.x will be compatible with 8.3.x as well. However, the new version does include some changes to strings, user interfaces, and internal APIs (as well as more significant changes to experimental modules). This means that some small updates may be required for your translations, modules, and themes. See the announcement of the 8.3.0 release candidate for more background information.


Chocolate Lily: From Critique to Action: Transforming Drupal Through User-Centered Economics

Planet Drupal - Wed, 2017/04/05 - 9:20pm

As controversy swirls around the Drupal project leadership, community members are asking searching questions about the role of corporate influence in the project.

It's a good time to take a step back and look at broader questions of economic structure. What different economic models could help spur alternatives? What would an economic model look like where free software is owned and shaped by users as well as producers?

Fortunately, there are many dynamic and successful models to learn from.


Hook 42: Hook 42's Sessions, BoFs, and Events at DrupalCon Baltimore

Planet Drupal - Wed, 2017/04/05 - 8:08pm

Charm City here we come! Hook 42 is on their way to DrupalCon Baltimore!

DrupalCon Baltimore will be here before we know it, and the Hook 42 team is thrilled to be presenting four sessions this year! Aimee, Kristen Pol, and Kristin Bradham (K2) are ready to share their knowledge on Drupal 8 theming and view modes, worst practices, and migrations (alongside our friend Ryan Weal). 

Along with our sessions, we are helping organize and host a couple of other events! We are excited to be helping plan this year’s Business Summit, as well as continuing our sponsorship of Women in Drupal!



Acquia Developer Center Blog: Catch the Acquia Developer Experience Roadshow

Planet Drupal - Wed, 2017/04/05 - 8:01pm

Next week, Acquia will be launching the next-generation of open source developer tools and extensions to Acquia Cloud to better deliver high quality customer value.

This toolset empowers development teams to speed development and delivery velocity, without compromising quality or stability.

It includes a consistent set of code-building, testing, and integration tools, an automated process pipeline, and self-service access to production-like environments.

Tags: acquia drupal planet

Drupal Modules: The One Percent: Drupal Modules: The One Percent — Bricks (video tutorial)

Planet Drupal - Wed, 2017/04/05 - 7:44pm
Drupal Modules: The One Percent — Bricks (video tutorial) NonProfit Wed, 04/05/2017 - 12:44 Episode 25

Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll consider Bricks, a module which allows you to reorder the layout of your content through the UI.





Drupal @ Penn State: #thedropheartsyou

Planet Drupal - Wed, 2017/04/05 - 6:54pm

*Text from youtube description of below video

I love this community. If you do too, throw up a video introducing yourself to the Drupal community. Maybe say why you are involved and why you care so much about it. At the end of my video I challenge others to donate to causes that make the world a better place, open source or otherwise. The organization I am donating to today is http://ourrescue.org/


Acquia Developer Center Blog: Achieve & Acquia Spark Conversation around Machine Learning and Healthcare

Planet Drupal - Wed, 2017/04/05 - 6:12pm

For more than ten years, Achieve, an Acquia partner, has been bringing innovative portal solutions to healthcare providers with a user-centered focus. They make the most complex web development projects possible for companies like Children’s Hospital Los Angeles, Universal Music Group, Dexcom, The Recording Academy, and Scripps Translational Science Institute.

Tags: acquia drupal planet