Drupal Planet

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

Code Positive: Living Documentation For Your Drupal Project

April 11, 2017 - 2:25pm

Understanding the importance and benefits of living documentation, and why it can be critical for the continuity of your Drupal project.

 

 

Categories: Blogs

Drupal.org blog: Technical Advisory Committee Update

April 11, 2017 - 2:12pm

In October of last year the Technical Advisory Committee was formed to evaluate options for the developer tools we use on Drupal.org. The TAC consists of Angie Byron, Moshe Weitzman, and Steve Francia, acting as advisors to Megan Sanicki, the Executive Director of the Drupal Association.

The TAC's mandate is to recommend a direction for the future of our tools on Drupal.org. Megan will evaluate this recommendation, make a decision, and prioritize that work in the development roadmap of the Drupal Association engineering team.

What is the motivation behind looking at our developer tools now?

Close followers of the Drupal project will have noticed a trend in the last several months. From Dries' announcement of easy upgrades forever, to the revamp of the project application process, to the discussion about making tools for site builders— there is a unifying theme: broadening the reach of Drupal.

This is the same motivation that underlies this evaluation of our developer tools, and defines the goals and constraints of this initiative:

  • Adopt a developer workflow that will be familiar to the millions of developers outside our community
  • Preserve those unique elements of how we collaborate that have made the Drupal project so successful
  • If possible, leverage an expert partner who will help keeping our tooling up to date as open source collaboration tools continue to evolve

This means looking at a number of elements of the Drupal.org developer tool stack:

  • The underlying git service
  • How we tag and package releases
  • The contribution workflow (patch vs. pull request)
  • Project management workflows (the issue queues and tags)
  • CI integration
  • Maintainership
  • Project pages

If this looks like a tremendous undertaking - that's because it is. But there are some things we already know:

  • Drupal.org should continue to be the home of project pages
  • We should adopt a pull request workflow (and ideally we want to be able continue to accept patches as well, at least in the interim)
  • We should move contrib projects to semver, following core's lead
  • We want to preserve our familiar understanding of maintainership
  • We want to avoided forked code and forked conversation
  • We want to ensure the security team still has the tools they need to provide their service to the community

We also know that whatever decision is made, these changes cannot happen all at once. We'll need to take a progressive approach to the implementation, and focus on the parts of the stack that need to change together, so that we don't bite off more than we can chew.

What options are being considered?

At this time, the technical advisory committee is considering three options as they prepare to make their recommendation. The options are: GitLab, which offers both self-hosted and SaaS options; GitHub, which has recently been adding long-requested new features; or continuing to evolve our custom-built tooling, perhaps via issue workspaces.

GitLab

GitLab is the up-and-comer among Git hosts. GitLab can be self hosted using either their community or enterprise editions, or repositories can be hosted at GitLab.com. Though they recently stumbled, they have been notably open and transparent about their efforts to build a leading collaboration platform.

Gitlab is itself open-source, and has just released its 9.0 edition. GitLab has aggressively pursued the latest in development tools and workflow features, including project management tools, a ui for merge conflict resolution with in-line commenting and cherry-picking, docker registries for projects, integration with CI tools, and even Gitter, an IRC alternative for real-time collaboration.

GitHub

For quite some time, GitHub was the only real player in git repository hosting outside of rolling a custom solution (as we did for Drupal.org). Over the years it has become the home of many open source projects, and while most of those don't match the sheer scale of Drupal in terms of codebase size and number of contributors, there are certainly other major projects that have made their home there.

However, for all of its presence and longevity in the open source world, there are very few options for customizing its toolset for our needs, and we could no longer self-host our canonical repositories. The Drupal project would need to adapt to GitHub, rather than the other way around.
 

That said, in recent months, GitHub has been putting a strong focus on feature development, adding a number of new features including: automated licensing information,  protected branches, and review requests.

Custom tooling

We also must consider that the tools we have now are what built Drupal into what it is today. A great deal of work has gone into our existing developer tools over the years, and we have some unique workflows that would have to be given up if we switched over to a tooling partner. An idea like the issue workspaces proposal would allow us to achieve the goal of modernizing our tools, and likely do so in a way that is better tailored to those unique things about the Drupal workflow that we may want to preserve. However, doubling down on building our own tooling would come at a cost of continuing to be unfamiliar to the outside development community, and dependent on an internal team's ability to keep up with the featureset of these larger players.

Each of these three options would be a compromise between reaching outward and creating familiarity, and looking inward to preserve the Drupal specific workflows that have brought the project to where it is today.

What have we learned so far?

The TAC has conducted their own internal evaluation of the options as well as worked with Drupal Association staff in a two day exploratory session at the end of last year. The primary focus was to identify and triage gaps between the different toolsets in the following areas:

  • Migration effort
  • Project management
  • Code workflow
  • Project handling
  • Testing
  • Git Back-end/Packaging
  • Integrations beyond tools

This initial study also looked at the impact of each option on Drupal community values, and some key risks associated with each.

What comes next?

