Drush vagrant site alias

Submitted by superadmin on Mon, 02/15/2016 - 21:22

Took me a while to figure this out so I thought I'd share it here.

 Do not use or localhost in the remote-host field. Instead use a valid hostname that is in your /etc/hosts.

$aliases['mysite'] = array(
  'root' => '/vagrant/docroot',
  'remote-host' => 'mysite.local',
  'remote-user' => 'vagrant',
  'ssh-options' => "-p 2222 -i /var/www/mysite/.vagrant/machines/default/virtualbox/private_key",
  'uri' => 'mysite.local:8001',


Powered by varnish

Submitted by superadmin on Sat, 02/13/2016 - 01:30

I finally got round to insalling varnish on this blog.  First thing I did was to edit /etc/default/varnish and change

DAEMON_OPTS="-a :6081 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"


DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"


Drupal 8 - Custom field formatter

Submitted by superadmin on Sun, 01/03/2016 - 14:23

Thanks to the Object Oriented approach adopted in Drupal 8,  working with field extension in terms of widgets and formatters have become much easier. Gone are the days where you had to copy huge junks of code to use in your custom formatter. Now you just extend an exisiting formatter and change the bit you want to override.

Creating a new custom formatter is a really straightforward process. I am going to assume you already have a module that you want to place the field formatter in. 

Drupal 8 - path placeholders

Submitted by superadmin on Wed, 12/30/2015 - 11:37

In Drupal 8 we can have placeholders in our path. In Drupal 7 these were either wildcard arguments and they were sometimes autoloaded. The process of autoloading placeholders is called upcasting and it's a bit more involved in Drupal 8 and will cover it at a later post.

Placeholders will be replaced with values provided in the url and will be passed as arguments to the controller method. The name of the placeholders and parameter names must match, this is important because if they don't an exception will be thrown.

Drupal 8 - ConfigFormBase and overrides caution

Submitted by superadmin on Sun, 12/27/2015 - 18:04

Drupal 8 makes a good attempt to stop overrides provided in places like settings.php from bleeding into configuration forms that will be exported. By default config objects obtained from Drupal::config can contain overrides from settings.php. However in the config object returned by ConfigFormBase::config() overrides are disabled and the data fetched from this object are the raw configurations. This could be dangerous when you want toggle between configuration between dev environment and production i.e. setting the site email address to a development inbox.

Drupal 8 - system settings form

Submitted by superadmin on Sun, 12/27/2015 - 15:22

system_settings_form was a handy function in Drupal 7 that saved forms to variables. This has been replaced by ConfigFormBase in Drupal 8. 

If we want the same behavior in Drupal 8 that was present in system_settings_form, our form class must extend ConfigFormBase. In doing so we must implement the abstract getEditableConfigNames method which returns the config names which are editable.

Also our buildForm method should call it's parent buildForm so that the submit buttons can be added.

Drupal 8 - FormBase buildForm parameter names

Submitted by superadmin on Fri, 12/25/2015 - 19:02

When creating configuration forms by extending FormBase, your buildForm method first two parameters must be named, $form and $form_state respectively. Anything else will result in the following runtime error:

::buildForm()" requires that you provide a value for the "$state" argument (because there is no default value or because there is a non optional argument after this one)