When Forge provisions a site, it uses a shallow clone of a single branch, which prevents switching to other branches later. This is helpful for performance but can be limiting when you need to test or deploy from a different branch on a staging or test server.

Here’s how Forge typically clones a repo

git clone --depth=50 --single-branch -b staging git@github.com:adampatterson/repo repo

If you check the remote branches:

git branch -r
# origin/staging

This setup locks the repository to the staging branch, as seen in the .git/config:

[remote "origin"]
    url = git@github.com:adampatterson/repo
    fetch = +refs/heads/staging:refs/remotes/origin/staging

Switching to Another Branch

To allow access to all branches, update the fetch configuration:

git config remote.origin.fetch "refs/heads/*:refs/remotes/origin/*"
git fetch

Your .git/config should now look like:

[remote "origin"]
    url = git@github.com:adampatterson/repo
    fetch = refs/heads/*:refs/remotes/origin/

Now you can view all remote branches:

git branch -r
# origin/dev
# origin/main
# origin/staging

To switch to a different branch:

git fetch origin
git switch main

If you want to lock the repository to a new default branch (e.g., main), reset the fetch:

git config remote.origin.fetch "refs/heads/main:refs/remotes/origin/main"

Step 1: Create a Cloudflare Account

If you don’t already have a Cloudflare account, you’ll need to create one and add your domain. Point your domain’s DNS settings to Cloudflare by changing your nameservers at your domain registrar.

Step 2: Install Cloudflared

Cloudflared is the daemon used to create a Cloudflare Tunnel. You’ll need to install it on your local machine or the server where your sites are hosted.

• For macOS: Use Homebrew:

brew install cloudflared

Step 3: Authenticate Cloudflared

Run the following command to authenticate cloudflared with your Cloudflare account:

cloudflared tunnel login

This command opens a browser window where you can log in to your Cloudflare account and authorize the connection.

Choose the domain that you’d like to use with your tunnel.

Step 4: Create a Tunnel

Create a new tunnel and give it a name:

cloudflared tunnel create tunnel-name

Confirm that the tunnel has been successfully created by running:

cloudflared tunnel list

Your tunnel configuration is complete! If you want to get information on the tunnel you just created, you can run:

cloudflared tunnel info tunnel

Step 5: Configure the Tunnel

Create a config.yml file inside .cloudflared to define how traffic is routed:

tunnel: <Tunnel-UUID>
credentials-file: /path/to/.cloudflared/Tunnel-UUID.json

ingress:
  - hostname: "*.domain.com"
    service: http://127.0.0.1:80
  - hostname: "*.example.com"
    service: http://127.0.0.1:80
  - service: http_status:404

In this example, *.example.com will route all requests to your local web server running on port 80. Make sure to replace example.com with your actual domain.

Validate your configuration:

cloudflared tunnel ingress validate

Validating rules from ~/.cloudflared/config.yml
OK

Test a specific domain:

cloudflared tunnel ingress rule https://foo.domain.com

Using rules from ~/.cloudflared/config.yml
Matched rule #0
    hostname: *.domain.com
    service: http://127.0.0.1:80

Tail the connection logs:

cloudflared tail <Tunnel-UUID>

Step 6: Start the Tunnel

Run the tunnel:

cloudflared tunnel run TUNNEL_NAME

To run it at login:

sudo cloudflared service install
sudo cloudflared service uninstall

Cloudflare Tunnel will be installed as a launch agent and start whenever you log in, using your local user configuration found in ~/.cloudflared/.

Except there’s an issue with the plist file that’s created.

To resolve this, we’re going to update the file by editing /Library/LaunchDaemons/com.cloudflare.cloudflared.plist

Original:

<array>
    <string>/usr/local/bin/cloudflared</string>
</array>

Updated:

<array>
    <string>/usr/local/bin/cloudflared</string>
    <string>tunnel</string>
    <string>run</string>
</array>

Start and stop the daemon:

sudo launchctl start com.cloudflare.cloudflared
sudo launchctl stop com.cloudflare.cloudflared

Manage the service:

sudo launchctl bootout system /Library/LaunchDaemons/com.cloudflare.cloudflared.plist
sudo launchctl bootstrap system /Library/LaunchDaemons/com.cloudflare.cloudflared.plist

Step 7: Update DNS

Finally, you need to add DNS records in your Cloudflare dashboard to point your desired subdomains (or wildcard
subdomains) to the tunnel. For wildcard subdomains, create a CNAME record like this:

• Type: CNAME
• Name: *
• Target: <TUNNEL_ID>.cfargotunnel.com

Resulting in client.domain.dev

If Cloudflare has an Edge Certificate you can also setup wild card subdomains.

• Type: CNAME
• Name: *.name.
• Target: <TUNNEL_ID>.cfargotunnel.com

Resulting in client.your-name.domain.dev

Required Local Changes

server {
    listen 80;
    server_name project.test project.example.com;
}

There’s no need to update your hosts file or Gasmask settings.

Additional Configurations for WordPress and Laravel

Your local sites will now have full SSL, can be accessed by your mobile devices, and if required shared with team mates.

WordPress
Update wp-config.php:

define('WP_HOME', 'https://project.example.com');
define('WP_SITEURL', 'https://project.example.com');

Laravel
Update your .env:

APP_URL=https://project.domain.com
HORIZON_DOMAIN=https://project.domain.com

Next, you may need to force HTTPS by editing your AppServiceProvider boot method.

use Illuminate\Support\Facades\URL;

class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        if (config('app.env') === 'local') {
            URL::forceScheme('https');
        }
    }
}

Additional Tips

• Consider adding basic authentication in Nginx to prevent unauthorized access.
• If you’re using Vite or hot module reloading, further adjustments are needed.

Setting Up Cloudflare Tunnel via Web Interface

Cloudflare allows you to configure your tunnel through its web interface:

1. Go to Zero Trust > Networks > Tunnels in your Cloudflare dashboard.
2. Click Create Tunnel, select Cloudflared, and name your tunnel.
3. Choose an installation method:
   • If Cloudflared is not installed, follow the installation steps.
   • If Cloudflared is already installed, proceed with configuration.
4. Add a public hostname:
   • Subdomain: *
   • Domain: Select your domain
   • Set the service type to HTTP and the URL to http://127.0.0.1:80

This setup provides full SSL support, allows access from mobile devices, and enables easy sharing with teammates.

By following these steps, you can securely expose multiple local sites using a single Cloudflare Tunnel with wildcard support—perfect for development, testing, and internal applications without exposing them directly to the intern

Normally I’d just drag a folder into the app icon in the dock, and I guess that’s fine.

But it’s also sometimes awkward on a dual monitor setup or when you’re using the trackpad.

To get started, open Automator.app and choose “New Document“.

Then choose Quick action, now search for for and add the  Run Shell Script action by double clicking or dragging it.

In the Run Shell Script action Set Pass input to as arguments.

Now we can add the following for PhpStorm

for f in "$@"; do
  open -a 'PhpStorm' "$@"
done

And this one’s for you if you’re a Visual Studio Code user.

for f in "$@"; do
  open -a 'Visual Studio Code' "$@"
done

Save as the automation accordingly “Open in PhpStorm“.

Now, if you right click on any files or folders, you should see the Quick Action Open in PhpStorm.

Previously, I often used symlinks for local development, and I still occasionally do.

However, I’ve found an easier method for my core projects: using the Wikimedia Composer Merge Plugin. This approach simplifies working on projects without making significant changes to composer.json in situations where you don’t want to modify the file publicly.

The Wikimedia Composer Merge Plugin allows us to merge multiple composer.json files at runtime, offering flexibility for managing dependencies in complex projects.

Getting Started

Let’s pretend we’re developing a WordPress site and using Composer to install and manage themes. Our project includes the Axe and Handle themes from GitHub, and we also need to make updates to these themes locally before publishing.

Here’s an example of our composer.json setup:

{
  "require": {
    "adampatterson/axe": "dev-main",
    "adampatterson/handle": "dev-main"
  },
  "repositories": [
    {
      "type": "vcs",
      "url": "git@github.com:adampatterson/Axe.git"
    },
    {
      "type": "vcs",
      "url": "git@github.com:adampatterson/Handle.git"
    }
  ]
}

Folder Structure

/sites/
    /wordpress.test/
        composer.json
        composer.local.json
    /axe/
        composer.json
    /handle/
        composer.json

Install the Merge Plugin

First, install the Wikimedia Composer Merge Plugin in your project:

composer require wikimedia/composer-merge-plugin

Next, configure the plugin in your composer.json file to include a local configuration:

{
  "require": {
    "wikimedia/composer-merge-plugin": "^2.1"
  },
  "extra": {
    "merge-plugin": {
      "include": [
        "composer.local.json"
      ],
      "replace": true
    }
  }
}

Define Local Packages

Create a composer.local.json file to define your local packages. This file should also be added to .gitignore to prevent it from being committed.

{
  "repositories": [
    {
      "type": "path",
      "url": "/Users/adam/Sites/wordpress/Axe"
    },
    {
      "type": "path",
      "url": "/Users/adam/Sites/wordpress/Handle"
    }
  ]
}

Now, when you run composer install or composer update, your themes will be symlinked automatically.

Working with Published Packages

If you want to install only the published packages, you can run:

composer install --no-plugins

However, keep in mind that WordPress themes and plugins managed with composer require composer/installers, which will be ignored when using --no-plugins. To work around this, temporarily rename your composer.local.json file before running the command.

Could you use this with Laravel?

Absolutely!

If you create a new Laravel project then yes, you can modify your composer.json file as mentioned above except that we’re going to need to include laravel/framework in composer.local.json.

{
    "require": {
        "laravel/framework": "*"
    },
    "repositories": [
        {
            "type": "path",
            "url": "/Users/adam/Sites/forks/framework"
        }
    ]
}

If you’re working on laravel/laravel then I’d say no, since we don’t want to add the Wikimedia Composer Merge Plugin to the public repo.

Using the Wikimedia Composer Merge Plugin streamlines local development and testing for Composer projects, especially when working with themes or plugins in WordPress. It’s a flexible, efficient solution that avoids cluttering your Git history with unnecessary commits.\

On an ARM macOS I ran tail -f /opt/homebrew/var/log/nginx/error.log and could see the following error.

2023/08/11 09:53:43 [crit] 29890#0: *9 open() "/opt/homebrew/var/run/nginx/client_body_temp/0000000002" failed (13: Permission denied), client: 127.0.0.1, server: local.test, request: "POST /livewire/upload-file?expires=1691769523&signature=61f7f20ef5a9047cec174fc9fa5dbb2b729b0f91394f75b23d41c0f358318463 HTTP/1.1", host: "local.test", referrer: "http://local.test/admin/inspections/5/submit"

🤨 WTF!

I resolved the issue by by running sudo chown -R $USER:_developer client_body_temp/

I am unclear why nobody was assigned to the folders, I also think that maybe my work laptop has the _developer group which I don’t think is standard.

You won’t need to restart Nginx but retry the file upload.

Hopefully you found this helpful!

To fix this error, you can try increasing the client_max_body_size setting in your Nginx configuration. Here’s how:

1) Open your Nginx configuration file. This is typically located at /etc/nginx/nginx.conf on a Linux server.

2) Find the http block in the configuration file and add the following line:

http {
    ...
    client_max_body_size [size];
}

Replace [size] with the maximum size of the request body you want to allow, in bytes. For example, to set the maximum size to 10 megabytes, you would use client_max_body_size 10m;.

3) Save the configuration file, test and restart Nginx using the following command:

sudo nginx -t
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful

sudo systemctl restart nginx

After increasing the client_max_body_size setting and restarting Nginx, you should be able to upload larger images to your WordPress website or blog without encountering the “server cannot process image” error.

However, if you are still experiencing this error after updating the client_max_body_size setting, there may be other factors at play. Here are a few additional things you can try:

• Update the upload_max_filesize setting in PHP. This setting specifies the maximum size of a file that can be uploaded to your server. If you are trying to upload an image that is larger than this size, you may receive the “server cannot process image” error. To fix this, you can increase the upload_max_filesize setting in your PHP configuration. This is typically located at /etc/php/php.ini or /etc/php/8.2/fpm/php.ini on a Linux server. Find the upload_max_filesize setting and increase it to a larger value, then save the file and restart your web server.
• Reduce the size of the image you’re trying to upload. The suggested maximum size for images in WordPress is 2560 pixels. If your image is larger than this, you’ll need to resize it before uploading. You can use a free image editing tool like GIMP or Adobe Photoshop to resize your image.
• Check your server’s resource usage. If the server is busy or has a high load, it may not have enough resources available to process your image. You can check your server’s resource usage by contacting your web host or using a tool like top. If the server’s resources are maxed out, you may need to upgrade to a more powerful hosting plan or consider moving to a different web host.

Combined with PHP having a quicker release cycle PHP 8, 8.1, and 8.2 are on their way.

I have to work with a couple of versions regularly in the CLI, and the best way I found to do this was to create an alias.

Let’s assume that you installed your versions of PHP using brew, or already know where your version of PHP is.

Add the following to your bash profile.

alias php7='/usr/local/opt/php@7.4/bin/php'
alias php8='/usr/local/opt/php@8.0/bin/php'

If you want you can install PHP 8.1 and 8.2 as well with brew install php@8.X and add another alias.

This will allow you to run php8 composer, you can do a quick test by creating an index.php file and adding phpinfo() to it.

php7 index.php | grep "PHP Version"
php8 index.php | grep "PHP Version"

If you have an M1 mac, your system paths will be different. You can replace:

/usr/local/opt/

with

/System/Volumes/Data/opt/homebrew/opt

If you were to run php -v and see v7.4 then you can now run php8 composer install in most cases, this has worked perfectly, but if you need something a bit more permanent it’s still best to change your system environment.

Alternatively, if you want to change your version of PHP in the command line more permanently you can add this function to your .bash_profile

function phpv() {
    brew unlink php
    brew link --overwrite --force "php@$1"
    php -v
}

And then run with phpv 8.2

I can’t take credit for the above shell script, but I also can’t find the original post that I discovered it on.

Previously I used OpenSSL locally on my Mac, and it was… OK, but it was sort of complicated and involved a lot of copy and paste.

To get started let’s start off by installing mkCert using HomeBrew. Create a new folder in your Sites directory called SSL, and navigate your way there in the terminal.

brew install mkcert
brew install nss # if you use Firefox

mkcert -install

mkcert site.local '*.site.local'

That was it! Your certificate is is ready to go, but now what?

Configure MAMP

Open /Applications/MAMP/conf/apache/httpd.conf and search for # Virtual hosts.

Add a line under httpd-vhosts.conf called httpd-secure-vhosts.conf.

Open /Applications/MAMP/conf/apache/httpd-secure-vhosts.conf and add the following, changing the names and paths to reflect your needs.

NameVirtualHost *:443

<VirtualHost *:443>
	ServerName site.local
    ServerAlias *.site.local
    ServerAlias dev.smi
    ServerAlias *.dev.smi

	DocumentRoot "/Users/{username}}/Sites/web_path/"

    <IfModule xsendfile_module>
        XSendFilePath "/Users/{username}}/Sites/web_path/"
    </IfModule>

    SSLEngine on

    SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

    ErrorLog "/Applications/MAMP/logs/apache_ssl_error.log"
    TransferLog "/Applications/MAMP/logs/apache_ssl_access.log"
    CustomLog "/Applications/MAMP/logs/apache_ssl_request.log" "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

    SSLCertificateFile "/Users/{username}}/Sites/ssl/site.local+1.pem"
    SSLCertificateKeyFile "/Users/{username}}/Sites/ssl/site.local+1-key.pem"

    SSLSessionTickets on

    <FilesMatch "\.(cgi|shtml|phtml|php)$">
        SSLOptions +StdEnvVars
    </FilesMatch>

    <Directory "/Applications/MAMP/Library/cgi-bin">
        SSLOptions +StdEnvVars
    </Directory>

    BrowserMatch ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

	<Directory "/Users/{username}}/Sites/web_path/">
		Options Includes FollowSymLinks ExecCGI
		AllowOverride All
		Order allow,deny
        Allow from all

	</Directory>

</VirtualHost>

Open /Applications/MAMP/conf/apache/httpd.conf again and look for Include /Applications/MAMP/conf/apache/extra/httpd-ssl.conf and uncomment that line.

I personally remove the VirtualHost from this file and leave it the httpd-secure-vhosts.conf file that we previously created.

By creating a wild card certificate you can simply add every new local site under that subdomain if you so choose.

In my free time I like to make stuff and post it on YouTube, and my “other” blog called Hey I’m A Maker. A lot of content creators will use affiliate links in order to make some extra income from their content. There are plenty of services out there to help you do this.

At the moment I have an Amazon Affiliate store that I tossed a few interesting items into. The issue is that I live in Canada and many of my viewers also live in Canada. The Amazon stores are not transferable between .com and .ca.

I began looking into ways of routing the link based on Geography. I discovered a few paid services for $10-20 a month which was far more than I wanted to spend.

After some exploring, I learned that Cloudflare is able to add Geolocation headers to their responses. If you are interested you can read more on how to set that up here.

Modify your WordPress theme

Once I had enabled the IP Geolocation feature I was able to see my region as CA using the following code as a test.

echo $_SERVER["HTTP_CF_IPCOUNTRY"];

The goal I want to achieve here is to modify a nav item based on our geographical location. In my case, Canadian visitors should see my Canadian affiliate store.

In the following code snippets, I will assume that your menu location is called primary and that the link you want to modify was added as a custom link.

To get this started I want to modify the WordPress menu items before the HTML has been created. To do this I will use the filter wp_nav_menu_objects.

Create a function called update_shop_link which will accept two parameters, $items and $args.

By now you should have something that looks like this located in your functions.php.

add_filter( 'wp_nav_menu_objects', 'update_shop_link', 10, 2 );
function update_shop_link( $items, $args ) {
    // Code here
}

Next up, we want to only modify a link that is in our primary menu and to make sure that HTTP_CF_IPCOUNTRY is set.

Once those are true we can set a variable $region, and then loop through the $items looking for a link that is of the type custom, and whose title is equal to Shop.

if ( $args->theme_location == 'primary' && array_key_exists( 'HTTP_CF_IPCOUNTRY', $_SERVER ) ) {
    $region = $_SERVER["HTTP_CF_IPCOUNTRY"];

    foreach ( $items as $key => $item ) {
        if ( $region === 'CA' && $item->type === 'custom' && $item->title === 'Shop' ) {
            // Code here
        }
    }
}

Now we have found out shop link you can modify the URL by overwriting it.

$item->url = 'https://www.amazon.ca/shop/adampatterson';

Wrapping it up

That’s all there is to it, now let’s roll it all together.

add_filter( 'wp_nav_menu_objects', 'update_shop_link', 10, 2 );
function update_shop_link( $items, $args ) {
	if ( $args->theme_location == 'primary' && array_key_exists( 'HTTP_CF_IPCOUNTRY', $_SERVER ) ) {
		$region = $_SERVER["HTTP_CF_IPCOUNTRY"];

		foreach ( $items as $key => $item ) {
			if ( $region === 'CA' && $item->type === 'custom' && $item->title === 'Shop' ) {
				$item->url = 'https://www.amazon.ca/shop/adampatterson';
			}
		}
	}

	return $items;
}

This method was specific to WordPress, but as long as you are using a server-side language you can intercept the region and do whatever you like.

You could even create a page like domain.com/shop that would automatically redirect to your Amazon store. If you really wanted that URL could redirect to a tiny URL that would allow you to collect some basic analytics.

If you enjoyed this then I would love it if you subscribed to my YouTube channel or had a look at my site Hey I’m A Maker.

add_image_size('square', 150, 150, true);

Now any time an new image is uploaded WordPress will generate a file something like image-150×150.jpg.

If you want to be able to insert these images in your posts then you will need to register the size with the Media moda.

add_filter('image_size_names_choose', 'add_image_sizes_editor');

function add_image_sizes_editor($sizes)
{
    return array_merge($sizes, [
        'square'   => __('Square', 'axe'),
    ]);
}

Now when you create a post and want to add an image your custom sizes will be available to you.