The next step for the TAC is to make their formal recommendation to the Executive Director of the Drupal Association. At that point, she will direct staff to validate the recommendation by prototyping the recommended solution. Once the recommendation has been validated, Megan will make a final decision and prioritize the work to fully implement this option, relative to other Drupal Association imperatives.

In the comments below, we would love to hear from the community:

What aspects of the way the Drupal community collaborates are the most important to you? What workflow elements do you feel need to be preserved in the transition to any new tooling option?

Categories: Blogs

InternetDevels: Drupal 8.3.0 is out: let’s take a look at its innovations

April 11, 2017 - 12:40pm

Drupal 8.3.0 is here — congrats, drupalers and customers!

Read more
Categories: Blogs

Cheppers blog: Sharing your data

April 11, 2017 - 10:20am

During our recent work on the GatherContent module, we received a feature request to allow other modules to modify the data we were saving. As this is not a very well known topic for non-contrib and non-core development, we decided to write a short blogpost about the different approaches in Drupal 7 and Drupal 8.

Categories: Blogs

La Drupalera (en): Problem installing composer on ubuntu with php versions

April 11, 2017 - 7:22am

The problem I raise is due to duality of php (cli), which means several versions of php are installed in our computer. In my case it had 5.3.29 and 5.5.9 versions. Composer needs php version > = 5.4.0
 

Install Composer curl -sS curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/usr/local/bin --filename=composer

I get the following error:

Some settings on your machine make Composer unable to work properly.

Make sure that you fix the issues listed below and run this script again:

The openssl extension is missing, which means that secure HTTPS transfers are impossible.

If possible you should enable it or recompile php with --with-openssl
 

Read more
Categories: Blogs

Agiledrop.com Blog: AGILEDROP: Other Top Drupal Blogs from March

April 11, 2017 - 5:24am
After our Drupal blogs from the previous month, it's always time for Drupal Blogs that were written by other authors. Here are the best Drupal Blogs from March. We'll begin our list with Alanna Burke and Drupal 7 Features vs. Drupal 8 Configuration Management. She praised the new configuration management system in Drupal 8 as one of its best pieces and explained, how it helps developers to export configuration into code compared to the old way of Features on Drupal 7. You can read the full blog post here. Our second choice is Drupal Serialization Step-by-Step by Mateu Aguiló Bosch, who… READ MORE
Categories: Blogs

Jeff Geerling's Blog: Using Ubuntu Bash in Windows Creators' Update with Vagrant

April 10, 2017 - 6:58pm

When Microsoft announced the Windows Subsystem for Linux, now seemingly rebranded as Bash on ubuntu on Windows, I was excited at the possibility of having Drupal VM (and other similarly command-line-friendly open source projects) work better in a Windows environment. But unfortunately, the Anniversary update's version of WSL/Ubuntu Bash was half-baked, and there were a lot of little issues trying to get anything cohesive done between the Windows and Ubuntu Bash environments (even with cbwin).

Then, a year or so later, Microsoft finally announced that tons of improvements (including upgrading Ubuntu in the WSL from 14.04 to 16.04!) would be included in the 'Creators Update' to Windows 10, dropping tomorrow, April 11.

Categories: Blogs

Chapter Three: Twig Concepts in Drupal 8 Themes - Part II

April 10, 2017 - 3:58pm

In the previous post I covered how to use the Component Libraries module and Twig to create simple reusable components, using an SVG sprite icon template as an example.

Part 2: Applying Twig Concepts to Write Better Code

When learning Drupal theming, overriding templates is one of the key topics of interest. It’s a simple thing. Copy the source template into your theme, modify it and clear the cache. Easy! However, doing just that over and over again, can lead to a mess of unmaintainable code.

Categories: Blogs

Acquia Developer Center Blog: Acquia Cloud CD Launches Today

April 10, 2017 - 10:00am

Today Acquia is pleased to announce the release of Acquia Cloud CD.

Acquia Cloud CD is a new service for development process and devops automation which makes life easier for teams working on the Acquia Cloud Platform. It's an evolution of our developer tools which we believe will help to accelerate code delivery and make life easier and more productive for teams.

Tags: acquia drupal planet
Categories: Blogs

Dries Buytaert: Next steps for evolving Drupal's governance

April 10, 2017 - 7:42am

The last time we made significant changes to our governance was 4 to 5 years ago [1, 2, 3]. It's time to evolve it more. We need to:

  • Update the governance model so governance policies and community membership decisions are not determined by me or by me alone. It is clear that the current governance structure of Drupal, which relies on me being the ultimate decision maker and spokesperson for difficult governance and community membership decisions, has reached its limits. It doesn't work for many in our community -- and frankly, it does not work for me either. I want to help drive the technical strategy and vision of Drupal, not be the arbiter of governance or interpersonal issues.
  • Review our the Code of Conduct. Many have commented that the intentions and scope of the Code of Conduct are unclear. For example, some people have asked if violations of the Code of Conduct are the only reasons for which someone might be removed from our community, whether Community Working Group decisions can be made based on actions outside of the Drupal community, or whether we need a Code of Conduct at all. These are all important questions that need clear answers.

