Naguel

I'm Nahuel, and these are my work experiences, ideas and thoughts as a web developer working on the eCommerce industry.

Missing query string parameters when using Varnish on Magento

Missing query string parameters when using Varnish on Magento

I had this weird issue a time ago with a simple task that consisted on getting some query string parameters from the URL, from the PHP $_GET variable, to store them in Magento after the Customer places the Order.

What sounded like a very straightforward task got complicated because the $_GET variable was missing some of the those parameters I needed to save.

Debugging this issue made me realise that all the missing parameters where those starting with utm. I was literally going to this example URL...

http://example.com/test.php?utm_source=Source&utm_medium=Medium&utm_content=Content&utm_term=Term&siteId=42689&siteName=naguel.com

...to get the following incomplete output when printing the $_GET variable:

The cause of this issue was Varnish's recommended VCL configuration for Magento that includes the following inside the sub vcl_recv {}.

# Remove all marketing get parameters to minimize the cache objects
    if (req.url ~ "(\?|&)(gclid|cx|ie|cof|siteurl|zanpid|origin|fbclid|mc_[a-z]+|utm_[a-z]+|_bta_[a-z]+)=") {
        set req.url = regsuball(req.url, "(gclid|cx|ie|cof|siteurl|zanpid|origin|fbclid|mc_[a-z]+|utm_[a-z]+|_bta_[a-z]+)=[-_A-z0-9+()%.]+&?", "");
        set req.url = regsub(req.url, "[?|&]+$", "");
}

That was literally subtracting all marketing-related GET parameters from the URL, including those starting with utm_.

The solution is quite simple: remove the utm_[a-z]+ from the if conditional and restart Varnish to apply the changes.

UTM parameters?

UTM stands for "Urchin Tracking Module" (who cares, right?), which are basically marketing-related parameters to track marketing campaigns, and to know how people interact with the site.

In my case I was dealing with them because of a Rakuten integration with Magento.

More information on what they are and what we can do with them can be found on "The Ultimate Guide to Using UTM Parameters" post from Neil Patel's blog.

Unable to load dynamic library 'pgsql.so'

Unable to load dynamic library 'pgsql.so'

I had this weird issue that seems to be related to macOS Big Sur and MAMP, allegedly, either both combined or when upgrading any of those two (or both?).

I don't know exactly why this happened to me out of the sudden (I blame MAMP as it was the last thing that I updated) but I managed to fix it anyway.

PHP Warning:  PHP Startup: Unable to load dynamic library 'pgsql.so' (tried: /Applications/MAMP/bin/php/php7.3.21/lib/php/extensions/no-debug-non-zts-20180731/pgsql.so (dlopen(/Applications/MAMP/bin/php/php7.3.21/lib/php/extensions/no-debug-non-zts-20180731/pgsql.so, 9): Library not loaded: /Applications/MAMP/Library/pg/lib/libpq.5.dylib
  Referenced from: /Applications/MAMP/bin/php/php7.3.21/lib/php/extensions/no-debug-non-zts-20180731/pgsql.so
  Reason: image not found), /Applications/MAMP/bin/php/php7.3.21/lib/php/extensions/no-debug-non-zts-20180731/pgsql.so.so (dlopen(/Applications/MAMP/bin/php/php7.3.21/lib/php/extensions/no-debug-non-zts-20180731/pgsql.so.so, 9): image not found)) in Unknown on line 0

To get around this situation, many suggest to update Brew with brew update. That didn't work for me (and to be honest I can't see what's the relationship with Brew and MAMP) but you can give it a try anyway since it's easy to do.

What's interesting about the error above is that it mentions pgsql.so.so which is clearly wrong because of the double .so extension.

So how do I actually fix this issue?

Go to that extensions subfolder mentioned in the error (for example, mine is /Applications/MAMP/bin/php/php7.3.21/lib/php/extensions/no-debug-non-zts-20180731/) and create a symlink for pdo_pgsql.so called pdo_pgsql.so.so by doing:

