DrupalCamp London 2017 was held on the 4th and 5th of March at the newly refurbished main hall of City, University of London. The new facilities are really nice and keep the conference in the same area, but they aren't too small that it feels cramped.
The European DrupalCon was held in Dublin from 26th - 30th September and I went along with a couple of colleagues to learn a few things about Drupal. I have been back from the conference for a few days now, and I wanted to write down some of the highlights of the conference in a blog post. There is a lot going on at DrupalCon and with 2000+ people, 3 full days of sessions, 2 tutorial days, multiple parties and over 10,000 cups of coffee consumed there is too much to write about here. So this will be a few random highlights and stand out moments of the conference.
DrupalCamp London, now in it's 4th year, was held of the weekend of the 4th, 5th and 6th of March at The University of London campus in London. Myself and a few other developers from Manchester headed down for the weekend to attend. I wasn't able to attend the CXO day on the 4th, but we were all in attendance for the camp event.
When overriding theme functions in Drupal 7 you would normally copy the theme function into the template.php and alter it to suit your needs. This isn't always convenient though, especially if you are trying to abstract functionality into modules and not have code in your theme layer that is reliant on module code. If you add theme override functions to your module files then they won't do anything as Drupal isn't looking for them there and won't pick them up.
It is possible to alter the theme registry in order to get Drupal to pick up your theme functions from your module code. This helps collect together code that performs a certain task and allows you to deploy theme alterations along with module updates.
DrupalCamp Scotland 2015 consisted of a Friday training day, followed by a day of talks and sessions on the 6th and 7th November.
The training day was based around Drupal 8 and had us looking at installation, configuration, and development. In the morning we set up a couple of Docker containers (on a Digital Ocean box) to run Drupal 8 from and then looked at the Drupal command line tool when setting up the system. Once installed we looked at the system structure and how the configuration management system worked. In the afternoon we created modules and themes, also using the Drupal console to generate some of the code fragments. I think the use of Docker on a remote server was a good idea in getting everyone up and running on the system without having to rely on local LAMP stacks or whatever. The training day was really good and I was able to swap lots of ideas and techniques with the trainers and other attendees.
Or, how you can render a Drupal page with an entirely different template.
I recently had a requirement where I needed to get Drupal to render a single page of HTML that was entirely separate from the normal page layout of a site. This was actually part of an API callback, but this got me involved in looking at how delivery callbacks work in Drupal 7. It isn't necessary to create a new theme just for the job of rendering a single page with some custom HTML, especially as Drupal has mechanisms to provide this built in.
The city of Sunderland played host to DrupalCamp North, which saw Drupal users and contributors travelling from all over the UK and Europe to attend. The event, which was held from 24th-26th July, was jointly led by the North East, North West and Yorkshire Drupal User Groups and consisted of a three day sprint, a business day, and a two day conference.
There are a few ways in which you can create complex node access systems. Modules like Taxonomy Access Control and Node Access will allow you to restrict node access in different ways, and work very well for setting up taxonomy or role based access control. There are a few edge cases where you need to restrict access to a node based on some arbitrary conditions like the age of the user or the contents of a field. This is where the build in Drupal access control mechanisms come into play. They do take a little bit of effort to get around how they work, but I hope to enlighten in this post.
Basic HTTP authentication is a simple authentication mechanism that is used to prevent access to a site or directory on a server. It is by no means the most secure authentication mechanism but it is commonly used on staging sites in order to prevent unwanted access. This is a good way of preventing search engine bots from spidering the staging site, which is undesirable as it can cause staging site pages appearing in search engines results.
The usual route to set this up is to create a .htaccess that sets up the authentication and references a .htpasswd file to create the username and password details. This can mean editing the .htaccess file in order to setup the password correctly. Unfortunately, this creates a .htaccess file that shouldn't be added to the repository as it would mean that the live site would also be password protected when the code is deployed.
When generating markup in Drupal you'll often want to store the output in a cache instead of regenerating it every time. This is especially important for potentially expensive rendering tasks that don't change between page requests. Drupal 7 comes with a cache system that can be taken advantage of with the cache_get() and cache_set() functions. There is also a third function called drupal_static() that also fills in gaps between these two functions.