Web development

You're looking at all the posts published under the tag #Web development.

Configure the Terminal to use MAMP's PHP

The idea of changing the Command-line to start using the PHP coming with MAMP is to be able to switch rapidly between PHP versions and to have the configuration for PHP in only one place. This is easy to implement and it covers how to configure the Terminal to use the same php.ini MAMP uses.

3 min read

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.

Ghost

Lazyload post Feature Image from Unsplash in Ghost

The image from Unsplash is big 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 but with a little bit of HTML and JS we can lazy load them to prioritize the content.

2 min read

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.

Web development

How to become a web developer in a lot of not easy steps

While the idea behind this how-to question is kind of the same, the answer depends exactly on what kind of developer you would like to be, because the offer is extensive out there.

3 min read

I'm being ask that a lot! No, for real, I'm not saying that for the sake of a cliche moment in the post, but the problem is that the answer is not that short nor that simple, hence this article.

Decide what's your thing

While the idea behind this how-to question is kind of the same, the answer depends exactly on what kind of developer you would like to be, because the offer is extensive out there.

I'm a web developer, a Full Stack developer that works with eCommerce platforms, so there lays my expertise, but maybe you are looking to become an iOS developer, Java developer, a videogames creator, or something else.

Clearly, the first thing you need to do is to decide that.

Take into consideration that if you are planning on making a living out of this job you will need to like it, and second you will need to investigate the job prospects of that choice you are now making (I don't think COBOL is really wanted these days, considering it's a language from 1959, for example).

Not all developers are the same, and not all guys and gals you see with code on theirs computers are creating a program for a PC (which I tend to think it's the general assumption when I say I'm a "programmer").

Start with some courses

I have to be honest here and say that I'm not impress by courses when I see them on resumes, because them alone tell me nothing. But I will assume here that you have no experience as a developer whatsoever, and that you are starting from scratch, therefore is safe to say that while a lot of courses won't land you on a job position, it's for sure the way to start.

It's the starting line not the finish line.

Based on what you decided on the last section related to what kind of developer you would like to become, now you can filter out some of the courses available all over the world.

My suggestion here is to go local, meaning pick a course provider from your city or country because they tend to have partnerships in place with IT companies in a way you can ended up as a trainee there after completing a course.

Investigate that. Not only find a course you would like to follow and suits you, but try to do it on a place (school?) that IT companies then use to recruit from.

Play around, play a lot

Courses usually end up with a real project you would be uploading into GitHub or similar.

That's not enough. From my point of view, practice beats theory.

After the course you will be on your own. Yeah, I mean, you can start a new one, but as I said before I'm not impress by courses as I expect "real" practice.

This is when you need to start building up your portfolio, meaning a GitHub with small projects, practice code, snippets, something to show, something not just only to tell others you are more than theory but also for applying that theory into real stuff, for actually keep on learning.

Do not forget courses will provide you with the basics, and you won't become a Senior developer following courses. It will be up to you, and that's with practice.

The way it happened to me is that I had a WordPress blog (not this one, another one, ages ago), with a basic theme that I wanted to customize. So I started doing small changes, then wanted more complex ones, and one thing led to another. That's how I started.

Land a job no matter the salary

With courses on your resume and a portfolio to show is time to become real. Bye bye training wheels!

Unfortunately, this is not easy, not because of the opportunities out there that I think are plenty on the IT sector, but because you will need to escape your comfort zone.

If you are reading this you might as well have a stable job already and this idea of becoming a developer is a plan for the short term future, so at some point, with courses already finished and code already uploaded into GitHub, you will need to decide how much salary you will be willing to let go in order to start on the business.

A trainee position won't pay much. Actually, if it pays at all that's a win already, but you need to start somewhere. For example, you can be a lawyer now and there's no chance your first job as a developer will match your current income. Accept that.

Take your first opportunity on the real world as a way to learn how a company operates for real, how working on a real project looks like. This is your chance to learn the real stuff.

Your first job might be a sacrifice in terms of money, but after this, with one job experience in your resume, the opportunities will increase exponentially.