ln -s pdo_pgsql.so pdo_pgsql.so.so

Now it doesn't matter what MAMP is looking for as it will find it either way.

That's not all. Go to /Applications/MAMP/Library/pg/lib and you'll notice something really weird which are broken paths for the symlinks libpq.5.dylib and libpq.dylib as seen below.

Again, how that happened is another mystery. But it doesn't matter, let's just fix those symlinks by deleting them and creating them again.

ln -s libpq.5.7.dylib libpq.5.dylib;
ln -s libpq.5.7.dylib libpq.dylib;

As you can see on the previous screenshot, the symlink libpq.5.dylib points to a broken path for libpq.5.7.dylib which is basically right there on the same folder. The same goes for libpq.dylib.

At the end everything should look like the following:

Configure the Terminal to use MAMP's PHP

Configure the Terminal to use MAMP's PHP

By default, after installation, MAMP will make its PHP binaries "available on the browser" while the Terminal will keep on using the system's PHP with its own configuration.

The idea behind changing the Command-line to start using the PHP coming with MAMP and its configuration is to be able to switch rapidly between PHP versions and to have the configuration for PHP in only one place.

Out there you can find enough guides that helps you archive this because, frankly, there are plenty of methods to get this done. This next one is how I personally do it because it's easy to implement and it also covers something most of other guides won't which is configure the Terminal to also use the same php.ini MAMP uses.

Configuring the Command-line to use MAMP's PHP

You need to edit your Terminal's Profile in order to add the following to the end:

#export PATH=/Applications/MAMP/bin/php/php7.1.33/bin:$PATH
#export PATH=/Applications/MAMP/bin/php/php7.2.33/bin:$PATH
export PATH=/Applications/MAMP/bin/php/php7.3.21/bin:$PATH
#export PATH=/Applications/MAMP/bin/php/php7.4.9/bin:$PATH

As you can see I'm adding a different line per PHP version I want to potentially have available on the Command-line (PHP 7.1.33, PHP 7.2.33, etcetera) but having them all but one (PHP 7.3.21) commented with the # at the beginning.

Every time you switch the PHP version in MAMP you should come back to the Profile and leave uncomment the same version so the Terminal and MAMP match.

Your Command-line's Profile file depends on your shell. If you are using the default Terminal coming with macOS chances are the Profile will either be ~/.bash_profile or ~/.bashrc. Mines it's ~/.zshrc because I use Oh My Zsh.

Remember that everytime you change your Profile you need to "reload" it by doing source ~/.bash_profile (or whatever file you are using).

You can check if everything was applied as expected by executing php --ini and seeing the paths are pointing to MAMP.

Configuring the Command-line to use MAMP's php.ini

Here's something interesting about MAMP Pro: it generates, each time it starts, the final php.ini file it will be using during the execution as its content depends on the settings configured on the software’s UI.

For example, if you enable/disable Xdebug on MAMP by ticking/unticking the checkbox on the app, MAMP will regenerate the php.ini file with your configuration (this is basically how MAMP applies any setting change that you perform from the UI).

The final generated php.ini file is located at /Library/Application Support/appsolute/MAMP PRO/conf/php.ini.

We already configured the Terminal to use MAMP's PHP binaries but we also need to configure it to use the generated php.ini by going to /Applications/MAMP/bin/php/php7.3.21/conf (where the not auto generate php.ini file is located) and delete it (after a back up).

Then we need to create a symlink called php.ini for /Library/Application Support/appsolute/MAMP PRO/conf/php.ini (which is the auto generated one by MAMP) by doing:

ln -sf /Library/Application\ Support/appsolute/MAMP\ PRO/conf/php.ini php.ini

The conf folder should ended up looking like this:

Of course the example is for PHP 7.3.21 but you will need to repeat this for the folder of each PHP version you will be using on the Command-line.

This only applies to MAMP Pro as the non-Pro version doesn't generates any php.ini and if you want to change something you need to edit the original file yourself.