Hello everybody! You might've experienced some changes of the project settings interface already - here’s the broad summary of what makes Drop Guard more efficient and more powerful now: composer package manager mode, speeding up the setup of update type behaviors (with a short mode option) and live site monitoring.
Drop Guard is in a continuous process of optimization and development. As it is still a unique platform concept on the market place, we started years ago with a sketchy blueprint of what Drop Guard is today - and rather will be in future. With this post I will give you a quick overview of what is planned and something which is a little secret between you and me.
We, at Drop Guard, never stop thinking what else can we do to help Drupalistas around the world to get aboard of the continuous update process ship (as we call it) as soon as possible. More and more threats are being discovered every day, and it's absolutely imperative to stay alerted all around the clock either with help of automation platforms like Drop Guard or doing things your own way.
The holiday season was a lot of fun for the Drop Guard team, but also very busy. We've worked hard to deliver a whole package of impressive features and improvements to our update management platform. Big plans were also made for 2017. Without further hesitation let's start the New Year with the news!
Our existing users may have already noticed a few changes and improvements in Drop Guard. However, not everything is visible enough, so we decided to make a short list with the recent updates.
Drop Guard is now capable of managing your composer.json and composer.lock files, in the same fashion as you would do it normally via CLI.
When executing the update task, Drop Guard modifies the composer.json to accommodate the recommended module or core version and runs "composer update" command to keep the composer.lock in sync. Both files get pushed to the repository, and the only thing you need to take care about is running "composer install" to receive the updated packages.
As always, Drupal Security Team did an excellent job and the news on the security vulnerabilities reported on Wednesday wasn't a bombshell for most of us. Everyone had a chance to prepare and pre-allocate resources to take all measures necessary to patch the supported websites.
A quick recap for those who missed the buzz or just slowly waking up right now.
The real benefits and value of Drop Guard are not about being able to monitor, but actually perform updates by committing the newer Drupal and modules versions directly into the project's Git repository. In this article, we'll familiarise ourselves with the basic Drop Guard concepts, and go through the update behaviours configuration process to secure our website.
Today, we’re excited to introduce you to a number of new features, improvements and fixes for Drop Guard - the first update in the series of releases planned for 2016. It includes many enhancements designed to improve user experience when creating projects in Drop Guard, support for the "Unsupported updates", and even smarter automated patching workflow. Read below to learn about the major improvements and don't forget to check your Drop Guard account to check it by yourself. Let's dive right in!
With this post, we are starting a new series - "Drop Guard recipes". It will be all about things which help us to be more productive, efficient, provide better service to our customers and ensure better security for Drupal. As you might expect, it will be mostly Drop Guard related, but we promise there will be a lot of interesting stuff for everyone. Stay tuned!
First of all, let's agree that if you or your team uses some sort of modern development workflow - which essentially means the path the code makes from the point it was originally written to the production website, you should be familiar with feature branches concept. Apart from traditional "dev", "stage" and "master" branches, you create separate named branches for website features or code updates which are not yet ready to be merged upstream.
6 January 2016 was a memorable day for the Drupal community. Probably for the first time since the Drupalgeddon a vulnerability with potential to affect millions of websites was discovered. The report on the insecure Drupal update process, published by IOActive, got immediate traction and responses from Acquia, Drupal Security Team and major players in the community.