My first site on Drupal 8. Or securing a Drupal site like a paranoid.

So, I just upgraded my first site to Drupal 8. Yup. It's in production right now. And it has an animated gif front and center.

In a couple of posts in the coming weeks I will talk about some experiences that I gained from it. Gotchas, goose-bumps moments, raging at the screen and all the other emotions we developers go through in typical day.

But first a couple of words about the over-all process.

The site itself is a pretty simple site. It is about the mobile game Crash n Dash (check it out by the way). It contains a front page, where we also display a somewhat real time statistic of online users. And it has a high scores list. As you probably understand, this requires a custom module, so there was that. Also, we have a simple custom theme, built on the Foundation framework. So there was that.

This allowed me to learn more about making a module in Drupal 8, the guzzle library for making requests, some good ol twig for the theme. I'll cover my findings in separate posts later.

Second, a word about security. Since Drupal 8 is alpha still, who know what kind of bugs and potential security holes you can find in there, right? So I ended up disallowing login through regular channels. Since this particular server is behind varnish, disallowing on the default address was really easy, I just put this in my vcl file:

  if ( == "") {
    unset req.http.Cookie;

What this does, is effectively denying all logging in to your site on port 80, since no user ever will get a cookie.

OK. Well that does not stop someone from logging in if they find the apache port, right? So I put this in my virtual host for the domain (in the directory directive):

Order Deny,Allow
Deny from all
Allow from
Allow from x.x.x.x # <- my own ip, so I personally can log in to the site.
AllowOverride All

Of course this does not cover all kinds of other tactics that some people might want to try, but at least we are limiting the possibilities to do harm.

So next project on d8 is this blog. I mean, as developers, do we really have any excuse for not moving to Drupal 8 with these simple blog sites we put up? I am moving right after I get my feet wet with the migrate module in d8, as I have really enjoyed the projects I have used migrate for earlier.

Full disclosure: I am also the author behind the website mentioned, and the game referenced in that site. It's a free game, but I think it is still fair to mention. This blog post is a cross post from Crash n Dash tech blog and is in part written for shameless self-promotion :)

Let's end the post with the animated gif that actually is on the front page of that shiny new Drupal 8 site.

One-liner for fetching the live-database on your dev server (or localhost)

So when I first realised that I was neglecting this blog, I somewhat found comfort in that at least it hadn't been a year, right? OK, so now it has almost been a year. Does that mean I have stopped finding solutions to my Drupal problems (as the "About me" block states)? Well, no. The biggest problem is remembering to blog about them, or finding the time. But finding the time is not a Drupal problem, and I most definitely have not found the solution to that problem. Anyway, I digress. Let's end the streak with a quick tip that I use all the time: Syncing live databases without having drush aliases.

If you use drush-aliases, you could just do drush sql-sync. But for me, even if I do, I still prefer this method, as I find it extremely easy to debug.

First I make sure I am in my Drupal root:

$ cd /path/to/drupal

Then I usually make sure I can bootstrap Drupal from drush:

$ drush st

If that output says my database is connected, then let's test the remote connection:

$ ssh "drush --root=/path/in/remote/server st"

If that output also says we are connected, it means we are good to go, with my favourite command ever:

$ ssh "drush --root=/path/in/remote/server sql-dump" | drush sql-cli

If you have a drush-alias for the site, you can also go:

drush @live-site-alias sql-dump | drush sql-cli

Drupal and HTTP requests revisited

Background: Read this older blogpost.

So I just made a new theme for my blog, and as it turns out, I got one extra HTTP request. I started using Font Awesome with the theme and the file is too big to be embedded as a base64 encoded font. Darnit. So up to 2 internal HTTP requests.

But anyway, I made a new direction in how to cache my css, and the result is way better for mobile.

Quick tip for dev sites with advanced integration

Where I work, we have some bigger clients where we have some advanced integration systems with their accounting systems, stock control, exports to old windows systems, and the list goes on. So these things are not something we want to (or in many cases can) run on the dev version of the site.

To keep things still in version control, and not having to turn things off when dumping in a fresh database copy, we use the $conf variables in settings.php

The file settings.php is not checked in in git, and this is also where we automatically turn off js and css aggregation, by for example setting

$conf['preprocess_css'] = 0;

And some other stuff. But we also add our own variable.

$conf['environment'] = 'development';

This way we can do a check in the top of all integration functions:

if (variable_get('environment', '') == 'development') {

So keeping this in our production code, ensures that integration functions are not run when testing on a dev site. Also, a lot of cron functions are moved to a separate drush command, and run by the server cron instead of implementing hook_cron(). This will then never be run on the dev site.

I am sure everyone has their own way of doing similar stuff, so please feel free to share your similar tricks, or improvements, in the comments.

Drupal in 1 HTTP request: Results!

A while back I wrote a blog post about loading my homepage in 1 HTTP request. As I said back then, this was only an experiment, but as promised I have done some testing to see if this was any use at all.

A short repeating for those who does not want to read the whole (previous) article: The front page of this website is loaded in 1 internal HTTP request. All images, CSS, media queries, javascript are in one flat HTML file, served directly from the server cache. So, then you open your inspector and find out google makes 2 requests, and I have the twitter feed loaded async. OK. But 1 internal.

First, let me explain how I did the tests. I did it locally (so network lag should not be an issue), and with phantom js, a headless webkit browser. So this should mean that the page is fully loaded in a browser at the times presented, and that it's not just the request that is done. I also did 1000 runs on each setting, just to have a lot of numbers. I never tried it going back to normal images instead of base64 encoded though. Should probably do that too at some point. Anyway, here are the results:

How to create webforms programatically

Well, not really. I mean, you can create webforms programatically pretty easily. This tutorial will show you how easy. Or you could just use the rules module if you just want the node created. But also, I want to share the things that got me scratching my head, like creating the description of each webform component programatically.

I am sure you have had this scenario as well. You enabled the webform module and tought the site admins how to create them and add components. But each time they want to create a new webform, they send an email to you asking for help, and you practically end up creating the nodes for them, since it has already been 3 weeks since last time you told them how it was done. Ok, so let's make it dead simple for them. Create a node with a title, and put all components in the body - one per line. Ah, no more emails, and code nerds can go back to their terminal and away from clicking with a mouse.

Use case:

So I have this site where you can sign up for parts of an order. Like a co-op. Let's say we are ordering kittens. So an admin puts out the news that he is shipping out a new order, and these are the kittens that are up for grabs.

  • Grey kitten
  • Black kitten
  • Killer kitten
  • Clown kitten

We want to create a webform to find out how many kittens of each type the users of the site would want in this order.

So instead of me telling the admins to create a webform and add numeric components for each kitten, I just tell them to go ahead and click the big button that says “create order” (visible for admins only). In the title field, they give the order a name (like the name of the supplier) and in the body field they list all kittens available, one kitten per line. Optionally they can also add an URL to an animated gif of the kitten, if included on the same line in a parentheses. So much easier for them, so they can concentrate on kitten distribution instead. I also added a description field so they can use that for a closer description of the order. Ok, so this is the code (Drupal 7 obviously):

Virtual host, hosts file, downloading and enabling modules and installing Drupal in one line.

Woah, that's a long title.
So, just wanted to share the little shell script I use for setting up local development sites in a one-liner in the terminal. Be advised that I don't usually write shell scripts, so if you are a pro, and I have made some obvious mistakes, please feel free to give improvements in the comment section. Also, while i have been writing this post, i noticed that Klausi also has a kick ass tutorial and shell script on his blog. Be sure to read that as well, since the article is much more thorough than mine. But since my script is for those even more lazy, I decided to post it anyway.
The idea I had was pretty simple. I constantly have the need to set up a fresh, working copy of drupal in various versions with various modules, i.e for bug testing, prototyping, or just testing a patch on a fresh install. While drush make and installation profiles are both awesome tools for a lot of things, I wanted to install Drupal without making make files and writing .info files, and at the same time generate the virtual host and edit my hosts file. And why not also download and enable the modules i need. For a while I used just

$ drush si

(site-install) on a specified directory for flushing and starting over, but part since I have little experience in writing shell scripts (I said that, right?), I thought, what the hey, let's give that a go. Fun to learn new stuff.
On my computer the script is called vhost, but since this is not a describing name, and the script is all about being lazy, let's call it lazy-d for the rest of the article (lazy-d for lazy drupal. Also, it is kind of catchy).

Drupal and HTTP requests - how low can you go?

New theme, new code. Click here to read about the way I use cache, and limit HTTP requests now.

Disclaimer: This is an experiment, and would probably not apply to most websites (if any). My mission: Load my homepage in 1 HTTP request without compromising layout or functionality. Just to be clear, the motivation is not to gain any performance from this, just to see if I can do it.

So, back to the point. Drupal has a lot of css, js and image files by default. To load them all you have to ask the server to serve them to you, simple as that. So if you have to ask less times, the page would load faster. In theory. This blog has over 40 requests on the front-page, out of the box. Luckily, Drupal has a number of tools you can use to minimize requests, and among them is the optimization you can find in core. You can find it under the “performance” settings (depending on what version you are on, this is located under “configuration->development” or “site configuration”). Cool. But this still leaves me at more than 10 HTTP requests. I want less! So what next.

Creating nodes with images using phonegap and services

A lot of different people has started experimenting with Phonegap and Drupal. You have Jeff Linwood and his Drupal plugin for Phonegap for iOS, and I just discovered Drupalgap as I was planning this post the last weeks, which does more or less (actually it does more, but not all) some of the same things I will try to do in this post.

Debugging cross domain javascript

As I have briefly mentioned in an earlier post, you can easily post to your Drupal site from a phonegap app. The reason for this is that the cross domain browser restriction does not apply for the apps you are building because it is basically a local file (the file:// protocol). While this is really swell, you don't actually develop on your phone, so it would be practical to try out all this in your browser before you deploy to your phone.