Headaches updating Drupal 8 Beta

Drupal 8 promises to bring a lot of new features and tools to help us build and maintain our websites (for more information, I recommend you see my other post about Symfony and Drupal, with a release candidate just around the corner (at the time of writing this blog).

Here in Rootstack we have been working with the new platform to develop several projects, and between the new changes, we have seen especially the inclusion of several modules contributed in the core of Drupal 8 and export system data files. However, the alpha and beta versions of any project always involves limiting, and Drupal 8 is not the exception, by making upgrading a project from its first beta version to the latest version available, a real headache.

When starting with the development of a project in Drupal 8, it is important to take into account the need for extension of the site and the use of existing sites contributed (include several modules for the construction site, instead of implementing the new API Drupal development to include features on the site). The main problem are the changes in the beta versions of Drupal Core API in a process of implementing new functionalities and moving them to the new Symfony components. Several contributed modules have been required to be frequently patched as to prevent failures and errors in some or all of its features, like custom modules developed for our projects.

However, making frequent updates to the Core of Drupal and its modules has not been proven to be a solution, because several of these changes have affected - and have been affected - the main Drupal 8 system for code export: Manager Settings.

The Configuration Manager is the new export system data source for Drupal 8 and is one of the most anticipated new features for developers, replacing the system Features, that worked well for those who have previously developed in Drupal but who know that it has its limitations (such as problems of conflict the structure of the characteristics is strictly maintained). However, the use of this system in site's changes has proven to be even somewhat volatile and possibly useless trying to make version upgrades.

The export structure (and the .yaml generated) has been changed in almost all beta versions, which in the attempts to import settings made in older versions, have resulted in failed imports or even worse, an incomplete import, which results in the malfunctioning of the site .

The unique specific system of import has facilitated the importation of the most complex structures (such as views), but still showing problems with some of them, such as Content Types and Custom Blocks, among others.

Finally, we mention that, given the various changes made to the contributed modules and fast update cycles to which they are exposed, these have proved to be our enemy # 1. In my first draft of Drupal 8, which was mostly based on custom code, we have been less affected by changes in versions, with the exception of maintenance hints of changes to API functions and legacy systems. On the other hand, in a more recent site, we learned that trying to upgrade to one or two versions, not only caused problems with the import of the above settings, but it brought all kinds of problems with other modules like Views and Panels, which were affected by a series of new bugs that affected several project requirements.

In closing, keep in mind these 3 points for your next project with Drupal beta 8:

1. Make sure it is NOT a site that requires a lot of maintenance/future extensibility (at least until they release the official version of Drupal 8).
2. Try to rely as little as possible of the contributed Drupal modules available, taking advantage as much as possible the new API development.
3. Do not try to update modules or Drupal 8 installation.

Once Drupal 8 is available and more stable modules and stability in the Core API appear, finally we can overcome this these obstacles and reach higher standards that this version will allow.