Freelock : Drupalgeddon2: Should I worry about critical security updates?

Planet Drupal - Fri, 2018/03/30 - 2:00am
Drupalgeddon2: Should I worry about critical security updates? John Locke Thu, 03/29/2018 - 18:00

No, you should not. You should let us worry about them, and go back to your business.

Seriously, we're getting questions from all kinds of people about whether this matters. I'm a bit surprised that there is any question about that. Would you be concerned if your top salesperson was selling for somebody else? If your cashiers were jotting down credit card numbers when they charged a card? If your office became a well-known spot for illicit drug or gun dealers? If your office had a bunch of scammers squatting and running a pyramid scheme? If your confidential client information could be revealed as easily as using a bic pen on an old Kryptonite lock?

Bic Pen vs Kryptonite Lock

We've seen some variation of every single one of those scenarios. And all of them are possible with a remote code execution flaw in a web application, like yesterday's Drupal security vulnerability.

And yet people still

Drupal Drupal Planet Security WordPress
Categories:

Tandem's Drupal Blog: Migrating Drupal 7 Organic Groups to Drupal 8 Group

Planet Drupal - Fri, 2018/03/30 - 2:00am
March 30, 2018 Migrating Drupal 7 Organic Groups to Drupal 8 Group takes a little bit of effort and migration elbow grease. Use Case for this Migration We are currently helping a university client migrate their intranet to Drupal 8. The intranet was built with Open Atrium in Drupal 7. Unfortunately there is no Open Atrium Drupal 8 version and ...
Categories:

Drupal blog: Thanks to the Drupal Security Team for keeping us safe

Planet Drupal - Thu, 2018/03/29 - 8:06pm

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

We released new versions of Drupal 7 and Drupal 8 yesterday that fixed a highly critical security bug. All software has security bugs, and fortunately for Drupal, critical security bugs are rare. What matters is how you deal with security releases.

I have the utmost respect for how the Drupal Security Team manages a security release like this — from fixing the bug, testing the solution, providing advance notice, coordinating the release, to being available for press inquiries and more.

The amount of effort, care and dedication that the Drupal Security Team invests to keep Drupal secure is unparalleled, and makes Drupal's security best-in-class. Thank you!

Categories:

Redfin Solutions: Getting Started with Herman: Living Style Guides and Pattern Libraries

Planet Drupal - Thu, 2018/03/29 - 7:55pm
Getting Started with Herman: Living Style Guides and Pattern Libraries

It all started with an innocent tweet:

https://twitter.com/mirisuzanne/status/948637526612324352

"Excited to announce our new open-source, Sass-driven pattern-library generator! Go design some systems!"

Chris March 29, 2018
Categories:

Texas Creative: Frosted Glass - HTML CSS TWEAKS

Planet Drupal - Thu, 2018/03/29 - 6:35pm

Creating a frosted glass effect using CSS is a better method than the old javascript hacks. Using CSS to create the frosted effect uses fewer resources from the site visitors computer by using the native browser rendering engine.

To test this just drag the frosted glass example in the top right of this page

Ok, without wasting much of your time I’m going to jump straight into it.

The main components used for a classic frosted glass effect are:

  • > The original content
  •  - - > The frosted glass container ( Exp. <div> )
  •  - - - - > Original content copy inside the glass container (the element that mimics the content on the page with a blur effect).

For a basic idea of how this works. Here is a simple example:

HTML structure:

Read More
Categories:

Commerce Guys: Commerce Kickstart Covered for SA-CORE-2018-002

Planet Drupal - Thu, 2018/03/29 - 5:06pm

On March 21st 2018, the Drupal security team posted a public service announcement that Drupal core would be receiving a security release. The vulnerability affected Drupal 6, Drupal 7, all versions of Drupal 8, and Backdrop (a fork of Drupal during the rewrite to version 8.) On March 28th that security release landed, and the Drupal world went scrambling to apply updates. As maintainers of Commerce Kickstart we have to be conscious of Drupal core releases, especially security ones.

