All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
Platform.sh customers should visit Safe from DrupalGeddon II aka SA-CORE-2018-02 for the specific steps we took to protect all our Drupal instances.
Earlier today, a critical remote code execution vulnerability in Drupal 6, 7, and 8 was disclosed. This highly-critical issue affects all Drupal 7.x and 8.x sites and most Drupal 6.x sites. It is trivially exploitable remotely by anonymous users on any site that exposes forms. It is very possible that your site exposes this vulnerability even if you are not aware of publicly accessible forms. You should update immediately any Drupal site you have to versions 8.5.1, 8.4.6, or 7.58, as appropriate.How to know if I am affected?
We are currently not aware of exploits of this vulnerability in the wild but this will undoubtedly change in the next few hours. Writing an exploit for this is trivial and you should expect automated internet-wide attacks before the day is out.
You should take immediate steps to protect yourself. This is as bad or worse than the previous highly-critical vulnerability SA-CORE-2014-05 that wreaked havoc three and a half years ago affecting more than 12 Million websites.
(Like, seriously, if you are reading this and you are not on Platform.sh or another provider that has put a platform-level mitigation in place, go update your sites and then come back and finish reading. Please. Platform.sh customers, see below for how to quickly update your site.)Where does the vulnerability come from?
The issue is in Drupal's handling of HTTP request parameters that contain certain special characters. These characters have special meaning in various places in Drupal, which if misinterpreted could lead to unexpected code paths being executed. The solution in the latest patch is to filter out such values before passing them off to application code.
Fortunately that same strategy can be implemented at the network layer. We have therefore applied the same logic to our Web Application Firewall to reject requests containing such values and deployed it across all projects in all regions, both Platform.sh Professional and Platform.sh Enterprise. That should protect all Drupal and Backdrop installations running anywhere on Platform.sh until they are upgraded.What to do?
You must update any and all Drupal instances with 6.x, 7.x and 8.x or Backdrop CMS, or verify that your hosting provider has put in place an automated mitigation strategy for this vulnerability. (All Platform.sh clients are safe; our new WAF now detects and blocks all variants of this attack). Even if your hosting provider has a mitigation strategy in place you should update immediately anyway.
Drupal 6.x is no longer maintained and unlike Drupal 7.x and 8.x it does not support automated updates. Third-party support providers may provide a patch but you should make plans to upgrade from Drupal 6 to Drupal 8 as soon as possible.
Hopefully you are using Composer for your Drupal 7.x and 8.x or Drush make for Drupal 7.x, as is the default with Platform.sh installations.To upgrade Drupal via Composer
To update your Drupal instances, and test nothing breaks you can follow the following simple procedure:
Verify that your composer.json file does not lock down drupal core to a minor version it should be something like "drupal/core": "~8.0". Then run:git checkout -b security_update composer update
Make sure that Drupal Core was updated to 8.5.1 or higher. (Check composer.lock using git diff). Commit and push your changes:
git commit –am ’fix for SA-CORE-2018-02’ && git push
On Platform.sh you can test that everything is fine on your automatically-generated staging environment, then merge to master putting this to production.
If you do not use Platform.sh you should test this either locally or your testing server; and follow your normal procedure to update your live sites.To upgrade Drupal using Drush Make
If you are using "Drush Make" style of dependency management, again, make sure you are not locked down to a vulnerable version such as:
projects[drupal][version] = 7.57
if it is, bump it up to 7.58. Then make a branch and update it:git checkout -b security_update drush pm-update
Commit the changes and push the result to Platform.sh for testing. Once you're satisfied nothing is broken merge back to master and deploy.To upgrade Drupal if you're checking Drupal core into your repository
If you're running a "vanilla" Drupal setup, with all of Drupal checked into Git, the easiest way to upgrade is using drush.
In your local environment, go to your Drupal document root and run:git checkout -b security_update drush pm-update drupal
Commit the changes and push the result to Platform.sh for testing. Once you're satisfied nothing is broken merge back to master and deploy. Afterward, look into how to migrate your site to a dependency managed configuration, preferably Composer. It will make maintenance far easier and more robust in the future.
As a reminder, your Platform.sh instances are not vulnerable as they are protected by our WAF. You should still apply the fixes ASAP.Damien Tournoud 28 Mar, 2018
An hour ago the SA-CORE-2018-002 critical Drupal vulnerability was disclosed. It was announced a week ago PSA-2018-001. That allowed us to gather our technical team and make sure we can develop and deploy a mitigation to all our clients immediately as the issue is made known.
If you're not running on Platform.sh, please stop reading this post and go update your Drupal site to version 8.5.1 / 8.4.9 / 8.3.8 / 7.58 right now. We're serious; upgrade first and ask questions later.
If you are running on Platform.sh: You're safe and can continue reading... then upgrade.
The vulnerability (also referred to as CVE-2108-7600) affects the vast majority of Drupal 6.x, 7.x and 8.x sites and allows arbitrary remote code execution that allow anonymous remote users to take full control of any affected Drupal site prior to 8.5.1 / 8.4.9 / 8.3.8 / 7.58.
The same issue is present in Backdrop CMS installations prior to 1.9.3.
If your Drupal site is not hosted on Platform.sh we encourage you to immediately update all your Drupal sites to 8.5.1 / 7.58 or to take your site offline. This is serious and trivially exploitable. You can expect automated attacks to appear within hours at most. If you are not on Platform.sh or another provider that has implemented a mitigation your site will be hacked. This is as critical as the notorious “DrupaGeddon” episode from three and a half years ago.
If you are hosting on Platform.sh...
Platform.sh is pleased to announce all Drupal sites hosted on all our regions and all our plans are automatically safe from this attack.
Platform.sh has many security layers that make attacks such as this much harder than on comparable services. Starting from our read-only hosts and our read-only containers, through our auditable and reproducible build-chain, and static-analysis based protective block.
In response to this latest vulnerability, we've taken two important steps:
We've added a new rule to our Web Application Firewall (WAF) on all regions and on all Enterprise clusters that detects and blocks requests trying to exploit this latest attack vector, even if your site hasn't been updated. (But still, please update.)
We are adding a check to our protective block to prevent deployment of affected Drupal versions. If you try to push an insecure Drupal version our system will flag it for you and warn you that you are pushing known-insecure code. Please update your code base as soon as possible.
As a client if you need any further assistance or want more information about the vulnerability, how it may affect you, and our mitigation strategy don’t hesitate to contact support. We have set our WAF to an especially aggressive stance for now and this may result in some users seeing a "400 Bad Request" message in some edge cases for legitimate traffic. If you experience this, please contact our support immediately they will be able to help.Ori Pekelman 28 Mar, 2018
myDropWizard.com: HIGHLY CRITICAL Drupal core security update for SA-CORE-2018-002 (including Drupal 6!)
Today, there is a Highly Critical security release for Drupal core to fix a Remote Code Execution (RCE) vulnerability. You can learn more in the security advisory:
As we noted last week, this issue also affects Drupal 6! So, we're also making a Drupal 6 Long-Term Support (D6LTS) release of Drupal core.Drupal 6 core security update
As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!
If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)
If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.
Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).
A remote code execution vulnerability exists within multiple subsystems of Drupal 7.x and 8.x. This potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could result in the site being completely compromised.
The security team has written an FAQ about this issue.Solution:
Upgrade to the most recent version of Drupal 7 or 8 core.
- If you are running 7.x, upgrade to Drupal 7.58. (If you are unable to update immediately, you can attempt to apply this patch to fix the vulnerability until such time as you are able to completely update.)
- If you are running 8.5.x, upgrade to Drupal 8.5.1. (If you are unable to update immediately, you can attempt to apply this patch to fix the vulnerability until such time as you are able to completely update.)
Drupal 8.3.x and 8.4.x are no longer supported and we don't normally provide security releases for unsupported minor releases. However, given the potential severity of this issue, we are providing 8.3.x and 8.4.x releases that includes the fix for sites which have not yet had a chance to update to 8.5.0.
Your site's update report page will recommend the 8.5.x release even if you are on 8.3.x or 8.4.x. Please take the time to update to a supported version after installing this security update.
- If you are running 8.3.x, upgrade to Drupal 8.3.9 or apply this patch.
- If you are running 8.4.x, upgrade to Drupal 8.4.6 or apply this patch.
This issue also affects Drupal 8.2.x and earlier, which are no longer supported. If you are running any of these versions of Drupal 8, update to a more recent release and then follow the instructions above.
This issue also affects Drupal 6. Drupal 6 is End of Life. For more information on Drupal 6 support please contact a D6LTS vendor.Reported By:
- Jasper Mattsson
- Samuel Mortenson Provisional Drupal Security Team member
- David Rothstein of the Drupal Security Team
- Jess (xjm) of the Drupal Security Team
- Michael Hess of the Drupal Security Team
- Lee Rowlands of the Drupal Security Team
- Peter Wolanin of the Drupal Security Team
- Alex Pott of the Drupal Security Team
- David Snopek of the Drupal Security Team
- Pere Orga of the Drupal Security Team
- Neil Drumm of the Drupal Security Team
- Cash Williams of the Drupal Security Team
- Daniel Wehner
- Tim Plunkett
The Drupal security team can be reached by email at security at drupal.org or via the contact form.
Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.
In just a few hours, the first serious critical security update for Drupal since "Drupalgeddon" will be released.
To make this update easier for DevShop users, we've pushed out a new release with 2 features that allow you to update your sites without ever leaving your web browser: "Update, Commit & Push" and "Tag a Release"."Commit & Push"
The "Update Drupal" button has been available in DevShop for some time, but now you can automatically commit the results by checking a box.
Acro Media recently launched a demo ecommerce site called Urban Hipster that exhibits the incredible range of out-of-the-box functionality you get with Drupal Commerce 2 (check it out here). To make the demo even more amazing, we've also created a “Plus” version that shows you what's possible with a bit of extra work.Some background
If you have an ecommerce business or have a product that you're trying to sell online, a product catalog could be just what you need. But if you produce your own product or you only have a few different products, a product showcase is actually a better way to demonstrate and sell your wares. It's like buying something on Amazon vs buying something on Apple: Amazon has an enormous list of products and all the pages look the same, whereas Apple has fully customized, unique pages for each item it sells.UH Axe builder product page
When you go to buy the UH Axe on the demo, you'll bring up a unique UH Axe builder product page in the Apple style. The page talks about what the UH Axe is and what its purpose is, and then you're able to choose the type of handle you want, the handle length, how heavy the axe head should be, whether you want a sheath, etc. By the time you add it to your cart, it has become a completely unique product with all the variations that you've chosen. But it exists and is configured the same way that any other product would.
It's actually a very similar configuration as the White and Wood Chair example on the demo; it just looks completely different.
The functionality behind a lot of the extra content is a module called Paragraphs. It's similar to Panels (which a lot of people use), but a bit simpler and more streamlined. It doesn't have the same breadth of functionality, but it's easier to work with, and it lets you do all those customizations like deciding where you want to put it on the page and so on. It looks very custom, but it is surprisingly configurable through the back end.
(A note of caution: while it's mostly out-of-the-box functionality, some of the more complex design elements did require a bit of custom code. That’s why it’s on the “Plus” demo.)
Keep in mind that it's not uncommon to have both ways of viewing the product: a fancy customized page as well as a more standard catalog. People can get to the product through either route.The bottom line
You can make awesome product pages through Drupal Commerce without a lot of effort.
More from Acro Media
- High Five video: Introducting the Urban Hipster (UH) Demo for Drupal Commerce 2
- High Five video: Digital Products and Recurring Subscriptions in Drupal Commerce 2
- Learn more about Drupal Commerce
- Learn more about Acro Media
If you'd like a personalized tour to discuss how Drupal Commerce fits into your ecommerce solution, give us a shout. We're happy to show and tell.
When it comes to considering what is the best CMS for a website, most don’t know up from down or Drupal from WordPress. At Mobomo, we consider ourselves Drupal experts and have guided many of our clients through a Drupal migration. Drupal is a content management system that is at the core of many websites. Drupal defines itself as “an open source platform for building amazing digital experiences.” These simple definitions make it sound easy, but it can in fact be very confusing. Listed below are some popular terms defined to help make the start of the migration process what it should be, simple and easy:
- Taxonomy – classification system. In WordPress, this system is very similar to the Categories you’ll find in that CMS.
- Vocabularies – a category, or a collection of terms.
- Terms – items that go inside a vocabulary.
- Tags – generic way to start classifying your content (this is the default).
- Menus – refers both to the clickable navigational elements on a page, and to Drupal’s internal system for handling requests. When a request is sent to Drupal, the menu system uses the provided URL to determine what functions to call.
- There are 4 types:
- There are 4 types:
- Content Type – Every node belongs to a single “node type” or “content type”, which defines various default settings for nodes of that type, such as whether the node is published automatically and whether comments are permitted. Common “Content Types” that just about any website would have include: blog post and page. Content types can have different fields and modules can define their own content types. The core Drupal Book and Poll modules are two examples of modules that define content types
- Fields – Elements of data that can be attached to a node or other Drupal entities. Fields commonly contain text, image, or terms.
- Node – A piece of content in Drupal, typically corresponding to a single page on the site, that has a title, an optional body, and perhaps additional fields. Every node also belongs to a particular content type, and can additionally be classified using the taxonomy system. Examples of nodes are polls, stories, book pages and images.
- Views – module that lets gives you a click and configure interface for running database queries. It can output the results in a variety of formats.
- Views Display – created inside of a view to display the objects fetched by the view in different manners.
- Module – Code that extends Drupal features and functionality (but doesn’t provide the HTML markup or styling of a theme). Drupal core comes with required (pre-installed) modules and some which are optional. Thousands of non-core or “contrib” modules are listed in the project directory.
- Core- features that are available within Drupal by default
- Custom- modules that are developed for a specific purpose that are not available within Drupal Core
- Contributed- after custom modules are created by Drupal developer, they are often made available to others within the Drupal community. There are more than 40,000 modules available today.
The post Key Drupal Taxonomy: Part 1 appeared first on .
Easy-to-guess passwords are all too often the means by which intruders gain unauthorised access. It's useful to be able to audit the passwords in use on your site - especially for user accounts with administrative privileges.
Ideally your Drupal site should have a robust (but user friendly) password policy (see my previous post: Password Policies and Drupal). However, this is not always possible.Tags: acquia drupal planet
Audience boosters, sales increasers, brand builders… All this and more applies to social networks! Drupal lets you easily integrate these unmatched promotion tools with your website. We have shared a great collection of Drupal social media integration modules in part 1 and 2.Read more
Every development team has a particular way of working. However, over the years I have noticed that there are a few common practices that, once documented and agreed upon, can help considerably in the team’s productivity. This article aims to serve as a template for new and existing projects.Assumptions
- The code is hosted on GitHub, BitBucket, or GitLab. What's important is that it supports pull requests.
- There is a ticketing system like Jira.
- There is a Continuous Integration tool that runs checks on pull requests.
Feel free to copy the following contents to an internal page in your wiki and start discussing and adjusting it with your team. It’s crucial that everyone in the team is willing to give these practices a go for a sprint and then evaluate and adjust during the next sprint retrospective.The README and CHANGELOG documents
Each repository must have a README file and may have a CHANGELOG document.
The README describes the project’s nature, lists requirements, and contains installation instructions. This document should contain everything that a developer needs to set up the project locally. If you are looking for a Drupal 8 specific one, here is an example.
The CHANGELOG is the living Release Notes document that allows anyone (developers, product managers, etc.) to understand exactly what changes are affiliated with a specific version of the project. This document is used when creating new releases to describe how should other teams update their current installations.Working with repositories
It’s useful to receive notifications every time that someone makes changes in a repository. We encourage you to subscribe to pull requests in order to start learning from everyone's code by clicking on the eye icon at the top right corner of each repository's homepage:undefined
Each project is different, so look at the repository’s README for instructions on how to set it up. If you find a repository which does not have a README, use this one as a template.Setting up your editor
You can use any editor to work on projects, but the one that offers the best integration with Drupal 8 at the moment is PHPStorm. Please take a few minutes to adjust PHPStorm to work with Drupal by reading this guide.Working on a ticket
Each ticket should have its own branch or branches. A branch name should be prefixed with the ticket number and a one or two-word description (for example, PROJECTNAME-123-foo). Here is how you can do it:cd /var/www/projectname git checkout master git pull origin master // Merge the current master into your branch. git checkout -b PROJECTNAME-123-foo // create and switch to a new branch 'PROJECTNAME-123-foo'
Once you are ready to push your changes, commit them to the branch with the following commands:git status // Shows your changes. git add [file] // Add any new or modified files. Supports patterns. git add --patch [file] // Better yet, review changes and stage your hunks. git diff --cached // Shows what is about to be committed. Review it carefully! git commit -m "PROJECTNAME-123 Description shorter than 50 characters"
Aim to make small commits which you can describe easily in your branch. The Erlang project has a good guide for writing good commit messages. If you want to add further info to the commit message, skip the -m parameter and use the default editor to set the title and the description of the commit message.
If your pull request alters the installation process or requires additional steps during the updating process, then adjust the README and CHANGELOG files accordingly.Writing and updating tests
Bug fixes and new features will be easier to peer review if the project's tests pass and the new code is covered by the tests. To get an idea of what sort of tests you may find, check out this article.Ok, ship it!
Once you have completed the above section, push the branch to Github:git push -u origin PROJECTNAME-123-foo // pushes your branch to the origin repository. PROJECTNAME-456 Fix video uploads only allowing mp4 undefined
Post a link to the pull request in the respective ticket and set it's status to "Needs Review" in order to track progress within the sprint.Peer reviews
The rule of thumb of peer reviews is that nobody can push to master branch. Everything should happen in pull requests which are reviewed and merged by the rest of the team.
After creating the pull request, prepare it for code review by following this guide. Once the pull request is ready for review, add reviewers to it through the web interface. Here is an example:undefined
When merging a pull request, follow the git standards with a short one-line message, a blank line, and paragraphs if needed. Here are two sample merge commits::[#pr-number] PROJECTNAME-123: Summary of the work being merged PROJECTNAME-123: Summary of the work being merged #pr-number
Finally, if this pull request completes the Jira ticket, then open it and change its status to the next one, which normally is "In QA", if you have a QA team, or "Done" if not.How to create a release
If you are distributing code to be deployed by other teams, then your team needs to keep a CHANGELOG which evolves along with the code. Review the section "The README and CHANGELOG documents" for an introduction.
Once the sprint has completed, it is time to create a release. Here are the steps to follow:
- If there is Continuous Integration, check that all tests pass and that there is the same or higher coverage that by the end of the previous sprint. If not, request the development team to fix this.
- Clone the repository where you want to create the new release.
- Create a new branch where you update the module's CHANGELOG by setting a version number at the top. If the module does not have a CHANGELOG file yet, create one using the example further above as a template.
- Developers indicate the level bump needed for each change by indicating it with the word "PATCH", "MINOR" or "MAJOR". This takes into account semantic versioning. So, depending on the changes that this release includes you increase either the PATCH, MINOR or MAJOR number for the next version.
- Once the pull request has been approved by the team, merge it.
- Create a tag: git tag -a [VERSION]
- Enter a description of what is being released on this tag.
- Push the tag to the repository: git push origin [VERSION].
Note: If you need to double check anything stated in the CHANGELOG while preparing the release, you may use the following command to retrieve all commits since the last release:git log --oneline --reverse --first-parent <insert last tag version here>.. | cut -c 9- git log --oneline --reverse --first-parent 1.0.0.. | cut -c 9- Ticket review guide
Here are a few tips for both sides: the individual working on the code and the people reviewing the pull request.For the pull request authors
- Make sure that the checked in code does what the ticket specifies.
- Use code sniffer to check and fix violations against Drupal’s coding standards.
- Add comments on the code as you see fit. This is useful not only for maintenance but also for peer reviewers.
- Make sure that your set of changes are covered by reasonable PHPUnit or Behat tests.
- Write a summary of what the code does and other related info such as screenshots. Include manual testing instructions if needed.
- If there is Continuous Integration, verify that all jobs pass.
- Verify that all the jobs executed by the Continuous Integration tool are passing. If there are failures, inspect the logs and notify the pull request’s author.
- Check that the code is easy to follow, respects Drupal’s Coding Standards, and is documented.
- If there are no tests, consider suggesting how they could be written.
- Look for performance and security risks. If you need tips, this guide offers great help.
Further tips can be found at The Peer Review How-To guide.Acknowledgments
This guide is the result of working with the following clients, which we thank deeply:
- The Biology Information and Technology team at the Iowa State University.
- The Draco team at Turner
- The MSNBC team at NBC Universal
Plus, the following folks at Lullabot:
Agiledrop.com Blog: AGILEDROP: What Marketing Tools and Services can Digital Agencies Integrate with Drupal 8
Last month, Matthew Grasmick sparked an important conversation surrounding Drupal's evaluator experience and our approach to documentation. It's become clear that we need to evolve our documentation governance model, in addition to formalizing best practices.
After receiving a tremendous amount of support and feedback, Matthew has continued the conversation by publishing a Documentation Initiative Proposal. Matt's proposal includes an evaluation of our current state, a picture of what success could look like, and what you can do to get involved. If you are passionate about improving Drupal's evaluator experience, I would encourage you to read Matt's proposal!
Drupal community nowadays is huge. Many people create stuff on Drupal.org, on Github, on Gitlab, wherever. Although Drupal.org makes a try to collect all the useful projects related to Drupal there are still some thing that cannot be done.
Drupal 8 uses Composer for package management. You can still install a Drupal 8 site by downloading a tarball, but we're all encouraged to use Composer to download Drupal core and other dependencies and to keep things up to date.
I'm just starting to get my head around how Drupal 8 works, so that I can reach the point where I can build new sites in 8.x rather than 7.x, and in time migrate existing sites over. Composer is part of the learning curve for this.Blog Category: Drupal Planet
There’s no foolproof way to get an unhackable Drupal site; there could always be an exploit that we don’t know about yet. But there are quite a few ways you can help reduce the risk of getting hacked. Let’s dive into some of the most common ways Drupal sites get hacked, and how to secure your site against these points of entry.Drupal Security Advisories
One of the most common ways to get hacked is to fall behind on known Drupal Security Advisories. Keeping up to date on the latest advisories is ultimately your first line of defense.
There are security advisories for both Drupal core and contributed projects with varying levels of security risk for the exploits found. You can sign up for the security email list to make things easier to keep track of. You can do this by logging into your Drupal.org account and editing your user profile. From there you can subscribe to the security newsletter on the newsletters tab. This list will email you soon after Drupal Security Advisories are released to the public, which helps quickly notify you or your team of possible exploits that need to be fixed.
You can use the Update Status module in Drupal core to see which sites are affected by these advisories. Then add an email address to send Security Alerts to daily or weekly. The Update Status alerts have also notified us in a few cases when the email list was backed up and took longer than it normally would.
Typically, Drupal core security advisories come out on the third Wednesday of the month unless it’s a highly critical update that needs to be patched sooner. Contrib project security advisories can come out on any given Wednesday.Read more
Two hundred and fifty people from across Germany and its neighbouring countries gathered in Essen on 17 and 18 March for DrupalCamp Ruhr, an event full of fresh discussions, workshops and presentations.Josef Dabernig Tue, 03/27/2018 - 08:41
The organizers decided to use the Open Space / Barcamp format that provided attendees with the option to pre-select certain sessions, but which could also be combined spontaneously with ad-hoc sessions that the participants had presented in the kick-off session. This meant that, in contrast to our regular conference experience, each of us got to quickly present our idea and were also able to adapt the camp’s schedule collaboratively before we started.
On each day, we would then agree upon the session plan. I ended up doing a planned session and two spontaneous ones. Before I start to explain what I talked about, I would like to highlight what stood out for me, in terms of discussions and themes at the conference:
Drupal 8 Distributions are ready
The initial panel discussion on distributions was a great moment to hear Distribution Maintainers and Leads talk about NP8, deGov, Thunder, Varbase, Commerce, OpenSocial and the Out of the Box initiative. It was great to see how much progress the distribution space has already made in Drupal 8. Distributions are an excellent way to highlight what Drupal can do and push for reusable, generic solutions. As I had worked 4 years with the epiqo team on Recruiter, one of the first Drupal 7 distributions, this was also a good reminder of the interesting challenges we face when creating products based on Drupal. In addition, the panelists also discussed how to best manage configurations using approaches like Features and Config Split.
Local Communities starting to collaborate
Another highlight was the discussions around aligning Drupal community efforts. The project, Local Community Distribution, was created to combine efforts in order to build and maintain local community websites. Representatives from various country initiatives were brought together, along with neighbouring countries such as France and the Netherlands, to share their codebases in the interim, which can be used as a solid foundation to get these projects off the ground. Details of the discussion can be found in this ticket.
Coincidentally, we recently started an initiative to create a new Drupal Switzerland website, so keep an eye on our group’s page or join one of the Zurich Meetups to follow the progress and join the discussion.
Communication moving from Slack to DrupalChat
Over the last few years, a large percentage of instant communication has moved from IRC to Slack because of superior usability. Unfortunately, Slack’s commercial focus limits the community using it - currently most of our channels appear empty due to the fact that Drupal Slack hides old messages. The local communities, therefore, decided to go for DrupalChat.eu as an alternative. If you are interested, follow this issue or join the BOF at DrupalCon NA.
Drupal 8 Initiatives are making progress
In my talk - Drupal 8 Initiatives, I tried to give an overview of the status, history and achievements of the initiatives that are contributing to the Drupal 8 project. It was a great opportunity to highlight how much Drupal 8 has already been evolving over the years as well as to show how any future contributions can be done collaboratively.
In the spontaneous session, we spoke about Agile and Project Management practices as well as the #d8rules initiative.
Keeping an eye on upcoming Drupal events in Europe
Thanks to the DrupalCamp Ruhr team for putting together such a dynamic event!
We are really looking forward to more collaboration and exchanges within the Drupal community during 2018. For those who can’t make it to DrupalCon Nashville, 9-13 April, Europe has you covered. Keep an eye on these events:
As usual, you can also find many more regional events on Drupical and finally, if you are interested in an unconference using the Open Space format, make sure to join us for Agile Lean Europe Zürich 2018, August 22-24.