Dec 27, 2014

Beta 3 --> Beta 4: Configuration schema and metadata

When I attempted to run the automated test suite for the module, several of the tests failed that had passed in the previous beta of D8.

But the following fatal error was also displayed:

Uncaught PHP Exception Drupal\Core\Config\Schema\SchemaIncompleteException: "No schema for optimizely.settings" at /var/www/html/opti/core/lib/Drupal/Core/Config/Testing/ConfigSchemaChecker.php line 91

For the module, optimizely.settings is the name of a group of configuration settings that are implemented using the Simple Configuration API, which I blogged about in this post.

So what happened?

As of Beta 4, by default the TestBase class and its derived classes such as WebTestBase are required to provide schemas for configuration data. This can be done through use of a .schema.yml file.

For example, for the optimizely module, I created the file


whose contents are

    type: mapping
    label: 'Optimizely Config Data'
        type: integer
        label: 'Optimizely ID Number'
        translatable: false

The type property indicates that this schema is to provide static mappings. The mapping property then describes one or more settings. In this case, there is just the one setting optimizely_id.

Besides integer, other commonly used types would be string and text. There are several others that are pre-defined, and you can also define your own type.

The translatable property is false by default but I decided to explicitly code it to emphasize that a primary purpose of these schemas is to document items that may need to be translated.

For each group of settings such as optimizely.settings, there may be an additional file named optimizely.settings.yml that provides other data about those settings, such as their values. I didn't need such a file here, but the source articles give examples and a lot of info.

One final thing: if you really don't want to adhere to this requirement, you can disable the check for the presence of schemas by including the following line in your test class. However, this is an expediency that is discouraged.

  protected $strictConfigSchema = FALSE;

Update: the langcode key is now required for automated testing. See


All TestBase derived tests now enforce strict configuration schema adherence by default

Configuration schema/metadata

Dec 24, 2014

Beta 3 --> Beta 4: Use libraries, not individual stylesheets or javascript files

I installed Drupal 8 beta 4 with hopes that I would not have to make any code changes other than bumping up the version number. Alas, it was not to be.

As soon as I tried to go to the module's configuration page, I got the unhelpful error message, 

  The website has encountered an error. Please try again later.

Going to admin/reports/dblog showed the log message:
LogicException: You are not allowed to use css in #attached in drupal_process_attached() (line 1759 of /var/www/html/opti/core/includes/

Searching for "css" through the change records for Drupal core revealed that css and javascript files are now organized and declared within libraries that are defined in the .libraries.yml file.

