On day two of DrupalCon Amsterdam, members of our Drupal team provide an analysis of the sessions they have been to so far..
Drupal 8 CMI on Managed Workflow
Although I have worked with the CMI API quite a lot from a module development point of view and have a general understanding of how it is architected I had not got round to understanding how this would fit into our development workflow. This talk was very popular and it was standing room only as the talk started. I attended this talk to find out more about how we CMI will integrate into our current continuous integration and automated testing practices and where these will need to change. Some contrib modules were identified that will extend the core functionality, this one was of particular interest to me as it should help many developers sleep easy in the knowledge that configuration isn’t being altered directly on production sites.
Decoupled Front-end and the Future
The session covered the reasons why you might want to go “Headless” (for example to use Drupal just to provide data to a web app) as well as the negative implications of separating back-end from front-end. For example, you lose some of the theme privileges Drupal provides such as render() functionality, Form API and any kind of drag-and-drop interfaces, e.g. panels.
Some of the main take-aways from this talk were that this is still in its infancy within Drupal: There is no proper “way” to go “Headless” yet and it is very much try-it-and-see. There was lively discussion in the Q&A about the viability of headless Drupal as well as how you could best go about achieving both an optimal development experience for front-end developers and a highly usable experience for the end-user of the site.
Overall, it was very though-provoking and I will certainly be keeping an ear to the ground to see where this idea is taken in the community and perhaps even try my hand at going “Headless” if a suitable project arises.
GSS - the CSS layout system that's 2 generations ahead
However, I think it will be worth trying out since there may be some more worthwhile use-cases than could be fitted in to a 1 hour session. It will also be worth keeping an eye on GSS see how it progresses as it may become more viable over time.
Automated Frontend Testing
Chris Ruppel began this talk by saying how important it was that we start doing this sort of testing now that the front-end trade as matured. He went on to discuss some of the tools available for frontend automated testing, outlined below.
This covered using CasperJS which is a test suite run on PhantomJS. It can be used to test things like the existence and functionality of JS libraries (e.g. Picturefill) as well as doing complex tasks such as resizing the viewport to check desired behaviour occurs.
Two methods of performance testing were mentioned here.
Firstly, automating Google Pagespeed Insights via Grunt and then checking for any performance regressions.
Secondly, Phantomas which is a web performance metrics tool run on PhantomJS. This is provides similar, but more in-depth, data than Google PageSpeed Insights. When running these tests you can filter it down to only show specific data as well as add test assertions to return failed if the metrics hit a certain level, e.g. 20 or greater requests.
Phantomas, also generates graphs so you can see at a glance how performance is altering as the build progresses - these also show the test assertions as a red-line so you can see if you’re getting too close to failing your performance goals.
CSS regression testing
Wraith was the tool outlined for this. It produces a visual diff between two environments so you can easily check that any visual changes you’ve made haven’t impacted things you didn’t mean to change.
Automated testing services
Finally, Chris covered Ghost Inspector - an automated testing service that builds CasperJS tests for you based on your actions. It also does visual diff regression testing similar to Wraith, although unfortunately it is not free.
I really enjoyed this session and I think there are certainly some things, particularly Phantomas, that I will be suggesting we begin implementing as part of our testing process at CTI.
Cory Doctorow was a brilliant start to DrupalCon. Talked about the implications of DRM vs FLOSS in a way that I hadn’t seen before: making a direct link between DRM and web security that made the issue not about web piracy but about the health, security and well-being of the whole human race. As technology becomes embedded in our lives - and in our bodies - if you don’t control your own tech, somebody else will. DRM makes it impossible - illegal - to know how software works, and so to see where it is insecure and patch it. FLOSS like Drupal is the first step to making the web secure, and anything else just isn’t up to the job.
Render Caching in Drupal 7 and 8
The Render Cache module looks to be doing amazing things to bring down page load times on a Drupal 7 site, but the real star of this show was the overview of cache tagging in Drupal 8. Whereas Drupal 7 has to rebuild its entire page cache for just one piece of content changing, Drupal 8 out of the box will tag all cache elements with relevant information from the content (its entity id, the tags it uses, etc) and then when you next save that information the cache will be wiped only where it matches those tags. This is really going to make a massive difference to performance once the code base has its final optimisations applied through the Beta process.
New Wave PHP
A breakneck session from @LornaJane giving the heads up on the new features and functionality Drupal developers can expect when they’re forced to upgrade to PHP 5.4 by Drupal 8. But the take home was that you really need this now: Drupal 7 runs on 5.4 without major problems (CTI Digital develop Drupal exclusively on 5.4) and you will save yourself many future headaches with an upgrade. Going up from 5.2 is not easy, but it is necessary. And if you can get yourself up to 5.5 or 5.6, all the better.
Drupal’s PHP Component Future
Kris Vanderwater was keen to have a discussion with the audience on the future of Drupal as a PHP project. With Drupal 8, Drupal is a mixture of Drupal modules and PHP components … looking further into the future, should we be writing components that work as pure PHP and can be released into the wild to be used in a non-Drupal environment? Drupal 8 has apparently already been built with this - Drupal second - in mind: some components written purely for core are written as components that could be used in any PHGP platform. They are then extended within Drupal core to add in the Drupalisms that make them work with Drupal. Of course, the inverse of this is that it is now possible to add in somebody else’s non-Drupal PHP component and get it working, as opposed to the heavy investment of building a custom module to implement it.
That's all for now - we'll be back tomorrow with more from DrupalCon Amsterdam 2014!