I believe that to achieve the best outcome, we will:

  1. Organize both in-person and virtual roundtables during and after DrupalCon Baltimore to focus on gathering direct feedback from the community on evolving our governance.
  2. Refocus the 2-day meeting of the Drupal Association's Board of Directors at DrupalCon Baltimore to discuss these topics.
  3. Collect ideas in the issue queue of the Drupal Governance project. We will share a report from the roundtable discussions (point 1) and the Drupal Association Board Meeting (point 2) in the issue queue so everything is available in one place.
  4. Actively solicit help from experts on diversity, inclusion, experiences of marginalized groups, and codes of conduct and governance. This could include people from both inside and outside the Drupal community (e.g. a leader from another community who is highly respected). I've started looking into this option with the help of the Drupal Association and members of the Community Working Group. We are open to suggestions.

In order to achieve these aims, we plan to organize an in-person Drupal Community Governance sprint the weeks following DrupalCon Baltimore, involving members of the Drupal Association, Community Working Group, the Drupal Diversity & Inclusion group, outside experts, as well as some community members who have been critical of our governance. At the sprint, we will discuss feedback gathered by the roundtables, as well as discussions during the 2-day board meeting at DrupalCon Baltimore, and turn these into concrete proposals: possible modifications to the Code of Conduct, structural changes, expectations of leadership, etc. These proposals will be open for public comment for several weeks or months, to be finalized by DrupalCon Vienna.

We're still discussing these plans but I wanted to give you some insight in our progress and thinking; once the plans are finalized we'll share them on Drupal.org. Let us know your thoughts on this framework. I'm looking forward to working on solutions with others in the community.

Categories: Blogs

Dries Buytaert: An apology to the Drupal community

April 9, 2017 - 9:10am

Last week Megan Sanicki, executive director of the Drupal Association, and I published a joint statement. In this blog post, I wanted to follow up with a personal statement focused on the community at large.

I've talked to a lot of people the last two weeks, and it is clear to me that our decisions have caused much alarm and distress in our community. I feel this follow-up is important even though I know it doesn't undo the hurt I've caused.

I want to deeply apologize for causing grief and uncertainty, especially to those in the BDSM and kink communities who felt targeted by the turmoil. This incident was about specific actions of a single member of our community. This was never meant to be about sexual practices or kinks, so it pains me that I unintentionally hurt you. I do support you and respect you as a key part of our community.

Shortly after I started Drupal more than 15 years ago, I based its core values on openness and equality. Gender, race, religion, beliefs, sexuality ... all are welcome in our community. We've always had people with wildly different views and identities. When we walk into a sprint at DrupalCon, we've been able to put our opinions aside, open our laptops, and start collaborating. Diversity has always been a feature, not a bug. I strongly feel that this foundation is what made Drupal what it is today; a global family.

Serving a community as unique and diverse as Drupal is both rewarding and challenging. We've navigated through several defining moments and transitions in our history. I feel what we are going through now is another one of these defining moments for our culture and community. In an excruciating but illuminating way this has shown some of what is best about our community: we care. I'm reminded that what brings us together, what we all have in common, is our love and appreciation of open-source software. Drupal is a positive force, a collective lifting by thousands and thousands, created and maintained by those individuals cooperating toward a common goal, whose other interests have no need to be aligned.

I want to help our community heal and I'm open to learn and change. As one of the next steps, I will make a follow-up post on improving our governance to a healthier model that does not place such sensitive decisions on me. I love this community, and recognize that the things we hold in common are more important than our differences.

(Comments on this post are allowed but for obvious reasons will be moderated.)

Categories: Blogs

Tech Rendezvous: Optimizing Bonita BPM

April 8, 2017 - 9:00pm
Categories: Blogs

Acquia Developer Center Blog: ES6 for Drupal Developers: Arrow Functions, Concise Methods, and Other Syntactic Features

April 7, 2017 - 6:16pm

Object structures and functions are possibly two of the most commonly utilized syntactic features in JavaScript, as they both have important roles in defining classes in object-oriented programming. In ES6, defining methods and functions has become much easier with the help of concise properties and methods, and especially arrow functions, which may help to limit the lines of code you have to write.

Tags: acquia drupal planet
Categories: Blogs

drunken monkey: The problems with config entity overrides

April 7, 2017 - 12: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.

Coda

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

Categories: Blogs

Liip: Advanced Drupal 8 Configuration Management (CMI) Workflows

April 7, 2017 - 8:59am

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.

Example:

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.

 

Categories: Blogs

Third & Grove: Calling Drush from Another Drush Command

April 7, 2017 - 3:30am
Calling Drush from Another Drush Command josh Fri, 04/07/2017 - 02:30
Categories: Blogs

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

April 7, 2017 - 2: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:

Categories: Blogs

Freelock : Drupal grows up, loses its innocence

April 6, 2017 - 9:16pm

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
Categories: Blogs

Cocomore: Recap: Drupal Developer Days 2017 in Seville

April 6, 2017 - 7:00pm

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.

 

Categories: Blogs

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

April 6, 2017 - 2: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.

Categories: Blogs

Pages