In preparation for the upcoming security release, we had patches ready to commit. Since there would be no other Drupal core releases before the security update, we could make our prepared changes ahead of time and push them once the releases landed. Within minutes of the security release dropping and the Git backend for drupal.org becoming available, the release tags were pushed.

For our Pantheon users, our first step was to merge in Pantheon’s Drupal 7 upstream and receive the Drupal core security fix. Once the packaging system of drupal.org built the Commerce Kickstart 2.53 release, we pushed that out as well.

All in all, by 3PM CDT the drupal.org releases for Commerce Kickstart 1.51 and 2.53 were out. We experienced some packaging issues due to a malicious attack hitting drupal.org during the security announcement and a backed up packaging queue. However, we monitored chat channels and communicated the process throughout.

Commerce Kickstart 1.51, 2.53 released. The @getpantheon upstream has been updated as well. GO AND GET YOUR SA-CORE-2018-002 FIXES NOW.

— Matt Glaman (@nmdmatt) March 28, 2018

Thanks to the Drupal Security and Infrastructure teams for handling this release and all the stress they endured.

Categories:

Acro Media: Drupal Website Debugging and Site Performance

Planet Drupal - Thu, 2018/03/29 - 5:00pm

Debugging a website (Drupal or otherwise) can be challenging. In this video, I go through a recent situation I faced where a client had reported their Drupal Commerce site completely slowing down every hour or so. I'll discuss the process I followed to figure out the problem and get it fixed.

Here's a breakdown of what happened
  1. I first used New Relic to see where the slowdown was happening. It could be a database issue, a PHP issue, maybe an external service call, who knows? New Relic can help determine this and I was able to determine that it was a database load issue that I was facing.

  2. Then I checked the system logs. Every hour or so, there were a lot of database insertions happening on a number of tables. It seemed really out of place and initially I couldn't narrow down why. I checked the logs and found that system cron was running at the exactly same time as the slowdown. It was also running for a similar amount of time that the slowdown was taking place. Normally, system cron only takes 1-20 seconds, but here it was running for about 3 minutes!
  3. Now I can review cron's code to see what should be happening. I found that cron will generate a list of tables and flush out the expired cache. Generating the list is a very resource intensive process and on this particular site, the list being generated was very large and complicated. After the list is generated, it should get permanently cached in the database and therefor it doesn't become a resource issue later. However, for some reason it was being deleted every time. This ended up being the issue I needed to find out, what was deleting the list.

  4. Since I needed to determine why it was being deleted, I attached logging to the general function used for deleting cache. From here I was able to trace it back to Drush, but I still didn't understand why Drush would be deleting this list of tables. I had to dig further.

  5. Eventually, I discovered what was happening. It turned out that the version of Drush that was being used was doing a call to try and find the system logging. However, it couldn't find it and as a side effect it cleared the cached list that cron had generated. Cron, which ran every hour, then couldn't find the cached list and so need to build it again. It was a cycle that just kept repeating itself every hour. I now understood the problem!

  6. And now for the fix. I needed to know why Drush was doing this and if I could prevent it. I first looked around the Drush project issue queue on Drupal.og and talked to a Drush maintainer. I wanted to know if this was an issue others were also experiencing. It turns out that it WAS a known issue and that it was resolved in a later release! The version on the site that I was working on was a few major versions behind. I bought the site up to the latest release and the issue was fixed! Cron ran and took only about 5 seconds, the generated list of tables was being cached and staying cached, and Drush was not clearing it out.
A good debugging exercise

The bug ended up being one that was with Drush, and not the website. The result, through an odd chain of events, ended up bringing the clients site to a standstill nearly every hour. Now that it's resolved, I can look back and see that it was a good exercise in debugging. Even though I didn't need to build the fix myself, it still took a lot of time and understanding to arrive at the fix, and it was great to have it resolved. Hopefully, if you find this because of a similar issue, maybe I can save you a little bit of time.

We can help

If your experiencing issues with your Drupal Commerce website, the good news is that we can help! Contact us if you would like to discuss your options.

Related Links
Categories:

