Each day, more Drupal 7 modules are being migrated to Drupal 8 and new ones are being created for the Drupal community’s latest major release. In this series, the Acquia Developer Center is profiling some of the most prominent, useful modules, projects, and tools available for Drupal 8. This week, a handy-dandy usability module called Linkit.Tags: acquia drupal planetusabilitydrupal 8D8Linkitautocomplete
I recently had the opportunity to give a beginners talk about website accessibility at MidCamp 2016 where I covered some easy ways to promote accessibility in terms of structure, color and contrast, fonts, links, and media. It was a wonderful experience for me and I was grateful for the audience who had some nice feedback and interesting questions. Here are the highlights of the presentation, plus the audio recording and links to related resources.
Over the past few months, I've been reading about BigPipe, Cache Tags, Dynamic Page Cache, and all the other amazing-sounding new features for performance in Drupal 8. I'm working on a blog post that more comprehensively compares and contrasts Drupal 8's performance with Drupal 7, but that's a topic for another day. In this post, I'll focus on cache tags in Drupal 8, and particularly their use with Varnish to make cached content expiration much easier than it ever was in Drupal 7.
Alan Stanley taught me this trick at an Islandora Camp a few years ago, and when trying to remember it this morning I messed up one critical piece. So I’ll post it here so I have something to refer back to when I need to do this again.
The Drupal Devel module includes a menu item for executing arbitrary PHP code on the server. (This is, of course, something you want to set permissions on very tightly because it can seriously wreck havoc on your day if someone uses it to do bad things.) Navigate to
/devel/php on your Islandora website (with the Devel module enabled), and you’ll get a nice, big
≶textarea> and an “Execute” button:
In this case, I’m generating the TECHMD datastream using the FITS module and displaying the results of the function call on the HTML page using the Devel module’s dpm() function:
include drupal_get_path('module', 'islandora_fits') . '/includes/derivatives.inc'; $object= islandora_object_load('demo:6'); $results = islandora_fits_create_techmd($object, False, array('source_dsid' => 'OBJ')); dpm($results);
Works like a charm!
We've been talking to our clients about Drupal upgrades a lot lately. This is not surprising, of course, given the recent release of Drupal 8, which signaled the end of life for Drupal 6.
The Drupal community is excited about all that Drupal 8 has to offer. If you’re on Drupal 6, however, that excitement may be muted by the feeling that you're between platforms. You want to be thoughtful about your next steps. You want to anticipate all the possible consequences. The stakes are high.
Here at Advomatic we've been involved in many, many Drupal upgrade decisions in the last few months. We've gotten good at helping customers navigate the options.
So what are we now telling our current customers, and prospective customers? Read on.
Tags: acquia drupal planet
When Drupal 8 and its innovative architectural changes were first announced several years back, there were a variety of reactions within the community ranging from euphoria and elation, to FUD and potential abandonment of the platform altogether. I remember feeling caught in the middle of these two camps, not really being able to come to any conclusion for some time to come.
Admittedly, I had my reservations about Drupal 8 but I really wanted to give it a chance. I experimented with it while in the early alpha stages, but for a themer it was frustrating as there were constant code changes to core (as was to be expected), and the theming layer was constantly evolving.
In fact, these broad changes with Drupal 8 prompted the forking of Drupal 7 into a new platform called Backdrop CMS, which would carry the essence of Drupal 7 into the future while taking some of the refinements made to Drupal 8 and splitting the difference. I tested out Backdrop during that time as well, but honestly I was not happy with Backdrop's theming layer; it seemed disjointed to me.Getting inspired all over again
Fast forward to 2016 and now that Drupal 8 has been out for almost six months, I decided to dig in again. It all started with attending SANDCamp here in San Diego at the end of February. Thanks to my company, Jackson River for making my attendance to the camp possible, I was inspired by Drupal all over again and moreover, by Drupal 8. I was especially taken by how awesome and logical theming is in Drupal 8; it's now super refined and powerful. At the camp, I took an all day Drupal 8 theming workshop led by the good folks at Chapter Three, and by the end of the day I saw the light and was a believer.
A lot of this has to do with two new base themes in Drupal 8 called "Classy" and "Stable," as well as the underlying Twig and YAML frameworks. Out the box, Classy and Stable each give you 100 + templates to override and modify into your own custom sub-theme.Classy has class
"Its purpose is to provide many classes throughout the markup that help annotate and describe markup elements that render on the page. In the past, the extra effort that Drupal applies to elements in annotating them this way has been viewed as helpful by some and a hindrance by others. In Drupal 8, you now have the option of either including or excluding this extra help."Go minimal, don't use classy
I'm now in the process of designing and developing a Drupal 8 theme and I'm still deciding whether to use Classy or Stable as my base-theme. I'm thinking I'll use Classy and then in any of my template sub-theme overrides, I can alter or remove markup as needed. Using either of these as a base-themes in combination with Twig debugging makes Drupal 8 a theming force to be reckoned with.Less preprocessing, more Twig
Much of what used to be done altering things like field markup with
theme_field in Drupal 7 is much more accessible and alterable directly in Twig templates now in Drupal 8. Thus, less of a need to use theme preprocess functions compared with Drupal 7. However, when you do need to write a preprocess function, you'll typically use minimal code. The other thing that I love with Drupal 8 theming is that theme hooks seem to be more accessible and easier to write via quick and easy alter hooks. Write a hook and magically see your new template suggestion(s) appear in your Twig debug area. In addition, the Drupal 7 module, View Modes in now part of Drupal 8 core so you get easy creation of view modes AKA Display Modes with a UI right out of the box. This is great news for themers, and I've become a huge fan theming using view modes over the past few years.
As a themer, if you were used to exploring data arrays in Drupal 7 with Devel's venerable
dpm functions, with Drupal 8 you can use Devel "Kint". Kint is somewhat mind boggling at first but it does do very similar things as
dpm did with Drupal 7. The one big feature missing for me with Kint is a search function similar to the Search Krumo module in Drupal 7. I hope that becomes available in the future. Kint most definitely comes in handy for designing your theme hooks.
I am really excited about theming with Drupal 8, I feel like I did when I first discovered and started developing with Drupal 6 back in 2009. In the coming months here on my blog, I hope to share some of this new-found theming knowledge. One of the main takeaways is that Drupal 8 theming presents far less of a barrier to entry than I thought it would.Tags
- Drupal Planet
- Drupal 8
Security audits in Drupal are not a trivial thing. This is how we do it.Tue, 2016-03-22 13:59By salva
Site audits are one of the services that some of our clients have requested from us in the past. While a site audit might be done with a specific objective in mind, there's always a common reason: find, understand, and fix any potential holes or problems that could cause a service outage on the site, or on the server where it is hosted. In some cases, that's the only reason, whereas in other cases the outcome of the audit will inform a more important decision, such as a platform or server move, or a site rebuild, to name a few.
Depending on the goal of an audit, the things to look at on the site might change a bit: is it a performance audit, a security one, or a general review to check the overall status of the site and the feasibility of keep evolving it in an efficient way? This post covers the details concerning security audits in particular, although some of the practices mentioned here do not belong exclusively to the realm of security, and will be equally needed in other audits. Let's get started.General aspects
There are some things that an audit should always cover, as they give a good overview of the site and how well it's been looked after. Some of these aspects are:
- General codebase observations: Get an overview of the structure and organisation of modules and custom php scripts (if any). In big projects, where people come and go and different developers get to work on the code, it's not uncommon to see a big mess in custom code, structured without consistent patterns or styleguides. This might not affect security directly, but it might be a sign that not much care has been put into how things are done, and it will surely impact maintenance.
- General code inspection: Performed through an IDE or automated tools, to find extensive uses of bad practices in code. Again, this might not necessarily surface any potential security holes, but depending on the tools used, there are cases in which it could actually do so. A good tool for a general review of Drupal modules is the Coder module, which can be tuned to look only for problems of a specific nature (e.g: only check Drupal standards).
- Site Audit Script: The Site Audit module is worth a look as well. While it's not the most feature-complete audit tool, it provides useful info about certain areas of a Drupal site, and includes some security checks too.
- Watch out for patched modules: The Hacked! module can help you to easily identify which contributed modules have been altered by developers after the official version was added to the codebase. It compares the installed version with the official one available in www.drupal.org, to highlight the differences. If the development team have behaved well, all these patches will be documented in some way in the codebase, so make sure you consider them in more specific audits, in particular for security.
Drupal core is great when it comes to security, and it also encourages module developers to follow good practices when contributing to the community, by providing clear guidelines about how to write secure code. However, considering the low entry barrier of the platform for anyone who has some basic PHP skills, it's not hard to find projects in which some of the standard APIs and guideliness are either overlooked, or bypassed entirely. This opens possible security holes in the system.
Being a CMS, the possible security holes of a Drupal site may not lay only in the codebase, but also in how the different modules are configured, often in a too-permissive fashion. Enabling PHP Filter to allow PHP execution from the UI, or a bad configuration of input (text) formats, are just a couple examples of how a bad configuration could be used to breach into the site. You can find more details about this in this page of the Administration & Security Guide.
In this article, I'd like to focus a bit more in the possible issues that can be generated at the codebase level. The next list covers the most common vulnerabilities that should be looked for when auditing a Drupal project, and some other aspects to consider. These checks are normally for the custom code. Some details are given next to each vulnerability type, with the common functions or elements that can be used to exploit the vulnerability, or where it might be introduced:
SQL Injection: Make sure no $_GET data is used without proper sanitisation, specially if it's going to be used in queries to the database. The term is a classic, I know, and it's been used and abused all over the web for a lot of years, but not without cause: it's been less than two years since I came across a vulnerability of this type (don't get excited, you won't find any name and shame in this post).
Check as well for usage of drupal_get_query_parameters(). If not treated safely, data received from there can be as dangerous as $_GET.
Remote code execution: Make sure $_POST data is being used safely. Not usually an issue if Drupal Form API is used. While not encouraged, it's possible for developers to use $_POST or $form_state['input'] to retrieve user-submitted data. So, when searching for places where this kind of data is used in code, make sure those variable names are included in the search.
Pay also attention to custom data stored in the database that is later used for custom logic, but having being previously retrieved through a custom form.
Some functions can be used to exploit vulnerabilities with malicious data captured through any of the methods described. Most of these functions are not too common for small websites, but they can be very dangerous if not used with care, so it's always worth looking for any usages of these in code, and in case you see any of them, ensure they're used safely:
XSS / Persistent XSS: Another classic. Check that all user input is sanitised before being output as HTML. See Handle text in a secure fashion:
General checks. Make sure these functions or statements are used according to the documentation, and with data sanitised where relevant:
Make sure anything contained in blocks content is sanitised, since these contents are output "as is".
Other possibly dangerous Drupal elements:
These elements are not dangerous as such, but they're used to display HTML contents. The general idea here is: sanitise data before displaying it!
Form API #title and #description
Form API #markup types.
Review usages of rich text fields in code, and make sure they're always displayed using their appropriate text format.
Views fields without sanitising (e.g: using the "raw” contents from a views template).
Do all custom hook_menu functions have access arguments declared?
Do all custom queries use the node_access tag where required?
Are permissions respected when displaying entities retrieved via EntityFieldQuery?
CSRF: Make sure all custom forms use Drupal's FAPI or confirmation forms / tokens.
These are some of the most common checks to go through when reviewing the site configuration:
HTTPS configured correctly.
PHP filter is disabled.
Access to text formats.
Private files directory is in a secure location outside of webroot.
Execution of PHP files in subfolders disabled.
Everything else covered in the Writing secure code page of the Drupal developer handbook.
Anything listed in the OWASP Top 10 should be always present in a security audit.
Some of the points listed there are rather uncommon to see these days. However, no matter how unlikely they are, a security vulnerability is always a risk, so as good developers is our duty to, at least, try our best to make sure we follow good practices and don't create holes in the system, or fix them if we find any.
Once in the auditor role, there are tools to automate the search for some of the possible issues in code. One example is the Security Review module for Drupal, which makes some checks on a given site (none on the codebase itself) and generates a report highlighting the areas where the configuration should be changed. Taking it a step further, the Paranoia module will automatically make some changes to your site, disabling certain sections or features that could make it insecure.
Security is not a setting, it's a process, and even experts (except Code Enigma sysadmins) make mistakes. The worst mistake one can make about a site is taking its security for granted.
PageDrupal Security Updates PageSecure Drupal Hosting BlogMeet the YubiKey PageDrupal Support
The Drupal Insert module is a convenient module to easily place images in content, without hassling around with a WYSIWYG editor. It is rightly a popular Drupal module (nearly 80,000 active installs). We are also using it in our blogs; in combination with Markdown you can easily and quickly format content.
The only problem is that the images are not looking good. The quality of the scaled images can be set in Drupal (Administration > Configuration > Media > Image toolkit), but I noticed they are never really good enough. Also because you have to deal with many different kinds and sizes of screens of visitors: you would like everybody to see a nice image (mobile, tablet, desktop, retina etc).Solution for better quality images
Drupal's menu system API underwent a large number of significant changes in Drupal 8, just like many other areas in Drupal's newest version.
The way we define what piece of PHP logic should respond to a particular path, e.g. /example, is no longer part of the menu; instead it is now defined via the route system. The menu system - as it should logically - is now used to define how a particular page (a route) fits into the menu system, tabs, and contextual links. Let’s take a quick look at how the familiar tasks of defining and altering such entries have changed.Tags: acquia drupal planet
We, at Drop Guard, are extremely concerned about all things Drupal security. Security is not something that can be taken for granted after ordering a security review, or passing through a "security checklist", or even after switching to Drop Guard for updates handling. We should always remember that security is a continuous process, and it consists of numerous bits and pieces requiring your attention all the time.
Luckily enough, Drupal is a highly modular system, and instead of reinventing the wheel we can take advantage of the existing and battle tested solutions which are aimed at helping us with ensuring the continuous security for our applications.
We've collected the essential security-related modules in our view, and split them into two categories - passive (designed to monitor and provide information) and proactive (designed to take action or make changes to application configuration to ensure stronger security).Modules Security Drupal Planet
There is a lot of hype around decoupled architectures, so before embarking on a project, it is important to make a balanced analysis. Your choice of architecture has implications on your budget, your team, time to launch, the flexibility for content creators, the ongoing maintenance of your website, and more. In this blog post, I'd like to share a flowchart that can help you decide when to use what technology.
This flowchart shows three things:
In practice, I believe many organizations want to use all of these content delivery options. In certain cases, you want to let your content management system render the experience so you can take full advantage of its features with minimal or no development effort (coupled architecture). But when you need to build a website that needs a much more interactive experience or that integrates with unique devices (i.e. on in-store touch screens), you should be able to use that same content management system's content API (decoupled architecture). Fortunately, Drupal allows you to use either. The beauty of choosing from the spectrum of fully decoupled Drupal, progressively decoupled Drupal, and coupled Drupal is that you can do what makes the most sense in each situation.
For years, we have been using and recommending memcached for Drupal sites as its caching layer, and we wrote several articles on it, for example: configuring Drupal with multiple bins in memcached.
Memcached has the advantage of replacing core caching (which uses the database) with memory caching. It still allows modules that have hook_boot() and hook_exit() to work, unlike external cache layers such as Varnish.
However, memcached has its limitations: It is by definition transient, so rebooting wipes out the cache, and the server can suffer if it has high traffic. It is also entirely memory resident, so to cache more items you need more RAM, which is not suitable for small servers.
The following is a detailed guide to get Redis installed and configured for your server. It assumes that you are an Ubuntu Server 14.04, or the equivalent Debian release.Installing Redis
drush @live dl redis
You do not need to enable any Redis modules in Drupal.
Then, install the Redis Server itself. On Debian/Ubuntu you can do the following. On CentOS/RedHat, you should use yum.
aptitude install redis-server
Then, install PHP's Redis integration. Once you do that, you do not need to compile from source, or anything like that, as mentioned in Redis README.txt file.
aptitude install php5-redis
Restart PHP, so it loads the Redis integration layer.
This assumes you are using PHP FPM:
service php5-fpm restart
If you are using PHP as an Apache module, then you need to restart it as follows:
service apache2 restartConfiguring Redis
Then in your settings.php file, you should replace the section for memcache which would be as follows:
$conf['cache_backends'] = './sites/all/modules/contrib/memcache/memcache.inc';
$conf['cache_default_class'] = 'MemCacheDrupal';
$conf['memcache_servers'] = array('127.0.0.1:11211' => 'default');
$conf['memcache_key_prefix'] = 'site1';
And replace it with the following configuration lines:
// Redis settingsCleaning Up
$conf['redis_client_interface'] = 'PhpRedis';
$conf['redis_client_host'] = '127.0.0.1';
$conf['lock_inc'] = 'sites/all/modules/contrib/redis/redis.lock.inc';
$conf['path_inc'] = 'sites/all/modules/contrib/redis/redis.path.inc';
$conf['cache_backends'] = 'sites/all/modules/contrib/redis/redis.autoload.inc';
$conf['cache_default_class'] = 'Redis_Cache';
// For multisite, you must use a unique prefix for each site
$conf['cache_prefix'] = 'site1';
Once you do that, caching will start using redis. Memcached is not needed, so you should stop the daemon:
service memcached stop
And you should purge memcached as well:
aptitude purge memcached
And that is all there is to it.Changing Redis Configuration
You can then review the /etc/redis/redis.conf file to see if you should tweak parameters more, such as changing maxmemory to limit it to a certain amount, as follows:
More below on this specific value.Checking That Redis Is Working
To check that Redis is working, you can inspect that keys are being cached. For this, you can use the redis-cli tool. This tool can be used interactively, as in, you get a prompt and type commands in it, and results are returned. Or you can use the specific command as an argument to redis-cli.
For example, this command filters on a specific cache bin, the cache_bootstrap one:
127.0.0.1:6379> keys *cache_boot*
Or you can type it as:
$ redis-cli keys "*cache_boot*"
In either case, if Drupal is caching correctly, you should see output like this:
As you can see, the key structure is simple, it is composed of the following components, separated by a colon:
- Cache Prefix
This is the site name in a multi site environment.
- Cache Bin
This is the cache table name when using the default database caching in Drupal.
- Cache Key
This is the unique name for the cached item. For cached pages, the URL is used, with the protocol (http or https) and the host/domain name.
You can also filter by site, using the cache_prefix:
$ redis-cli keys "*site1:cache_page*"
The output will be something like this:
You can also check how many items are cached in the database:
$ redis-cli dbsize
The output will be the number of items:
(integer) 20344Flushing The Cache
If you need to clear the cache, you can do:
$ redis-cli flushallChecking Time To Live (TTL) For A Key
You can also check how long does a specific item stay in cache, in seconds remaining:
$ redis-cli ttl site1:cache_page:http://example.com/
The output will be the number of seconds:
(integer) 586Getting Redis Info
You can get a lot of statistics and other information about how Redis is doing, by using the info command:
$ redis-cli info
You can check the full documentation for the info command.
But here is one of the important values to keep an eye on is used_memory_peak_human, which tells you the maximum memory that was used given your site's specifics, such as the number of items cached, the rate of caching, the size of each item, ...etc.
You can use that value to tune the maxmemory parameter, as above.
You can decrease the Minimum Cache Lifetime under /admin/config/development/performance to make the available memory fit that number, or the other way around: you can allocate more memory to fit more.Monitoring Redis Operations In Real Time
And finally, here is a command that would show you all the operations that are being done on Redis in real time. Do not try this on a high traffic site!
$ redis-cli monitorPerformance Results
Redis performance as a page cache for Drupal is quite good, with Time To First Byte (TTFB) is ~ 95 to 105 milliseconds.Alternatives To Redis and Memcached
We did fairly extensive research for Redis and Memcached alternatives with the following criteria:
- Compatible With Redis or Memcached Protocol
We wanted to use the same PHP extension and Drupal Redis (or Memcached) modules, and not have to write and test yet another caching module.
- Non-Memory Resident Storage
We want to reduce the memory foot print of Redis/Memcached, because they both store the entire key/value combinations in memory. But still wanted to get acceptable performance.
The following products all claim to meet the above criteria, but none of them worked for us. They were tested on Ubuntu LTS 14.04 64-bit:
Using MongoDB article for more details.
MemcacheDB is a Memcached compatible server which used the excellent Berkeley DB database for storage.
This MemcacheDB presentation explains what it does in detail.
It has an Ubuntu package right in the repository, so no need to compile from source, or manually configure it. It works flawlessly. The -N option enable the DB_TXN_NOSYNC option, which means writes to the database are asynchronous, providing a huge performance improvement.
Configuration in Drupal's settings.php is very easy: it is exactly like Memcached, with only the port number changing, from 11211 to 21201.
Alas, all is not rosy: it is not really a cache layer, since it does not expire keys/values based on time, like Memcached and Redis does.
Redis-NDS is a fork of Redis 2.6, patched for NDS (Naive Disk Store).
It does compile and run, but when the line: 'nds yes' is added to the configuration file, it is rejected as an invalid value. Looking briefly in the source, we also tried 'nds_enabled yes', but that was rejected as well. So we could not get it to run in NDS mode.
ARDB is another NoSQL database that aims to be Redis protocol compatible.
We compiled this with three different storage engines: The Facebook RocksDB did not compile to begin with. Google's LevelDB compiled cleanly, and so did WiredTiger. But when trying to connect Drupal to it, Drupal hanged and never came back with both engines.
SSDB is also another NoSQL database that tries to be Redis protocol compatible.
It compiled cleanly, but had the same symptom as ARDB: Drupal hangs and never receives back a reply from SSDB.
If you were able to get any of the above, or another Redis/Memcached compatible caching engine working, please post a comment below.Resources
- A useful article on Redis persistence. Make sure you read this in conjunction with Redis' own documentation on presistence.
- Redis documentation on memory optimization.
- The Pantheon Redis instructions are useful, even though they are specific to their hosted service.
One of these scenarios is using MongoDB as the caching layer for Drupal.
This article describes what is needed to get MongoDB working as a caching layer for your Drupal site. We assume that you have an Ubuntu Server LTS 14.04 or similar Debian derived distro.Download The Drupal Module
First, download the MongoDB Drupal module. You do not need to enable any MongoDB modules.
drush @live dl mongodbInstall MongoDB Server, Tools and PHP Integration
Then install MongoDB, and PHP's MongoDB integration. Note that 'mongodb' is a virtual package that installs the mongodb-server package as well as other client tools and utilities:
aptitude install php5-mongo mongodbRestart PHP
Restart PHP, so that MongoDB integration takes effect:
service php5-fpm restartConfigure Drupal With MongoDB
Now, edit your settings.php file, to add the following:
$conf['mongodb_connections']['default']['host'] = 'mongodb://127.0.0.1';
$conf['mongodb_connections']['default']['db'] = 'site1';
$conf['cache_backends'] = 'sites/all/modules/contrib/mongodb/mongodb_cache/mongodb_cache.inc';
$conf['cache_default_class'] = 'DrupalMongoDBCache';
Note, that if you have multisite, then using a different 'db' for different sites will prevent cache collision.Monitoring MongoDB
You can monitor MongoDB using the following commands.
mongotop -vTuning MongoDB
Turn off MongoDB's journaling, since we are using MongoDB for transient cache data that can be recreated from Drupal.
Edit the file /etc/mongodb.conf and change journal= to false.Performance Results
Quick testing on a live site showed that MongoDB performance is acceptable, but not spectacular. That is specially true when compared to other memory resident caching, such as Memcached or Redis.
For example, on the same site and server, with Redis, Time To First Byte (TTFB) is ~ 95 to 105 milliseconds. With MongoDB it is ~ 200, but also goes up to ~350 milliseconds.
Still, MongoDB can be a solution in memory constrained environments, such as smallish VPS's.Tags:
Civil Comments is a platform that brings real-world social cues to comments sections via crowd-sourced moderation and powerful community management tools. Civil Comments is the first commenting platform specifically designed to improve the way people treat each other online.
Unlike others who have thrown up their hands and accepted that the comments sections of the Internet would either be dominated by bullies and trolls, or become a moderation burden for a site's editors, the team at Civil is attempting to solve the problem with community moderation. It is an exciting new take on a widespread problem, and Chromatic is thrilled to bring Civil Comments integration to Drupal with a new contrib module.
It should be noted (and is on the project page!) that there is not currently a free version of Civil Comments. For the time being, it is only available with a subscription as Civil continues work on the platform, but from what I understand a free version is on the horizon.
It's a good time to press your advantage as a Drupal developer.
Drupal 8 has launched, and it's much easier now for Drupal developers to expose content and features on their sites via an API. The capability is built right into Drupal 8 Core. Some contrib modules are attempting to make such capabilities even better.Tags: acquia drupal planet
I had a question the other day on twitter as to if it’s possible to run drush sites aliases in parallel. Apparently I was asking the question the wrong way as @greg_1_anderson (Drush co-maintainer) told me that Drush supported –concurrent and apparently has for several years. In fact, its supported it so long and is so under used that they might remove it from Drush as a result :).