You hate WordPress? This can reunite you!
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:
- your WordPress app name
- a WordPress app description
- 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:
- Add the repository to your
composer.json - Add the desired plugins and themes to your requirements using
wpackagist-pluginorwpackagist-themeas the vendor name. - Run
composer update - Plugins and themes are installed in
wp-content/plugins/andwp-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:
- WordPress needs to be bootstrapped from the new location using an
index.phpfile - The
wp-contentfolder will only contain the default plugins and themes from WordPress - 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.phpBootstrap 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.