Recording from Sept 4th 2015 Drupal 8 critical issues discussion

Posted by Drupal core announcements on September 4, 2015 at 11:48am

We met again today to discuss critical issues blocking Drupal 8's release (candidate). (See all prior recordings). Here is the recording of the meeting video and chat from today in the hope that it helps more than just those who were on the meeting:

If you also have significant time to work on critical issues in Drupal 8 and we did not include you, let me know as soon as possible.

The meeting log is as follows (all times are CEST real time at the meeting):

[11:09am] alexpott:
[11:09am] Druplicon: => Remove all usages SafeMarkup::checkPlain() and rely more on Twig autoescaping [#2545972] => 157 comments, 29 IRC mentions
[11:09am] catch:
[11:09am] Druplicon: => drupal 8.0.0-beta15 => 0 comments, 1 IRC mention
[11:09am] GaborHojtsy: catch: woot :)
[11:10am] alexpott:
[11:10am] Druplicon: => #options often is escaped by the code that creates the render array, the render element should do this itself [#2560863] => 19 comments, 6 IRC mentions
[11:11am] alexpott:
[11:11am] Druplicon: => postgres changeField() is unable to convert to bytea column type correctly [#1031122] => 98 comments, 6 IRC mentions
[11:12am] dawehner:
[11:12am] Druplicon: => Add an API for data value updates to reliably run after data format updates [#2538108] => 37 comments, 11 IRC mentions
[11:15am] plach:
[11:15am] Druplicon: => Composite indexes are not correctly deleted/re-created when updating a field storage definition [#2561129] => 38 comments, 9 IRC mentions
[11:16am] plach:
[11:16am] Druplicon: => Blocks containing a form include the form action in the cache, so they always submit to the first URL the form was viewed at [#2504139] => 113 comments, 20 IRC mentions
[11:18am] plach:
[11:18am] Druplicon: => [meta] Provide a beta to beta/rc upgrade path [#2341575] => 69 comments, 32 IRC mentions
[11:22am] GaborHojtsy:
[11:22am] Druplicon: => Replace remaining !placeholder with @placeholder [#2506445] => 97 comments, 16 IRC mentions
[11:23am] GaborHojtsy:
[11:23am] Druplicon: => Drupal 8's APIs Defined => 0 comments, 1 IRC mention
[11:23am] GaborHojtsy:
[11:23am] Druplicon: => Replace !placeholder with @placeholder in hook_help() text [#2560783] => 38 comments, 5 IRC mentions
[11:32am] dawehner:
[11:32am] Druplicon: => Add an API for data value updates to reliably run after data format updates [#2538108] => 37 comments, 12 IRC mentions
[11:49am] Fabianx-screen: hook_post_update()
[11:55am] Fabianx-screen: node.post_update.php

How to setup Drupal on Codio in minutes

Posted by Microserve on September 4, 2015 at 11:18am
How to setup Drupal on Codio in minutesSep 4th 2015

Installing Drupal on a *local development environment, for the first time, can be a baffling process!
Place this file here, change that setting, connect to some server, something to do with lamp stack etc?

Luckily, with the emergence of cloud based IDEs (integrated development environments) like Cloud 9 and Codio, we can now make this process much simpler, accessible and efficient. For more on Cloud based IDEs, see Martin's post Coding In The Cloud.

In this post I'm going to guide you through a few steps, specific to getting Drupal up and running on Codio in minutes.

*This tutorial assumes that you are comfortable with using a terminal based interface and have a working knowledge of Drupal using the LAMP server stack.

Install Drupal on Codio in minutes

Step 1 - Register with Codio it's FREE!

Before anything else you need to visit codio and sign up to a free account.

Step 2 - Create a project

Once you have a Codio account, visit the dashboard page and choose New Project in the top right corner.

For the available starting point options, choose LAMP.  
This will setup a new Codio 'box' - A unique server instance for use with our project, which contains it's own LAMP stack, a new blank MySQL database and an integrated text/code editor.

Add a name and a description for our project, then select the visibility (private projects are a premium feature in Codio so leave it set to public unless you fancy paying for a subscription). Once you're happy, click create.

Step 3 - Install Server Utilities And Software

Just like Blue Peter, here's a script we made earlier

To complete your 'stack' you will need to add various add-on utilities 'to get all the bits talking to each other', these include: php5, php5-apache2, php5-pdo-mysql, php5-gd, mysql and composer.
Also before installing Drupal itself, we need to install drush, - an invaluable Drupal developer's shell/utility app which is full of useful commands for interacting with Drupal via the terminal, giving you the ability to install and enable modules/themes/profiles etc, clear site caches and various other tasks. (you can learn more about drush here).

You could install all of these parts manually, but as we are just trying to get to a stage where you can see and use Drupal quickly, I have provided a script below which automate the entire process for us. 

So...  Open the Codio terminal by going to 'Tools > Terminal' in the main menu and paste the following snippet of code and hit enter:

wget -O - | bash

*To understand what processes exactly are being automated, by  the above script, below is a long-hand version of what is happening in the background.

#A bash script is a text file that contains a sequence of commands for a UNIX-based operating system.
#! /bin/bash

#This installs all the parts you need for Drupal to work
parts install php5 php5-apache2 php5-pdo-mysql php5-gd mysql composer

#Installing drush 
composer global require drush/drush:6.*

#Start up the apache server
echo "parts stop apache2 mysql ; parts start apache2 mysql" > ~/
chmod +x ~/

#Create a random database password and grant user permissions to the database
pass=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 10 | head -n 1)
mysql -u root -e"create database codio; create user codio@localhost identified by '$pass'; grant usage on *.* to codio@localhost; grant all privileges on codio.* to codio@localhost"

#Print out the new username and password so a user can view it and use it
echo "user: codio"
echo "pass: $pass"
echo "db: codio"


When the script above has stopped running, look for the database username and password entries in the code. COPY THE PASSWORD! and paste into a text file or similar, we'll need it later.

Step 4 - Download Drupal Core

Close the terminal and reopen it again. - This will refresh our Codio box cache and let it know drush exists.

Let's install Drupal which will be easy with drush.

  1. Still in the terminal, move up a folder to the root of our box by using the following command:

  2. Now in the root we can install Drupal. The following command downloads the latest version of Drupal core and renames the parent folder from 'Drupal' to match our Codio environment's 'workspace' folder. Don't worry, this has no baring on you Drupal site name, it just prevents all our Codio urls being appended with /drupal.

    drush dl drupal --drupal-project-rename=workspace
  3. CD back into our workspace folder (the folder which now contains our Drupal files and the root of our running Codio box):

    cd workspace
Step 5 - Giving Drupal Access To Our Codio Database

Nearly there.

You now have our Drupal files all downloaded and ready to go. The only small bit left to do is update the database file.

  1. In the folder tree on the left of the Codio interface, go to workspace > sites > default.
  2. Make and in-place copy of the file default-settings.php and rename the new copy to settings.php.
  3. Our default folder should now containing both default-settings.php and the new settings.php. We do this so that we always have an unedited copy as back-up, should we mess up our custom copy.
  4. Open the new settings.php file.
  5. We're going to tell Drupal which database to use and which login credentials to use when accessing it. These settings are for our local environment only. When moving our site to a production environment (or to any other environment for that matter) we will need to update to reflect the database which we want the site to access. Here we're on our Codio box, so we're using our 'codio' database.
  6. Copy the code below and paste it in, below line 216.
  7. Replace the password for the one you copied earlier in step 3, then save the file (Ctrl + S). The database name and username will always be 'codio'. It's fine to leave these as they are, as on Codio there is a completely unique LAMP stack per project, therefore no chance of conflicting database names.
$databases['default']['default'] = array(
   'driver' => 'mysql',
   'database' => 'codio',
   'username' => 'codio',
   'password' => 'your_password_here',
   'host' => 'localhost',
   'prefix' => 'main_',
   'collation' => 'utf8_general_ci',
Step 6 - Install Our Drupal Site

Now to tie all the bits together and actually install the Drupal site from the file downloaded earlier. 

  1. From the top Codio menu, click the dropdown next to project index (static) and select box URL
  2. The browser will open a new tab with the new box setup and running.
  3. Notice the unique server alias url in the address bar (Codio will auto-generate one at random so it could be called literally anything).
  4. In the address bar, after the url add 'install.php' - for example
  5. Hit enter.

That's it, now just run through Drupal's normal installation process and you are good to go!


Installing Drupal can now be a (relatively) straight forward process without any faff. Plus the joy of Codio and many other cloud based IDE's is you can access them, wherever you have an Internet connection.

Super Charged Install Option

Its important to understand the steps above, but if you are in a real rush and need Drupal set up on Codio as quickly as possible, I'm also including the below automation script, which will automatically (duh!) take care most of these steps for you, including creating and editing our settings.php:

wget -O - | bash

To use this speedy set-up script do the following:

  1. Create a new Codio project only this time select default rather then LAMP.
  2. Open terminal and run the code above
  3. Skip to Installing our site like in step 6 - 'Install our Drupal Site'

* Foot Note
Although of course technically cloud based IDEs aren't 'local' to your specific machine (a possible advantage actually, as you can access them from any machine with an internet connection and the correct login), but here were are using Codio as 'local' development environment as opposed to a live production server.

Steve Furley's picture

Written by: Steve Furley, Front-end Developer

Microserve is a Drupal Agency based in Bristol, UK. We specialise in Drupal Development, Drupal Site Audits and Health Checks, and Drupal Support and Maintenance. Contact us for for further information.

Drupal 7 Panels: Page Manager User Pages

Posted by Jim Birch on September 4, 2015 at 9:00am
Lego Uncle Jim in the Pool

By default, Page Manager has the User Profile Page (/user/user-id) and the User Edit Page (/user/user-id/edit), but there are a few user pages that are missing, most obvious will be the login page.

The Drupal User Pages module is a simple module that is not that commonly used that adds in the important missing pieces by adding these four options to Page Manager:

  • User Login Page (/user/login)
  • User Password Page (/user/password)
  • User Page (/user)
  • User Register Page (/user/register)

Page Manager User Pages

Read more

Still on Drupal 6? Here are your options!

Posted by Zoocha Blog on September 4, 2015 at 7:23am

With the imminent release of a Drupal 8 Release Candidate, which could potentially be announced as soon the end of September at Drupalcon Barcelona, the clock has just started ticking a lot louder for those sites still on Drupal 6 with the looming support transition policy about to kick in:

Drupal 6 core and modules will transition to unsupported status three months after Drupal 8 is released. "Unsupported status" means the community will not be providing support or patches in the same way we do now.


If a similar timeline is followed, as Drupal 7 had from Release Candidate through to Full Release, then this realistically means that Drupal 6 (and Pressflow 6) will be lucky to be considered supported by the time that we are shaking off our New Years hangovers. Not an ideal situation for Drupal 6 site owners to find themselves in.

So what can you do if you're sitting on a Drupal 6 site?

  • Stay on Drupal 6 - The latest usage statistics suggest that you're in the same boat as nearly 130,000 other site owners, so it is probable that security patches and bug fixes will still surface on in one way or another beyond the official support period, while there are parties interested in prolonging the life of Drupal 6.
  • Upgrade to Drupal 7 - The safe bet would be start planning how you are going to take advantage of the continued support from by upgrading your site to Drupal 7 now -- but how? via the standard upgrade path, or by a re-build?
  • Upgrade to Drupal 8 - If you've stuck with Drupal 6 for this long, the opportunity to bypass any talk of a Drupal 7 to Drupal 8 in a few years time would probably appeal to you, so why not leap on to the bleeding-edge of technology, and go with Drupal 8 now and then stick with it for the next decade! There are even tools in the works to help you make the jump directly!

All three options have their merits, it just all depends on how much your are prepared to invest, wait, or how much risk you are prepared to take.

Knowing that nothing paints a picture quite like a graph with a subjective hyperbolic axis; here's our attempt at conveying the options that are on the table for Drupal 6 site owners:

Investment required for Drupal version number selection Risk associated with Drupal version number selection

Obviously staying put on your existing Drupal 6 implementation is going to be the cheapest option, with Drupal 8 being the most expensive as it will be a learning experience for any developer that works on it in the early days, with no small amount of time battling against a more limited set of module options that are likely to be littered with bugs initially. The risk graph above, was trying to illustrate that the risk of staying on Drupal 6 is high as it slips out of the official support period, while moving on to Drupal 8 before it is deemed a robust platform comes with its own set of risks (e.g. stability of platform, limited set of available modules etc.). If a time factor could be applied to the risk graph, then the risk of moving to Drupal 8 would obviously degrade as time passes by, and Drupal 8 matures.

What it boils down to, is that if you are risk averse, and are prepared to invest, the safe option is for you to upgrade your site to Drupal 7 as soon as you can. For those of you that are more gung-ho, you could sweat your existing Drupal 6 platform for a while longer, riding the risk of being on an unsupported release, and hang on long enough until Drupal 8 is considered robust enough before going ahead with the upgrade.

The Zoocha approach for upgrading from Drupal 6 to Drupal 7

If after weighing up your options you decide that upgrading to Drupal 7 is the prudent thing to do, then we have a straightforward, sensible approach that we have developed over the years that we would like to share, that will hopefully put you on the right path and save you time and money during the upgrade process. Depending on the complexity of your Drupal 6 site, there may even be time to upgrade to Drupal 7 before the official support period expires.

In our approach, the first thing we would recommend doing before a line of code is written, or an upgrade path is launched into, is to perform a Drupal audit and evaluation of the existing Drupal 6 site. We suggest doing this as it tells you if:

  • There are any contrib modules without a clear upgrade path to a D7 version.
  • The volume of custom code, technical debt, and level of re-factoring that will be necessary to upgrade the code to be compatible with D7. This goes for both the theming layer and custom modules.
  • Drupal core, or any contrib modules have been patched, or modified in any way beyond their original versions. If they have, then this is another problem to contend with.
  • The information / data / content-type structure is sound, and how / where it is stored.
  • There are any integrations worth paying heed to, and giving special consideration.
  • The code is locked to an older version of PHP, through use of functions that have been deprecated in recent versions of PHP.
  • How the content is surfaced to render the pages (through Views, Panels, Blocks etc.).
  • The theming layer is locked to an old version of a front-end framework without a clear upgrade path.

With this information known, along with any planned roadmap functionality considered, a balanced assessment can then be made as to whether it will be more cost-effective, with reduced risk and a better end result, to perform a re-build of the site in Drupal 7, rather than perform a standard upgrade. What you can also think about at this stage, is to see if there are any possibilities of compromise in terms of functionality, or improved module selections that can be made, such as calling upon some of the newer Drupal 7 only modules like Paragraphs and WorkBench, so that budgets and timelines can be met. At this point we would generally recommend producing an options appraisal that lays out in plain language what are the pro’s and con’s of each approach are, so that business owners can make an informed decision about where they want to take their platform / site.

Drupal 6 Upgrade - make sure that you script it!

If after performing the evaluation it appears that an upgrade will be possible, and is the more attractive option to the site owner, then we would generally advise that the upgrade approach as detailed on is followed. However, for non-trivial sites, we would advise against performing these steps manually, and instead encourage you to try to capture the upgrade process in code, via a bash script making use of Drush, and php where necessary. The reason why we suggest this is so that when you are developing locally, you can at any point bin your current attempt at an upgrade, and start again at any previous step, or alter the order in which you do things simply by re-running the script. On non-trivial sites, this can save you a great deal of time, and also makes it much easier for other developers to pick up where another left of, let alone the efficiencies gained when it comes to dealing with content-freezes and pushing the changes live. When the upgrade script is ready to go, it's an undeniably satisfying experience watching your terminal shell hammering through the script, with a shiny new Drupal 7 site coming out the other side!

One type of requirement that can often tip the balance in favour of the re-build approach, is that of a new mobile compatible, responsively designed theme. If your site is of any level of complexity, trying to upgrade a Drupal 6 non-responsive theme, whilst maintaining the site branding and design, to become a Drupal 7 responsive version is something that should not to be approached lightly. In cases like this we would always recommend using a new Drupal 7 starter theme (such as Bootstrap), and then using that as a basis for a refreshed design -- a Drupal themer experienced with Bootstrap would be able to create a new theme for a site using this method in about half the time (typically) compared to upgrading an existing Drupal 6 theme to the same responsive standard.

Re-build of a Drupal 6 site in Drupal 7

If a re-build in Drupal 7 is decided upon, then I'm sure we all have a favoured development process that we go with in the construction of a new site. If however you are inexperienced with Drupal 7, then it would make sense to engage a Drupal 7 specialist to help validate your architecture, approach and plan, and act as a sound board throughout development.

The final step that we would recommend undertaking in any upgrade or re-build, would be to verify that no content has been lost/corrupted, and all key user journeys and functionality operate correctly. There are quick ways of doing this, and not so quick, but we'll save the 'how' on this for another post.

What can you do to protect your site, come Drupal 6 support retirement day?

If you decide to stay on Drupal 6 (and hang on until Drupal 8 matures enough before trading up), it's time to batten down the hatches folks! Maybe that is being a bit dramatic, as if you look hard enough you'll find sites running Drupal 5 out there still doing a job. If a Drupal upgrade is out of the question, then now would be a good a time as ever to make sure that you are doing all that you can to protect your site via other means from the dark forces at work online.

The main thing that you can do to protect your site is to review your Drupal configuration against best practices, evaluate your current hosting / infrastructure and make sure that it is as secure as can be, and be vigilant in terms of monitoring, with a plan to revert to backup should something go wrong. In the unlikely event that another SQL injection compromise in Drupal core is discovered akin to the recent 'Drupalgeddon' vulnerability, then there is very little you can do to counter this, short of wait for a fix to surface on and to apply it as quickly as you can.

At the server level there are several mitigations that can be made (hat tip to mig5 for some of the suggestions that follow), along with Drupal practices that you can employ that will collectively go a long way to protecting you in the post Drupal 6 support era, even if your site is running modules that are technically deemed insecure. The following list is by no means exhaustive, applies to any version of Drupal, and would be a good starting point for you to measure your infrastructure and Drupal configuration against:

1) Maintain regular backups

The most important thing you can do is to maintain regular backups of both the Drupal codebase, user files and database. If something then goes bad, or a compromise occurs, then you can revert to the last known safe backup (on entirely new infrastructure if needs be). Just make sure that you keep your back-ups on a different server to your production box.

2) IP Restriction

If practical, restricting access to your Drupal administration area (/admin) by IP address (or range) is a highly effective way of cutting off external access to the admin UI. This wouldn't stop a privilege escalation exploit in Drupal, but it could still protect access to those admin areas, which would be re-assuring to have in place in the event of an admin password leak for instance.

3) Update core and contrib modules

Make sure that you keep your Drupal core and contrib modules up to date, until turns off the taps. When they finally do, then you will want to make sure that you are on the latest version of everything where possible, libraries included.

4) Stay on top of your server updates

It's all too easy to fall behind with your server software updates if you are managing them yourself / in-house. Try to at least once a week run the operating system software updates, and immediately upon a 'Heartbleed' esque threat.

5) Add a security certificate

If nothing else, it demonstrates to your users that you take security seriously, and prevents credentials any other potentially sensitive information being sent in plain text. Security certificates are cheap and easy to install, so there is no reason not to have one.

6) Ensure that you are not running an any standalone app's, or other sites within the Drupal codebase

It's more common than you think seeing a WordPress install or some such, nestled in the Drupal codebase (think that perhaps arrived there as a standalone marketing campaign and not touched again since it was hastily deposited there. This obviously leaves a potential security hole that you'll want sow up, so think about moving such invaders elsewhere, and configuring your web-server to handle their new locations.

7) Replace Apache/PHP with Nginx/PHP-­FPM

Replacing Apache/PHP with Nginx/PHP-­FPM, and using a 'hardened' Nginx config will provide several improvements to security, and even potentially increase the performance of a site. One of the ways it does this is by restricting the ability of the server to execute php files, so that you can give execute permission to specific named files only, such as index.php and cron.php. What this particular measure would do is protect you in the event that someone managed to get a malicious php file on to your server, and prevent them from ever been able to execute it. The other thing you should do here is turn off the core PHP module.

8) Information disclosure

