The official release of Drupal 8 is edging closer. The announcement at DrupalCon Amsterdam (attended by a few of my colleagues), that Drupal 8 had reached “beta”, signaled that we’re approaching the final straight and before too long it will be time to start really getting to grips with the new features. So what does it mean to a site builder with Drupal 8? On the face of things, there is nothing to worry about - pretty much everything that was there in Drupal 7, is still to be found in 8. Apart from the “to be expected” moving of user interface adjustments, the technical side of building up a site structure looks very similar.
As part of discussions with a prospective client, I was recently asked about our involvement with the Drupal community. I provided some written responses to our business development team, however it occurred to me that we didn't have the spirit of our contribution documented anywhere visible (outside of Upbeat) - so here it is.
Following on from DrupalCon Amsterdam and the launch of Drupal 8 beta, we're starting to put Drupal 8 through its paces. Part of that process will be taking contributed modules that we maintain and moving them across to work with Drupal 8. This blog post looks at the first module we ported - login tracker. Login tracker is a fairly straightforward module that tracks user logins to a site and makes the information available to views for reporting. It's a fairly simple module with no real user-interface, or configuration, so makes for an easy first module to port. That does mean though that this post doesn't talk about Twig, or the Configuration Management system in Drupal 8 - two big areas of change. Note: This post isn't intended as an exhaustive guide - it's just a record of our experience porting a module.
What did I set out to do? From day to day we get a variety of questions from non-drupal-working staff, and I thought it would be a good idea to shed some light on the basic principals that we use everyday. This would make sales processes easier "it's not quite as easy as it looks", and general project management a bit easier as they would be able to flex their basic drupal muscles which would inspire the client even more than normal.
DrupalCon this year was in Amsterdam, a great city providing an accessible location for 2300+ of the worlds most dedicated Drupal developers and agency business people. As silver sponsors of the event we had the opportunity to learn and meet others through the wide variety of sessions and social events.
At the end of September, three of the Hydrant team attended the European DrupalCon in Amsterdam. I was lucky enough to attend the conference, and was joined by Leo White our MD, and Lewis Harper our Business Development Manager. We obviously all had different ideas about what we wanted to get out of the conference, but mine were firmly of a technical nature. A pleasanter-than-usual journey down the M6 to Manchester airport left us with a few hours to kill before the flight, and we spent most of this discussing what we expected the conference to cover, and what we wanted to achieve.
Recently, we built a Drupal Commerce site that has its it’s products created automatically from an XML feed. To import these products, we used the feeds module (https://www.drupal.org/project/feeds). The site also made use of the “inline_entity_form” module (https://www.drupal.org/project/inline_entity_form), making it possible to associate and update both a product entity and it’s node display at the same time. Two feeds were set up, one for the product entity and another for the node display. This unearthed a problem with using feeds though… the product entity needed to be created before the node display, so that the relativity could be set. If the node display is created first, the relativity is not set, resulting in a broken output.
Cambridge Consultants is a world-class supplier of innovative product development engineering and technology consulting, with offices in the UK, USA and Singapore.
Not so long ago, I was extolling the virtues of Codeception as the logical choice for testing our Drupal sites with - it seemed easier to use for our PHP-familiar developers, without having to learn Behat's "Gherkin" syntax, and the concept of writing "features". But if you want speed and fluency in your test scripts, Behat wins hands down (once you're used to it). Not to mention the fact that you get an awesome little report of all the steps to handover to the client. Here is how to get started: