Rebuilding the Cheppers website with Drupal 8: On The Road

Our solution

Each member of our team has installed the latest Drupal 8 version (8.0.0-beta6 at the time) on his computer. We created a custom install profile by copying the .yml files from core/profiles/standard/config/install to our custom profile folder profile/<your_profile>/config/install. Later as we’ll build up the install profile we will copy the modified and newly created config files as well to this folder. I was tasked with creating new content types and when I finished, I wanted to share it with the other members of my team, so I did a full config export (admin/config/development/configuration/full/export) and my colleagues tried to import (admin/config/development/configuration/full/import) the tarball but the import failed, showing this message: “The staged configuration cannot be imported, because it originates from a different site than this site. You can only synchronize configuration between cloned instances of this site.” When we checked the exported .yml files in the system.site.yml we could see that the UUID (universally unique identifier) of each site is different. After some googling, we found this blog post, and based on what we learned from it, we wrote a deploy module so that all of our dev sites would have the same UUID. We placed the deploy module in profiles/<your_profile>/modules/custom/<your_module> folder. This folder consists of the following files:

<your_module>.install

function<your_module>_install(){
// This module is designed to be enabled on a brand new instance of
// Drupal. Settings its uuid here will tell this instance that it is
// in fact the same site as any other instance. Therefore, all local
// instances, continuous integration, testing, dev, and production
// instances of a codebase will have the same uuid, enabling us to
// sync these instances via the config management system.
// See also https://www.drupal.org/node/2133325
<your_module>_set_uuid('<a uuid like: af5248ff-4844-4461-b200-ce87afba7af9>');
}

<your_module>.module

<?php
/**
* @file
* site deployment functions
*/
use Drupal\Core\Extension\InfoParser;

/**
* Set the UUID of this website.
*
* By default, reinstalling a site will assign it a new random UUID, making
* it impossible to sync configuration with other instances. This function
* is called by site deployment module's .install hook.
*
* @param $uuid
* A uuid string, for example 'e732b460-add4-47a7-8c00-e4dedbb42900'.
*/

function<your_module>_set_uuid($uuid){
// After Jan. 16th, 2015, see [Nathanael's comment](http://dcycleproject.org/comment/2603#comment-2603)
\Drupal::configFactory()->getEditable('system.site')
->set('uuid',$uuid)
->save();
}

<your_module>.info.yml

name: Your module name
type: module
description: 'Your module’s description'
package: <a package name>
version: VERSION
core: 8.x

Once this was done and all of the dev sites were reinstalled, they had identical UUIDs. To check this, do a full export on both sites and compare UUID in system.site.yml files. Then, we tried a full export/import again. After my teammates uploaded the config.tar.gz file consisting of the settings of my dev site, we saw a long list of configuration files and received this message: Your configuration files were successfully uploaded, ready for import. Everything looked good up to that point. We pressed the [Import all] button. Earlier, we had selected the All messages, with backtrace information option on admin/config/development/logging page and we received this error message (I'll paste the whole message so others with the same problem might find this post easier).


Drupal\Core\Entity\Query\QueryException:Null implementation can not be queried. in Drupal\Core\Entity\ContentEntityNullStorage->getQueryServiceName()(line 82 of core/lib/Drupal/Core/Entity/ContentEntityNullStorage.php).
Drupal\Core\Entity\EntityStorageBase->getQuery()
Drupal\Core\Entity\Event\BundleConfigImportValidate->onConfigImporterValidate(Object,'config.importer.validate', Object)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('config.importer.validate', Object)
Drupal\Core\Config\ConfigImporter->validate()
Drupal\Core\Config\ConfigImporter->initialize()
Drupal\config\Form\ConfigSync->submitForm(Array, Object)
call_user_func_array(Array,Array)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object)
Drupal\Core\Form\FormBuilder->processForm('config_admin_import_form',Array, Object)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array,Array)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object,1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object,1,1)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object,1,1)
Drupal\Core\StackMiddleware\PageCache->pass(Object,1,1)
Drupal\Core\StackMiddleware\PageCache->handle(Object,1,1)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object,1,1)
Stack\StackedHttpKernel->handle(Object,1,1)
Drupal\Core\DrupalKernel->handle(Object)

This error occured because we hadn’t cloned the database and the export/import mechanism only works smoothly on sites in which the databases are exactly the same. Besides that, we realized that one file was missing from the tarball made by full config export. I couldn’t find an issue about this on drupal.org, so I submitted one. Trying to find a solution, we wrote a module we called config_partial_export, which we made into a contrib module. You can find it here, any feedback is welcome. With the help of this module, we can now easily export only the modified config files. The team members copy the exported files (through git, of course) to their profiles/<your_profile> config/install folder, and after reinstalling their sites, we see all the changes made on dev site. To make the site install easy, we use a phing script. The details about how we do this might be a subject of an upcoming blog post. Solving this problem will make the rest of this project much simpler, so this has been a very important part of our progress in learning to work with Drupal 8. We think we came up with quite a good solution, but if you think you can do better, please let us know.