I know, it's scary, but come on, you first job won't be a Senior position. Get real, face it, it will be worth it.

Web development

Change Googlebot crawl rate

If you are thinking about controlling the crawl rate using the Crawl-delay directive on your robots.txt file, forget it, Google ignores that. You need to use what's remaining of the old Google Search Console

2 min read

As weird as it sounds it could happen that Google hits your site at a pace your server won't be able to handle, causing page speed issues and a potential site down related to a high CPU usage and too many MySQL connections.

Google claims to be smart enough to be able to self-regulate the crawl rate at which it hits a site (they said that they have "sophisticated algorithms to determine the optimal crawl speed for a site"), but that's not true all the time.

If you can contact your hosting provider, they might be able to tell you the number of requests the bots are making (where around 20000 in the last six hours could be enough to cause issues) and the logs for those calls.

185.93.229.3 - - [23/Sep/2021:05:32:55 +0000] "GET /about/ HTTP/1.0" 200 20702 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Make sure that the IP you are seeing on the logs are really from Google not being smart about the crawl rate, and not a DDoS attack in disguise.

If you are certain about Googlebot being the one causing the problems with your server, you need to adjust the crawl rate first, and then block Google, temporarily, while you wait for the new crawl rate to take effect.

Adjust the crawl rate using Google Search Console

If you are thinking about controlling the crawl rate using the Crawl-delay directive on your robots.txt file, forget it. Google ignores that.

You need to use what's remaining of the old Google Search Console, not the new fancy one, here https://www.google.com/webmasters/tools/settings.

Selecting the “Limit Google's maximum crawl rate“ option will display a slider for you to configure a lower crawl rate.

How low? I can't tell you exactly, since that would depend on your site and server capacity, but as reference I remember configuring it as follow for a Magento project living on a size XL AWS instance.

1 requests per second
1 seconds between requests

You can try something like that, or even lower, maybe at 0.5 requests per second.

Block Googlebot temporary for a few days

So, here's the catch: the new crawl rate setting is not immediately applied.

After saving the new crawl rate you'll get a message saying that "Your changes were successfully saved and will remain in effect until Sep 17, 2021" but it's not until you open up the confirmation email that you'll read that "within a day or two, Google crawlers will change crawling to the maximum rate that you set".

This means that your site will keep on getting hit at the same pace for a day or two, so the solution is to block Google for that period of time while you wait for the new crawl rate to get into effect.

Remember to lift the ban on Google after 2 days, and monitor for the following days that Google isn’t affecting the site performance again (so confirming the new crawl rate is working, otherwise you might need to bring it down a little more).

Front End

Play spot the difference as part of your front end development process

If you're a developer whose main task is to look at a PSD file and "make it happen", then I can't stress hard enough how important is for the job that you achieve this successfully. If you're thinking that this is obvious and there's no need for a post, trust me, it's still a problem among devs.

4 min read

I know that inside the front end development kingdom there are a lot of different sub species, different front end developers out there working in different stuff: a few more focused on the functionality closer to back end development, and some working on converting designs into code.

If you're a front end developer whose main task is to look at a PSD file and "make it happen" in code, then I can't stress hard enough how important is for the job that you achieve this successfully. And if you're thinking that this is obvious and there's no need for a post, trust me, it's still a common problem among developers... and it's hard to me to understand why.

What's the main task of a fire fighter? Extinguish a fire. What's the main task of a plane pilot? Fly the plane. Main task of a mother?... I have no idea, but my chips are on keeping the baby alive.

Jokes aside, what do you think is the main task of a a front end dev? Get a design, then implemented it as pixel perfect as it can be.

I saw this problem presented in a variety of seniorities, as it doesn't distinguish between Juniors and Seniors. Of course, the problematic is more present in lower seniorities, that's not surprise, but it still cause for rework in more experienced developers.

If "main task" seems like too much, as you probably thinking, just like I am, that a front end developers faces a lot of task during a day and it's hard to decide which one is the main one (again, related to the fact that your front end developer job description it's for sure different than the others), then just let's not get stuck in grammar.

