Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Oct 17 2020
Oct 17

But in this post I'd like to talk about one of the disadvantages that here at Wunderkraut we pay close attention to.

A consequence of the ability to build features in more than one way is that it's difficult to predict how different people interact (or want to interact) with them. As a result, companies end up delivering solutions to their clients that although seem perfect, turn out, in time, to be less than ideal and sometimes outright counterproductive. 

Great communication with the client and interest in their problems goes a long way towards minimising this effect. But sometimes clients realise that certain implementations are not perfect and could be made better. And when that happens, we are there to listen, adapt and reshape future solutions by taking into account these experiences. 

One such recent example involved the use of a certain WYSIWYG library from our toolkit on a client website. Content editors were initially happy with the implementation before they actually started using it to the full extent. Problems began to emerge, leading to editors spending way more time than they should have performing editing tasks. The client signalled this problem to us which we then proceed to correct by replacing said library. This resulted in our client becoming happier with the solution, much more productive and less frustrated with their experience on their site. 

We learned an important lesson in this process and we started using that new library on other sites as well. Polling our other clients on the performance of the new library revealed that indeed it was a good change to make. 

Oct 17 2020
Oct 17

A few years ago most of the requests started with : "Dear Wunderkraut, we want to build a new website and ... "  - nowadays we are addressed as "Dear Wunderkraut, we have x websites in Drupal and are very happy with that, but we are now looking for a reliable partner to support & host ... ".

By the year 2011 Drupal had been around for just about 10 years. It was growing and changing at a fast pace. More and more websites were being built with it. Increasing numbers of people were requesting help and support with their website. And though there were a number of companies flourishing in Drupal business, few considered specific Drupal support an interesting market segment. Throughout 2011 Wunderkraut Benelux (formerly known as Krimson) was tinkering with the idea of offering support, but it was only when Drupal newbie Jurgen Verhasselt arrived at the company in 2012 that the idea really took shape.

Before his arrival, six different people, all with different profiles, were handling customer support in a weekly rotation system. This worked poorly. A developer trying to get his own job done plus deal with a customer issue at the same time was getting neither job done properly. Tickets got lost or forgotten, customers felt frustrated and problems were not always fixed. We knew we could do better. The job required uninterrupted dedication and constant follow-up.

That’s where Jurgen came in the picture. After years of day job experience in the graphic sector and nights spent on Drupal he came to work at Wunderkraut and seized the opportunity to dedicate himself entirely to Drupal support. Within a couple of weeks his coworkers had handed over all their cases. They were relieved, he was excited! And most importantly, our customers were being assisted on a constant and reliable basis.

By the end of 2012 the first important change was brought about, i.e. to have Jurgen work closely with colleague Stijn Vanden Brande, our Sys Admin. This team of two ensured that many of the problems that arose could be solved extremely efficiently. Wunderkraut being the hosting party as well as the Drupal party means that no needless discussions with the hosting took place and moreover, the hosting environment was well-known. This meant we could find solutions with little loss of time, as we know that time is an important factor when a customer is under pressure to deliver.

In the course of 2013 our support system went from a well-meaning but improvised attempt to help customers in need to a fully qualified division within our company. What changed? We decided to classify customer support issues into: questions, incidents/problems and change requests and incorporated ITIL based best practices. In this way we created a dedicated Service Desk which acts as a Single Point of Contact after Warranty. This enabled us to offer clearly differing support models based on the diverse needs of our customers (more details about this here). In addition, we adopted customer support software and industry standard monitoring tools. We’ve been improving ever since, thanks to the large amount of input we receive from our trusted customers. Since 2013, Danny and Tim have joined our superb support squad and we’re looking to grow more in the months to come.

When customers call us for support we do quite a bit more than just fix the problem at hand. Foremostly, we listen carefully and double check everything to ensure that we understand him or her correctly. This helps to take the edge off the huge pressure our customer may be experiencing. After which, we have a list of do’s and don’t for valuable support.

  • Do a quick scan of possible causes by getting a clear understanding of the symptoms
  • Do look for the cause of course, but also assess possible quick-fixes and workarounds to give yourself time to solve the underlying issue
  • Do check if it’s a pebkac
  • and finally, do test everything within the realm of reason.