Wunder blog: Drupal security update: Wunder clients safe and sound

Planet Drupal - Thu, 2018/03/29 - 4:11pm
Drupal security update: Wunder clients safe and sound peeter.pratka Thu, 29/03/2018 - 15:11

We are happy to announce that the highly important Drupal core security update “SA-CORE-2018-002” has been carried out successfully at Wunder: All our clients’ websites are patched and secure.

Our secret? Excellent preparation.

Last Wednesday (21st March 2018), the Drupal Security Team shook the community when they announced that a major security update is to be rolled out on the evening of Wednesday 28th March. Some even started nicknaming the update “Drupalgeddon 2.0” due to the resemblance to a highly critical security update in 2014.

Our team of Wunderers in charge stayed calm and immediately went into preparation mode. An internal plan of action was released soon after to make sure that the update could be applied as fast as possible to provide maximum security to our clients. Several Wunderers along our dedicated security team took responsibility over services to make sure we get them updated quickly.

Our team? Dedicated and fast.

So when update night rolled around, our team knew exactly what to do: Updating and applying hotfixes to our clients’ sites was executed in the smoothest way possible. To give you some numbers: More than 130 different websites were done in about 3 hours!

Shoutout to the team: You rock!

None of this would have been possible without our exceptional team of Wunderers who worked tirelessly to ensure that all client projects received the security update as fast as possible. Huge thanks for your outstanding performance and excellent work!

Special thanks go to those members of our team who were part of the task force that kept our client's applications safe and sound yesterday:

Agnis Mateuss
Aleksi Johansson
Annina Järvenpää
Artis Krumins
Arturs Vilkajs
Fredrik Lassen
Gatis Rudins
Gints Erglis
Hannes Kirsman
Ilmari Oranen
Jan Lindström
Janne Koponen
Joao Ventura
Karlis Daugavietis
Karlis Kalnins
Lauris Igaunis
Marc Galang
Maris Abols
Martins Bertins
Matti Hernesniemi
Mikael Kundert
Mikelis Zalais
Mikk Miggur
Nikita Izotov
Olli Erinko
Pasi Kauraniemi
Pauli Huhtiniemi
Peeter Pratka (also organiser)
Raimonds Kalnins
Saimons Jegers
Santeri Lindgren
Timo Kirkkala
Tomi Mikola
Toni Sinisalo
Tormi Tabor
Tuomas Leppänen (also organiser)
Viljami Salmi

Drupal Drupal Planet Drupal8 Security
Categories:

Acquia Developer Center Blog: Decoupling Drupal 8 Core: Core REST, HAL, and Setting Up Drupal as a Web Services Provider

Planet Drupal - Thu, 2018/03/29 - 3:38pm

Perhaps the most critical piece of any decoupled CMS architecture is the API layer which exposes data in the back end for consumption by other applications. In Drupal's case, the REST module (also known as the RESTful Web Services module) in Drupal 8 core fulfills this responsibility. The REST module contains important logic that drives the availability of data through formatted responses.

Tags: acquia drupal planet
Categories:

Dries Buytaert: Thanks to the Drupal Security Team for keeping us safe

Planet Drupal - Thu, 2018/03/29 - 9:36am

We released new versions of Drupal 7 and Drupal 8 yesterday that fixed a highly critical security bug. All software has security bugs, and fortunately for Drupal, critical security bugs are rare. What matters is how you deal with security releases.

I have the utmost respect for how the Drupal Security Team manages a security release like this — from fixing the bug, testing the solution, providing advance notice, coordinating the release, to being available for press inquiries and more.

The amount of effort, care and dedication that the Drupal Security Team invests to keep Drupal secure is unparalleled, and makes Drupal's security best-in-class. Thank you!

Categories:

OSTraining: Learn Drupal 8 Layout and Theming By Taking the Class

Planet Drupal - Thu, 2018/03/29 - 9:16am

One of the most frequently asked questions among our Drupal students is "How to control layouts?"

If you really would like to be in control of layouts, you need to learn theming.