The default Drupal codebase contains a number of innocuous files that give information away about the version of Drupal you are on, such as Preventing access to these, or removing them altogether can make it more challenging for attackers to determine your configuration via automated tools. Also hiding information such as the version of PHP and other server side software / extensions that you are running will help too.

9) Install php5­suhosin

Suhosin (pronounced 'su-ho-shin') is an advanced protection system for PHP installations. It was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core. Suhosin comes in two independent parts, that can be used separately or in combination. The first part is a small patch against the PHP core, that implements a few low-level protections against buffer overflows or format string vulnerabilities and the second part is a powerful PHP extension that implements numerous other protections.


Installing php5­suhosin with the default settings will improve the overall security of your platform, but watch out for any undesired consequences of it being in place, such as POST request limits.

10) Install OSSEC + Anti-Virus

Installing OSSEC, even in standalone mode ­ to monitor for intrusion attempts and unexpected changes to files, and potentially block them. OSSEC will then trigger alerts when it detects something amiss, such as:

  • rootkit and trojans (viruses)

  • alerting to poorly configured files e.g. files with insecure permissions

  • attempted brute force logins to any administration area

  • other anomalies in the system (unexpected change in network services, logs generated by the applications that might indicate a problem e.g. syntax errors, resource issues).

We would also recommend implementing other rootkit and virus scanning software on Linux servers (such as RKhunter and ClamAV) to further augment the detection of malicious software.

