Planet Drupal

Syndicate content - aggregated feeds in category Planet Drupal
Updated: 35 min 33 sec ago

Code Positive: Living Documentation For Your Drupal Project

Tue, 04/11/2017 - 19:25
img src= width=940 height=230 alt=pickle jar title=Pickle jar typeof=Image class=image-style-rss-banner /hr /pUnderstanding the importance and benefits of living documentation, and why it can be critical for the continuity of your Drupal project./p hr /p /p p /p blog: Technical Advisory Committee Update

Tue, 04/11/2017 - 19:12
div class=field field-name-body field-type-text-with-summary field-label-hiddendiv class=field-itemsdiv class=field-item evenpimg alt=Workflow icon class=left height=238 src=/files/git-icon_0.png width=150 /In October of a href= rel=nofollowlast year the Technical Advisory Committee was formed/a to evaluate options for the developer tools we use on The TAC consists of a href= rel=nofollowAngie Byron/a, a href= rel=nofollowMoshe Weitzman/a, and a href= rel=nofollowSteve Francia/a, acting as advisors to a href= rel=nofollowMegan Sanicki/a, the Executive Director of the Drupal Association./p pThe TAC's mandate is to recommend a direction for the future of our tools on Megan will evaluate this recommendation, make a decision, and prioritize that work in the development roadmap of the Drupal Association engineering team./p h2What is the motivation behind looking at our developer tools now?/h2 pClose followers of the Drupal project will have noticed a trend in the last several months. From Dries' announcement of a href= rel=nofolloweasy upgrades forever/a, to the revamp of the a href= rel=nofollowproject application process/a, to the discussion about a href= rel=nofollowmaking tools for site builders/a— there is a unifying theme: broadening the reach of Drupal./p pThis is the same motivation that underlies this evaluation of our developer tools, and defines the goals and constraints of this initiative:/p ulliAdopt a developer workflow that will be familiar to the millions of developers outside our community/li liPreserve those unique elements of how we collaborate that have made the Drupal project so successful/li liIf possible, leverage an expert partner who will help keeping our tooling up to date as open source collaboration tools continue to evolve/li /ulpThis means looking at a number of elements of the developer tool stack:/p ulliThe underlying git service/li liHow we tag and package releases/li liThe contribution workflow (patch vs. pull request)/li liProject management workflows (the issue queues and tags)/li liCI integration/li liMaintainership/li liProject pages/li /ulpIf this looks like a tremendous undertaking - that's because it is. But there are some things we already know:/p should continue to be the home of project pages/li liWe should adopt a pull request workflow (and ideally we want to be able continue to accept patches as well, at least in the interim)/li liWe should move contrib projects to semver, following core's lead/li liWe want to preserve our familiar understanding of maintainership/li liWe want to avoided forked code and forked conversation/li liWe want to ensure the security team still has the tools they need to provide their service to the community/li /ulpWe 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./p h2What options are being considered?/h2 pAt this time, the technical advisory committee is considering three options as they prepare to make their recommendation. The options are: a href= rel=nofollowGitLab/a, which offers both self-hosted and SaaS options; a href= rel=nofollowGitHub/a, which has recently been adding long-requested a href= rel=nofollownew features/a; or continuing to evolve our custom-built tooling, perhaps via a href= rel=nofollowissue workspaces/a./p h3GitLab/h3 pGitLab 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 Though they a href= rel=nofollowrecently stumbled/a, they have been notably open and transparent about their efforts to build a leading collaboration platform./p pGitlab is a href= rel=nofollowitself open-source/a, and has just a href= rel=nofollowreleased its 9.0 edition/a. GitLab has aggressively pursued the latest in development tools and workflow a href= rel=nofollowfeatures/a, 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 a href= rel=nofollowGitter/a, an IRC alternative for real-time collaboration./p h3GitHub/h3 pFor quite some time, GitHub was the only real player in git repository hosting outside of rolling a custom solution (as we did for 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 a href= rel=nofollowmajor projects/a that have made their home there./p pHowever, 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 /  /p pThat said, in recent months, GitHub has been putting a strong focus on a href= rel=nofollowfeature development/a, adding a number of new features including: a href= rel=nofollowautomated licensing information/a,  a href= rel=nofollowprotected branches/a, and a href= rel=nofollowreview requests/a./p h3Custom tooling/h3 pWe 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 a href= rel=nofollowissue workspaces/a 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./p pEach 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./p h2What have we learned so far?/h2 pThe 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:/p ulliMigration effort/li liProject management/li liCode workflow/li liProject handling/li liTesting/li liGit Back-end/Packaging/li liIntegrations beyond tools/li /ulpThis initial study also looked at the impact of each option on Drupal community values, and some key risks associated with each./p h2What comes next?/h2 pThe 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./p pIn the comments below, we would love to hear from the community:/p pWhat 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?/p/div/div/div

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

Tue, 04/11/2017 - 17:40
div class=field field--name-field-preview-image field--type-image field--label-hiddendiv class=field__itemsdiv class=field__item evenimg src=/sites/default/files/public/blog_preview/new_features_in_drupal_8.3.0.png width=937 height=622 alt=Drupal 8.3.0 is out: let’s take a look at its innovations //div/div/divdiv class=field field--name-body field--type-text-with-summary field--label-hiddendiv class=field__itemsdiv class=field__item evenp style=text-align: right;emDrupal 8.3.0 is here — congrats, drupalers and customers!/em/p a href= more/a/div/div/div

Cheppers blog: Sharing your data

Tue, 04/11/2017 - 15:20
a href= img src= width=536 height=300 alt= class=image-style-cheppers-blog-teaser-mobile //a pDuring our recent work on a href= target=_blankthe GatherContent module/a, 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./p

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

Tue, 04/11/2017 - 12:22
div data-history-node-id=301 class=node node--type-article node--view-mode-rss ds-1col clearfix img property=schema:image src= width=650 height=433 alt=Problem installing composer on ubuntu with php versions typeof=foaf:Image class=image-style-max-650x650 /pThe 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.0br /  /p h2Install Composer/h2 pre code class=language-bashcurl -sS curl -sS | sudo php -- --install-dir=/usr/local/bin --filename=composer /code/pre pI get the following error:/p p dir=ltremSome settings on your machine make Composer unable to work properly./em/p p dir=ltremMake sure that you fix the issues listed below and run this script again:/em/p p dir=ltremThe openssl extension is missing, which means that secure HTTPS transfers are impossible./em/p p dir=ltremIf possible you should enable it or recompile php with --with-openssl/embr /  /p div class=field field--name-node-link field--type-ds field--label-hidden field__itema href= hreflang=en-x-simpleRead more/a/div /div Blog: AGILEDROP: Other Top Drupal Blogs from March

Tue, 04/11/2017 - 10:24
a href= src= //a 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… a href= MORE/a

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

Mon, 04/10/2017 - 23:58
div class=field field-name-body field-type-text-with-summary field-label-hiddendiv class=field-itemsdiv class=field-item even property=content:encodedpWhen Microsoft announced the Windows Subsystem for Linux, now seemingly rebranded as a href= on ubuntu on Windows/a, 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 a href= pThen, 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./p/div/div/div

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

Mon, 04/10/2017 - 20:58
pIn the a href= post/a I covered how to use the a href= Libraries/a module and a href= to create simple reusable components, using an SVG sprite icon template as an example./p h2Part 2: Applying Twig Concepts to Write Better Code/h2 pWhen 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./p

Acquia Developer Center Blog: Acquia Cloud CD Launches Today

Mon, 04/10/2017 - 15:00
div class=field field-name-field-blog-image field-type-image field-label-hiddendiv class=field-itemsdiv class=field-item evenimg typeof=foaf:Image class=img-responsive src= width=140 height=85 alt= //div/div/divdiv class=field field-name-body field-type-text-with-summary field-label-hiddendiv class=field-itemsdiv class=field-item even property=content:encodedpToday Acquia is pleased to announce the release of a href= Cloud CD/a. /p pAcquia 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./p/div/div/divdiv class=field field-name-field-blog-tags field-type-taxonomy-term-reference field-label-inline clearfixdiv class=field-labelTags:nbsp;/divdiv class=field-itemsdiv class=field-item evena href=/tags/acquia-drupal-planet typeof=skos:Concept property=rdfs:label skos:prefLabel datatype=acquia drupal planet/a/div/div/div

Dries Buytaert: Next steps for evolving Drupal's governance

Mon, 04/10/2017 - 12:42
pThe last time we made significant changes to our governance was 4 to 5 years ago [a href=, a href=, a href=]. It's time to evolve it more. We need to:/p ulliUpdate 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./li liReview 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./li /ulpI believe that to achieve the best outcome, we will:/p olliOrganize both in-person and virtual roundtables during and after DrupalCon Baltimore to focus on gathering direct feedback from the community on evolving our governance./li liRefocus the 2-day meeting of the Drupal Association's Board of Directors at DrupalCon Baltimore to discuss these topics./li liCollect ideas in the a href= queue of the Drupal Governance project/a. 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./li liActively 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./li /olpIn 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. /p pWe'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 Let us know your thoughts on this framework. I'm looking forward to working on solutions with others in the community./p

Dries Buytaert: An apology to the Drupal community

Sun, 04/09/2017 - 14:10
pLast week Megan Sanicki, executive director of the Drupal Association, and I published a href= joint statement/a. In this blog post, I wanted to follow up with a personal statement focused on the community at large./p pI'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./p pI 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./p pShortly 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. /p pServing 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: emwe care/em. 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./p pI 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./p pem(Comments on this post are allowed but for obvious reasons will be moderated.)/em/p

Tech Rendezvous: Optimizing Bonita BPM

Sun, 04/09/2017 - 02:00

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

Fri, 04/07/2017 - 23:16
div class=field field-name-field-blog-image field-type-image field-label-hiddendiv class=field-itemsdiv class=field-item evenimg typeof=foaf:Image class=img-responsive src= width=140 height=85 alt=javascript image title=javascript image //div/div/divdiv class=field field-name-body field-type-text-with-summary field-label-hiddendiv class=field-itemsdiv class=field-item even property=content:encodedpObject 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./p/div/div/divdiv class=field field-name-field-blog-tags field-type-taxonomy-term-reference field-label-inline clearfixdiv class=field-labelTags:nbsp;/divdiv class=field-itemsdiv class=field-item evena href=/tags/acquia-drupal-planet typeof=skos:Concept property=rdfs:label skos:prefLabel datatype=acquia drupal planet/a/div/div/div

drunken monkey: The problems with config entity overrides

Fri, 04/07/2017 - 17:31
div class=field field-name-field-image field-type-image field-label-hiddendiv class=field-itemsdiv class=field-item evenimg typeof=foaf:Image src= width=320 height=213 alt= title=Overrides – when to use which? //div/div/divdiv class=field field-name-body field-type-text-with-summary field-label-hiddendiv class=field-itemsdiv class=field-item even property=content:encodedpstrongabbr title=too long, didn't readTL; DR:/abbr/strong 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./p pstrongFair warning:/strong 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./p h2What are config overrides?/h2 pIf you're not familiar with Drupal 8's concept of configuration overrides, I suggest you quickly read up on it a href= the documentation on In short, it allows you to define overrides for configuration (who would have thought?) in your codesettings.php/code, making it easy to have different settings for different environments – very common, of course, if you have separate development or testing environments./p pThe 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 codesettings.php/code./p pTo 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 code\Drupal::configFactory()-gt;getEditable('');/code 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./p h2Then what's the problem?/h2 pWhile this codegetEditable()/code 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 codeloadOverrideFree()/code on codeConfigEntityStorage/code, 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.)/p pThe 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 a href= UX WTF/a, 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./p h2So, what problems remain?/h2 pNice 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:/p h3Config entities aren't always edited on admin pages/h3 pWhile 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./p pSo, 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./p h3Admin pages don't always load config entities just for editing/h3 pThe 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./p pMore of a problem, though, are other non-editing uses of config entities, which was one of the two main problems we faced in the a href= API module/a (see a href= #2682369: Fix problems with overridden config entities/a): 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./p pLuckily, once you're aware of this problem, there's actually a pretty easy solution: you can just use the codewith_config_overrides/code parameter option in your codeMODULE.routing.yml/code 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./p pIt's slightly more complicated on pages where you can emboth/em 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./p h3Entities aren't always loaded by the route controller/h3 pIt'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, codeadmin/structure/types/manage/lt;vargt;{node_type}lt;/vargt;/code), 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./p pHowever, 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./p h3The really complicated problem/h3 pUp 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./p pHowever, 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 a href= Search API issue mentioned above/a./p pLet'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 emwith/em overrides. So, even though only the description was changed, from within codehook_entity_update()/code and the entity's codepostSave()/code 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)./p pSimilar 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, a href=/blog/search_api_d8_releaseas mentioned before/a, I'd appreciate it if site owners who might be affected could thoroughly test this for their site, with a href= newest Beta release/a), 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./p pThe Core issue I created for this problem is this one: a href= #2744057: Inconsistencies when updating overridden config entities/a. 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./p pTherefore, 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 a href= swentel/a:/p blockquotepDamn, overrides are really not a safe thing at all./p/blockquote h2Coda/h2 pI 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 a href= 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./p psmallImage credit: a href= kids/a/small/p /div/div/div

Liip: Advanced Drupal 8 Configuration Management (CMI) Workflows

Fri, 04/07/2017 - 13:59
pAfter 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./p h2Introduction to Drupal CMI/h2 pFirst 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./p h3Example:/h3 pIf you change some configuration on the live database, these configurations will be reverted in the next deployment when you use/p p/ppre class=crayon-plain-tagdrush config-import/prep/p pThis is helpful and will make sure, you have the same configuration on all your systems./p h2How can I have different configurations on local / stage / live environments?/h2 pSometimes, you want to have different configurations on your environments. For example, we have installed a #8220;devel#8221; module only on our local environment but we want to have it disabled on the live environment./p pspan id=more-8866/span/p pThis can be achieved by using the configuration split module: a href= h3What does Configuration Split?/h3 pThis module slightly modifies the CMI by implementing a Config Filter (a href= 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 strongleast Drush 8.1.10 installed/strong./p h3Configuration Split Example / Installation Guide/h3 pInstall config_split using composer. You need need at least #8220;a href=; andstrong gt;/strong drush 8.1.10 for this guide./p p/ppre class=crayon-plain-tagcomposer require drupal/config_split ^1.0/prep/p pEnable config_split and navigate to #8220;admin/config/development/configuration/config-split#8221;/p p/ppre class=crayon-plain-tagdrush en config_split -y/prep/p pOptional: Installing the a href= module/a will make the selection of blacklists / greylists way more easier. You can enable chosen only on admin pages./p p/ppre class=crayon-plain-tagcomposer require drupal/chosen ^1.0/prep/p pI recommend you to create an #8220;environments#8221; subfolder in your config folder. Inside this folder you will have a separate directory for every environment:/p pimg class=alignnone wp-image-8869 size-full src= alt=Drupal 8 Configuration Management Folders //p pNow you can configure your environments:/p pimg class=alignnone wp-image-8867 size-full src= alt=Config Split in Drupal 8 Configuration Management srcset= 957w, 300w, 768w sizes=(max-width: 957px) 100vw, 957px //p pThe most important thing is, that you strongset every environment to #8220;Inactive#8221;./strong We will later activate them according to the environment via settings.php/p pimg class=alignnone wp-image-8870 size-full src= alt=Config Split settings with the Drupal 8 Configuration Management srcset= 781w, 300w, 768w sizes=(max-width: 781px) 100vw, 781px //p pHere is my example where I enable the devel module on local:/p pimg class=alignnone wp-image-8873 size-full src= alt=Dev Environment Example srcset= 949w, 300w, 768w sizes=(max-width: 949px) 100vw, 949px //p h4Activate the environments via settings.php/h4 pThis 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:/p p/ppre class=crayon-plain-tagsettings.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)/prep/p pYou need to add the following line to the variables-[environment].php. Please change the strongvariable name/strong according to your environmentstrong machine name/strong:/p p/ppre class=crayon-plain-tag// This enables the config_split module $config['']['status'] = TRUE;/prep/p pIf you have done everything correctly and cleared the cache you will see strong#8220;active (overriden)#8221;/strong in the config_split overview next to the current environment./p pNow you can continue using/p p/ppre class=crayon-plain-tagdrush config-import -y drush config-export -y/prep/p pand config_split will do the magic./p h2How can I exclude certain Config Files and prevent them to be overridden / deleted on my live environment?/h2 pThe most prominent candidates for this workflow are strongwebforms/strong and strongcontact forms/strong. In Drupal 7, webforms are nodes and you were able to give your CMS administrator the opportunity to create their own forms./p pIn Drupal 8 webforms are strongconfig entities/strong, which means that they will be deleted while deploying if the yml files are not in git./p pAfter 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:/p h3Set up an #8220;Excluded#8221; environment/h3 pFirst of all, we need an #8220;excluded#8221; 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#8217;t forget to deploy this folder to your live system before you do the next steps./p pimg class=alignnone wp-image-8874 size-full src= alt=Folders //p pimg class=alignnone wp-image-8877 size-full src= alt=Excluded srcset= 847w, 300w, 768w sizes=(max-width: 847px) 100vw, 847px //p pNow you can exclude some config files to be excluded / grey-listed on your live environment:/p p/ppre class=crayon-plain-tagwebform.webform.* contact.form.*/prep/p pimg class=alignnone wp-image-8876 size-full src= alt=Greylist Webform in Config Split srcset= 726w, 300w sizes=(max-width: 726px) 100vw, 726px //p pSet the excluded environment tostrong #8220;Inactive#8221;/strong. We will later enable it on the live / dev environment via settings.php./p h3Enable #8220;excluded#8221; environment and adapt deployment workflow/h3 pWe enable the #8220;excluded#8221; environment on the live system via variables-live.php (see above):/p p/ppre class=crayon-plain-tag// This will allow module config per environment and exclude webforms from being overridden $config['config_split.config_split.excluded']['status'] = TRUE;/prep/p pIn your deployment workflow / script you need to add the following line before you do a drush config-import:/p p/ppre class=crayon-plain-tag#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/prep/p pThe drush command #8220;strongdrush @live config-split-export -y excluded/strong#8221; will export all webforms and contact forms created by your CMS administrators into the folder #8220;excluded#8221;. The #8220;drush config-import#8221; command will therefore not delete them and your administrators can happily create their custom forms./p h3Benefit of disable #8220;excluded#8221; on local environment/h3 pWe usually disable the #8220;excluded#8221; 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./p h2Final note/h2 pThe CMI is a great tool and I would like to thank the maintainers of the a href= module/a for their great extension. This is a huge step forward making Drupal 8 a real Enterprise CMS Tool./p pIf you have any questions, don#8217;t hesitate to post a comment./p pnbsp;/p

Third Grove: Calling Drush from Another Drush Command

Fri, 04/07/2017 - 08:30
span property=schema:name class=field-name--titleCalling Drush from Another Drush Command/span span class=field-name--uid rel=schema:authorspan lang= about= typeof=schema:Person property=schema:name datatype= xml:lang=josh/span/span span property=schema:dateCreated content=2017-04-07T06:30:00+00:00 class=field-name--createdFri, 04/07/2017 - 02:30/span

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

Fri, 04/07/2017 - 07:00
pWebsites will run into problems.nbsp;Whether you're using Drupal or any other software, there will be problems at some point./p pDrupal 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:/p pHowever, often these errors will appear on your site and will be visible to visitors:/p

Freelock : Drupal grows up, loses its innocence

Fri, 04/07/2017 - 02:16
div class=g-plusone-wrapper style=margin: 0 1em 1em 1em;float:right g:plusone href= size=medium annotation=bubble width=250 /g:plusone/divdiv class=field field-name-body field-type-text-with-summary field-label-hiddendiv class=field-itemsdiv class=field-item evenpExtreme 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./p pThe 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?/p/div/div/divdiv class=field field-name-taxonomy-vocabulary-5 field-type-taxonomy-term-reference field-label-hiddendiv class=field-itemsdiv class=field-item evena href=/tag/drupal-planetDrupal Planet/a/divdiv class=field-item odda href=/tag/drupal-8Drupal 8/a/divdiv class=field-item evena href=/tag/drupal-upgradeDrupal upgrade/a/div/div/div

Cocomore: Recap: Drupal Developer Days 2017 in Seville

Fri, 04/07/2017 - 00:00
pWe 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./pp /p

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

Thu, 04/06/2017 - 19:30
div class=field field-name-body field-type-text-with-summary field-label-hidden text-content text-secondarydiv class=field-itemsdiv class=field-item evenpLast 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./p /div/div/divdiv id=comment-wrapper-nid-2833/div