I use MailPoet on my personal site to run my email lists and that means I sometimes have it active when I’m developing locally. When I have any site set up to develop locally I use the WP_ENVIRONMENT_TYPE constant to tell WordPress that I’m on a local site, but unfortunately MailPoet doesn’t respect this.

I found out that MailPoet is monitoring my emails (fine) and found that I had some URL’s that were unreachable at curtismchale.test because they’re on my local computer and can’t be reached by anyone but me. Thus my account was blocked from sending and marked as spam. I got a fairly pleasant but strongly worded email about sending spam and my account is now under review until I confirm that I’ve removed the curtismchale.test domain.

So instead of using built in features of WordPress to make my life easy MailPoet wants me to always make sure I disable the plugin locally so I don’t send emails. That sounds good, but I’ve found bugs in MailPoet during local development that I would not have found in a live environment. Bugs I was able to fix or work around because I was developing locally.

What MailPoet should do is what WooCommerce Subscriptions does, notice I’m on a local environment and then put up a nag about being disabled because I’m probably local and if I want it to process payments or emails anyway I have to click a button.

I never have to manually worry about WooCommerce Subscriptions trying to charge my users twice because they built a plugin that anticipates developer needs.

I’ll forget to turn MailPoet off some other time when I’m doing development and I’ll get another email about it. Maybe next time they’ll shut my account down…but that could be fixed if they added the local check.

Yes I did mention that to the support agent, but I likely won’t wait for them to add the feature. I’ll likely build a plugin that lets you choose plugins to turn off locally that will automatically turn them off if it detects WP_ENVIRONMENT_TYPE set to local.

His overall answer is no, WordPress is JavaScript focused. While I think there are a few interesting sessions that Reuben highlighted I feel disappointed to still see WP going down the React route as it is so slow.

As I wrote a few days ago, we should send HTML to users then use some JavaScript to make the interactions a bit nicer. Your whole site should work without JavaScript involved in any fashion.

All this JS crap continues to feel to me like we’re slowly heading back to the Flash days where you had to wait for loading screens.

Out of the box Varying Vagrant Vagrants lets you define a PHP version to use for each site you’re adding to the configuration file. What this doesn’t do is change the PHP version that WP CLI uses when you use vagrant ssh to log into the sites you’ve just created. Unless you take an extra step WP CLI will continue to use the default PHP version for VVV.

Installing Other PHP Versions

In your ~/vvv-local/config/config.php file you’ll see a section that looks like this.

# Extensions https://varyingvagrantvagrants.org/docs/en-US/utilities/
# are system level items that aren't websites, that install tools or packages
# the core extensions install tools such as phpmyadmin or new PHP versions
# these used to be called utilities but people kept requesting
# extensions not realising so it was renamed
  core: # The core VVV extensions
    - tls-ca # HTTPS SSL/TLS certificates
    - phpmyadmin # Web based database client
    #- memcached-admin # Object cache management
    #- opcache-status # opcache management
    #- webgrind # PHP Debugging
    #- mongodb # needed for Tideways/XHGui
    #- tideways # PHP profiling tool, also installs xhgui check https://varyingvagrantvagrants.org/docs/en-US/references/tideways-xhgui/
    #- nvm # Node Version Manager
    #- php56
    #- php70
    #- php71
    #- php72
    #- php73
    #- php74
    - php80
    - php81
    - php82

Note at the bottom of the section of code I’ve removed the comments on PHP 8.0, 8.1, and 8.2. By doing this I’ve asked VVV to install those versions of PHP when it provisions.

Setting PHP Version for WP CLI

Now we need to log into VVV with vagrant ssh. To see which versions of PHP you have available navigate to /usr/bin. Then I usually type php and hit the tab key twice to try and autocomplete the command. Since there are many things starting with php terminal shows me a bunch of options.

