Drupal tips and tricks

The small things that make life easier with Drupal

What to do when your Drupal site has been hacked

Submitted by Frederic Marand on Fri, 2016-06-24 10:36

2017-10-21 UPDATE: attend this session in French at DrupalCamp Lannion next week !

These are the slides of the presentation I gave yesterday at DrupalDevDays Milan.

Life after the hack from OSInet, for Drupal Project

Drupal tip of the day: how to drop the Simpletest collections when using Drupal with MongoDB

Submitted by Frederic Marand on Wed, 2015-11-04 18:06

The problem

When running tests on a server using the recent versions of the MongoDB module for Drupal, and more specifically the MongoDB simpletests, the simpletest runner may leave droppings in your MongoDB Drupal database, which have no business remaining there. How to remove them while keeping the good collections ?

The typical case will be after a failed test runs, looking like this:

Drupal 8 tip of the day: replace hook_drush_command() by a YAML file

Submitted by Frederic Marand on Fri, 2015-10-23 17:35

One of the big trends during the Drupal 8 creation has been the replacement of info hooks by two main mechanisms: annotations, and YAML files. In that light, hook_drush_command(), as the CLI equivalent of the late hook_menu, replaced by various YAML files, looks just like a perfect candidate for replacement by a commands section in some mymodule.drush.yml configuration file. Turns out it is incredibly easy to achieve. Let's see how to kill some hundred lines of code real fast !

Drupal 8 tip of the day: autoloaded code in a module install file

Submitted by Frederic Marand on Thu, 2015-08-27 08:24

(updated 2017-08-30, see bottom of post). Autoloading in D8 is much more convenient that in previous versions, however, it still has limitations. One such issue is with hook_requirements(), which is supposed to be present in the module install file, not the module itself: when called at runtime for the site report page, the module is loaded and the PSR/4 autoloader works fine. However, when that hook is fired during install to ensure the module can indeed be enabled, the module is not yet enabled, and the autoloader is not yet able to find code from that module, meaning the hook_requirements('install') implementation cannot use namespaced classes from the module, as they will not be autoloadable. What are the solutions ?

Logging for MongoDB

Submitted by Frederic Marand on Sat, 2015-08-22 19:51

One nice thing during Drupal 7/8 development is the ability, thanks to the devel module, to get a list of all SQL queries ran on a page. As I've been working quite a bit on MongoDB in PHP recently, I wondered how to obtain comparable results when using MongoDB in PHP projects. Looking at the D7 implementation, the magic happens in the Database class:

<?php
// Start logging on the default database.
define(DB_CHANNEL, 'my_logging_channel');
\Database::startLog(DB_CHANNEL);

// Get the log contents, typically in a shutdown handler.
$log = \Database::getLog(DB_CHANNEL);
?>

With DBTNG, that's all it takes, and devel puts it to good use UI-wise. So is there be an equivalent mechanism in MongoDB ? Of course there is !

Drupal 8 tip of the day : check menu links consistency

Submitted by Frederic Marand on Sun, 2014-10-05 14:16

One of the interesting aspects of the revamped menu/links system in Drupal 8 is the fact that menu links are now in easily parseable YAML files, the "(module).links.menu.yml" in each module, in which each menu link can be bound to its parent link, hopefully producing a tree-like structure.

Tip of the day: Standalone DBTNG outside Drupal

Submitted by Frederic Marand on Sat, 2014-02-08 09:58

A few days ago, while I was writing a bit of Silex code and grumbling at Doctrine DBAL's lack of support for a SQL Merge operation, I wondered if it wouldn't be possible to use DBTNG without the rest of Drupal.

Obviously, although DBTNG is described as having been designed for standalone use: DBTNG should be a stand-alone library with no external dependences other than PHP 5.2 and the PDO database library, in actual use, the Github DBTNG repo has seen no commit in the last 3 years, and the D8 version is still not a Drupal 8 "Component" (i.e. decoupled code), but still a plain library with Drupal dependencies. How would it fare on its own ? Let's give it a try...

When Drush Make fails to apply patches...

Submitted by Frederic Marand on Fri, 2013-01-25 12:32

The issue

These last few days, I had noticed a problem with Drush Make and patches: some patches, be they rolled by our team or from elsewhere, would apply without a glitch, but some others, which worked normally according to the test bot on Drupal.org, would fail to apply without any obvious reason.

I had mostly put it out of my list of pressing issues when I really had to use an old version of OpenLayers, 7.x-2.0-alpha2 to be specific, AND apply a patch fixing one of the bugs in that module: behaviors plugin not being located correctly (http://drupal.org/node/1898662 if you want details). So I rolled the patch, tested it locally, the qa.d.o bot applied it and did not report more errors than expected for that old version.... and my Drush Make install refused to apply it.

Here was the relevant excerpt:

projects[domain] = 3.7
projects[domain][patch][] = "http://drupal.org/files/domain-foreach_argument-1879502-1.patch"
; ...snip...
projects[openlayers] = 2.0-alpha2
projects[openlayers][patch][] = "http://drupal.org/files/0001-Fix-the-path-file-declaration-for-behaviors.patch"
The Domain patch applied normally, but the OpenLayers patch would't apply. What could be wrong ?

How to restore Unfuddle dumps: migrating to Drupal CaseTracker

Submitted by Frederic Marand on Sat, 2011-09-03 17:02

Unfuddle is a very convenient and fairly cheap SaaS hosted Redmine (with extensions) and SVN/Git, which I use regularly on customer projects. Their service includes reassuring "Backup" options, going as far as to include the ability to backup to your own Amazon S3 bins in addition to their local backups.

Recently, however, I had to go back to an archived project for which I had dutifully taken a dump before closing it on Unfuddle, and looked for a way to restore it to my Unfuddle account. To no avail. Unfuddle support then kindly confirmed that the service did include a backup feature, but no restore:

Backups of projects within Unfuddle are for personal use only and cannot be restored into accounts via the interface. This however may be possible with some custom scripting on your part and with the use of our API (http://unfuddle.com/docs/api).

What then ?

What to do when you can no longer login to your Drupal site

Submitted by Frederic Marand on Thu, 2011-08-04 09:51

So the scenario is this: you notice that you are no longer able to login on your Drupal site:

the {users} table entry for your account looks just fine
the login and access timestamps on your account are just a few seconds old, matching your latest attempt to login
you reset your password in the DB, just in case, and it still does not work
the telltale is that Drupal will not even tell you your login failed: it actually works, as the {users} table shows, but yet you are not logged in

Can you guess what can have been going wrong and fix it ?

Subscribe to Drupal tips and tricks