The most basic don’t that we swear by is:

  • never, ever apply changes to the foundation of a project.
  • Support never covers a problem that takes more than two days to fix. At that point we escalate to development.

We are so dedicated to offering superior support to customers that on explicit request, we cater to our customers’ customers. Needless to say, our commitment in support has yielded remarkable  results and plenty of customer satisfaction (which makes us happy, too)

Sep 04 2016
Sep 04
But in this post I'd like to talk about one of the disadvantages that here at Wunderkraut we pay close attention to. A consequence of the ability to build features in more than one way is that it's difficult to predict how different people interact (or want to interact) with them. As a result, companies end up delivering solutions to their clients that although seem perfect, turn out, in time, to be less than ideal and sometimes outright counterproductive.  Great communication with the client and interest in their problems goes a long way towards minimising this effect. But sometimes clients realise that certain implementations are not perfect and could be made better. And when that happens, we are there to listen, adapt and reshape future solutions by taking into account these experiences.  One such recent example involved the use of a certain WYSIWYG library from our toolkit on a client website. Content editors were initially happy with the implementation before they actually started using it to the full extent. Problems began to emerge, leading to editors spending way more time than they should have performing editing tasks. The client signalled this problem to us which we then proceed to correct by replacing said library. This resulted in our client becoming happier with the solution, much more productive and less frustrated with their experience on their site.  We learned an important lesson in this process and we started using that new library on other sites as well. Polling our other clients on the performance of the new library revealed that indeed it was a good change to make. 
Sep 04 2016
Sep 04
A few years ago most of the requests started with : "Dear Wunderkraut, we want to build a new website and ... "  - nowadays we are addressed as "Dear Wunderkraut, we have x websites in Drupal and are very happy with that, but we are now looking for a reliable partner to support & host ... ". By the year 2011 Drupal had been around for just about 10 years. It was growing and changing at a fast pace. More and more websites were being built with it. Increasing numbers of people were requesting help and support with their website. And though there were a number of companies flourishing in Drupal business, few considered specific Drupal support an interesting market segment. Throughout 2011 Wunderkraut Benelux (formerly known as Krimson) was tinkering with the idea of offering support, but it was only when Drupal newbie Jurgen Verhasselt arrived at the company in 2012 that the idea really took shape. Before his arrival, six different people, all with different profiles, were handling customer support in a weekly rotation system. This worked poorly. A developer trying to get his own job done plus deal with a customer issue at the same time was getting neither job done properly. Tickets got lost or forgotten, customers felt frustrated and problems were not always fixed. We knew we could do better. The job required uninterrupted dedication and constant follow-up. That’s where Jurgen came in the picture. After years of day job experience in the graphic sector and nights spent on Drupal he came to work at Wunderkraut and seized the opportunity to dedicate himself entirely to Drupal support. Within a couple of weeks his coworkers had handed over all their cases. They were relieved, he was excited! And most importantly, our customers were being assisted on a constant and reliable basis. By the end of 2012 the first important change was brought about, i.e. to have Jurgen work closely with colleague Stijn Vanden Brande, our Sys Admin. This team of two ensured that many of the problems that arose could be solved extremely efficiently. Wunderkraut being the hosting party as well as the Drupal party means that no needless discussions with the hosting took place and moreover, the hosting environment was well-known. This meant we could find solutions with little loss of time, as we know that time is an important factor when a customer is under pressure to deliver. In the course of 2013 our support system went from a well-meaning but improvised attempt to help customers in need to a fully qualified division within our company. What changed? We decided to classify customer support issues into: questions, incidents/problems and change requests and incorporated ITIL based best practices. In this way we created a dedicated Service Desk which acts as a Single Point of Contact after Warranty. This enabled us to offer clearly differing support models based on the diverse needs of our customers (more details about this here). In addition, we adopted customer support software and industry standard monitoring tools. We’ve been improving ever since, thanks to the large amount of input we receive from our trusted customers. Since 2013, Danny and Tim have joined our superb support squad and we’re looking to grow more in the months to come. When customers call us for support we do quite a bit more than just fix the problem at hand. Foremostly, we listen carefully and double check everything to ensure that we understand him or her correctly. This helps to take the edge off the huge pressure our customer may be experiencing. After which, we have a list of do’s and don’t for valuable support. Do a quick scan of possible causes by getting a clear understanding of the symptoms Do look for the cause of course, but also assess possible quick-fixes and workarounds to give yourself time to solve the underlying issue Do check if it’s a pebkac and finally, do test everything within the realm of reason. The most basic don’t that we swear by is: never, ever apply changes to the foundation of a project. Support never covers a problem that takes more than two days to fix. At that point we escalate to development. We are so dedicated to offering superior support to customers that on explicit request, we cater to our customers’ customers. Needless to say, our commitment in support has yielded remarkable  results and plenty of customer satisfaction (which makes us happy, too)
Dec 30 2013
Dec 30

