Skip to content

Latest commit

 

History

History
104 lines (71 loc) · 4.02 KB

vip.md

File metadata and controls

104 lines (71 loc) · 4.02 KB

VIP

If the app is going to be deployed on VIP you will need to make the following changes.

Replace wp-content with the VIP Go Skeleton

rm -rf wp-content

git clone https://github.com/Automattic/vip-go-skeleton wp-content

Make sure you bring over the appropriate parts of the wp-project-skeleton folder though.

Change the vendor location to be a client-mu-plugin

"config": {
    "vendor-dir": "wp-content/client-mu-plugins/vendor"
}

Because we have moved the vendor directory, we will also need to update the path from which the test bootstrap file loads the autoload file generated by Composer

// /tests/bootstrap.php
require_once $root_dir . '/wp-content/client-mu-plugins/vendor/autoload.php';

Update config to reflect the move of mu-plugins to client-mu-plugins

Swap references mu-plugins with client-mu-plugins in the following files:

  • .gitignore
  • phpcs.xml.dist
  • phpunit.xml.dist

Change the install location of mu-plugins

"wp-content/client-mu-plugins/{$name}/": [
    "type:wordpress-muplugin"
],

Replace install with vip-install

rm bin/install;

mv bin/vip-install bin/install

Or remove bin/install and just use bin/vip-install

Update vendor volums for app and app_xdebug in docker-compose.yml

We set the vendor directory as a volume in docker so we can set it to delegated due to it predominantly being written too by the container. When on VIP this is likely to differ from wp-content/vendor to something more like wp-content/client-mu-plugins/vendor so this should be updated accordingly within docker-compose.yml.

Ordering of initialisation files

VIP uses a 000-vip-init.php file to initialise their code, we use a 000-boxuk-init.php file. Code initialised by the VIP initialisation script defines a constant called WPCOM_VIP_CLIENT_MU_PLUGIN_DIR. It does not check whether this constant is already defined before defining it, so we are unable to set it ourselves. However, code initialised by our script relies on this constant being set. Therefore the VIP initialiser needs to run before ours. Because these files are loaded in alphabetical order, 000-vip-init.php will be loaded after 000-boxuk-init.php. Therefore, in order to swap the order these are loaded we must rename our initialisation file to 001-boxuk-init.php.

Also, add the following to the top of your 001-boxuk-init.php file so that the plugin loader reads from our client-mu-plugin directory rather than the vip mu-plugin directory:

define( 'MU_PLUGIN_LOADER_SRC_DIR', WPCOM_VIP_CLIENT_MU_PLUGIN_DIR . '/' );

Generate DI container cache at deployment

When using the DI Container, we cache it. However, VIP do not permit writing to the filesystem in this way. Therefore, this file needs to be generated before it is deployed to VIP.

One approach to this is to generate the cached file within your CI pipeline using a script such as this:

#!/usr/bin/env php
<?php
/**
 * This dumps the DI cache during the build so it can be part of a deploy.
 *
 * @package WordPress
 */

declare ( strict_types=1 );

require __DIR__ . '/../wp-content/client-mu-plugins/vendor/autoload.php';


// Define constants for custom VIP Go paths
require_once __DIR__ . '/../wp-content/client-mu-plugins/001-boxuk/BoxUkContainer.php';
require_once __DIR__ . '/../wp-content/client-mu-plugins/001-boxuk/BoxUkContainerFactory.php';

const WP_CONTENT_DIR = __DIR__ . '/../wp-content';
const WPCOM_VIP_CLIENT_MU_PLUGIN_DIR = WP_CONTENT_DIR . '/client-mu-plugins';
const WPMU_PLUGIN_DIR = __DIR__ . '/../wp-content/client-mu-plugins';
const WP_PLUGIN_DIR = __DIR__ . '/../wp-content/plugins';
const WP_DEBUG = false;

BoxUkContainerFactory::instance();