We created a brilliant "Drupal 8 Theming and Layout" video class to help you. In this post, you will take a look at the class modules and what you can learn while taking them.

Categories:

myDropWizard.com: The continuing importance of the Drupal 6 Long-Term Support program

Planet Drupal - Thu, 2018/03/29 - 7:02am

Drupal 6 reached End-of-Life over 2 years ago, so you might be forgiven for thinking that Drupal 6 and its Long-Term Support (D6LTS) no longer matter.

However, yesterday (March 28th, 2018), there was a HIGHLY CRITICAL security vulnerability announced that affected Drupal 6, 7 & 8 (and even Backdrop).

This wasn't the first Drupal 6 LTS core release (did anyone notice that one?) and it probably won't be the last. And there are still ~65,000 sites running Drupal 6 according to Drupal.org, which were affected by this issue, and could be affected by future issues.

Luckily, the Drupal 6 LTS program is still going, and we got a patch and release out immediately!

But the D6LTS program won't go on forever... at least without users of Drupal 6 continuing to buy support from the D6LTS vendors.

I think this is a good time to remind everyone what the D6LTS program is and why it's still important to the Drupal community...

Categories:

Wunderkraut Sweden Blog: Drupal SA-CORE-2018-002 and us

Planet Drupal - Wed, 2018/03/28 - 11:27pm
One week ago, we got a warning about a very important security update for drupal core, that effected drupal 7 and 8 (and even 6, that is not supported anymore) were going to be released today. And we started to plan for updates. One week ago, we got a warning about a very important security update for drupal core, that effected drupal 7 and 8 (and even 6, that is not supported anymore) were going to be released today. And we started to plan for updates. For a couple of years ago, it was a hard work for us to update a site if a security update was released. Now days our hosting and our processes is much better and simplified, and thanks to the team effort of our Live-team at Digitalist, we got our most important sites patched in minutes after the security release were released.  Totally we patched around 1700 sites that we are hosting in less than 2 hours after the security patch were released. If you… Read More
Categories:

Platform.sh: More details on Drupal SA-CORE-2018-002

Planet Drupal - Wed, 2018/03/28 - 10:00pm
More details on Drupal SA-CORE-2018-002 Crell Wed, 03/28/2018 - 20:00 Blog

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

Platform.sh: SA-CORE-2018-002 Drupal core vulnerability: We've got you covered

Planet Drupal - Wed, 2018/03/28 - 9:56pm
SA-CORE-2018-002 Drupal core vulnerability: We've got you covered Crell Wed, 03/28/2018 - 19:56 Blog

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:

  1. 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.)

  2. 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
Categories:

Pantheon Blog: Security Update: Drupal SA-2018-002

Planet Drupal - Wed, 2018/03/28 - 9:28pm
The Drupal Security Team has published Drupal SA-2018-002 to address a critical vulnerability. This the first update of this magnitude since SA-2014-005 (aka “Drupageddon”) back in 2014. In that case, the time from release to automated exploitation was around seven hours.
Categories:

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

Planet Drupal - Wed, 2018/03/28 - 9:25pm

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:

Drupal core - Critical - Remote Code Execution - SA-CORE-2018-002

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!

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

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

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

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

Categories:

Security advisories: Drupal core - Highly critical - Remote Code Execution - SA-CORE-2018-002

Planet Drupal - Wed, 2018/03/28 - 8:14pm
Project: Drupal coreDate: 2018-March-28Security risk: Highly critical 21∕25 AC:None/A:None/CI:All/II:All/E:Theoretical/TD:DefaultVulnerability: Remote Code Execution Description: 

CVE: CVE-2018-7600

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.

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: Fixed By:  Contact and more information

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.

Categories:

Drupal core announcements: FAQ

Planet Drupal - Wed, 2018/03/28 - 6:50pm

this is a faq

Categories:

ThinkDrop Consulting: Newest version of DevShop eases Drupal update and release process.

Planet Drupal - Wed, 2018/03/28 - 6:15pm
Newest version of DevShop eases Drupal update and release process. Jon Pugh Wed, 03/28/2018 - 12:15

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.

Categories: