Naguel

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

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:

Magento and a deadlock found when trying to get lock

Magento and a deadlock found when trying to get lock

"What now?" issues every now and then with Magento are the norm, and I got this one a few days ago:

SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction, query was: INSERT INTO `catalog_product_index_eav_temp` SELECT DISTINCT [...]

Apparently the server went down for a second, or MySQL went down... or something happened and a reindex process was interrupted (in my case the one for the "Product EAV" index), and there was no way to make it work again.

Even the usual bin/magento indexer:reset and then a manual reindex with bin/magento indexer:reindex didn't do the trick and the only difference was that instead of the previous error I was getting the classic one:

Product EAV index is locked by another reindex process. Skipping.

Lucky me, I find this tweet by @willemwigman on Twitter that basically indicates that, when you have no way to "unlock" an index and after you already tried the reset and manual reindex, spot the lock node within your app/etc/env.php file and change the prefix within the inner config node.

<?php
return [
    [...]
    'lock' => [
        'provider' => 'db',
        'config' => [
            'prefix' => 'new-prefix-here'
        ]
    ]
];

Reset the indexes and try to reindex again.

That alone should do the trick.

Add related posts to Ghost blog

Add related posts to Ghost blog

The related posts are quite easy to add to Ghost if you have some basic knowledge on how to edit your current theme (there's no option to turning this ON and OFF on the Admin, unfortunately, so you must do it on the theme itself).

If you open your theme's files you would see a post.hbs template which is the one for the articles (for "this page you are seeing right now", basically), and the block expression {{#post}}...{{/post}} would be the one containing everything related to the post itself.

Outside that expression, after it, we want to add the related posts taking advantage of the {{#get}} helper.

{{#get}} is a special block helper that makes a custom query to the Ghost API to fetch publicly available data.

get documentation for Functional Helpers by Ghost

Clearly, you can use this helper to get the related posts anywhere you want, like on the sidebar of the blog if yours have one, or in a page instead of a post (but I personally like them at the end of an article).

Let's say you would like to get a list of related posts based on the tags of the current one, which can be done by filtering the data on the filter attribute.

{{#get "posts" filter="tags:[{{post.tags}}]+id:-{{post.id}}" as |related|}}
	[...]
{{/get}}

In this case the filter attribute also contains id:-{{post.id}} to ignore, from the list of posts we are getting, the current article (we wouldn't want to suggest as related post the same post the user just read).

You can add as many filters as you want using the + sign as separator.

Inside this helper, the related "object" will be the one containing all the related post, so you just need to "loop it".

{{#get "posts" filter="tags:[{{post.tags}}]+id:-{{post.id}}" as |related|}}
    <div class="related-posts-wrapper">
        {{#foreach related}}
            <article class="{{post_class}}">
                <a href="{{url}}">{{title}}</a>
            </article>
        {{/foreach}}
    </div>
{{/get}}

Once inside the foreach you are in the context of the post, and then you can just get whatever you want from that post such as the {{url}}, {{title}, etcetera.

You can limit how many post to show by using the limit attribute on the {{#get}} helper (15 by default, which seems like too much)

{{#get "posts" limit="2" filter="tags:[{{post.tags}}]+id:-{{post.id}}" as |related|}}
    ...
{{/get}}

The related posts can be anything you like and you would like to consider as related posts, as you are not limited to that filter for the tags I used as an example.

I'm currently using tags:[{{post.primary_tag.slug}}] within the filters to only consider those posts that have the primary tag of the current post as a tag in any position, as I think those posts would be more relevant to the current one.

{{#get "posts" filter="tags:[{{post.primary_tag.slug}}]+id:-{{post.id}}" as |related|}}
    ...
{{/get}}

This is not the same as using primary_tag:{{post.primary_tag.slug}} which is another filter option, in this case to get only those posts that their primary tag is the same as the current post (there's a slightly difference).

Optionally, you can use the featured:true filter option to get those posts that are checked as featured within the Admin.

{{#get "posts" filter="tags:[{{post.tags}}]+featured:true+id:-{{post.id}}" as |related|}}
    ...
{{/get}}

If you have multiple writers in your blog and you want to show related posts where the current author also participates you can use the authors:{{post.primary_author.slug}} option within the filters.

{{#get "posts" filter="authors:{{post.primary_author.slug}}+id:-{{post.id}}" as |related|}}
    ...
{{/get}}

This is different than using primary_author:{{post.primary_author.slug}} where we are filtering by those posts where the primary author is the same.

Refer to the get documentation on Ghost for more ideas on how to filter.