Don't we love having a good performance review, from our bosses to ourselves, every now and then? Of course we do! Is that moment were we get to be told how great of an employee we have been (finger cross that's the case) and to potentially get a salary raise (and I don't have to ask how much we love that).

Thing is that our performance review, appraisal, catch up, or whatever you would like to call, it is about having a conversation where you should also bring something to the table.

Why?

This is an opportunity to not only get feedback from your company, but also to help shape your role into it, to define a roadmap for your own career for the next cycle up to, let's say, your next performance review.

When you are not part of this conversation, when you are just a listener, you leave your future in the company up to whatever other decides for you. If you are "sort of lucky", the company you work for might already has defined a plan for you, and if you are "very lucky" you will like that plan. You would be betting, twice.

But, again, that's oddly the case when we don't have a say for our career.

How?

What I like to do for basically all meetings I have (and my performance review is no exception) is come prepare with notes and bullet points to discuss.

For this particular scenario I recommend doing a self-evaluation, ahead of the meeting, to know were we stand and were we would like to go from there.

Depending on our role in the company we can also cover where the company stands, where we would like it to go, and how we think we can get there.

Average is officially over, so don’t be that at work

There was a time when you would learn a skill and that would be enough to succeed, but nowadays what you learn has an expire date as much as the milk in your refrigerator.

NaguelNahuel Sanchez

I divide my self-evaluation, self-assessment, auto-evaluation, or, again, whatever you would like to call it, into different sections starting with "What I like to do and what I don't like to do".

This is a reflection time opportunity for me to know, up to this moment, after everything I went through from the last catch up, of all the things I've been doing so far what I actually like to do, and if I think I would like to continue doing them.

For example, let's say I've been doing a lot of documentation since the last time we had a catch up. Did I like that? Or was it more of an emergency role I had to take on that I would like to dodge from now on? Can I think of any available role I might like to fulfill with this skill that I think I'm good at and also like to perform?

The "what I don't like to do" part is to identify if the tasks I've been performing were those sort of a one-time-only tasks due to an emergency, or if they are in fact part of my job description.

If the stuff you don't like to do outnumber the things you do like, then you have a bigger problem here. But that's just another good idea for doing a self-evaluation: you can get yourself aware of how happy (or not) you are at your job.

The second section is called "Things I should put more attention at", which basically means "what I've been doing wrong" (but let's keep a positive tone here and not sound that radical). Now is when I need to be truly honest with myself in order to be able to identify where I have room to improve at work.

It's not only about telling where I could be better, but also to discover why I wasn't doing my best so far, and what I think could increase my performance on these areas.

I consider important to demonstrate that I'm able to tell when I'm not at my best before somebody points that out to me, and that I'm also capable of being part of "fixing" this situation with ideas and suggestions of my own.

Third section is about "Things we should keep an eye on", which involves the company itself and it's my chance to talk about how I see the place I work in.

You are, supposedly, at a different position than your superiors, therefore you might be able to provide another vision at how things are: what do you think the company is doing well, what things would be good to avoid losing, and what things do you think the company should put more effort in.

Clearly, this would be attached to your bosses' willingness to get some feedback on a meeting designed mainly to provide it to you. But, if you have the chance to give it a shot, just go for it.

Since my role is more technical I do have a fourth-ish section which is more like a twist for the last one, and I call it "Things we should keep an eye on... from a technical point of view" (the title speaks for itself).

This is my opportunity to say where I would like things to go, for the company, on the technical side, which is allegedly my area of expertise.

Following on the example of me doing a lot of documentation, I can bring ideas on how we can make this behaviour part of the company's culture.

Up there you can see a real self-evaluation I did on March 2019 before a performance review I had, and two more on the sidebar.

Keeping them works as a log to retrace my steps when I feel overwhelmed to assess if I'm on track regarding my latest self-evaluation of my performance or if I need to adjust something.

Basically, my idea is to avoid working blindly from one catch up to the other.

I'm going to be honest with you: I have no idea why this can happen.

This is one of those errors that makes you say "this started to happen out of the sudden and I'm 100% sure I touched nothing". But it's there, and I have a potential solution, hoping you are in a hurry to get it fixed without asking too much questions.

[Composer\Downloader\TransportException]
The "https://example:example@repo.example.com/packages.json" file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Failed to enable crypto
failed to open stream: operation failed

The full error is up there and it appears when you use Composer such as when running composer install, and it seems to be that your computer is using a wrong (or not up to date?) CA certificate when trying to communicate with a Composer repository.

cacert.pem is a bundle of CA certificates that you use to verify that the server is really the correct site you're talking to (when it presents its certificate in the SSL handshake).

Comment by Daniel Stenberg on Stack Overflow

So, fixing this is quite simple as it only involves replacing the cacert.pem file with the one you can download here: CA certificates extracted from Mozilla.

If you are using MAMP, chance are that the file you need to replace, locally, is on /Applications/MAMP/Library/OpenSSL/certs/, but if you are unsure you can open a Terminal and run locate cacert.pem to get a list of all the places where you can find the Certificate Authority file.

If still unsure about the location of the cacert.pem you need to replace, check your php.ini and look for the openssl.cafile= line.

[openssl]
; The location of a Certificate Authority (CA) file on the local filesystem
; to use when verifying the identity of SSL/TLS peers. Most users should
; not specify a value for this directive as PHP will attempt to use the
; OS-managed cert stores in its absence. If specified, this value may still
; be overridden on a per-stream basis via the "cafile" SSL stream context
; option.
openssl.cafile=path/to/cacert.pem

Finally, remember to restart Apache before trying again.

While the title up there make this post looks like a promoted and/or paid one, that's not the case (I wish), and instead this is an honest appreciation of Cloudways and how it has made my life easy while dealing with servers, specially considering that I don't think myself as an advanced devOps.

Recently at the company I work for we had the task to move an existing Magento project, already in production and publicly accessible, from a server outside Cloudways to a server managed by Cloudways.

What's next is going to be long, and everything described could take around 3 days (one day for the server creation, another day for testing the new instance, and a third day for the actual site moving), depending on your skills.

So let's get to it.

Preparation

Make sure to tick a few boxes before moving forward by checking if you have the following:

• Credentials to access the original server over SSH and SFTP, with enough permissions to manipulate files within the web root folder (usually public_html or www), use scp, tar, and cat for server configuration files such as the one for Nginx and Varnish.
• Server permissions to use mysqldump to create a database backup, or a way to get your hands on a database backup of the project living on the original server.
• Access or a point of contact for managing DNS changes for the project’s domain.
• Access to the payment gateway accounts and/or credentials needed to configure the payment methods.

Finally, make sure to identify which third-party services currently connect directly to the server over SFTP or similar, because those will need to be reconfigured to point to the new IP and/or to be given new SFTP credentials.

Create the server in Cloudways

Decide on the server size and create it on Cloudways, making sure to factor in how much space you will need for the database, files, and "maneuver" as you will be moving zipped files from the original server to unzip them later.

Cloudways offers Magento-ready instances for specific versions. If the project you are moving uses a Magento version already listed in Cloudways you can select this version from the dropdown that appears when creating the server, otherwise make sure to select “PHP - Custom App” instead.

This is important because, for example, if you are moving a Magento 2.2 version to Cloudways you can not select “Magento - Version 2.4.1 (with Elasticsearch)” from the dropdown as this instance will come with Elasticsearch 7 out of the box and you won’t be able to downgrade it to Elasticsearch 6 (which is the required version for Magento 2.2 using ElasticSuite).

If you need to go down the route of selecting “PHP - Custom App”, then you must contact Cloudways Support for them to "flag" this instance as Magento internally, after creating it.

This is because Cloudways offers specific configurations and performance-oriented settings for each type of instance, like an internal logic in place to load the specific Varnish settings a Magento project would require.

Whatever the Application type you choose, you still need to contact Cloudways Support to ask them to:

• Downgrade Composer from version 2 to 1 by running composer self-update --1 (you can't do it because you don't have enough server permissions to do so).
• Install a few Elasticseach plugins by running bin/elasticsearch-plugin install analysis-phonetic; bin/elasticsearch-plugin install analysis-icu; bin/elasticsearch-plugin install analysis-smartcn; on the /usr/share/elasticsearch folder (another thing you won't be able to do due to permissions).

You still need to configure a few bits here and there using the Cloudways Dashboard to make sure you match your project needs, including but not limited to the following items:

• PHP version, execution limit, memory limit, error reporting, and timezone.
• MySQL version and timezone.
• Nginx WAF module to be Cloudflare, Sucuri or disabled.
• Elasticsearch version, if needed.
• Redis, if needed.
• Varnish, if needed.

I can't tell what you need to put in those fields as that depends on the project.

Configure the Application

Inside the "Domain Management" section, make sure to configure the project's domain and all the additional necessary domains (like the ones used for different stores if your Magento project is configured to use multiple websites and stores).

Your "SSL Certificate" configuration will depend on what your project needs.

Since you are moving from one server to other, chances are you already have a SSL certificate that you can use, otherwise the Let's Encrypt option is quite good.

If you are using a firewall such as Cloudflare or Sucuri, the certificate might be "living there" already so there's nothing you need to configure here.

Do not add any cron in the "Cron Job Management" section for now.

We'll come back to the "Application Management" configuration later at the end.

Stop crons on the original server

By editing the crontab with crontab -e on the original server, or by contacting the original server hosting provider, disable all the crons by adding # at the beginning of each line.

This needs to happen before you move any file from the original server to Cloudways, and before the database backup creation.

Technically speaking, you want to avoid Magento to keep on writing any file in, for example, the var folder within the Magento root folder, related to Orders processing or Catalog management (like stock updates), and you want Magento to stop altering tables related also to those entities, which are the usual stuff affected by crons (among many other things).

If, for example, there are pending Order and/or Catalog tasks, they will be taking place in Cloudways after we finish the migration and we enable back the crons on the new server.

Move the files

Make sure to move the pub/media folder from within the Magento root folder, and any other custom folder and file that doesn't live in the repository.

Usually, there are some custom folders and files inside the pub and var folders that are not created automatically.

If you happen to be using Capistrano on the original server you would have a shared folder in the web root. In that case, just move that folder from the original server to Cloudways.

The way I do it is by creating a .tar.gz file with everything in it, but any cache folder...

[user_original]:~$ tar cvzfh shared.tar.gz shared/ --exclude='pub/media/catalog/product/cache';

...and then I transfer it from the original server to Cloudways using scp...

[user_original]:~$ scp shared.tar.gz user_cloudways@18.133.133.133:/mnt/data/home/master/applications/example/public_html

Make sure to push this file into the public_html folder in the Cloudways server, so you just need to unzip it there with tar -xvf shared.tar.gz; and then delete it.

Something I would like to do, just in case, after this big move, is to fix any potential permissions issue with the files and folders I just unzipped, by reseting those permissions using the Cloudways Dashboard.

Enable Maintenance Mode

Put the site living on the original server into Maintenance Mode by running bin/magento maintenance:enable before proceeding.

For what it's worth, the downtime starts now.

Move the database

Using mysqldump create a database backup on the original server.

[user_original]:~$ mysqldump -uroot -p database_name > database_export.sql;

For security reasons, make sure this happens on a folder not accessible over the browser, like on the private_html folder or anywhere outside the web root.

Once done, push this .sql file to the Cloudways server using scp again.

[user_original]:~$ scp database_export.sql user_cloudways@18.133.133.133:/mnt/data/home/master/applications/example/private_html

For the same security reasons, make sure to push this file to the private_html folder in the Cloudways server.

Once the transfer is completed, and before anything else, you need to remove the DEFINER from the .sql backup to avoid any "Access denied; you need (at least one of) the SUPER privilege(s) for this operation" issue while trying to import it.

Basically, run the following command on the private_html folder in Cloudways (or anywhere you pushed the .sql file before).

[user_cloudways]:~$ sed 's/\sDEFINER=`[^`]*`@`[^`]*`//g' -i database_export.sql;

Now the backup is ready to be imported into the actual database in the new server.

For this to happen you need to contact Cloudways Support with the request.

After the import, make sure to delete the .sql file.

Configure Magento

By accessing directly to the recently imported database in Cloudways, and not through the Magento Admin Panel, make sure to have the correct details for Varnish and Elasticsearch, keeping in mind that Cloudways uses port 8081 for Varnish, and 127.0.0.1:9200 for Elasticsearch.

Make sure there's no reference in the core_config_data table to the IP for the old server that you might need to change for the IP of the new one.

Go back to the files, and edit the app/etc/env.php file you transferred from the original server to fix the credentials for connecting to the new database living in Cloudways now.

In that same file, correct the details for Redis (if used) keeping in mind that Cloudways uses 127.0.0.1 and 6379 for the host and port, respectively.

Once done, clear cache and reindex to make sure everything is working.

Configure the Application again

Go back to the "Application Management" in the Cloudways Dashboard and configure, in the new server, all the crons you commented out on the original server, making sure to use the right paths for the new server.

Inside the "Application Settings", configure the "WEBROOT" to point to the pub folder from within the Magento root folder.

Point the domain to the new server

First thing first, make sure Magento is still on Maintenance Mode on the new server, and whitelist your IP to be able to access the site (using the bin/magento maintenance:allow-ips command).

Now change the DNS settings to point the project's domain to the new server.

The whole idea is to open the site only for you in order to test it before allowing real customers. So, while the DNS change propagates, some customers will hit the site on the old server (that will show the maintenance page forever and ever), and others will hit the site on the new Cloudways server (that it will also show the maintenance page while you test it).

Now is when you test the site and make sure everything is okay.

Disable Maintenance Mode

Once you are done with the testing open the site, now in Cloudways, to the public, by disabling the Maintenance Mode (with the bin/magento maintenance:disable command).

The downtime ends now.

If you are unlucky enough to be reading this article it means that you are seeing that error when trying to reindex Magento.

ElasticSuite Category Indexing index process unknown error:
{"error":{"root_cause":[{"type":"cluster_block_exception","reason":"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"}],"type":"cluster_block_exception","reason":"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"},"status":403}
ElasticSuite Thesaurus Indexing index process unknown error:
{"error":{"root_cause":[{"type":"cluster_block_exception","reason":"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"}],"type":"cluster_block_exception","reason":"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"},"status":403}

This happens because you are probably running out of disk space and Elasticsearch turns itself into read only mode because, well, there's no more space to do stuff.

In order to get out of this situation, you need to first disable that Elasticsearch feature of switching to read only mode (otherwise it will happen again) by running the following...

curl -XPUT -H "Content-Type: application/json" http://localhost:9200/_cluster/settings -d '{"persistent":{"cluster.routing.allocation.disk.threshold_enabled":false}}'

...and then get Elasticsearch out of the read only mode with the next command:

curl -XPUT -H "Content-Type: application/json" http://localhost:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'

Besides this, you'll need to do some disk clean up to recover some space.

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.

For job interviews to fill a technical role it's obvious that the questions needs to be, well, technicals, with focus on the hard skills questions aiming to know the candidate's knowledge in a specific framework, code language, software, etcetera.

But the attitude is very very very... very much... important. I said it before:

Everybody has access to the same documentation, to the same in-house training programs, to the same software, to everybody's code, to basically the same people to ask questions and to learn from... and what's set the difference between someone progressing in his or her line of work and someone stuck is the personality each developer has.

Soft skills related questions allow you to get to know the human you are interviewing, having in mind that you'll share with that person more than some lines of code if you ended up offering the job.

It also humanise the interview. If you pay attention people are usually tense answering the technical questions but when you throw in a soft skills one candidates relax and enjoy the conversation created around that question.

Developer’s work success being too much about personality rather than hard skills

Maybe what’s set the difference between someone progressing in his or her line of work and someone stuck is the personality each developer has.

NaguelNahuel Sanchez

At my current job we have a few very good soft skills questions I would like to share now in case you find them useful (our interviews are for web developers so the questions, while soft skills related questions, orbit around that role).

What do you think makes a good developer?

I personally expect whatever answer that's not about code, software, or any other hard skill stuff.

People usually talks about the ability of being flexible, passionate about it, the importance on working as part of a team, etcetera. Still some candidates mention hard skill stuff not covered before in the interview such as testing, and that's fine.

What do you think makes a good manager?

I like this one because it's a chance for the candidate to talk about others, and it's expected that they think of their current boss (obviously).

The answer will give you an idea of how the candidate works on a team structure where somebody is on a position above them. And at the same time it will hint you if the candidate will do well with the current managers at your company.

I like the answers about leadership and motivation.

What do you think you would add to the team if you were to get the job?

This is the polite version of "Why do you want this job besides money?".

I like this one because it forces the candidate to summarise what's their contribution to the team. And it's important to emphasise the team in the question, like you are not just adding something to the company but adding something to a team made of real humans.

What would you expect from the team if you were to get the job?

In opposition to the previous one, this is the time for the candidate to tell us how they see themselves after any period of time as part of a new team.

Again, we are asking about the team, not the company, so we try to keep it human while guiding the candidate into giving us something not technical.

If you were to organise a work social night out, what would you plan?

This always takes the candidates by surprise. They are thinking about PHP, VueJS, code reviews, pull requests and out the sudden they need to think about beers (because beers is the right answer to a social night out plan).

What do you like to do when you aren't coding?

There's no better question than this one to force the candidate to stop talking about hard skills and say something about their personal life (as much as they want, don't force people into talking about their personal life on a job interview).

It is also fun to learn about others people hobbies.

There are two ways to configure how Magento send order related emails (order confirmation, invoice, shipment and credit memo emails):

• Either immediately when an action is performed (for example, right after you place an order).
• Or cron-based (asynchronous).

Magento itself recommends to configure this to be asynchronous for performance reasons, so the email dispatch process doesn't block nor delay what the customer is doing (for example, less time consumption when the customer is placing an order), or to avoid long cron runs (or total crons block) when an ERP is updating orders status in bulk.

Enabling the “Asynchronous email notifications” setting moves processes that handle checkout and order processing email notifications to the background.

Configuration best practices by Magento

For my personal experience, it is also recommended to configure emails sending to be asynchronous to avoid having unsent emails.

When this is configured as immediately (not async), if an email fails to be dispatched because of any reason (like a server timeout) then Magento won’t try to send that email again in the future and the customer won’t be ever notified of his/her action.

Basically, there are a lot of good reasons to have this to be async.

Before setting this up

If you are going live for the first time on a new site there's not much to worry about, but if you are changing this setting from not-async to cron-based on an already live site then there's something to consider first.

The way this works when it's configured to be async is that Magento will rely on a cron to pick up from the database (from those tables related to Orders, Invoices, Shipments and Credit Memos) all those entities where the email was not dispatched, and it will send it.

Problem is that Magento doesn't care much about the date of those entities.

For example, if there’s an Order from 2019 whose order confirmation email was not sent because of any reason (for example, because there was a PHP error that stopped the execution), the cron will now pick this Order up and Magento will send the email related to that order.

To avoid this behaviour we should mark all pending emails from Orders, Invoices, Shipments, and Credit Memos as if they doesn't need to be dispatched, which can be done by executing the following SQL statements before enabling the asynchronous sending.

UPDATE sales_order SET send_email = 0;
UPDATE sales_invoice SET send_email = 0;
UPDATE sales_shipment SET send_email = 0;
UPDATE sales_creditmemo	 SET send_email = 0;

What we are doing here is ignoring the sending of emails for old Orders (and Invoices, Shipments and Credit Memos) so when we change this to be async the cron will only cares for future stuff.

Changing the configuration

Enable the “Asynchronous sending” option under “Stores → Settings → All Stores → Sales → Sales Email → General Settings”.

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:

"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.

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.

I changed a configuration on a client's site that triggered thousands of emails to different customers, which forced our client's Customer Service team to handle the same number of customer calls in a single day that they would usually receive over a normal week. They even had to write an apology email for all affected users, assuring them there was no data breach on the site.

It was a long day.

Admit it

Shit happens, and people make mistakes. I did on that occasion, and I will again in the future, or somebody else will, but at least I'll be happy if we, as a team, don't make the exact same mess I did again.

The first thing to do when you screw up is to admit it: tell somebody that you screwed up and explain exactly how.

If there's a big problem, and you alone caused it, chances are people will be chasing ghosts to fix something they won't fully understand if you don't come forward and tell them exactly what happened.

You are the only one that knows, basically (until everybody finds out).

The goal is to shift everybody's mindset from panicking about a mystery error to focusing on putting out the fire and doing some damage control. Back to my example: everybody was wondering how the emails went out, but when I told them it was me who had changed a setting, everybody moved towards finding a solution (emails were still going out at that point).

Trying to cover up something is really a stupid idea because, again, shit happens and it shouldn't be the end of the world. In any case, people will find out rather sooner than later.

Say sorry as you should be

Being on the defense on this type of situations is pretty common, but you shouldn't be. You made a mistake, you admitted it, now apologise without making excuses or blaming something (or somebody) else.

As individuals and as a team we should learn some stuff starting with the fact that human error is an actual thing. Saying sorry is as important as learning to accept someone's apology.

Keep in mind that if you didn't screw up this time, you could be the one causing the mess next time, so don't believe you're so perfect. At the same time, if you were the cause of all the problems today, take a breath, somebody else will take that leading role next time.

Not the same mistake twice

When the adrenaline is over and the problem is solved do everything within your reach to avoid the same mess to repeat itself.

Let's try to have new problems, not always the same ones (it's boring otherwise).

While all human errors can't be eliminated (unless there's no human in the equation) we can always reduce the chances for them to happen by identifying what mechanism we (the team) can put in place to prevent them.