Now I need to set the version of PHP I want to use with sudo update-alternatives --set php /usr/bin/php8.0 if I want to use 8.0. This sets the default php call to the version of PHP you want to use for a site.

Now in the documentation for changing PHP versions in VVV there is a troubleshooting section at the bottom that talks about changing the value in vvv.nginx.conf file, but as with much documenation…it doesn’t tell you where that file is and I can’t find it. Ideally I’d change the default PHP version to 8.2 as it’s the most current version, but after looking through the docs a few times…there aren’t clear instructions on it.

If I do figure this out, I’ll update the documentation so that everyone can benefit from clear obvious documentation.

While doing a site inspection I noticed that we had over 20,000 spam subscribers on the site with addresses that lead to telegram. The WordPress admin is a terrible way to try and delete users when you have this many to do, so we turned to wp cli.

First I noted that the site couldn’t delete all the users at once because the command would time out so I used wp list user --role=subscriber --number=10 --field=ID to list 10 users and then increased the number of returned results till I was able to retrieve 5,000 users at once. Then it was a matter of combining this with wp delete user to delete the listed users. Then I ran the command a few times to clean up the site.

Our final command looked like this.

wp user delete $(wp user list --role=subscriber --field=ID --number=5000) --reassign=1

My current WordPress project has multiple custom plugins and themes with different repositories. Since I manage 80+ sites, I also end up working on bugs and features on a few different sites throughout the day which means I need to get any updates I’ve made to those custom plugins. Today I’ll show you the command I use to do that from the terminal.

find . -type d -depth 2 -exec git --git-dir={}/.git --work-tree=$PWD/{} pull origin master \;

Let’s walk through the command above so you can understand how to change it to suit your needs.

First find . searches through the current directory and we set a few options for it. -type d tells the find command to only search directories. -depth 2 tells the command to search 2 levels of directories down. I use 2 as the depth because I execute this command from the wp-content folder which lets me pull any changes to themes or plugins with a single command. -exec runs a custom command in each directory.

Next, we define the custom command to be run in each directory. git --git-dir={}/.git --work-tree=$PWD/{} pull origin master matches directories with the .git folder and then runs pull origin master on those directories.

A number of our directories have been switched over to the new default main branch as well so I run the same command a second time replacing master with main to make sure I get those repositories.

I still make sure that I have manually run git pull when I start working on a custom plugin or theme, but this command helps make sure that if I forget I’m not stuck in merge conflict hell.

For a long time, I manually changed the $version parameter when I was using wp_enqueue_script or wp_enqueue_style. At some point, I’d forget to make the change though and then some caching plugin would have issues because it wouldn’t realize that the script/style had been updated and I’d waste time wondering why I was seeing a cached version of scripts.

To combat this I started adding the version number of the plugin or theme as the $version argument in wp_enqueue_script so let’s look at how I do that.


My first stab at solving this problem was while writing a plugin and dealing with admin scripts and styles only. If this is your sole use case then get_plugin_data( __FILE__ ) will get you the information you need.

add_action( 'admin_enqueue_scripts', 'admin_enqueue' );