It might not be your main task as a front end developer, but for sure is an obvious task, something that you should be already been achieving without anybody raising any doubt about it when you deliver.

So why aren't you? Or why you still have this problem in your team?

If it's your problem then awesome, today is a great day to start solving that. And if not your problem but something you see that happens within your team or company... then it's still your problem, sort of.

The most common excuses I heard about it is the lack of tools, or people using the wrong tools, to view and manipulate the designs.

"Oh, it looks different because I don't have Photoshop in my computer so I opened the document with other software that converts .psd files if you're using Linux."

That's not a good excuse and you know it.

We're missing a synchronization here between developers and people in higher position within the company when deciding on what tools to use. Are we going for Adobe Photoshop for the designs' team?, great, then let's make sure that we also have Adobe Photoshop in the developers' computers... and not Linux if we're going to deliver .psd files to them.

Here's another one, "We were on a hurry, so I couldn't spend time on making the implementation pixel perfect". I can only assume that the equivalent for that on a fire fighter would be something like "Oh, we were on a hurry, so we only extinguish the fire on the first floor".

That "explanation" is a symptom of a higher problem within the company that might deserves an individual post, but for the moment just stop the presses and evaluate if you're giving to the developer the necessary time to accomplish all the items included in yours definition of done. If not, then you're asking for the impossible.

On the other side, if you're the developer. Come on dev, stand your ground! Do not go for an impossible estimation knowing that you won't be able to deliver successfully. If the time frame won't allow you to go for a pixel perfect implementation, then speak up. If everybody is on board of what the outcome will be, then good, no surprises for nobody.

And finally, the Top 3 seems to be "I tested it on Chromium for Linux Mint and it looked exactly like the designs". Looks like a child of the first excuse, and still a bad one.

On the developer's side, ask for the specifics, ask what browsers you are supporting for that particular project, or ask for metrics from Google Analytics to know exactly what your final customers are using. And test, my friend, test it on more browsers (specially knowing that Chromium for Linux Mint can't have the final word).

If you're the company, or somebody with a technical seniority that have a say on technical decisions, then define what browser do you support and include them on your definition of done. Avoid having technical decision based on the personal believes of each developer on the team.

Spot the difference

Have you ever played that magazine or newspaper game where you have two almost identical images next to each other and the goal is to spot the 10 differences? Why don't you try the same game with your work before tagging it as done?

I've been on meetings where emotions are high, reviewing an implementation that clearly doesn't look like the designs, where the conversation last for less than a minute because all it takes from the person evaluating the job is to put the original design next to the developer implementation and ask "Does it look the same? Does it look like it is finished?".

And of course it doesn't. Just avoid that meeting by playing the game by yourself and prevents others from playing it for you with your work.

On a not much of a side note, I find the post "The Undefinition of "Done"" quite cool, so check it out as it might help with your development process.

Ghost

A blank Ghost blog theme for development

The Pale Ghost theme is a blank theme, developer ready, focused on the markup without styles, that already includes all the Ghost features for you to customize or remove in order to create your own theme.

2 min read

This blogs runs on the Ghost platform built with Node.js, with a homemade theme that uses Handlebars, HTML, CSS and JavaScript, and if you are reading this article chances are that you're already a Ghost blog owner and that you're looking to develop your own theme.

The problem with the Ghost default theme named Casper, while it's extremely helpful to learn how to develop a custom Ghost theme, is that it is too complex or "it has too many things" you probably don't want for your blog.

For example, when creating the theme for this blog, I had to "deconstruct" Casper to start building on top of the ashes because I wanted a more simple theme, that has my own code wrote the way I wanted it.

Introducing the Pale Ghost blank theme

I already searched for Ghost blank themes, and truth be told there are many out there, but none suits my desires. All the blank themes I encounter has too much JavaScript, or they are too much complex to the point they looses they purpose of being a blank theme.

This blank theme in particular is very simple, so you might be spending time in the styling part with CSS/SASS/LESS rather than working on the markup. And if you want to move stuff around, you'll find it's easy with the Pale Ghost theme as it is well deconstructed into different .hbs files for an easy development.