For example, in the D7 version there are lines of code such as the following when building a form,

  $form['#attached']['css'] = array(
    drupal_get_path('module', 'optimizely') . 

  $form['#attached']['js'] = array(
    drupal_get_path('module', 'optimizely') . 

In D8, we have instead yet another YAML file optimizely.libraries.yml whose contents are,

    version: VERSION
        css/optimizely.theme.css: {}

    version: VERSION
      js/optimizely.admin.js: {}
      - core/jquery
      - core/drupalSettings

In this example, two libraries optimizely.forms and optimizely.enable are defined. Both css and javascript can be part of the same library, but I separated them for finer granularity.

The relative paths to the files are relative to the root of the defining module.

For the css property, the theme sub-property or some other sub-property is required for a valid definition. Otherwise, the attempted inclusion of the css will silently fail. See the article CSS file organization (for Drupal 8).

The dependencies property is critical. After a couple of hours of debugging, I realized that the JavaScript was failing because jQuery is no longer automatically included in every page, so it must be explicitly specified. The other dependency is a variable that is referenced that is part of drupalSettings.

VERSION seems to be a filler value that means no particular version.

To use these libraries,  the equivalent form building code then has the lines,

  $form['#attached']['library'][] = 

  $form['#attached']['library'][] = 


Adding stylesheets (CSS) and JavaScript (JS) to a Drupal 8 module

hook_library_info() is replaced by *.libraries.yml file

CSS file organization (for Drupal 8)

Change records for Drupal core

Dec 22, 2014

Beta 3 --> Beta 4: "Routes use _controller instead of _content"

When defining routes in the .routing.yml file, the _content property is no longer valid. I got a "page not found" error when browsing to such a route.

Use _controller instead.


  path: /admin/config/system/optimizely/add_update/{oid}
    _content: \Drupal\optimizely\DoUpdate::buildUpdateForm
    _title: Optimizely Edit Project
    _permission: administer optimizely


  path: /admin/config/system/optimizely/add_update/{oid}
    _controller: \Drupal\optimizely\DoUpdate::buildUpdateForm
    _title: Optimizely Edit Project
    _permission: administer optimizely


Routes use _controller instead of _content

Dec 16, 2014

Migrating the Optimizely module to Linux Mint

Migrating the Optimizely module to Linux Mint for local development involved three steps:

- installing Drupal 8 beta 3
- installing the module and testing it manually
- running the module's automated test suite

This all went pretty smoothly with minimal work, which is very encouraging as far as transitioning to doing Drupal development in a Linux system.

The one important point I'd like to make in this post is that to chown the entire Drupal instance to www-data:www-data as the owner:group seems to take care of all the owner and permission problems I've had in the past.

The rest of this posting is pretty routine stuff but potentially useful for anyone doing a similar migration.

(1) Installed Drupal 8 beta 3.

Edited /etc/apache2/apache2.conf to insert the following directive, where opti is the site root under the web server root.

<Directory /var/www/html/opti>
    AllowOverride All

Changed the owner of the entire site instance to the user that Apache apparently runs under.

# cd /var/www/html
# chown -R www-data:www-data opti

(2) Installed the Optimizely module.

I copied over the module tree from my old development system. I could have just cloned the repo from Github instead.

# cd /var/www/html/opti/modules/
# mkdir contrib

# cp -r ....../optimizely contrib

And changed the owner of contrib and its subdirectories.

# chown -R www-data:www-data  contrib

These steps were sufficient to get the module installed, enabled, and functioning.

(3)  Ran the module's automated test suite.

When I tried to enable the Testing core module, I got the error message

The testing framework could not be installed because the PHP cURL library is not available.


# apt-get install php5-curl

This then allowed the Testing module to be enabled.

Successfully ran the entire suite of nine tests. No fails, no exceptions.

The test run finished in 8 min 42 sec.

Interestingly, I did not have to increase the php max execution time as was necessary when I ran this suite in a Linux Mint virtual box on a old Windows 7 host.

Dec 13, 2014

Running out of disk space on Linux Mint partition, changing the MySQL data directory

I bought a PC with Linux Mint 17 already installed. This is my first time working on a Linux system, so there's been a bit of a learning curve.

Things were going along pretty well until I started to get all kinds of weird errors.

• A text file that I maintain manually had the last part of its contents truncated from the last time I had saved it.

• I could not log in to phpMyAdmin even though I knew the username and password were correct.

• An initial install of Drupal 7 would not come up with its front page. A PDO error on a SQL query was being reported.

Eventually I suspected something related to databases, happened to run the Disk Usage Analyzer and found that one of the disk partitions had run out of space. Oh, joy.

It turns out that the system I got was configured with three partitions. On the File Systems tab of the System Monitor app, it shows the partitions and their total sizes as

/dev/sda1   /boot  463.9 MiB
/dev/sda5   /       18.6 GiB
/dev/sda6   /home  215.4 GiB

By default, MySQL 5.5 stores its data on /var/lib/mysql which is on the / partition which has about 18 GiB allocated to it.

That partition was not large enough for the Drupal 7 database along with everything else that was there, which apparently includes the system itself and apps that I had earlier installed.

Looking at these space allocations, I inferred that /home is where user data of all sorts is intended to be kept.

So I used the sources listed below to figure out how to change where MySQL stores its data.

(0) But first, I figured I should clean up the mess I had already created by uninstalling phpMyAdmin, and then completely uninstalling MySQL.

(I carried out all the commands in this post while logged in as root. Alternatively, you could use sudo instead.)

# apt-get remove phpmyadmin

# /etc/init.d/mysql  stop
# apt-get remove mysql-server
# cd /var/lib
# rm -r mysql

# apt-get autoremove

That last command is to remove any packages that are no longer needed on the system. I'm pretty fussy about not keeping useless clutter around.

(1) Then, re-installed MySQL 5.5.

# apt-get install mysql-server

(2) Changed the MySQL data directory to use the much larger partition. In my case, I chose to put the data directly under /home

# /etc/init.d/mysql  stop
# cp -R -p  /var/lib/mysql  /home

# cd /var/lib
# rm -r mysql

# ln -s  /home/mysql  /var/lib/mysql

That last command is to provide a symbolic link from the default directory to the real one. Otherwise, you can edit the datadir setting in the MySQL configuration file /etc/mysql/my.conf

Note that the MySQL logs are still located in  /var/log/mysql

(3) The final step was to deal with the AppArmor app.

Edited /etc/apparmor.d/usr.sbin.mysqld to change from

  /var/lib/mysql/ r,
  /var/lib/mysql/** rwk,


  /home/mysql/ r,
  /home/mysql/** rwk,

I couldn't find the apparmor app mentioned in the source articles. Instead, I rebooted in order for these AppArmor security changes to take effect. (Could the AppArmor functionality be baked into the Linux Mint system?)


How to change the MySQL data default directory

Linux Ubuntu move mysql database to other path in 5 minutes

How to Remove MySQL Completely from Linux System

Dec 3, 2014

Setting up xDebug with Sublime Text under Linux Mint

I wrote an earlier post about setting up the xDebug PHP debugger with the Sublime editor under Windows 7.

I'm now migrating to developing on a Linux system and have done this set up for Sublime Text 3 and Linux Mint 17.

This post borrows heavily from the earlier article. 

(1) Installed xDebug 2.2.3 extension for PHP.

(a) While logged in as root,

  # apt-get  install  php5-xdebug

This installed the php5-xdebug package, creating the two files


On your system, the path for may be a little different.

20-xdebug.ini is actually a link to the file mentioned in step (2) below.

(b)  Restarted Apache. Loaded a page containing a call to phpinfo() to check that the extension was installed. On the page there appeared an xdebug section with several tables that showed settings and directives.

(2) Added directives for xDebug.

Edited /etc/php5/mods-available/xdebug.ini to include the following lines.

  xdebug.remote_enable = On
  xdebug.remote_host = "localhost"
  xdebug.remote_port = 9000
  xdebug.remote_handler = "dbgp"
  xdebug.remote_autostart = On
  xdebug.remote_mode = req
  xdebug.remote_connect_back = 0 

Because I only want to debug locally, I set xdebug.remote_connect_back to 0 to turn it off. I believe this should be set to 1 if you intend to debug a site running on a remote system.

(3) Installed the Sublime package manager, "Package Control".

(a)  Within Sublime, clicked Preferences > Browse Packages, then browsed up one level to find the full path for the Installed Packages folder. On my system the path is

  ~/.config/sublime-text-3/Installed Packages

(b)  Downloaded the file Package Control.sublime-package from

(c)   Copied that file into the Installed Packages directory.

(d)  Re-started Sublime.

In Sublime's Command Palette window, various Package Control commands are then available on the palette and elsewhere.

(4) Using Sublime's Package Control, installed the Xdebug Client package.

  Tools > Command Palette ...  >  Package Control: Install Package

Typed Xdebug Client into the search field, and clicked on Xdebug Client in the search results to install.

This adds a submenu, Tools > Xdebug, or you can use the keyboard equivalents.

(5) To start an xDebug session.

To start a debugging session, I load the site by appending the query string ?XDEBUG_SESSION_START=1  to the initial url, like so.


The value of  XDEBUG_SESSION_START  is a session name that is stored in a cookie, so it probably could be any name you choose.

There are other ways to start an xDebug session, but for getting started with using this debugger, this seems like the simplest.

Finally, in Sublime itself, to activate the editor as an xDebug client,

  Tools > Xdebug > Start  Debugging


Debug PHP with Xdebug in Sublime Text 2 (in Linux mint)


martomo / SublimeTextXdebug

Package Control

Download:  Package Control.sublime-package