function admin_enqueue(){

	$plugin_data = get_plugin_data( __FILE__ );
	$version = $plugin_data['Version'];

	wp_enqueue_script( 'my_script_name', plugins_url( '/plugin-folder/path-to/script.js' ), array( 'jquery'), esc_attr( $version ), true );


Unfortunately, if you want a method that works when you’re adding scripts to the frontend and to the admin area of WordPress you’re going to be let down by get_plugin_data as this function is only defined in the WordPress admin area.

To get reliable access to this data anytime you want to add $version to your enqueued scripts you need to use get_file_data . This is available on both the frontend and the admin area in WordPress.

add_action( 'wp_enqueue_scripts', 'frontend_enqueue' );

function frontend_enqueue(){

	$plugin_data = get_file_data( __FILE__, [
		'Version' => 'Version',
	], 'plugin' );
	$version = $plugin_data['Version'];

	wp_enqueue_script( 'my_script_name', plugins_url( '/plugin-folder/path-to/script.js' ), array( 'jquery'), esc_attr( $version ), true );


get_file_data reads the first 8kb of a file for metadata embedded in the file. Then you can define the metadata values you want to be passed through in an array. The final declaration of plugin above will translate into a filter that will be named extra_plugin_headers that you could modify if needed.


The biggest caveat to using get_file_contents is that you need to be doing your enqueue work in the main plugin file that has the standard WordPress plugin headers as that is what the plugin is reading.

That works for me, and using get_file_contents I can use a standard snippet to enqueue scripts and make sure I have the version number appended all the time.

After running sudo dnf update && sudo dnf upgrade today Chrome wasn’t working as expected. Icons weren’t showing on the default Chrome landing page and text wasn’t showing in Google Docs, among other issues with web content not being displayed.

One quick command clears some residual cache and gets it working again.

rm -rf ~/.config/google-chrome/Default/GPUCache/

Thanks reddit.

One of the biggest tips I’d give to any new programmers is that your code should gracefully degrade. Let’s look at a simplified example in a recent WordPress project I was working on.

In a plugin there was a line similar to what you’d see below that includes a file from a theme.

require_once plugin_dir_path(__FILE__) . '../../themes/<theme-name>/lib/assets.php';

In our default install this isn’t a problem because the theme exists and assets.php also exists. So the file is included and we have no issues.

But this week I’ve been building a system to check which theme is active and force activate a specific theme for a site if it’s not active. It also lets us know if the theme isn’t present so it can’t be activated. While testing this I renamed the theme folder to have it deactivate itself and then the line above breaks.

This is where we should fail gracefully and check if we have the file in the expected location before we try and include it. Further, outside of standard PHP notices, there is no reporting at any level about the issue.

I’ve added a task to fix this, but this is what the fix would look like in pseudo-code if you’re curious.

  • Check if the theme exists with wp_get_themes()[^1]
  • If theme exists, check if the file in question exists
  • If either of the above fail, let someone know about it in your reporting system so that the issue can be resolved.

In the case above, I’d send a message to the our dev slack channel along with some information about what the fix should be and if a developer should be involved. We have a number of errors that can be handled by support staff without involving a developer because of the tooling we’ve already built.

In general, before you try to use some custom functionality, make sure it exists and then deal with the case if it doesn’t exist so your whole site doesn’t die.

Yes we should not even have a plugin/theme dependency like this. That is a different topic to address and one of the many items of technical debt we need to dig out of.

[^1]: This can be an expensive function so be clear about it’s cost and that the cost of the function increases as you add more themes.

Right now I’m working on a Google Analytics 4 integration that needs some data and views. To get the clicks/views I’m using the Selenium IDE Firefox Extension which records my clicks and the replays them. But to even have content for those clicks, I need to generate a bunch of it.

Enter WP CLI Random Content by Bryan Richards.

I’ve used two commands so far. wp random generate --count=50 to generate 50 posts. Then wp random generate --count=50 --post_type=question to generate 50 questions for the WP FAQ Manager plugin.

WP CLI Random Content has far more options than I’ve described above. You can have it add taxonomies to your generated content, use --with-terms=true to have it generate terms first then generate content and attach it to those terms.

Overall, it’s a one stop shop for generating basic content for testing your WordPress sites.

Google Analytics 4 API requires the bcmath PHP extension to be installed but not every server will have it. To find out if you do type the following line in terminal.

php -r "print_r(get_loaded_extensions());"

The output will be something like you see below. On this instance you can see that I have bcmath installed already.

If you don’t have bcmath installed already then you’ll need to run the following command, assuming you have PHP 8.0 installed and that your server is uses apt to install its packages.

apt-get install php8.0@bcmath

Once that’s installed you’re ready to use Google Analytics 4 API to build your own analytics dashboard.