It also includes everything a Ghost theme can deliver, just as Casper, but with a simple implementation. The goal with this theme is to avoid the part where we as developers smack things down before actually building up.

For a more technical description of what this blank theme includes you can check the Pale Ghost theme's GitHub page.

Downloading...

You can download this blank Ghost theme from the Pale Ghost theme's GitHub page, where you'll find the "Releases" section.

VTEX

How a VTEX developer looks like from a technical point of view

VTEX requires a front end developer with a signed certification from his mother saying that he's great with those "Find the n differences" puzzles you get on the Sunday's newspaper, because the primary task he'll face is to transform a given design into "code", as pixel perfect as it can be.

3 min read

If you happen to be on a similar position as I am where one of my task is to conduct interviews and vote on someone getting hire or not, you also have to be able to establish if that person can work with a specific platform.

It is not the same working on a VTEX store, an ORO implementation, or in a Magento project. For each platform you have to have a specific set of skills, and again, depending on the platform, more experience on some specific skills are necessary and the seniority on a specific ability vary when you change the CMS you are messing with.

So, how it looks like now?

Translated to actual skills, for a start it means we're looking for someone very good at xHTML, CSS (and/or any CSS preprocessor like SASS or LESS), that can also handle simple JavaScript logic or jQuery for basic UX interactions.

Bear with me if you not agree on that "simple JavaScript logic" statement, because there's a reason why I said "for a start". With this specific developer you are kicking off the team you need for a VTEX implementation but you are not finish yet.

Based on my experience, someone with the ability to handle the layout will cover a high percentage of what the project needs. Seriously, even on highly custom VTEX projects always the largest amount of workload falls on the person who handles the implementation of the designs and that's why is very important to have someone who nails this task.

The next step is to choose between two options: we either look harder for a person with the mentioned skills that can also handle the logical part of a development, or we get another team member for this job only.

If we go for the first option, now finding the developer became a little bit more complicating.

I think that considering a lot of front end developers, on one end we have the "developer who handles the layout and leaves the logic to back end" and in the other side the "kind of full stack developer hungry for programming but with no love for the look and feel".

Our first option requires us to find someone in between, and that's hard (talking, again, from my work experience). Personally I'll go for this option, because, personally, I feel more comfortable with those "in between" developers. But that's just me.

The second option is more suitable when looking at this from a company level where you have multiple VTEX implementations.

Imagine an scenario where you have three VTEX projects ongoing, each with a person assigned full time implementing the layout only, and a fourth developer jumping from VTEX 1, to VTEX 2 and VTEX 3 working on the customizations only, while leaving the "make this as the designs indicate" to the full time assigned coworker.

The person in this second option needs to know JavaScript for real, because all VTEX front end custom stuff always falls on the need of use of JavaScript.

The developer, sort of acting as a back end developer in this platform (in a manner of speaking) will be dealing with the logical part of the implementation like struggling with the APIs and integrating with VTEX's Master Data.

But how it will look like in the future?

The platform is evolving constantly and it is on its peak on what updating the technology stack refers. This means that what I just said above still applies, but we need to consider what is coming.

In the not so distant future the idea of VTEX IO as the VTEX's web application development platform is that custom (and useful) customization that takes places on a specific VTEX store become an App, in a sort of plug and play plugin for that specific store and others.

For example, let's say you have to development something to get the users' email using a form in order to subscribe them to the newsletter configured using MailChimp. Do it once, make it an App, and reuse it on the future or sell it to other existing stores seeking for the same functionality.

In this new world, besides the fact that you need a little bit of npm and the use of a Terminal to set up your workspace, you'll definitely need to know React and GraphQL in order to build the application.

So don't get sleepy.

Job Interviews

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

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

3 min read

When giving a performance's reviews, one idea I used to pitch to somebody with the potential to be an even better developer in the future is that we all have the same tools in the company to improve ourselves.

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.

