Parse YAML in PHP Using Symfony YAML

Convert data in YAML format into a PHP array.

I do a lot of work in WordPress. I also build a lot of static websites – both for rapid design in-the-browser and as a low-cost small-business website solution. I mainly use the excellent Jekyll static site generator.

Jekyll uses YAML for config and data files (it can also use CSV format, but that’s another story). WordPress doesn’t use YAML.

I like YAML because it is very human friendly – the whole team (including non-developers) can easily build YAML config files in a way that you’re not going to see with formats like JSON or XML. This is an example of a YAML array used to create Javascript variables for use in a Google map:

# Map centre Latitude & Longitude
# ------------------------------------------------------------------------------
latitude: 52.7157856867271
longitude: -8.8741735070805

zoom: 15
#height: 548px

# Set custom colour variables
# ------------------------------------------------------------------------------
waterColour: "#398A8D"
landColour: "#dec7c7"
mainRoadColour: "#777777"
minorRoadColour: "#a9a9a9"

# A nested array
# ------------------------------------------------------------------------------
- One
- Two
- Three


In the context of Jekyll, you could use this as a data file – e.g./_data/map.yml – writing Javascript variables into `<head>` something like this:

var cwCentre = {
latitude:{{ }},
longitude:{{ }},
zoom:{{ }},
mainMarker:"{{ site.baseurl}}/{{ }}",
secondaryMarker:"{{ site.baseurl}}/{{ }}",
waterColour:"{{ }}",
landColour:"{{ }}",
mainRoadColour:"{{ }}",
minorRoadColour:"{{ }}",
title: "{{ | escape }}",
description:'{{ map_description | markdownify | strip_newlines }}',
{% if "multi-centre" == %}
var markers = [
{% for location in %}
'{{ | escape }}',
{{ location.latitude }},
{{ location.longitude }},
'{{ location.description | escape }}'
{% unless forloop.last %},{% endunless %}
{% endfor %}
{% endif %}

YAML in WordPress

I recently needed to convert a Jekyll site to a WordPress theme. Moving the map config settings required parsing YAML data into a PHP array. Fortunately this can be achieved pretty easily thanks to the Symfony YAML component.

I’m a recent convert to Composer, and find it amazingly powerful. You can add the Symfony YAML component with a single composer command.

Add Symfony/YAML Using Composer

composer require symfony/yaml

When you run this, composer will add a new `symfony/yaml` directory under the project ‘vendor’ directory. It will also add the relevant namespace to the ‘autoload_psr4.php’ file, so that the new class will be autoloaded.

Using the YAML parser

To read the YAML contents of the config fields into a PHP array:

use Symfony\Component\Yaml\Parser;

$yaml = new Parser();

$value = $yaml->parse( file_get_contents( get_template_directory() . '/assets/map.yml' ) );

For the YAML content presented above, the following will be output:

$value = array (
'latitude' => 52.715785686727102,
'longitude' => -8.8741735070804992,
'zoom' => 15,
'waterColour' => '#398A8D',
'landColour' => '#dec7c7',
'mainRoadColour' => '#777777',
'minorRoadColour' => '#a9a9a9',
'test' => array (
0 => 'One',
1 => 'Two',
2 => 'Three',

This array can be passed to wp_localize_script() when enqueuing the map script.

The WordPress/PHP way would be to collect such data from a form on an admin page, storing the data in the wp_options table. However taking variables from YAML files can be a good way to quickly port settings, which might even be used as defaults. It might also be a good way to configure certain project settings.

Semantic Bootstrap Layout Classes with an Offset

Making CSS classes descriptive, or semantic, can help improve code maintainability by describing an elements purpose, rather than it’s presentational function.

People level this as a criticism against Bootstrap (and other CSS frameworks) – where column names are presentational rather than semantic. In other words, in a typical Bootstrap project the main content area might have a class name like .col-md-8, which is not semantic.

Fortunately, Bootstrap makes it pretty easy to define semantic classes that apply the built-in presentational logic, by use of the make-x-column()mixins.


The Sage WordPress starter theme (a great starting point for WordPress projects) defines a .main and a .sidebar class out of the box.

The column widths for these elements can then be set in a _variables.scssfile.


I’ve modified the Sage definition of .main and .sidebar to add an offset to the sidebar, using the additional Bootstrap mixin make-sm-column-offset().

I find the offset really good for user experience – constraining the main content area generally makes for greater readability, and the extra whitespace between content and sidebar can reduce the sensation of clutter.

// Grid system

.main {

// No sidebar, `.main` is full width
@include make-sm-column($main-sm-columns);

// `.main` is contained by the `.sidebar-primary` parent class -

// this class is added to the <body> of pages that display the sidebar.

// If a sidebar displays, `.main` can take a reduced width.

.sidebar-primary & {

// `.main` is narrower by 2 columns, to give room for the offset
@include make-sm-column($main-sm-columns - $sidebar-sm-columns - 2 );



.sidebar {

// Set the width, then the offset, using Bootstrap mixins
@include make-sm-column($sidebar-sm-columns);
@include make-sm-column-offset(2);



Checking Bash Scripts

I found this very useful resource that allows you check bash scripts online:

I’ve been writing quite a few bash scripts lately – amongst other things, I find them useful for running automatic backups and scaffolding out projects from a Github repo starting point.

The tool helps with:

…typical beginner and intermediate level syntax errors and pitfalls where the shell just gives a cryptic error message or strange behavior, but it also reports on a few more advanced issues where corner cases can cause delayed failures.


It is certainly helping me to improve my bash scripting.

Linter Shellcheck in Atom

You can set up Shellcheck as an Atom package.

In Ubuntu:

# Install shellcheck on your system
sudo apt-get install shellcheck

# Install Base linter for Atom
apm install linter

# Install shellcheck
apm install linter-shellcheck

You’ll need to restart Atom.



Adding a .htaccess File to a Jekyll Site

How to have Jekyll build a .htaccess file into your project

If you serve your site with Apache, adding a .htaccess file to your document root allows fine control over access permissions.

Amongst other things, .htaccess rules can set:

  • In-browser caching
  • Access – you could allow/disallow access from certain IP addresses or ranges
  • Redirects
  • Rewrites

You can also prevent modification of code over 3G on some European providers (I’ve experienced UK providers in particular totally mangling site styles).

When setting up WordPress sites, I would typically lock down access to the entire admin area by IP address as a security measure. While this isn’t necessary for Jekyll sites (where there is no login), .htaccess rules can be a useful way of controlling how your site resources are cached. This has the potential to speed up site loading times.

.htaccess in Jekyll

Update: by default, Jekyll includes .htaccess files – so explicitly including your .htaccess file is unnecessary.

By default Jekyll excludes dotfiles – but you can easily override this behaviour.

In the project config.yml (or config_prod.yml if you have a production environment config file), add this line:

include: ['.htaccess']

Jekyll will now build the .htaccess file – which is much more convenient than editing the file on the server.

Create .htaccess file in the root of your Jekyll project.

When you build  the project, the .htaccess file will be included in the project root.

Sample .htaccess for Cache Control

The following .htaccess directive tells browsers to use cached content for the specified files. Just add the directive to the project .htaccess file:

# Set browser caching
# ------------------------------------------------------------------------------
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
# End caching block

WordPress Debugging

On-screen debugging output, writing errors to a log file, real time monitoring of the debug log

In general, error logging should be enabled in the development environment and disabled in production environments.

To enable WordPress error reporting to the browser, and to enable error logging to file, add the following lines to wp-config.php:

// Enable error reporting output to browser. Default value is false.
 define( 'WP_DEBUG', true );
// log errors to `/wp-content/debug.log`. Useful when debugging code that does not output to browser.
define('WP_DEBUG_LOG', true);

Continue reading » “WordPress Debugging”