The perils of “nulled” WordPress themes

Having the largest ecosystem of any CMS ever, WordPress users have a lot of choice when it comes to themes. There’s thousands of open source offerings on as well as many more paid for ones on marketplaces such as Envato.

I recently wanted to assess the code quality of a few different paid themes before deciding on one to buy, so I downloaded some “not quit legitimate” copies from one of the many shady “nulled theme” sites, to run in a sandbox. Obviously you’d have to be a) quite immoral and b) an idiot to use such things in production, but I figured what’s the harm if the winning one’s going to be bought anyway.

After choosing the winner I thought I’d diff the two copies I had. Just how bad was the malware going to be?

Continue reading “The perils of “nulled” WordPress themes”

Setting permissions for your Gitlab CI Runner & W3 Total Cache

So in the last post on this, I looked at setting up auto deploy for a WordPress site using GitLab’s CI runner.  I also wanted the W3TC cache to be cleared, and thanks to WP-CLI, that was possible by adding:

to the end of the script node in .gitlab-ci.yml.

Now. “sudo?!?!?!?!” I hear you say? There’s a security risk if ever I saw one. Luckily this doesn’t have to be the case if things are set up right. Make a separate user for GitLab Runner and limit it to sudo-ing as only www-data and only running that command while doing so.

It’s a good idea to setup a separate user in general too, for security.

There wasn’t an awful lot of info on that when I Googled though, so (from inital user creation):

Done! Your CI script will now be able to run WP-CLI commands as www-data. No root access, no entering passwords.

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”

Git: Bringing the dev branch up to master

Other devs done a load of work on your develop branch that got abandoned? Branch diverged too much to merge back in with master? Well:

Job done. Remember branches are just pointers to states of the code over time.

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:

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):

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' ) ) );

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' ); ?>';
add_action( 'wp_head', 'my_ajax_url', 3 );

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.

The best way to spider & download an entire website

There seem to be a lot of GUI tools out there that purportedly download entire websites. The last one of these I tried using was SiteSucker, which sucked pretty badly. What you really need is this:

run from the terminal. I put this here in the interests of me remembering all the options and hopefully someone else saving themselves so many boobless hours of crap applications that don’t work.

Continue reading “The best way to spider & download an entire website”

Setting up SSH public key authentication

Tired of typing a password every time you login to your server? You’d be needing some SSH keys then. DSA ones are the best for this apparently, so on your local machine:

[bash]ssh-keygen -t dsa
cat ~/.ssh/[/bash]

copy the key you’ve just made to the clipboard, and on your remote machine paste it into the file ~/.ssh/authorized_keys

Simple as that. No more typing that password every time.

Fixing slow wp-cron requests on servers behind NAT routing

So we’ve been having a weird problem with WordPress installs on supposedly fast linux VMs running very slowly. It was mainly noticeable on server requests for the Dashboard by logged in users. After a bit of analysis using New Relic, we narrowed it down to external web requests taking a long time.

The trouble was, these requests were mainly pointed back to the server itself. For instance:


The actual load on Nginx & PHP processes was practically non-existent. PHP was just waiting for it’s cURL requests to come back. How strange.

As it turns out, the server was receiving all it’s network traffic via NAT, which meant that while resolved to, say, (an external IP), all the actual box was aware of was it’s internal IP, say The external was never directly configured as one of it’s network interfaces. This meant that requests like the above had to make a round trip all around the network and back again before they’d get processed. Not good.

Our solution was to setup an alias for the loopback interface so the external IP would behave exactly the same as when it was requested internally, and so never leave the box:

vi /etc/sysconfig/network-scripts/ifcfg-lo:1


“service network restart” or a quick reboot and job done!

This was on CentOS 6.5 btw, but I’m sure it’s pretty similar for Ubuntu or any other flavour of Linux.

Git version control and WordPress

I use Git for pretty much any decent sized coding project I do, and that includes WordPress sites. There are a number of different ways to set things up, but I thought I’d share mine as I think it’s the cleanest and nicest way to go about it. …although I would, wouldn’t I!

First thing: Don’t keep the core files under version control. WordPress has a great update system baked in so this is not necessary.

Second thing: Make sure you can bring anything you wrote yourself under version control. As well as the template, you may make custom site specific plugins, have special things going on in your .htaccess etc. etc.

So, make a new git repo, copy the core files into it, tell git to ignore them all with .gitignore and start to commit and push our own code.

Make yourself an ssh key pair:

[bash]ssh-keygen -t rsa[/bash]

Accept the defaults, get the new public key:

[bash]cat ~/.ssh/[/bash]

Copy that into Github or Beanstalk or wherever your repository is hosted.

Now lets put it up on a server. As Git doesn’t like cloning into non-empty directories, we need to download the wordpress core into a separate dir and merge it in using rsync (mv will not work here):

[bash]cd /var/www/your_site
git clone html
rsync -a wordpress/ html/
rm -rf wordpress[/bash]