Back to my emails: the setting I changed wasn't on the Live site but on a testing environment that happened to contain real customer data. In this case, the problem was in how we create those testing environments (a fault in the process we have in place).

The problems could be prevented by improving the processes, adding any necessary documentation, and most important by spreading the information across the team.

Learning from a mistake isn't a cliché; it's something tangible.

If you really learned from a mistake, you will end up with more documentation available to the team, a better process in place, and everybody informed about what happened and what can be done to avoid it happening again.

Always keep in mind that, in 2017, La La Land was announced as the winner of the Best Picture category at the Oscars because somebody handed the wrong envelope. And they improved the process afterwards.

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.

Magento usually has bugs (thank you, Captain Obvious) after the release of a version, that are later corrected on subsequent releases (known issues).

Using patches to change core files in Magento is not a bad practice when the goal behind it is to bring core fixes existing on newer versions to the one we have running, avoiding so a full upgrade.

How to apply a patch

I'm starting the other way around as applying a patch might be more common than actually creating one, specially because Magento itself releases patches for its own platform, third-party vendors release patches for their extensions, and the community also makes patches for others to use.

There's a well known Composer package named cweagans/composer-patches that handles the patches and applies them to the original Magento modules every time you run composer install and/or composer update.

Technically speaking, this tool installs all Composer packages required, then removes the Magento modules affected by the patches we are including, and re-install those modules with the code changes applied.

