Using GitLab CI to Deploy WordPress Sites

So I work with a team that use Git to manage all the theme code for a large WordPress site. It’s a corporate, and as is the way with big organisations, they wanted their version control in house. Hence I set them up a GitLab box. Want to make an alteration to CSS or whatever?

  1. Code & test on your local dev stack
  2. Commit via git & push up to Gitlab
  3. SSH into the server, `git pull` the new code down
  4. Run `gulp build` to update the compiled assets

Job done. Wouldn’t it be great if you didn’t need steps 3 & 4 though? They don’t take long in the short term, but get very tedious after a while. They also introduce an element of risk if you have less technical people needing to deploy code that shouldn’t be let loose on the terminal of your production web server…. Hence: GitLab CI to the rescue!

Continue reading “Using GitLab CI to Deploy WordPress Sites”


Local Theme Development on WordPress MultiSite

So this blog runs as part of my WP Multi Site network. Multi-site is great – one click to upgrade the WP core for all sites, one setup for caching etc.

One problem is local dev though. You don’t want to pull the whole network down to your local machine to work on a theme (it’d take ages) but you still want to develop against the posts and pages that are on the live site.

Interesting solution to this:

WP Multi-site stores DB tables with different prefixes for each site. So for instance you’d have wp_2_postswp_2_options etc. for site No. 2.

Let’s try altering a few bits in wp-config.php to make use of this:

define('WP_HOME', 'http://localsite.loc');
define('WP_SITEURL', 'http://localsite.loc');
define('DB_NAME', 'your_multisite_db');
define('DB_USER', 'your_multisite_user');
define('DB_PASSWORD', 'yourpw');
define('DB_HOST', '127.0.0.1:3307');
$table_prefix = 'wp_2_';

Finally create an SSH tunnel so you can access the DB running on your server on local port 3307 (Your local MySQL will be running on 3306). …..presuming you need to do this of course (article all about this here):

ssh -L 127.0.0.1:3307:127.0.0.1:3306 user@yourserver -N

That done, you should be good to go! One important caveat with this method: wp_users and wp_usermeta tables are global to all sites in the Multisite network (along with a few others). Therefore you won’t be able to login on your local copy and anything involving users on the front end will be screwed (like displaying post authors for instance). This really wasn’t much of a problem for my purposes on this site though. …so I thought I’d share.

Hope this helps someone!


Browser Sync, WordPress and Access-Control-Allow-Origin Errors

Well hopefully this will save someone half an hour….

A common way to make front end JS interact with WordPress’s AJAX functions (/wp-admin/admin-ajax.php) is to use something like:

[code lang=text]
wp_localize_script( 'my-script', 'myAjax', array( 'ajaxurl' => admin_url( 'admin-ajax.php' ) ) );
[/code]

Which is great. Unfortunately you’ll run into problems if you’re using Browser Sync for testing, in the form of a load of Access-Control-Allow-Origin errors in your console.

This is because wp_localize_script will escape the URL, scuppering the clever search & replace stuff Browser Sync does in it’s middleware / proxy functions.
To get round this, do something like:

[code lang=text]
function my_ajax_url() {
?>
<script type="text/javascript">
var ajaxurl = '<?php echo admin_url( 'admin-ajax.php' ); ?>';
</script>
<?php
}
add_action( 'wp_head', 'my_ajax_url', 3 );
[/code]

Sorted. Also, don’t go down the first route I did of making all WP’s URLs root relative because:
1. You can’t filter admin_url()
2. There are good reasons not to.