This weekend I attended the Druapl7Camp 2011 in Leeds and so I booked a hotel room for the weekend and managed to find the right place on Saturday morning. I was one of the first to arrive and was able to greet people as the came through the door. With coffee flowing nicely and the wifi appearing to be stable we all set down to the first session.
Install Party/Webfaction Demo
The first session was partially a install party and partly a demo of the Webfaction hosting platform. The install party consisted of hands on help for people who have brought a laptop and wish to install Drupal7 on it. I think the few people who were in this position were glad of the help and learnt a lot about getting up and running with their own Drupal7 site.
The Webfaction demo showed off a nice hosting platform management system. It has a fully featured control panel with options to select the type of software to install (Git, Joomla, Drupal etc) and after a few minutes of fiddling with forms there is a fully installed system ready to work on.
The host looks reasonable and I will probably be taking another look, my current host is quite dissapointing so I have been looking to move so I might consider webfaction in the future. I would say that when looking at the costs it seemed a little on the high side compared to other hosts and the the amount of hardware that you get with the package is quite limited.
Using HTML5 in Drupal 7
This was an introduction to HTML5 and a quick run through of the templates available in Drupal7, with a quick history of HTML5 at the start.
The introduction to the templates within Drupal 7 was very interesting. The main new template file was html.tpl.php file that surrounds the page.tpl.php template. The page.tpl.php template surrounds the node.tpl.php template. Euan's comparison of Drupal templates to Russian dolls was a good analogy and helped people visualise what was going on with the different templates.
The the .info file of the templates in Druapl 7 has the same structure as the Drupal 6 file.
Euan looked through the different variables available within the different template including things like regions and the default variables available from Drupal. The biggest change I saw in the html.tpl.php is that the $closure variable has been changed to $page_bottom.
The $content variable in the node.tpl.php template is the main text of the node. but instead of just printing out the variable it is passed to a render() function, the return value of which is the rendered string. the $content variable is actually an array of items which will all get rendered at this point. to prevent this you can call hide() on a part of the variable like this:
- hide($content['links']); // hide the link
- print render($content); // render the rest
- print $content['links']; // print the rest
This was a great little introduction to theming and about how the main templates fit together within the system.
Updating modules from Six to Seven
This was a session all about how to update modules from Drupal 6 to Drupal 7, what to look out for and any tools that might help.
The main help page on the drupal.org site that lists the things that have changed from Drupal 6 to Drupal 7 in terms of modules is very comprehensive. This list, however, is split by date that the change was added and so isn't all that helpful.
There is another help page that is much more useful and contains a canonical list of items that developers need to look at before they can update the module. This also lists how the Coder module interacts with this change, if it detects it or even if it is needed.
When you run coder against a Drupal 6 module with conversion detection turned on it will print a list of recommendations. This list will link through to the canonical list of items.
Andrew took a random module from Drupal.org (the RSS permissions) module, which he then used to detect what sort of changes should be made to the module to get it up and running. This module removes the RSS link tag and icon from the page based on permissions of the module. This module was used as it was only one file, but contained enough hooks to make a good example.
The first thing that Andrew did was to put the module on an active Drupal 7 site. Drupal will not allow you to enable modules that are not compatible with the current version, information which is set within the .info file of the module.
Andrew then used the Coder module to scan the module to see the upgrade path that was needed. This module gives good tips and help on what to update and prevents you having to go through every single module change and seeing what needs to be changed. It is possible to go through a massive box ticking exercise like this but it is a lot of work for very little gain.
From this single pass we could see straight away that hooks like hook_perm() had changed to hook_permission() and hook_access() is now called hook_node_access(). There was also a couple of changes within the .info file that were needed to get up and running.
The Coder module only gets you so far. It is easy to change the module hook names to the updated versions, but the inside of the hook might be different and will therefore need looking at so using Coder can only get you so far. For example, the big difference is the with the database controls, which are completely different and therefore need to be looked at in detail.
The module maintainer had already created a Drupal 7 module so it was interesting to see how they applied the changes from Drupal 6 to Drupal 7 and how the Coder module might have got them started.
This talk left me feeling more confident about updating things from Drupal 6 to 7. There might be a bit of work to get things working, but at least I now know where to start looking at what to change.
Yet Another Drupal Development/Deployment Presentation (YADDP)
Mike Bell, Ixis
Mike's talk was a quick breakdown of how Ixis go about developing and deploying Drupal applications. Essentially, there is no solution to deployment, just a set of best practices. The files are generally easy to deploy, but the main problem is the database where settings aren't carried across. This shouldn't be a problem but it tends to be.
Their main method of deployment consists of creating a drush make file with references to all of the modules and features needed to get the site up and running. When they deploy they push this to the site and run drush to build and install the Drupal site. Some of the modules are contained within their local git server and these are also referenced in the make files. Mike said that they use git flow to keep track of the things they do in git.
For source control Ixis have a development branch and a production branch, and it is the production branch that only ever gets used to create live sites. The general workflow of a Drupal build at Ixis consists of creating a number of features, adding these into git, using git hooks to run various tasks when code has been committed before going onto releasing the site. One tip that Mike gave was that the Features status page will falsely report on overridden Features that haven't been overridden. He said that it is often best just to make sure that the site is doing what you think it should, rather than rely on Features to report on itself.
Content migration is a bit of a sticking point, and Mike said that he had tried various different approaches to migrate content from one site to another, with varying levels of success. The UUID suite is intended to make this job easier by giving all content a unique ID so that it can be moved, which was especially useful for taxonomy migration, but Mike has not had much success with this. Ixis have a rule (as do many of the people I talked to over the weekend) that they don't allow content migration, once it's on staging they do allow some content entry, but once live nothing will be migrated.
One thing to watch out for on Drupal sites are what Mike called ghetto updates. These are community modules that get updated for one reason or another. Generally, things don't go wrong, but every now and then problems will arise because of an update. When an update does happen the drush make file is updated with the latest version of the module, which then copies the newer module when deployment happens.
For the full deployment Ixis use a single user, this mitigates any permissions issues on remote servers, and pull from production branch, rather than the dev branch. The database is fully backed up before everything happens just in case, and if high available is needed the document root can be switched in order to minimise downtime.
Overall this talk was fascinating. It was interesting to learn of the different practices that Ixis use to streamline their deployment and how they use lots of the community tools available to help them build their Drupal sites. It is clear that a lot of care and attention is taken over how sites are built and that Mike and the rest of the team at Ixis strive for a better solution to the deployment problem.
What's New In Views?
Steve took us on a tour of the new features in Views 3 and how to use them. Rather than present a bunch of slides Steve had created a single node with a bulleted list of items that he would cover in the talk. This was probably the best approach as he would read a bullet point and then go off to show us what that functionality was, and meant that he wasn't swapping between a presentation and a Drupal site every few minutes.
Essentially, there are some extra aspects of functionality but most of the new stuff is that Views are easier to manage. When creating a View you get a wizard that adds some reasonably sensible defaults to get you up and running. The first thing available is the title, with an optional description, and Views also adds a page view to start off with, with the option to create an additional block.
Once the wizard is done you get the View with the options you selected. This is the new Views administration page with some of the more advanced options hidden. There are lots of different things available here, and I made a list of some of more important features (for me a least).
- New filter mechanism allows for and/or selection of data.
- Sorts are exposable to the user.
- Items per page are exposable.
- Templates have a much more advanced system so that labels and elements can be completely changed via the interface.
- Improved header and footer, can add text, a node or even another view to the header and footer.
- Relationships are improved and seems to understand things a lot more.
- Arguments are now called contextual filters
- Cloning and exporting is still there, but you can also clone single things like pages and blocks.
I have been wondering what was new in Views 3 and Steve did a great job of introducing it. When I come to use Views in the future I will certainly feel less nervous about the new interface.
Advanced Searching in 7
Matt Fielding, Joe McGuire
Matt is a front end developer/designer and Joe is a back end developer so it was interesting to see two different points of view about how search works.
The search API is a Drupal 7 module, but was available as in Drupal 6. The API provides a way to plug in different search solutions to a Drupal site and not just rely on the default MySQL solution. This means that you can set up the site using the default but switch on a third party solution like Solr and also allow for faceted search using Views.
Photo By Karen Leech
The Faceted Search module became available in Drupal 6, which was popular but the default Drupal 6 search didn't scale on large sites. The search API built upon the work done integrating Solr search into Drupal 6.
The search API is pluggable, highly extensible with lots of contributed modules available to do all sorts of different things. The whole module is fully object oriented, and so fully extensible. Joe talked us through some of the history of the module, why it was created and what the philosophy was for creating it. Essentially, the module began as a summer of code project from Google and was the work of a single developer. The idea to add different search solutions into Drupal proved so useful that lots of people took interest and the module grew in features.
Joe then took us through a demo of how to use search API. In Drupal 7, using Views 3 to integrate the search solution into the site, as well as integrating faceted search implementation a lot easier. Joe set up a couple of views on a page and searched using the default MySQL search. He then swapped over to using a Solr server and everything that he had setup worked as it did before. This is a good way to go about setting up a site as any search solution created through views will work the same way when swapping the back end implementation.
Drupal 7 Queues
This was my first full conference talk and it was recieved very well. The content of the slides was quite complex in some parts but I didn't lose that many people. I think the biggest piece of advice I got was to include more real world examples. There were a few examples in the code, but these were mostly just me playing about with queues to see what sort of things I could get it to do with the minimum amount of changes to the surrounding APIs. When I write up the talk properly I will include a few of the examples that I discussed with other developers after the talk.
Theming in Drupal 7 Kicks A$$
Richard Burford, Simon Paulston
We had already had one talk about Drupal theming from Euan, but this talk was a far more detailed approach to how theming works in Drupal 7.
The main message of the talk was that the $content variable file exists in the Drupal 6 node.tpl.php as a string, but this approach is bad as there is little control over it.
The $content variable in Drupal 7 is an array and is therefore a lot more adaptable. The render() function is used to render the entire array or to render just parts of it. Two functions exist that allow parts of the array to be turned on and off within the render() function, these are hide() and show().
Hooks like hook_preprocess_node() are still available in Drupal 7, but most things in Drupal 7 now have a preprocess hook. This allows great fine grained control over the $content array before it gets sent to the render() function.
One tip that Simon Paulston gave was to group links by type. This means that if you are passing an array of items to the render() function you should make sure that they hang off of the same id.
Overall, this was a great introduction into the new theming functions within the Drupal 7 theme world and I helpful to me as I prepare my transition from Drupal 6 to Drupal 7. It also won the award for best slides with numerous lolcats and fancy effects.
DrupalCon London 2011
Karen gave us a quick introduction to DrupalCon London, with a break down of what was going on where it is and what information wasn't on the website. The conference runs over three days and will consist of six tracks so the £230 entrance fee should be well worth it. This price will only remain until the end of the month, where the early bird sales will stop and the price will increase.
Apparently, according to Karen, the conference is also looking for volunteers. So if you are in London (Croydon really) around the 22nd - 26th August then get in contact with the organisers through the site and see how you can help.
Saturday Night, Pizza, Beer And Pub
The sponsors were kind enough to buy pizza and beer for everyone, and there was plenty of it. Even after eating and drinking for nearly an hour there were still plenty of pizza and beer left over when we went to the pub (which I can't remember the name of). We didn't go direct to the pub, but got very lost in Leeds looking for it and eventually found it using Richard Burford's GPS enabled phone. It was good to see some parts of Leeds that I wouldn't have been to otherwise, and the pub when we eventually got there was a great venue. Although only just big enough to fit us all in.
This session consisted of discussions about the various methods that people use (or don't use) to keep track of their Drupal projects and how they deploy them. Most developers seem to have a wide variety of systems and environments which causes them to either adapt their practices to fit or to use a new practice every time. This was a follow on from the talk that Mike gave the day before and was a nice easy first session of the day for those people who were out late the night before. Richard Burford and Simon Paulston had lots of good suggestions about using systems like drush, and git to migrate things easily.
My own practices, where I use Phing for a lot of my deployment processes, seemed to intrigue some developers. If I get some requests I might publish the Phing script on this site.
Richard Burford, Simon Paulston, James Panton
Richard Burford, Simon Paulston and James Panton, who are all seasoned git professionals, were kind enough to take a group of us through how to use git. They even discussed (and sometimes focused) on the fact that a commit should be a logical step of changes to the source code. Richard Burford got us to read a post by webchick (the core maintainer of Drupal 7) about how poor commit messages eat baby kittens.
SVN, which many of us at the camp were familiar with is a centralized version control that lives on a server. When you want to work on the source code you pull it down and work on it locally before committing it back.
Git, on the other hand, is decentralized so that every person has their own repository. Even when working on a project held on a central server the process is of cloning the project, working on it, and then merging it back into the main project.
Git is also very fast at what it does, which is good news to me as I have spent many an hour waiting for SVN to do simple things. Using tools like bot commit can useful to tell people when things have been pushed, which makes working with teams easier. If your company has an internal irc server then it is a good idea to get the drupalbot module as it can also publish git messages into the channel.
Rather than write down what was covered here I will save it elsewhere for now and repost it as a introduction to git tutorial at a later date. Richard has also promised to do the same in more detail so I will be watching out for that.
Morten didn't actually attend the camp, but was still able to give a talk about Drupal Camp Berlin by Richard calling him on Skype and putting the video stream full screen on the projector. It took us a little while to get everything up and running, but this was an excellent demonstration of the technology in action. I don't think I will be going to Berlin any time soon, but it was great to hear about similar things to the Leeds camp happening in other parts of the world.
Group Project Discussion
The intent at the end of day 2 was to create a project that we would all work on. I was feeling a little out of it by then so I didn't participate much in the conversation, although I did listen to the proceedings. The idea was that we would get together and create a website that linked people together based on lots of factors. These were as simple as location, but could branch into things like what operating system they used and what their skillset was. This is an extention of the simple interest tracking that can be done on druapl.org. Nothing was actually built before I had to leave to catch the train home, but I will be interested to see what happens with this project.
Overall, Druapl7Camp Leeds was an excellent weekend. I met a whole load of awesome people who either knew a little bit or a lot about Drupal 7, but were willing to share any knowledge they had. It was also nice to put some faces to the names I see on irc and Twitter every day.
I would like to thank the organizers of the camp for doing such an amazing job in getting everything together. The food and drink was amazing, and there was a lot of it (which was good). It was well worth the £20 admission fee and I will be looking out for the same camp next year.
Thanks for this. We were so busy organising the event we didn't get properly organised on session write-ups. This is really thorough.