➜  ~ composer install
Gathering patches from patch file.
Removing package magento/module-customer so that it can be re-installed and re-patched.
  - Removing magento/module-customer (102.0.5)
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Package operations: 1 install, 0 updates, 0 removals
Gathering patches from patch file.
Gathering patches for dependencies. This might take a minute.
  - Installing magento/module-customer (102.0.5): Loading from cache
  - Applying patches for magento/module-customer
    patches/composer/magento/module-customer/22952.patch (#22952 - Delegated account creation fails with custom attributes present in customer address)

For making this happen, first you need to add your .patch file in the patches/composer/magento/[module-name]/ folder (relative to the Magento root, at the same level your composer.json file lives).

The name of the .patch file doesn't really matter, but I personally like to use the number of the GitHub issue where the known issue was discussed, if that even exists. Otherwise, any descriptive name would do.

For the [module-name] folder name use the Composer package name containing the files you are patching.

As an example, the Composer package name for the Magento_Customer module is module-customer. This information is on the composer.json file of each package, inside the vendor folder.

Finally, on the root composer.json file, inside the extra node create the patches node and define the patch to apply as the following example.

"extra": {
    "composer-exit-on-patch-failure": true,
    "patches": {
        "magento/module-customer": {
            "#22952 - Delegated account creation fails with custom attributes present in customer address": "patches/composer/magento/module-customer/22952.patch"
        }
    }
}

See that I'm adding a description to what the patch does, and the GitHub issue number, followed by the relative path to the .patch file itself.

How to create a patch

Identify the core file you would like to change using a patch.

For the sake of an example, I'm going to patch the vendor/magento/module-customer/Model/Address.php file to apply a fix for the "Delegated account creation fails with custom attributes present in customer address" issue reported in the magento/magento2 repo itself.

Create an exact copy of the file, and make all the necessary changes.

If you are using PhpStorm, you can create a "scratch file" to hold any code temporary, like a draft, by pressing CMD + Shift + N.

Output the changes into a .patch file using the diff command on the Terminal while standing in the root of your Magento.

➜  ~ diff -Naur path/to/old/file.php path/to/new/file.php > example.patch

Following my example, I need to execute the following...

~ diff -Naur vendor/magento/module-customer/Model/Address.php /Users/nahuelsanchez/Library/Application\ Support/JetBrains/PhpStorm2021.1/scratches/scratch_113.php > example.patch

...in order to get my example.patch file.

Unfortunately, here's when we need to perform some manual intervention on the generated example.patch file.

First, remove the date and time appearing the end of the first two lines.

Second, you can see that the first path is the real path to the original file living in the vendor folder. Add a a/ prefix to it.

Third, replace the second path with the first path, but using the b/ prefix instead.

Fourth, and finally, add a new line on top of everything with diff --git a/vendor/core/file.php b/vendor/core/file.php.

Do not touch anything else there, not even the empty lines at the end (if any).

The resulting file ready to be used as a patch should look as the following example:

diff --git a/vendor/magento/module-customer/Model/Address.php b/vendor/magento/module-customer/Model/Address.php
--- a/vendor/magento/module-customer/Model/Address.php
+++ b/vendor/magento/module-customer/Model/Address.php
@@ -159,7 +159,9 @@
         $customAttributes = $address->getCustomAttributes();
         if ($customAttributes !== null) {
             foreach ($customAttributes as $attribute) {
-                $this->setData($attribute->getAttributeCode(), $attribute->getValue());
+                if (isset($attribute)) {
+                    $this->setData($attribute->getAttributeCode(), $attribute->getValue());
+                }
             }
         }

Unsplash is a great Ghost built-in integration that allows you to quickly add an image to your posts, and I personally use it every time to add the Feature Image to all my articles (the big one below the title, before the content).

Unfortunately, out of the box the image from Unsplash is really big (2000px wide) and impacts on the page speed of the site since the browser will download the image first then continue with the rest of the page.

There's no much we can do about the image size as we can't follow the "How to use responsive images in Ghost themes" official guide because that only applies to images you manually upload and not those coming from third-parties...

Dynamic image sizes are not compatible with externally hosted images. If you insert images from Unsplash or you store your image files on a third party storage adapter then the image url returned will be determined by the external source.

...but with a little bit of HTML and JavaScript we can lazy load them to prioritize the content over the image download.

Usually, the Feature Image in the Ghost theme will look something like:

<img src="{{feature_image}}" />

This is a classic img tag with the src containing the URL of the image. But we need to do some changes here first before moving to the JS side of this technique.

In the src we are going to put a placeholder image to avoid having a broken image while the rest of the page loads, we are going to move the actual image to the data-src attribute, and finally we'll add a new class to the element.

<img src="{{asset "images/placeholder.png"}}" data-src="{{feature_image}}" class="lazyload" />

The placeholder image should be a small image in terms of weight. I'm using an image with a solid colour of 183 bytes so I can "reserve" the space of the final Feature Image to avoid "jumps" in the browser while everything loads.

Finally, the JS is quite simple. We need to wait for the window to be loaded, get all the img elements with the lazyload class, and replace the src with what's on the data-src so we trigger the actual image download.

window.addEventListener('load', (event) => {
    let images = document.getElementsByClassName('lazyload');

    for (let i = 0; i < images.length; i++) {
        images[i].src = images[i].dataset.src;
    }
});

With this in place we should see that the content is prioritized over the Unsplash image, and if we are using a placeholder we should see that first in the "Network" tab of our browser's DevTools, with the actual image loading later.

This is the new normal, get used to it and get ready, because what's now (somehow still) a benefit from a company will be a requirement in the not too distant future. I wouldn't be surprised if working from home becomes a skill on a job offer rather than a perk.

Imagine listing on your resume not only your English level but also your work from home seniority.

All the lockdowns imposed around the globe due to the Covid-19 situation forced companies into a WFH scheme where everybody went remote from day to night.

I think this is here to stay in a combination of remote working and office space, resulting on a true flexible work from home scheme, because this is not only better for the employee but also cheaper for a company (no more rent?).

No more bs against working from home thanks to a pandemic

Companies were forced to reorganize quickly to continue working with their employees from home: the bs around this was cut immediately, the scepticism towards having people working from their homes disappeared. It had too, there was no other option.

NaguelNahuel Sanchez

I had the luxury of a WFH benefit on my last job and now, for the past two years, I became a full time remote employee to a London-based eCommerce agency so I sort of know how to work from home, and I don't see myself ever again going to an office Monday to Friday, so here's my take with three aspects on how to nail working from home.

Your space in the house

My first ever mistake (and probably everybody's first ever mistake) when I started to work from home everyday was to use the same table where I ate as my desk too.

The problem is not the table itself and the fact that the Mac shares it with a slice of pizza, but the inner feeling of being always on the same place, always, all the time, when working and when not doing it.

So even if you disconnect from Slack or close the lid, you are always at your working station, which is not good (mentally speaking).

Having a room in your house as the office is the main recommendation somebody could give you when diving into the work from home culture because it will easily allow you to "call it a day" when you have to, the same way you picked up your things from your desk at the company building and returned home.

Sometimes you'll need to isolate from the rest of the house when living with somebody else, on situations like having to concentrate on a task or having a Zoom meeting so here's where a door will come at handy, or some noise-cancelling headphones.

This leads us to having a set of house rules for all the house members for when work is happening, because not everybody is used to this work from home scheme and there was no reason at all until now to be aware of this new normal and having somebody in the house that now works from it.

For example, I tend to announce that I'm going to start a meeting, and that's enough for me. But you can set other rules too, like "Headphones means no interruptions", or guidelines for when the office door is closed.

Surely, I understand that having a spare room to be used as an office is usually a luxury, I'm no idiot.

For example, I rented my current place with this objective in mind, and I'm sure this will be something that's going to be considered, in the future, for when renting and/or moving.

But, still, there's always something you can do to mentally disconnect from work when you are done with it.

If you can't have a separate room, you maybe can have a specific place in the house to work, which is not the table where you eat. Like a small desk on the dinner or living room, that you know you use only for working.

Even if there's no physical space to do so, and you are forced no matter what to use the dinner table for working, then you can rely on environment settings to differentiate working hours from free time (like lighting).

Finally, something that works when there's no office room in the house is to close the computer and save it on a drawer, as a big gesture to call it a day.

A routine to avoid burnouts

One of the main problems of working from one, that we already mentioned as partially solvable by having a dedicated physical space to work, is the feeling of being on a constant work mode, on a state where work and life get mixed together and there's no clear differentiation between one and the other.

Having to go to an office imposed, at some capacity, a routine that you had to follow like waking up at a specific hour, having to take a shower for the sake of respecting your coworkers, having breakfast, etcetera.

Now you have to set your own routine, which is easy, and follow it, which is not.

This starts with having to follow regular hours every day, a routine. For example, I have set on my smartwatch reminders to have breakfast and lunch, which is a way to avoid losing track of time when I'm working.

Even if I do not actually follow them on a day because "I'm too busy" or because "I need to finish this first", it's a way to take awareness of "when are we".

You don't need to actually get up hours before work to take a shower, that clearly can be done later, but you shouldn't get up a minute before checking in at work. Allow you at least 15 minutes of being up and running before sitting on your desk.

I know that stay in bed for as much as we can is temping, and it's a clear benefit of working from home. But that's the benefit of not commuting, that's from where we gain sleeping hours.

So, 15 minutes of sleep won't make you any difference, but having 15 minutes for you before starting to work results on being more awake, therefore rested, through the entire day.

For a better working day, work on having a better wake up routine.

You don't have to have breakfast before work, that doesn't have to necessarily be part of your wake up routine, but instead you can have it later, during work, as a break.

Pause work during working hours to have breakfast? Isn't that against the rules? Please! When you were at the office you had some water cooler moments, or stop by the desk of a coworker to have some chat about whatever, or you made yourself five cups of coffee.

You had your breaks at the office and it's fine to have them now at home.

Call it a day

Avoid falling into an eternal working state of mind, or workaholism, is what you will be constantly fighting while working for home if you don't train yourself to be better at remote working.

Stop working is part of being good at it.

If the company you work for doesn't care for time tracking, you should track your time anyway, for yourself, to be aware of how much are you spending at work. And, as if you were going to an office, you should call it a day at some point, and don't work until the next day.

At the company I work for we have a Slack reminder with some stuff before we go, which also works as a reminder of what time is it (the same as the use of an alarm or the reminders I already mentioned I have on my smartwatch).

And when it's time to go. Go. No, really, go. Whatever it is, with the exception of an emergency, can be continued tomorrow... or next week.

If you can go out after calling it a day, even better. Leaving home is very good to clear your mind, even if it's for a short walk or for having a moment at a coffee store (which is my thing).

Working from home was always a luxury I can see becoming the new normal after this big social experiment we all suffered due to the pandemic.

Internet is full of tips and tricks on how to succeed at working from home. You just need to find those that suit you and get on with it.