Here at Wunderkraut Benelux, we love Ægir. We use to manage some aspects of our development, staging and production environments.

Since we often provide access, documentation, etc to our internal and external clients, we have created an Eldir sub-theme that adds a Wunderkraut flavour and some other tweaks which make the Ægir UI more friendly and tasty.

weldir_-_content.png

Weldir, as we've named the theme, builds on the Eldir theme and adds a few things we felt that were missing; buttoned pagers, a better footer position, some breathing room, and so on. Since we also document stuff in Ægir, we've added styling which can be used on links to create in-content buttons - call-to-actions if you will, to spruce up content and draw attention where needed. Simply add the button class to your link.

Weldir is available on GitHub. We hope it provides you with an alternative theme for this great tool.

Sep 17 2013
Sep 17

Why I wanted to find an alternative

I have worked on Windows (the dark days), several Linux distros (the enlightened days) and for the last few years Mac OS X is my OS of choice (the productive days).

Windows wasn't a sustainable option, for many reasons, but running a stable WAMP stack was near impossible. Linux had some obvious benefits but maintaining a LAMP stack on a Linux Desktop OS' took time and it wasn't as agile on its feet as it should have been.

On OS X, MAMP was the dominating tool for web developers for a long time. The ability to bypass the pain of getting a native stack running felt easy. But at the end of the day there were a lot of limitations.

Homebrew seemed a viable option but it still took a lot of time to get a kick-ass stack build and the effort didn't lend itself to being easily distributable.

Most of the above solutions also had the drawback that if you wanted to experiment with your stack, and it was rendered unstable or if it just fell apart, loads of precious time was lost to get it back up and running.

Goals of a local dev environment

With those experiences in mind, I set out some criteria for an ideal local development environment;

  • A local environment should be like your repo. Discardable and re-installable with no hassle and the same results.
  • It should be tweak-able per project.
  • The specs should match (any) production specs.
  • Solr, Memcache, Xdebug, Xhprof, Varnish, etc should be available options.

When used in teams or in a professional setting;

  • A local environment needs to be the same on each team member's machine and equal to production. No surprises during deployment. No "it works on my machine".
  • Measure the setup time of new team members or hardware in hours, not days.
  • Measure project setup in minutes, not hours.

What is Vagrant

Vagrant is a command line tool that runs virtual machines on top of Virtualbox (and since recent VMware). The vm's that Vagrant runs are headless by default so there's an impressive performance gain compared to normal Virtualbox vm's.

Between the host and guest machine, ports can be forwarded and folders can be shared. These folders can be shared over NFS, which eliminates the performance penalty experienced with normal vm's.

So the code (website) being served by the Vagrant webserver can be accessed from the host machine. This allows you to use the tools you would otherwise use (IDE, GIT, …).

Since ssh access is baked into Vagrant, you can easily log into the Vagrant box and tinker around. Using drush aliasses, you don't even need to be in the vagrant box to execute drush commands.

Vagrant comes with an API that allows you to provision a box. This is intended to run provision scripts in Ansible, Chef, Puppet, Shell. These can take a clean vagrant box and install whatever packages you need installed.

Vagrant boxes can be repackaged, so besides being able to share configuration with the provision scripts, you can also package a box. Effectively baking a certain setup in a box and distributing it.

The possibility to do shell provisioning has some additional benefits since it can be used to do more than provisioning.

Why Vagrant

It's obvious that Vagrant offers something that you wouldn't find in the tried and tested aforementioned tools.

It allows you to setup a LAMP stack with the specs you need, package it, distribute it, destroy it and run it again.

This makes it easy to share vagrant boxes within a team, provision boxes with packages as needed by the project.