This is something that bothers me in the sense that it makes me feel I'm losing control of any recruiting process I might been part of, or any "technical coaching" I'm giving.

Because while it might sounds as a "motivational speech" during the performance's review, let's do not lose sight of the timeline here. If we get to that point saying is more about personality than hard skills, then it was also more about personality a few months ago during the interview process.

What if interviews are all about luck and not about us evaluating correctly the hard skills of a candidate?

Sometimes it feels like it doesn't matter if I really really prepare for an interview, or if I improve my tricks to get to really really know the candidate's hard skills, because it feels like it all goes down to about how lucky we are as a company when we take our chances with a candidate by saying "Yes, come work with us". Does it happens to you?

I remember joking about this issue by proposing something like open the company's door, let 20 candidates join us, and we'll see how they perform during a month... and by the end lets "fire all the personalities" that didn't succeed.

Let's not waste more time with interviews and technical exercises! Everybody is welcome for a month, and we'll decide later who can stay.

Yep, that would be a fun disaster to watch. But again, this is sometimes what I'm experiencing with the whole recruiting process, and also I stand corrected by saying it's not really a feeling but an actual fact because we truly accepted people with serious doubts about their hard skills that in a short time became great developers, and we also let in promising ninja developers that resulted in a total fiasco.

So, what's the next step?

I don't know.

I'm struggling with this problem and this is more of a sharing my concerns post than a post with an outstanding solution at the end. But let's do some brainstorming in order to get some action items to work on later.

Probably the first idea is that we suck at interviewing because we don't have the skills or the tools to really get to know the candidate's hard skills pass the personality and what that person is selling during the interview.

We should improve the exercises we're giving, enhance the questions we're asking, and have a clear understanding of which hard skills we are looking for and to what degree of knowledge we're aiming for those identified skills.

Before that face to face technical interview, it seems like it's necessary to improve the first informal interview to rule out the personalities we do not want. Because, don't get me wrong, we do want people objective-oriented and willing to learn everything... but that's not the only things we want to depend from.

So, it seems like this last thing is more mandatory not to solve our main problem here but to avoid a different one.

When the process fails again (meaning when we bet for a candidate and things goes wrong again) we should be doing an analysis of what happened and we should be having metrics about failing and succeeding process in order to identify what's working and what's not.

The goal here is not to all say "Oh, we fail again, let's try again one more time" but more about getting the reasons behind the process that didn't go as expected, and getting hints about how to make it better.

I still do not know for sure how to solve this, but I get myself some ideas to sleep on it and I hope you too.

VTEX

Understanding the product's name front end logic in VTEX

Is VTEX showing the name from the "Product" in the Admin? Or is it showing the name we entered in the "SKU"? Or is it showing both?... or why sometimes it seems like VTEX is using the "Product" name and in other occasions it is using the "SKU" name?

2 min read

Is VTEX showing the name from the Product in the Admin? Or is it showing the name we entered in the SKU? Or is it showing both?... or why sometimes it seems like VTEX is using the Product name and in other occasions it is using the SKU name?

In other words, what's the name I'm going to see in the front end of my VTEX store when creating a new product?

