You are here
A DrupalCon Prague Retrospective - and why i-KOS are excited about Drupal 8
17 Oct 13
At i-KOS we specialise in [Drupal Commerce](http://www.drupal.org/project/commerce)the [modules](http://drupal.org/project/commerce_sagepay)[we](http://www.drupal.org/project/commerce_reorder)[maintain](http://www.drupal.org/project/commerce_extra_price_formatters)on Drupal.org are specifically related to Drupal Commerce. Our upgrade path is dependant on our partners at Commerce Guys and as a result we haven't focussed too much attention on Drupal 8 - except for observing the core initiatives from the outside.
That all changed at DrupalCon Prague recently - where we took several of our Drupal developers primarily to focus on Drupal 8 sessions and discussion. There was a wide range of sessions in the programme and as you would expect a high proportion related to Drupal 8 as we approach the point where contributed module maintainers can start to think about porting their code.
Whilst there are many concurrent initiatives going on in Drupal 8, we feel there will be the biggest impact on the type of sites we build every day from these changes:
Drupal exists in a single database - user content and module configuration are all contained with this. When working on a site where there are multiple environments - for example, development, staging and production - this becomes a headache to manage.
The moment a user starts entering content you have a management problem on your hands. Even if the site is not yet in production. Changes to a module's settings or a view configuration needs to be handled carefully. There are known techniques for handling this kind of problem - for example the Features module - but they are not ideal solutions and can rise to complications of their own.
The Configuration Management Initiative (CMI) aims to solve this problem by providing a central mechanism for modules to export their configuration to a file. The configuration files can be version controlled in a Git Repository and restored to the production site - thereby ensuring that updates can be carried out without risking any loss of content.
Symfony and OOP
In the lifespan of Drupal 6 and 7, a number of PHP frameworks have gained significant popularity. One of the most well known is Symfony. Many of the functions within Drupal core were specific to Drupal and in Drupal 8 many have been replaced by standard Symfony functions.
Adding Symfony support is a big change for Drupal, but it will mean that the focus of the core development is on Drupal specific functionality rather than reinventing tried and tested functions already implemented by Symfony.
In Drupal 7, support for Object Oriented Programming was available, but sporadically implemented both in core and contributed modules. This lead to a mixture of procedural and object oriented code that was sometimes difficult to understand.
Drupal 8 has a much more structured OOP approach and is something that the seasoned Java developers at i-KOS are looking forward to using.
Much of the work we do involves integrating Drupal Commerce with 3rd party systems. Web Services are the natural way to achieve this and it's a big improvement to see support for this in core. In a nutshell this means that Drupal switches from being a page generating CMS to an engine for delivering content in any form - whether is be JSON, XML or a proprietary format.
Improved Multilingual Support
Even though Drupal 7 took great strides in improving multilingual support, it was never perfect - with at least two techniques available that partially solved the problem.
The Multilingual initiative took a complete fresh start on the problem and allows field level translation throughout a site.
Less in Contrib more in Core
Whilst a bloated Drupal core is not something that anyone wants, the core initiatives are doing a great job of incorporating the essential features that were previously in the contrib space but were added to almost every site anyway.
So What Next?
We are still in the same position - when core APIs are frozen the move of contrib modules to a 8.x branch can start to happen. [However as we have seen with the Flag module](http://www.youtube.com/watch?v=AilpWNE0jzo "Flag module update"), this isn't as scary as it first appeared.
Everything we have seen this week though shows that many of the contrib modules we expected we'd have to wait for may not be required with D8 core and that will certainly reduce the time to market.
The [Drupal Commerce 2.0 Roadmap](http://www.drupalcommerce.org/roadmap "Drupal Commerce Roadmap") contains a plan for getting a Drupal 8 version of Drupal Commerce out. There's clearly a lot of work still to be done but we'll be keeping a much closer eye on things now as Drupal 8 matures to the point where we can help out a bit more effectively.
Exciting times are ahead!