So the setup of a LAMP stack needs to be done once, it is packaged and distributed. Using shell provisioning we wrote scripts that will do the heavy lifting to setup a project on the first run. The result; a project served to your browser with one command in a matter of minutes.

From the available tools and options that I've tested over the years, Vagrant had the right answer to the problems I wanted to solve and the goals that had been set out.

Install

Virtualbox and Vagrant both come with easy installers, no compiling or other other questionable methods of installation are being used.

"It's so easy that even your designer could install it."
~ Anonymous Vagrant Fan

Vagrantfile

The Vagrantfile is the file that defines;

  • VM tweaks
  • NFS shares
  • provisioning
  • the base box
Vagrant.configure("2") do |config|
 
  ## Configuration
 
  # Virtualbox tweaks. See http://docs.vagrantup.com/v2/virtualbox/configuration.html
  config.vm.provider :virtualbox do |vb|
    # Moar memory
    vb.customize ["modifyvm", :id, "--memory", "1024"]
  end
 
  # NFS shares. See http://docs.vagrantup.com/v2/synced-folders/nfs.html
  config.vm.synced_folder "www", "/var/www", :nfs => true
  config.vm.synced_folder "logs", "/var/log", :nfs => true
  config.vm.synced_folder "scripts", "/home/vagrant/scripts", :nfs => true
  config.vm.synced_folder "db", "/home/vagrant/db", :nfs => true
 
  ## Provision
 
  # scripts/provision.sh will provision the box
  # comment out when using a re-packaged box 
  config.vm.provision :shell, :inline => "
    sh /vagrant/scripts/project_setup.sh;
  "
 
 
  ## The Vagrant Box
 
  # Defines the Vagrant box name, download URL, IP and hostname
  config.vm.define :vagrant do |vagrant|
    vagrant.vm.box = "precise64DCL"
    vagrant.vm.box_url = "http://bit.ly/precise64DCL"
    vagrant.vm.network :private_network, ip: "192.168.66.6"
    vagrant.vm.hostname = "vagrant.dcl"
  end
end

Provisioning

Vagrant allows for provisioning with various tools;

  • Ansible (yaml)
  • Chef Solo (ruby)
  • Chef Client (ruby)
  • Puppet Apply (ruby)
  • Puppet Agent (ruby)
  • Shell

The Vagrant instances we use internally at Wunderkraut Benelux will be provisioned using an optimised version of the Puppet scripts we use to manage our server config. For edge-case projects that will not be hosted with us or legacy projects, we'll use custom (usually shell) provisioning.

For the demo setup of DrupalCamp Leuven, I went with shell provisioning since it will have the lowest threshold for most users. I won't claim that scripted shell provisioning is a walk in the park - compiling from source and interactively installed packages can be tricky - but it should allow most devs to tweak the LAMP provisioning to their needs without needing to learn other provisioning methods.

I could recommend talking to your local sys-admin on preferred hosting partner for collaborating on automated provisioning. In the end, it'll save you both some headaches.

Demo setup

To setup the demo, run the following command;


wget http://bit.ly/DCL13_setup && sh DCL13_setup

or

