•DS://
About

You hate WordPress? This can reunite you!

 • 6 minutes read

WordPress and the love of developers!

Everyone knows WordPress, and everyone knows that developing with WordPress is a pain is the ass ( If not, I can't do anything for you :( ).

The most common answer about people loving WordPress so much is: extensibility.

From the past years WordPress provides a lot of themes and plugins and this is why people will choose WordPress compared to other CMS.

However, WordPress as a big dark sides for developers, it uses old and deprecated stuff, do not use a template engine for rendering views, and so on about many things...

It's 2016, why not using new features?

Let's now see how we can integrate in WordPress some cool stuff, already used by many developers.

Composer

Composer is a dependency manager for PHP that has been gaining steam lately. Your first question is most likely what is a dependency manager and why do I need one?. Almost any code you write probably ends up depending on 3rd party libraries. All of these libraries (projects, frameworks, files, etc) become dependencies of your project. Composer lets you declare the dependencies for a project, and it will install and manage them.

1. Installing composer

Installing Composer is pretty simple with one caveat: It requires PHP 5.3 to run. Follow the instructions for either *nix, OSX or Windows.

I suggest installing Composer globally and then you can just use the composer command from anywhere.

2. Project Setup

To start using Composer in your project, all you need is a composer.json file.

This file describes the dependencies of your project and may contain other metadata as well.

In this example bellow, we will add some optional metadata to name properly your WordPress application:

  1. your WordPress app name
  2. a WordPress app description
  3. finally, some information about yourself
1{ 2 "name": "davidsanchez/sources", 3 "description": "Package to build WordPress sources for davidsanchez.me", 4 "authors": [ 5 { 6 "name": "David Sanchez", 7 "email": "david38sanchez@gmail.com" 8 } 9 ] 10}

Integrating with WordPress

We are now ready to see how to use Composer with WordPress. When you think about a typical WP site, the easiest example of dependencies are plugins. But there’s something more fundamental to realize: WordPress itself is a dependency.

If we think about it, we’re creating a site, or application, that depends on WordPress. The WordPress core is a 3rd party library that is required for your application to work. This is difficult to understand at first due to how WordPress sites are usually structured.

The best solution right now is to use a fork of WordPress with a already added composer.json file.

https://github.com/johnpbloch/wordpress is currently the most popular/accepted package.

It’s simply an auto-updating fork (syncs every 15 minutes with the official WP repo) that includes composer.json wordpress-core-installer package. You can view it here.

Under, your authors metadata, we will add the next lines to require WordPress core:

1{ 2 "require": { 3 "johnpbloch/wordpress": "~4.5" 4 }, 5 "extra": { 6 "wordpress-install-dir": "wp" 7 } 8}

That’s it.

We just require johnpbloch/wordpress with the version of WordPress that we want and then tell Composer we want WordPress installed to wp.

WordPress Packagist

Fortunately, the awesome people at Outlandish have created a repository of WordPress plugins called WordPress Packagist.

Basically, they mirror every WordPress plugin and add a composer.json file that requires composer-installers and sets their package type to wordpress-plugin or wordpress-theme.

Their instructions are simple too:

  1. Add the repository to your composer.json
  2. Add the desired plugins and themes to your requirements using wpackagist-plugin or wpackagist-theme as the vendor name.
  3. Run composer update
  4. Plugins and themes are installed in wp-content/plugins/ and wp-content/themes/

So, we will now add the require metadata to tell Composer to get the WordPress plugins and themes from the WordPress Packagist:

1{ 2 "repositories": [ 3 { 4 "type": "composer", 5 "url": "https://wpackagist.org" 6 } 7 ], 8 "extra": { 9 "installer-paths": { 10 "content/mu-plugins/{$name}/": [ 11 "type:wordpress-muplugin" 12 ], 13 "content/plugins/{$name}/": [ 14 "type:wordpress-plugin" 15 ], 16 "content/themes/{$name}/": [ 17 "type:wordpress-theme" 18 ] 19 } 20 } 21}

After that, you will be able to go to the WordPress Packagist and add your WordPress plugins and themes into your composer.json file.

Restructuring WordPress

Like we said before, with Composer WordPress will be a depency, this is why people choose to put the WordPress's core into a directory named wp/.

No matter which direction you choose when installing WordPress in a subdirectory there is a certain amount of restructuring that needs to be done to make it work. Mainly three things need changed:

  1. WordPress needs to be bootstrapped from the new location using an index.php file
  2. The wp-content folder will only contain the default plugins and themes from WordPress
  3. Any environment/config files (e.g. .htaccess/wp-config.php) also need to be in the root path

So our directory structure should now look something like this:

1/ 2| 3|-- wp-content/ 4|-- wp/ <-- Our directory install location for WordPress (not stored in Git repo) 5|-- .htaccess 6|-- index.php 7|-- wp-config.php 8|-- .gitignore 9|-- composer.json <-- If using Composer 10`-- local-config.sample.php

Bootstrap index.php

This part is relatively simple. We’re going to install WordPress into the wp subdirectory, so we need to tell our webserver where to find WordPress. As everything is routed through the main index.php file (see .htaccess) we can simply create a bootstrap index.php file with the following contents:

1<?php 2// WordPress bootstrap 3define('WP_USE_THEMES', true); 4require __DIR__ . DIRECTORY_SEPARATOR . 'wp/wp-blog-header.php';

Environment config

You’ll notice the local-config.sample.php file in the root directory above. While this is not technically necessary it’s a good idea to split up environment-specific config information (such as database credentials and secret keys) from the “global” config information stored in wp-config.php (such as the table prefix and the wp-content location).

The idea here is that the wp-config.php file will hold any “global” config information and then load the correct “environment” config file as required. So for your production site you can deploy a production-config.php file which can be loaded by wp-config.php if it exists (we don’t store it in the Git repo though for security purposes) and if production-config.php doesn’t exist fall back to local-config.php which assumes you are working on a local development environment.

The content of our new wp-config.php file should look like:

1<?php 2// =================================================== 3// Load database info and local development parameters 4// =================================================== 5if (file_exists(__DIR__ . DIRECTORY_SEPARATOR . 'production-config.php')) { 6 define('WP_LOCAL_DEV', false); 7 include __DIR__ . DIRECTORY_SEPARATOR . 'production-config.php'; 8} 9else { 10 define('WP_LOCAL_DEV', true); 11 include __DIR__ . DIRECTORY_SEPARATOR . 'local-config.php'; 12} 13 14// ======================== 15// Custom Content Directory 16// ======================== 17define('WP_CONTENT_DIR', __DIR__ . DIRECTORY_SEPARATOR . 'content'); 18define('WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/content'); 19 20// ================================ 21// Language 22// Leave blank for American English 23// ================================ 24define('WPLANG', ''); 25 26// ========================= 27// Disable automatic updates 28// ========================= 29define('AUTOMATIC_UPDATER_DISABLED', false); 30 31// ======================= 32// Load WordPress Settings 33// ======================= 34$table_prefix = TABLE_PREFIX; 35 36if (!defined('ABSPATH')) { 37 define('ABSPATH', __DIR__ . DIRECTORY_SEPARATOR . 'wp' . DIRECTORY_SEPARATOR); 38} 39require ABSPATH . 'wp-settings.php';

Sample config

You will need to rename the local-config.sample.php to local-config.php to use it. It should look something like this:

1<?php 2/** The name of the database for WordPress */ 3define('DB_NAME', 'local_db_name'); 4 5/** MySQL database username */ 6define('DB_USER', 'local_db_user'); 7 8/** MySQL database password */ 9define('DB_PASSWORD', 'local_db_password'); 10 11/** MySQL hostname */ 12define('DB_HOST', 'localhost'); // Probably 'localhost' 13 14/** Database Charset to use in creating database tables. */ 15define('DB_CHARSET', 'utf8mb4'); 16 17/** The Database Collate type. Don't change this if in doubt. */ 18define('DB_COLLATE', ''); 19 20/** The Database tables prefix */ 21define('TABLE_PREFIX', 'wp_'); 22 23/** 24 * https://codex.wordpress.org/Editing_wp-config.php#Debug 25 */ 26define('WP_DEBUG_DISPLAY', true); 27define('WP_DEBUG', true); 28 29/** 30 * Salts, for security 31 * https://codex.wordpress.org/Editing_wp-config.php#Security_Keys 32 */ 33define('AUTH_KEY', 'put your unique phrase here'); 34define('SECURE_AUTH_KEY', 'put your unique phrase here'); 35define('LOGGED_IN_KEY', 'put your unique phrase here'); 36define('NONCE_KEY', 'put your unique phrase here'); 37define('AUTH_SALT', 'put your unique phrase here'); 38define('SECURE_AUTH_SALT', 'put your unique phrase here'); 39define('LOGGED_IN_SALT', 'put your unique phrase here'); 40define('NONCE_SALT', 'put your unique phrase here'); 41 42/** 43 * https://codex.wordpress.org/Editing_wp-config.php#WordPress_Upgrade_Constants 44 */ 45define('FS_METHOD', 'direct');

Install WordPress using Composer

Now that we have our working composer.json file, let’s actually install WordPress and his dependencies by running composer install in a terminal.


© 2013-2024 All rights reserved.

Built with Next.js. Designed with in Montreal