Today’s post is a quick tip that will help you keep your robots.txt after you update the site’s Drupal core with drush.

Most likely, you know the problem, too: each time you update the Drupal core (with drush, first of all), you lose all changes you may have introduced to robots.txt manually. A good idea is to always have a backup of this file handy, but every now and then you only have an outdated version of robots.txt and you learn that only when you check the updated site with webmaster tools.

Security of a website is a crucial thing that sometimes does not receive the attention it should.

Today, I’d like to share the routines we apply when checking up security of a Drupal-powered website. For the most part, this article is a summary of the report Dmitry Kochetov, our Drupal security specialist, made at DrupalCamp Krasnodar 2016.  

You have most likely been there too. The website is nothing out of the ordinary, quite a small one, but the space it occupies on the hard drive is no match to the outward size, which boosts backup costs the customer pays. The most obvious reason for the discrepancy is unused files, we thought, and so started looking for them. In this article, I tell the story of the quest for unused files in a Drupal-powered website (and not just Drupal, for that matter).

Hi!

Today, I'd like to share with you a Drupal module I made, the Performance Monitor. I covered it in my keynote at DrupalCamp Krasnodar 2016.

Let's start with the reasons why I coded this one in the first place.

The Task

At Initlab, we often receive queries (mostly from web developers) that boil down to a couple of typical issues: the site is slow after migration to another server/hosting; the site is slow and it feels like the server should be optimized for Drupal.