11) Update the admin username

If you set the site administrator role to have a username other than admin, and then you will thwart the bulk of brute force attacks that assume this user exists.

Putting it all to the test

Once you are confident that you have made all the security improvements you are able to on your platform, then you should put it to the test -- one such tool that can help you here goes by the suitably scary name of Zed Attack Proxy which is an Open Source penetration testing tool:

The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.

It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.

ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.


Running ZAP over your site on a scheduled basis, analysing the results (including what your monitoring says) and taking any remedial action should give you confidence that you've done everything you can to secure your platform.

Hope you found this article useful, and please let us know in the comments if you spot any errors, or have any advice for Drupal 6 site owners that is pertinent right now, along with any recommendations about how such folk can protect their sites come the time when Drupal 6 is no longer supported!

HTTP Authentication for specific domain in Multisite environment

Posted by KnackForge on September 4, 2015 at 7:10am
I'm running a multisite Drupal installation, Drupal's multisite allows me to run different websites off the same set of PHP files, but with different databases (so different content). Like,, and All of them point to single folder in my server.   What should be added to .htaccess file to use http authentication only for without affecting others ( and   I have used below code to achieve what i want..  
  1. # set the "require_auth" var if Host ends with ""

Authoring Experience (AX) Best Practices for Images in Drupal

Posted by Chapter Three on September 3, 2015 at 7:43pm

Do you add content to Drupal websites? Have you ever found yourself in the process of uploading an image, with no clue what size to upload? Or whether Drupal will scale or crop the image? If so, you’re not alone.

Drupal sites get built a million different ways because of scope, budget and time. Because of this, sites behave differently. One site may automatically crop and scale an uploaded image to fit within a template. Another may require you to do that work before hand. This behavioral inconsistency can leave admins guessing as to how the site behaves.

You might be thinking “But we account for this during training.” Many teams train clients how to use their sites during a hand off. They account for any lack of help text with verbal explanations. While that trained client maintains the site, everything may go fine. But what happens when that person leaves and another person takes over? Do they get trained? Is there documentation?

WHITEHOUSE.GOV Puts Open Source on the Map

Posted by Promet Source on September 3, 2015 at 7:35pm

Obama's presidency has been marked by a number of technological firsts: Obama's been unofficially dubbed the "social media President" as he was the first sitting US president to have a twitter account, his campaigns embraced methods such as email marketing and by all accounts he's the first president to use a selfie stick. Yup.

Drupal Slideshows with FlexSlider from WooThemes

Posted by OSTraining on September 3, 2015 at 7:22pm
drupal flexslider

Flexslider is a jQuery plugin by WooThemes and it makes it very easy to create slideshows.

You can integrate it into Drupal easily, using the FlexSlider module which has full Views integration.

The FlexSlider page on, shown below, gives you an idea of the slideshows you can build with FlexSlider.

Flashback Friday - DrupalCon Barcelona in 2007 and 2015

Posted by DrupalCon News on September 3, 2015 at 6:52pm

If you have deja vu when we say DrupalCon Barcelona, you could be one of the people who attended DrupalCon Barcelona back in 2007! In true Throwback Thursday fashion, we are going to break down the tried and true things that have been the same for the past eight years, and what you can expect to be different at our upcoming DrupalCon.

Responding to Drupal's highly critical SQL injection vulnerability

Posted by Colan Schwartz on September 3, 2015 at 6:26pm logo Digg logo Facebook logo Favorite logo Google+ logo logo LinkedIn logo Reddit logo SlashDot logo StumbleUpon logo Technorati logo Twitter logo Topics: 

On October 15th, 2014, the highly critical SA-CORE-2014-005 - Drupal core - SQL injection vulnerability was announced. Shortly afterwards, research showed that sites not patched that same day could very well be compromised. Two weeks later, a public service announcement was released explaining the gravity of the situation. There was also a FAQ, a flowchart for dealing with it and a module that could potentially confirm a compromised site. Needless to say, it was a challenging time for the community.

At the time, I was asked by a client of mine to analyze a site to determine risk.

Some common attack vectors associated with the vulnerability were:

  • Changing the superuser's (user ID 1) username, password or e-mail address.
  • Adding new users to the user table with the administrator role (usually ID 3).
  • Adding entries to the menu_router table.
  • Adding PHP files to the code base or in the sites/all/files directory.
  • Adding nodes (pages) or blocks with executable PHP.
  • Downloading the list of user passwords
  • Determining hackability through the version listed in CHANGELOG.txt
  • Spawned processes run by the Web server
  • Adding new roles
  • Permission changes

So based on the above, and some other sources, it was possible to produce a list of things one could look for to determine if a site had been compromised. As has been discussed elsewhere, failure to confirm any of these did not mean the site was not compromised, but it did provide some indication of risk.

  1. Rerun the Security Review module.
  2. Perform checks with the Drupalgeddon & Site Audit modules.
  3. Check for changes to user 1's username, password or e-mail address.
  4. Check all users in roles other than "anonymous" and "authenticated".
  5. Check for strange entries in the menu_router table.
  6. Check for code files outside of version control.
  7. Check for code files inside sites/all/files.
  8. Check for new nodes or blocks in the DB.
  9. Check for strange processes spawned by the Web server user.
  10. Check for any new roles.
  11. Check for any permission changes.
  12. Check the mail logs for anything suspicious being sent out.
  13. Scan site with the Sucuri tools Free Website Malware and Security Scanner and Unmask Parasites.
There are some worthwhile things to note with respect to the checklist above:
  1. Some of the clues (such as 5 and 6 above) would have been long gone as they're rebuilt during cache clears and deployments.
  2. It's theoretically possible that malicious processes could have been spawned by the Web servers. The names could have been renamed to look non-malicious, but unless something was set up to make these persist across power cycles, they would be wiped on a system reboot.
  3. It's also theoretically possible that user passwords could have been compromised. In Drupal 7, hashed passwords are salted, but the random string used for the salt could have been read as it's in sites/default/settings.php. With that in mind, the site would be susceptible to brute force, dictionary and rainbow table attacks. If the site isn't going to be rebuilt, it would be a good idea to expire all passwords and forcing users to reset them. If another system is handling authentication, this isn't an issue.

And of course there could be any number of other things. The best course of action would be to rebuild the site. If that's a challenge, always consider the level of risk before deciding not to. Hopefully we won't have to make too many of these determinations in the future.


This article, Responding to Drupal's highly critical SQL injection vulnerability, appeared first on the Colan Schwartz Consulting Services blog.

Building Drupal Web Sites in China: The Existing Landscape

Posted by Acquia Developer Center Blog on September 3, 2015 at 5:02pm
Adam Malone

After working with both Chinese customers and global customers with a Chinese user base, we at Acquia have developed an understanding not only of the sometimes difficult requirements faced, but also the existing state of both sites and platforms.

Tags: acquia drupal planet

Require JS, Grunt, Bower, Foundation, Compass and Drupal - Let’s just be friends, with benefits.

Posted by Cheeky Monkey Media on September 3, 2015 at 4:41pm
Require JS, Grunt, Bower, Foundation, Compass and Drupal - Let’s just be friends, with benefits.

In depth, but not too deep

Okay, so you want to use RequireJS to manage and organize your JS and all the dependencies, in a modular way. You also don’t want deal with RequireJS caching the heck out of your JS changes during development, otherwise...Derpal..  but, you do if you’re ready for production.

Also...  Compiling with Grunt (compass), component package management with Bower, and having it not interfere with Drupal. (.info files… we’ll get to that).

And finally, I’m not a fan of installing ruby gems and all that globally...

InternetDevels on Clutch’s Top Ukrainian Developers List

Posted by InternetDevels on September 3, 2015 at 2:01pm
InternetDevels on Clutch’s Top Ukrainian Developers List

Hey Drupalists! Any news – fine or great? Because we cannot restrain our emotions for longer: American researcher of world’s IT industry Clutch ranged us as one of 12 Top Web and Software Developers in Ukraine. Not bad, yes? Especially if to take into account that we are the only Drupal developer on the list.

Read more

Why Drupal, Why Now? An Agency CTO’s Perspective

Posted by Acquia Developer Center Blog on September 3, 2015 at 1:22pm
Corey CapletteReason #1: Drupal is Technology Ready

For the past 15 years Velir has been customizing and implementing top-tier content management systems. Given our focus on creating digital solutions, content management is at the core of almost every project we take on.

We’re veterans in the CMS space, but up until recently we exclusively worked with commercial CMS platforms. As the CTO of my agency, I wanted to explain why we’ve now decided to take the leap with Drupal.  

Tags: acquia drupal planet

Pane Field: World domination with ctools panes inside your content

Posted by .VDMi/Blog on September 3, 2015 at 12:29pm
 World domination with ctools panes inside your contentIf you're building flexible content with something like Paragraphs and build your sites from an editors perspective, you will really like this one. Pane Field brings the ease of ctools panes to Entity Fields. With this modules you can use ctools panes inside your content!

Pane Field is a new Drupal module by VDMi.
Most of the time we will give our users 3 Paragraphs types:

  • Text (just a simple WYSIWYG and a title field)
  • Text with image (simple WYSIWYG, title field, image field (media/scald/image), image position)
  • Image (media/scald/image)

Over time we learned that when content editors discover such flexible content, they immediately start thinking about exceptions. You’ll probably get some questions about “special” content like animations, videos and call-to-actions. That's where Pane Field comes in!

While most of these exceptions can be implemented in Paragraphs, it’ll become a problem when you have 10 different animations, or 10 different call to actions and the list keeps growing. That’s why we thought of another way to keep the ease of content editing, but have the flexibility of ctools panes. Which gives you - the developer - an very easy way to quickly create new pieces of content that the editor can use.

Ctools panes (also known as content types) are simple ctools plugins that basically define what they are, how they are configured and how they should be rendered. A definition is placed inside the same file that takes care of configuration/rendering. The definition will look something like this:

 * Plugins are described by creating a $plugin array which will be used
 * by the system that includes this file.

$plugin = array(
  'title' => t('Buy our product'),
  'description' => t('Buy our product and get another one for free call to action.'),
  'category' => t('Call to Actions'),
  'edit form' => 'shop_cta_buy_our_product_edit_form',
  'render callback' => 'shop_cta_buy_our_product_render',
  'admin info' => 'shop_cta_buy_our_product_admin_info',
  'required context' => new ctools_context_required(t('Node'), 'node'),
  'defaults' => array(
    'title' => 'Improve your daily workflow with our turboblender',
    'subtitle' => 'Buy now and get one free!',
    'button' => 'Buy now!',
    'button_link' => 'order',

The callbacks will look like this for a simple pane, they are in the same file as the definition:

 * 'Edit form' callback for the content type.
function shop_cta_buy_our_product_edit_form($form, &$form_state) {
  $conf = $form_state['conf'];

  $form['title'] = array(
    '#title' => t('Title'),
    '#type' => 'textfield',
    '#default_value' => $conf['title'],

  $form['subtitle'] = array(
    '#title' => t('Subtitle'),
    '#type' => 'textfield',
    '#default_value' => $conf['subtitle'],
    '#maxlength' => 2048,

  $form['button'] = array(
    '#title' => t('Button'),
    '#type' => 'textfield',
    '#default_value' => $conf['button'],

  $form['button_link'] = array(
    '#title' => t('Button Link'),
    '#type' => 'textfield',
    '#default_value' => $conf['button_link'],

  return $form;


function shop_cta_buy_our_product_admin_info($subtype, $conf, $context) {
  $output = new stdClass();
  $output->title = '';
  $output->content = '<strong>'. t('Title') . ':</strong> ' . check_plain($conf['title']) . '</br>';
  $output->content .= '<strong>'. t('Subtitle') . ':</strong> ' . check_plain($conf['subtitle']) . '</br>';
  $output->content .= '<strong>'. t('Button') . ':</strong> ' . check_plain($conf['button']) . '</br>';
  $output->content .= '<strong>'. t('Button Link') . ':</strong> ' . check_plain($conf['button_link']) . '</br>';
  return $output;

function shop_cta_buy_our_product_render($subtype, $conf, $panel_args, $context) {
  $node = $context->data;
  $block = new stdClass();
  $block->title = '';

  $content = array(
    '#theme' => 'shop_cta_buy_our_product',
    '#path' => drupal_get_path('module', 'shop_cta'),
    '#title' => $conf['title'],
    '#subtitle' => $conf['subtitle'],
    '#button' => $conf['button'],
    '#button_link' => $conf['button_link'],

  $block->content = $content;

  return $block;

And there you go, you created a new piece of custom content for your website. In the theme function you can use a template that has some custom HTML. Now you can enable the pane in the instance settings of the pane field:

As you can see, your new pane is available, all default ctools panes are also available.

When you edit content, you can now add a new Paragraph, select the paragraph type with the pane field and then select the new ctools pane:

You’re probably wondering “WHY?” at this moment

Pane Field causes extreme flexibility in your content without the hassle of creating a new paragraphs type, adding fields to them, adding preprocess functions, creating a bundle template. It allowes you to create exceptions to your base types much faster. It also is faster (in CPU time) compared to using a new Paragraphs type because it’s not a new entity, it’s just a field value with a reference to the ctools pane and some configuration values.

One big note: because the pane configuration is simply stored serialized in the field value, you can’t use them in stuff like Views or Search API (you can render the field and index that though).

Here is a more comprehensive article about how to write content panes.

Upgrading a Drupal distribution

Posted by Colan Schwartz on September 2, 2015 at 10:54pm logo Digg logo Facebook logo Favorite logo Google+ logo logo LinkedIn logo Reddit logo SlashDot logo StumbleUpon logo Technorati logo Twitter logo Topics: 

Upgrading Drupal distributions, technically referred to as installation profiles, can be tricky. If you aren't using Drupal Core, but rather a distribution of it, it's not possible to follow standard processes for upgrading Drupal core and contributed modules. You must upgrade the distribution as a whole.

In this article, we'll be working with the Web Experience Toolkit (wetkit) as the example distribution.

Assumptions Steps
  1. Switch to your Web directory and make sure your working tree is clean.
    1. cd $(drush dd @site); git status
  2. Note any commits made to the distro since it was last upgraded. These will have to be reapplied (cherry-picked in git-speak) after the upgrade unless they were explicitly added to the distro in the latest release. Find them with this command.
    • git log profiles/wetkit/
  3. Make sure that you read and understand any distro-specific information on upgrading it. In this example, the documentation is available over at Release Cycle / Updates.
  4. This is a workaround until Drush up should update contrib profiles as well is fixed. Download the distro with the following command. For the version number, use the version that was released immediately after the version that you currently have installed. For example, if you have 7.x-1.4, you need to download 7.x-1.5. If you're multiple versions behind, you'll need to repeat these instructions multiple times. Jumping more than one release ahead could cause problems.
  5. Unpack it.
    1. tar zxvf /tmp/wetkit-7.x-Y.Z-core.tar.gz --directory /tmp
  6. Move your sites folder out of the way so that it won't be overwritten. It's necessary to do this as the administrator to maintain permissions on the files directory.
    1. sudo mv sites /tmp
  7. Copy the new release's files into your Web dir. Don't copy core's Git ignore file; keep ours. This is a workaround for Rename core .gitignore file to example.gitignore and add explanatory comments.
    1. cp -r /tmp/wetkit-7.x-Y.Z/.htaccess /tmp/wetkit-7.x-Y.Z/* .
  8. Replace the new default sites dir with our own.
    1. rm -rf sites
    2. sudo mv /tmp/sites .
  9. Remove the distro-specific Git ignore files, as they'll cause us to ignore files we shouldn't.
    1. rm $(find profiles/wetkit -name ".gitignore")
  10. Stage all of the changed files.
    1. git add --all
  11. Commit the upgrade with a comment like, "Issue #123: Upgraded the WxT distro from release 7.x-A.B to 7.x-A.C."
    1. git commit
  12. Cherry-pick each of the commits that you noted in the first step. Ideally, these are upstream patches that you either found or posted yourself while working on the distro. For each commit message, use something like "Issue #567: Applied patch from" so you'll know if you'll be need to re-apply it again, or if it's been committed (and you no longer need to worry about it).

    1. git --edit cherry-pick COMMIT_ID_1
    2. git --edit cherry pick COMMIT_ID_2
    3. ...
  13. Update the database schema.
    1. drush updb
  14. Clear all of the application caches.
    1. drush cc all
  15. Test the local site to ensure everything is working.
  • Whenever we override the distro's module versions in sites/all/modules/contrib (this should be an extremely rare occurence, if ever), we should set up Profile Status Check. In fact, it probably wouldn't hurt to include this module in all of the official distributions.

This article, Upgrading a Drupal distribution, appeared first on the Colan Schwartz Consulting Services blog.

From Our Sponsor: Managing Data with Drupal

Posted by DrupalCon News on September 2, 2015 at 9:08pm

There has been a radical shift in how enterprises want to use Drupal. Their focus is moving from sites to integrated services., and this change is typically accompanied with a set of new technologies, such as MongoDB and Node.js. Still, the role of Drupal has become more central than ever. How?

Drupal: Add new operators to views filters (such as contained in CSV) or how to override default view's handlers

Posted by DrupalOnWindows on September 2, 2015 at 8:21pm
Language English

Today I'm going to show you how to turbo boost Drupal's default views filters with an example on how to add  a "Conatained in CSV" operator for Numeric and String filters.

Imagine a user wants to perform a batch operation on entities with ID's X, Y and Z. Unless they all appear on the same page, or you set the page size to inifinte this is impossible because Views Bulk Operations won't let you manually pick items between searches and/or pages.

We want something like this to happen:

More articles...

The Top 7 Reasons To Use Drupal In Higher Education

Posted by Axelerant Blog on September 2, 2015 at 6:00pm

In recent years, using Drupal in higher education is a popular choice among leading schools. It has become the preferred website platform for hundreds of higher education institutions around the world. Schools like Harvard University, University of Adelaide, Bentley University, Uncommon Schools, University of Waterloo, and Yale all agree that Drupal is the content management framework that supports the current and future needs of students, faculty, alumni, and their communities.

In short, Drupal has proven it serves higher education website needs. Here are seven specific reasons it's best for your school.

The Top 7 Reasons To Use Drupal In Higher Education I am Ready for College - Drupal at Universities

1. Multi-Site Functionality

Most universities and colleges maintain multi-faceted websites, ones that serve a broad range of purposes. By leveraging Drupal's inherent multi-site functionality, institutions provide their departments with a substantial toolbox and relevant media types for communicating with students, staff, and other users via a single system.

This multi-site capability helps institutions break out independent websites by giving control and ownership to individual departments. This significantly reduces administrative overhead from the IT office.

2. Easy Responsive Design Implementation

According to an eMarketer study, an estimated 90 percent of US college students will own a smartphone by the time they graduate in 2016. Another study done in 2012 has published findings that "nearly half of all 18 to 29 year-olds using the Internet, do most of their online browsing on their mobile device."

Academic centers can use Drupal to stay up-to-date and relevant to users by delivering smoother, responsive website experiences. Experiences from each user's device of choice. Drupal sites adapt to user evolutions, making it optimal for institutions with student demographics.

3. Workflow Modules

Drupal's Workflow modules and features set allows universities and colleges to control and manage the publication process effectively, without limiting its use as a mere content management tool. There's granular control available for every content publishing processes. At each step, employees can be notified to complete their tasks (like copy editing). This keeps team members from performing tasks out of order.

4. Content and User Access Control

With Content and User Access Control, site administrators can create privileges grouped together by access level, function, and role. These permission sets can be assigned to groups of users rather than manually granting privileges to each and every user. Permission sets help decentralize task responsibilities like creating, editing, and managing content. All without putting extra workload on your IT hub. These access control features are exceptionally handy with respect to university websites where professors, students, alumni, and site visitors require unique user experiences and different access rights.

5. Efficient Use of Taxonomy System

Drupal's taxonomy system is a robust method for classifying website content into groups. Taxonomy systems can be designed and deployed on a per-content basis. This ensures extremely efficient content categorization on the site, resulting in ease of access for site visitors or users. Through taxonomy usage only relevant content is delivered to user; this avoids distractions and simplifies navigation.

6. Collaboration Modules

Apart from forward-facing content—static pages, forums, course schedules, blogs, and articles—Drupal provides powerful collaboration features and document management for back-end users. These systems are not typically part of the public front-end, but are critical for faculty and students who require access to manuals, handbooks, procedural guides, and research documents. Because of its tools for collaboration, Drupal is arguably the best tool for supporting internal teams and research for university and college websites.

7. Single Sign-On

Most every higher education institution has existing authentication systems for email or other internal accounts. Through Drupal using LDAP and CAS, single sign-on academic websites are easily possible. These single point access integrations result in a secure environment for users to multiple resources and services through a single login.

Drupal Distributions for Higher Eduction

Want to get started with Drupal? There are complete Drupal distributions like OpenAcademy, OpenEDU, and OpenScholar for kickstarting educational sites. These higher education Drupal distributions will provide your academic website with relevant and highly useful features with little effort from your end.

Want More Help?

Axelerant has worked on multiple higher education projects, like SUNY Maritime's Drupal migration. Contact us below and we'll talk about how we can make Drupal happen for your institution.


The post The Top 7 Reasons To Use Drupal In Higher Education first appeared on Axelerant.

Drupal 8 beta 15 on Friday, September 4, 2015

Posted by Drupal core announcements on September 2, 2015 at 4:38pm
Start:  2015-09-04 00:00 - 23:30 UTC User group meeting Organizers:  catch xjm

The next beta release for Drupal 8 will be beta 15! (Read more about beta releases.) The beta is scheduled for Friday, September 4, 2015. To ensure a reliable release window for the beta, there will be a Drupal 8 commit freeze from 00:00 to 23:30 UTC on September 4.

Beta 15 will include a couple of important API changes. See SafeMarkup::set(), SafeMarkup::checkPlain(), and other methods are removed from Drupal 8 core for details.


Subscribe with RSS Subscribe to aggregator - Planet Drupal