mkdir DCL13 && cd DCL13 # made a dir to clone the Vagrant & Drupal repo
git clone [email protected]:sjugge/DCL13_Vagrant.git # clone the Vagrant repo
git clone [email protected]:sjugge/DCL13_Drupal.git # clone the Drupal repo
cp DCL13_Vagrant/project_box/Vagrantfile DCL13_Drupal/Vagrantfile # copy the Vagrantfile to the repo
cp -r DCL13_Vagrant/project_box/scripts/* DCL13_Drupal/scripts # copy the scripts & recources to the Drupal repo
cd DCL13_Drupal # go to the Drupal repo
vagrant up # 'vagrant up' the Drupal repo

The demo setup exists out of 2 repos;

  • DCL13_Drupal: a Drupal codebase repo
  • DCL13_Vagrant
    • provision_box: here is where all the LAMP stack provisioning is done on an empty Vagrant base box
    • project_box: here is where the project provisioning is written, tested and available as source for the project repo (DCL13_Drupal)

This may seem complex at first, but it has proven to provide a manageable way to run Vagrant with the least amount of maintenance.

Managing Vagrant over different projects

The workflow of the repos is as follows;

This folder contains the Vagrantfile and provisionscripts used to install a LAMP stack on en empty Vagrant base box. The base boxes provided by Vagrant are widely used, hence stable.

On this base box, we run the provision script, installing the LAMP stack and other tools. This box is then packaged and tested with the project_box.

There are several reasons why we package our provisioned boxes;

  • reduce setup time since the LAMP install is packaged
  • allows for offline `vagrant up`-ing
  • ensure a central management of improvements to the LAMP stack an project setup scripts

This folder will be used to test out the packaged provision_box before distributing it. The project_box folder contains the structure of our projects. Drupal resides in the `/www` folder, and contains a few more folders. These allow us to keep track of other things such as patches, docs, etc.

There is also a `/scripts` folder which is used in the same fashion as with the provision_box, with that difference that we use the shell provisioning to setup a project. Creating a database, provide a correct Drupal settings file, handle project specific setups, clearing caches, variable tweaks and so on.

This way there is a distinct task for both repo sub-folders, LAMP stack setup and project setup.

The project_box is not re-packaged. We do use the provisioning scripts and Vagrantfile in the Drupal repos. The easiest way is to create an alias that will copy over the scripts folder and Vagrantfile to your current (Drupal) repo, e.g.

alias vagrantify="cp ~/DCL13_Vagrant/project_box/Vagrantfile . ; cp -r ~/DCL13_Vagrant/project_box/ scripts ."

When adding the following to your global or repo's `.gitignore` file, these will be excluded from your repo;

# vagrant stuff
.vagrant/*
Vagrantfile
scripts/*

By excluding these files from project repos, the Vagrantfiles and scripts that are used to run a project will be at the latest version and won't need to be maintained over several repos, which can become quite a timesink.

Per project customised scripts can still live in a project repo. Note that in this case, the project_box provision script should be modular.

One way of achieving this is to have a script that is invoked by the Vagrantfile, that in turn will run all the other scripts from the `/scripts` folder.

Is a repo with a Drupal codebase and a few folders that will be mounted over NFS. By copying the Vagrantfile and scripts folder from the Vagrant repo, you'll be able to run `vagrant up`, and end up with a Drupal site running on your codebase and db dump.

There is a `/db` folder which has a .sql dump. I can't recommend keeping db dumps in a repo since these might get bloated. Ideally you fetch a db dump from production and place it in the `/db` folder before running `vagrant up`.

Some Tips & Tricks

Provision checks

At the end of the provision script, the file is created.

This provision check will prevent from an already provisioned box, to be provisioned twice. Provisioning a box twice may result in corrupted installs or loss of data. This simple method will prevent this.

`sudo vagrant up` is not the best idea

When `vagrant up` is running, admin permissions will be needed. Since you may have to stick around a bit to enter your password when prompted, it's tempting to run `sudo vagrant up` instead of `vagrant up`.

It is however not the best way to ensure you can enjoy your coffee, knowing that you won't return to a `Password:` prompt.

Executing `sudo vagrant up` may result in the box being created with the admin as owner, possibly starting a chain reaction of inexplicable issues.

This issue has been brought to the attention of the Vagrant maintainers and a solution may be in place (soon). But to ensure you won't run into these issues, you could execute (or alias) the following command;

sudo echo tnx && vagrant up

I have been doing this for some time and haven't had any issues to report as when running `sudo vagrant up`.

List (running) Vagrant boxes

Sometimes you'll want to know the unique machine name of a vagrant box (re-packaging) or to check if you have any vagrant boxes running.

To list vagrant boxes, run;

VBoxManage list vms

To list running vagrant boxes, run;

VBoxManage list runningvms

Find a vagrant box on your system

It can happen that you've placed a vagrant instance on your filesystem but are unable to locate it. `/etc/exports` keeps track of NFS shares, so with the UUID of the box, you'll be able to locate the vagrant box on your system by checking the `/etc/exports` file.

pre-destroy scripts

In some cases it may be good to execute some scripts before destroying a box. For instance to create a db backup before it is lost forever.

You could handle this by creating an alias of `vagrant destroy` that invokes a script first. In a recent or upcoming release of Vagrant, the API will be providing this functionality.

Resources

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web