I'm writing this down because I found there's always a confusion about what is VTEX showing as a name for a product when looking at it in the front end (like in a category or product's page) considering there's a tricky logic there that involves the Product entity and the SKU.

Product entity name and SKU name?

To avoid any misunderstanding, let's discuss first what I mean by "Product entity name" and what I'm talking about when referring to the "SKU name".

When I say "product's name" we all think about a product as a whole, the item itself and the name that item has. But a product in VTEX is divided into two thing: The Product (or the Product entity) and the SKUs included on that Product.

I know I might sound philosophical and delusional but just take a look at this screenshot so I explain myself better.

understanding-the-products-name-front-end-logic-in-vtex-01-1

Is our site showing the name from the first column or from the second one?

Which one is going to appear on the front end of the VTEX store?

It just depends on this simple logic you need to consider.

If the Product entity name is exactly the same as the SKU name, then VTEX will show only one. Take a look at the screenshot above where the names in both columns are identical, meaning the front end will only show "iPhone X 64GB Silver".

On the other hand, if the name in the Product is different from the name in the SKU, then VTEX will show the two names separated by a dash (-).

For example, if for the Product we have "iPhone X 64GB" and for the SKU we have just "Silver", then the result on the front end it is going to be "iPhone X 64GB - Silver". That simple.

understanding-the-products-name-front-end-logic-in-vtex-02

Knowing that, if you're facing the "problem" in VTEX with the front end showing the names "duplicated" or if you didn't understand from where that final name is coming... now you know.

Keeping both the Product and SKU with the exacly same text (not even a difference in the capital letters) will show only one name, no dash.

VTEX

Check if a user has made a purchase on a VTEX store

There's a twisted workaround to check if the user has already made a purchase on the current VTEX store thanks again to VTEX Master Data.

3 min read

There's no a simple built in functionality on VTEX that allows to check if the current user browsing the store has already made a purchase there, but there's a twisted workaround to get this information.

Before actually going through the guide, this is the idea: we need to create a new attribute in the CL Data Entity that retains this information and this attribute is going to be updated on the Order Placed page doing an HTTP request to the VTEX Master Data using JavaScript.

Sounds simple? Well...

Creating the new attribute

Thanks to the VTEX Master Data API we can get a lot of information about the clients, but if he or she has made a purchase is not there anywhere, that's why we need to create a new attribute that will hold this information.

The new attribute, let's name it buyer, needs to be Boolean, and we need to grant it permissions to be read it and edit it using the API.

Attribute configuration on the Client Data Entity

All existing registered users on our store will have it in null or false until we changed it to true after a user performs a full checkout process.

Updating the attribute

After the user performs a purchase he will end on the Order Placed page that says something like "Em breve você receberá um e-mail no endereço john doe@example.com com todos os detalhes do pedido". We need to get that email from the source code of the page and using jQuery AJAX performs a PATCH in order to set the buyer attribute in true.

The problem is that we can't directly insert any piece of JavaScript code in the VTEX Smart Checkout. If you're thinking on adding the JavaScript code into any of the orderplaced-* templates, it won't work, the code won't be displayed because of security reasons.

Here's the fun part: we need to use Google Tag Manager to insert JavaScript on that page.

GTM as our Trojan Horse

Since the VTEX Smart Checkout, as any other checkout process from any other platform, is a sensible part of the site and that's the reason why we don't have, directly on VTEX, a way to insert JavaScript code.

If we have Google Tag Manager integrated into our VTEX store it's our lucky day because that tool can add JavaScript on the page, and the idea is to give to GTM our jQuery AJAX request code.

To accomplish this we need to create a new Custom HTML Tag where instead of HTML we are going to add our script. This script.

$(window).load(function() {
    if ($('.orderplaced-sending-email strong').text().trim()) {
        var urlProtocol = window.location.protocol;
        var apiUrl = urlProtocol + '//api.vtexcrm.com.br/storename/dataentities/CL/documents';

        $.ajax({
            "headers": {
                "Accept": "application/vnd.vtex.masterdata.v10+json",
                "Content-Type": "application/json"
            },
            "url": apiUrl,
            "async" : false,
            "crossDomain": true,
            "type": "PATCH",
            "data": JSON.stringify({
                "email" : $('.orderplaced-sending-email strong').text().trim(),
                "buyer" : true
            })
        });
    }
});

Next, on the Fire on step, click on More in order to create a new trigger. The new trigger needs to be a personalized event that will be fired on "orderPlaced".

Save the tag and publish the changes on Google Tag Manager. This is not affected by VTEX cache so we should see the changes immediately.

At this point every time a user hits that page, meaning every time an user finish a purchase, the buyer attribute will be set to true. So now in any other page of the store you can use the VTEX Master Data API to check if buyer is true. If so, then the user browsing the site already made a purchase and you can do whatever you want with that information.

Waaaait

This is a delicate move. You are inserting JavaScript into the checkout process so test it very well, you don't want to screw this part of the VTEX implementation.