Changing Magento Cloud PHP version

Technology hardware and software are upgrading constantly, mostly in order to provide a better service and/or improve security, in the middle of this constant changing the PHP scripting language needs to cope with all these dynamic environments. 

Magento Cloud also facilitates changing the PHP version; providing more convenience to any DevOps team. 

When upgrading the PHP version, its version needs to be compatible with the Magento host version. The following table can be referenced for helping to determine the correct PHP version.

Adobe Commerce versionPHP version
2.3.57.2, 7.3
2.3.67.3
2.3.77.3, 7.4
2.4.07.3, 7.4
2.4.17.4
2.4.27.4
2.4.37.4
2.4.48.1
2.4.58.1

For changing the PHP version, the file .magento.app.yaml must be edited. For example:

Original service definition:

type: php:7.2

Updated service definition:

type: php:7.3

Commit the changes and push the changes for activating a redeploy:

git add –all

git commit -m “Changed PHP version”

git push <remote> <branch>

After redeploying open a tunnel via Magento CLI:

mgc tunnel:open

mgc tunnel:info

And check the service version for confirming the upgrade by SSH into the environment and check the PHP version:

php -v

After confirmation, the environment can be used as normal.

Images not loading in Magento Cloud Due to Cache Issue

By design, when the site administrator uploads a new product image, Magento will autogenerate all the image sizes and required cache folders inside the pub/media folder. After this, every time the frontend browses those images Magento will serve those cache folders, aiming for faster browsing times.

Magento Cloud architecture allows extra settings for handling those image cache folders; including the minimum persistence time on the cloud.

The .magento.app.yaml file, besides allowing to configure the PHP version, extensions, and relationships, also allows configuring how long the cache folder must persist in the cloud. Let’s consider the following example where the cache folder is being configured to be stored for at least 1 year.

“/media”:

            root: “pub/media”

         …

            expires: 1y

    …

This will assure that the cache folder will not lose any data for at least 1 year; however if after one year the environment is redeployed, it is possible that the images will not be displayed and the browse console will display a 404 error when attempting to load any product image.

For solving this issue and also, for renewing the cache folder for another year, the cache needs to be regenerated by accessing the environment via SSH and executing the following command:

php bin/magento catalog:images:resize

This command will regenerate all necessary images sizes and their corresponding cache resource inside pub/media. Also, after this, it is recommended to re-index and clean the cache.

php bin/magento indexer:reindex 

php bin/magento cache:flush

After this, all product images will be displayed normally.

Downgrading Magento Cloud Services Versions

Magento Commerce Cloud allows a service downgrade for any particular environment; the downgrade process is not as direct as upgrading, but it is still very convenient.

When downgrading a service, its version needs to be compatible with the Magento host version. The following table can be referenced for helping to determine the correct service version.

ServiceAdobe Commerce 2.4.xAdobe Commerce 2.3.5 ~2.3.9
elasticsearch7.7, 7.96.8, 7.5, 7.7, 7.9
mysql/mariadb10.2, 10.410.1 ~10.3
rabbitmq3.83.7, 3.8
redis5.x, 6.x5.x, 6.x

The easiest way for downgrading a service is by renaming it or creating a new one in the magento/services.yaml file. For example:

Original service definition:

elasticsearch:

    type: elasticsearch:7.7

    disk: 1024

Updated service definition:

elasticsearch2:

    type: elasticsearch:6.8

    disk: 1024

After that, the services relationship must be updated in the .app.magento.yaml file. For example:

Original service relation:

relationships:

    database: “mysql:mysql”

    redis: “redis:redis”

    elasticsearch: “elasticsearch:elasticsearch”

    rabbitmq: “rabbitmq:rabbitmq”

Updated service relation:

relationships:

    database: “mysql:mysql”

    redis: “redis:redis”

    elasticsearch: “elasticsearch2:elasticsearch”

    rabbitmq: “rabbitmq:rabbitmq”

Commit the changes and push the changes for activating a redeploy:

git add –all

git commit -m “Downgraded elasticsearch service”

git push <remote> <branch>

After redeploying open a tunnel via Magento CLI:

mgc tunnel:open

mgc tunnel:info

And check the service version for confirming the upgrade:

elasticsearch2:

    –

        username: null

        …

        type: ‘elasticsearch:7.7’

       …

After confirmation, the environment can be used as normal.

Upgrading Magento Cloud Services Versions

As part of its solution, Magento Cloud facilitates changing the services for any particular environment; reducing also the risks of causing a conflict within components.

When upgrading a service, its version needs to be compatible with the Magento host version. The following table can be referenced for helping to determine the correct service version.

ServiceAdobe Commerce 2.4.xAdobe Commerce 2.3.5 ~2.3.9
elasticsearch7.7, 7.96.8, 7.5, 7.7, 7.9
mysql/mariadb10.2, 10.410.1 ~10.3
rabbitmq3.83.7, 3.8
redis5.x, 6.x5.x, 6.x

For instance, for Magento 2.3.7, a valid selection would be as follows:

  • elasticsearch:7.7
  • mysql/mariadb:10.2
  • rabbitmq:3.8
  • redis:5.0

For changing a service version, the file .magento/services.yaml must be edited. For example:

Original service definition:

elasticsearch:

    type: elasticsearch:6.0

    disk: 1024

Updated service definition:

elasticsearch:

    type: elasticsearch:7.7

    disk: 1024

Commit the changes and push the changes for activating a redeploy:

git add –all

git commit -m “Upgraded elasticsearch service”

git push <remote> <branch>

After redeploying open a tunnel via Magento CLI:

mgc tunnel:open

mgc tunnel:info

And check the service version for confirming the upgrade:

elasticsearch:

    –

        username: null

        …

        type: ‘elasticsearch:7.7’

       …

After confirmation, the environment can be used as normal.

Upgrade Shopify APP from EASDK to Shopify App Bridge 2

Shopify App Bridge 2 is the latest SDK for any custom APP uploaded to Shopify. In the past, EASDK was one of the most popular SDK used by developers for utilizing the Shopify platform; however, this one is not supported anymore by the Shopify platform, leading to all apps using EASDK to be deleted in the near future. For this reason, Shopify is urging all partners developers to upgrade to Shopify App Bridge 2.

The upgrading process requires a function substitution at the App’s Javascript level, luckily Shopify documentation documentation is very complete on how to achieve this task.

Upgrade basics

The first step is to find the javascript import for the old EASDK and replace it with the new Shopify App Bridge script.

Original

<script src=”https://cdn.shopify.com/s/assets/external/app.js“></script>

New

<script src=”https://unpkg.com/@shopify/[email protected]“></script>

Referencing to [email protected] will let the APP use the latest Shopify App Bridge 2, however, if another version is required it can be changed to something like [email protected]

The second step is to replace the EASDK init function for the new createApp function

Original

ShopifyApp.init ({

apiKey: “<? php echo $ this-> config-> item (‘shopify_api_key’);?>”,

shopOrigin: “https: //” + current_shop,

debug: true,

forceRedirect: true

});

New

var AppBridge = window [‘app-bridge’];

var createApp = AppBridge.default;

var app = createApp ({

apiKey: “<? php echo $ this-> config-> item (‘shopify_api_key’);?>”,

shop: current_shop,

shopOrigin: current_shop,

});

Finally, the following steps is to find for any call to ShopifyApi to the equivalence in Shopify App Bridge 2, for example, the process for replacing a Toast would be as follows:

Original

ShopifyApp.flashError(‘Error’);

New

var AppBridge = window [‘app-bridge’];

var actions = AppBridge.actions;

var Toast = actions.Toast;

const toastOptions = {

message: ‘Error ‘,

duration: 5000,

isError: true,

};

const toastNotice = Toast.create (app, toastOptions);

toastNotice.dispatch (Toast.Action.SHOW);

A complete reference on how to substitute the old EADK functions can be found in the official Shopify documentation. 

https://shopify.dev/apps/tools/embedded-app-sdk/methods

Finally, after upgrading to Shopify App Bridge 2, please remember to update to the latest Shopify API version and test for discarding any unexpected issue after the upgrading. 

Using CSS on Magento Page Builder

Page Builder is Magento’s tool functionality for providing merchants a convenient way for designing pages ready for production; furthermore, allows faster releasing times and a cost reduction related to web development. 

Originally provided in the Magento Commerce / Enterprise version only, it is now also available in Magento Open Source, starting from version 2.4.3.  Page Builder provides a very intuitive drag and drop interface that also allows setting those little details that make a website stand out from the rest; being CSS one of them.

Adding a customized CSS style on any Page Builder element is as simple as adding a new HTML code element in the page.

Then, by editing the html code block, any custom class CSS style definition can be defined, just like in any regular html file.

After saving, the custom CSS class can be used in any other Page Builder block by just adding it into Advanced properties of any block setting

After saving again, the CSS class will be applied to any block that is referencing the custom CSS class.

However, in some special cases, a deeper knowledge of Magento theme development would be required for a whole customization of self-generated elements, but the general website development process experience will definitely be improved.

HTTP Basic Authentication for Magento Cloud

There is no doubt that live testing is much preferred before pushing to the Production environment, however, there are times when a new feature or changes on Integration/ Staging environment is preferred to be kept private or secret from the public network; for this, HTTP authentication would be a solution.

What is HTTP Basic Authentication?

The basic flow of any HTTP Basic Authentication is as follows:

  1. A client requests access to any page from the store.
  2. The web server returns a dialog box that requests username and password.
  3. The client submits the username and password to the server.
  4. The server authenticates the user,if successful, returns the requested page.

Magento Cloud provides a very simple web interface for enabling HTTP authentication; just click on the environment and go to Configure EnvironmentSettings; then click Edit on HTTP access control.

The interface will look like the following:

By using the above interface the administrator can set any amount of usernames and passwords, and/or restrict or allow by IP address.

After finishing setting up the administrator must switch HTTP access control to ON in order to apply the changes, this will display a login dialog if the client has not been authenticated yet.

This will add an extra security layer to those teams that require to live test under a certain degree of discretion, being also secured since Magento Cloud utilizes SSL as default for all communication.

Setting Up Magento PWA Venia to Production Mode

After developing or testing new features, for any particular Venia environment on developer mode, the next step is to deploy to production mode in order to take full advantage  of the customized and enhanced code for being used as a Magento frontend.

This article will not cover any CI/CD process, due to its dependency and dynamic nature based on custom requirements and testing.

  1. Installing Venia 

1.1 Before Installation

Need to check both Node and Yarn versions on the host; being the following version the minimum required. 

node -v (Should be 10.16.3 or higher)

yarn -v (Should be 1.13.0 or higher)

If the host’s versions are lower, an update or reinstall is required. 

For more information regarding specific OS installation steps can be found in the following links:

https://nodejs.org/en/
https://yarnpkg.com/getting-started/install

1.2 Installation

  1. In the local folder to be used as the root directory, create the initial project and answer the questions:

# yarn create @magento/pwa

  1. Start the dev server:

# yarn watch @magento/pwa

After this, the dev server will be ready to be used; however, it is recommended to create a custom hostname and SSL cert, especially if there are more than one environment being developed in the same local environment.

# yarn build create-custom-origin ./

After this, everytime the dev server starts will use a unique and customized hostname and SSL certificate.

If the dev requires a very specific hostname it can be changed in the .env file by setting changing the value for CUSTOM_ORIGIN_EXACT_DOMAIN

Note: everytime the hostname is modified the create-custom-origin command must be executed.

  1. Running Production Mode

After testing and developing all the required features, the Venia can be set now to production mode as follows:

1. Setting up .env params

The following params in the .env file need to be set up in order to run production mode properly. 

STAGING_SERVER_PORT=xxxx —> for customizing the port number

CUSTOM_ORIGIN_EXACT_DOMAIN=”xxxxx” → for customizing the hostname

2. Compilation

Before running production mode, the code needs to be compiled into the build folder.

# yarn run build

3.3 Running

Finally, the production mode can start.

# yarn start

  1. Setting up NGINX

It is also recommended to deploy a Web server for enhancing security and performance. 

Usually, ReactJs-based projects work better with NGINX. The following checklist needs to be followed:

  1. Static vs Proxy mode: Should NGINX be set as static or proxy mode? This depends on if NGINX will handle the whole request or just serve as a bridge for another software.
  1. Firewall Settings: Make sure that all ports configured for both Venia and NGINX are able to be accessed securely from any secure client.
  1. SSLCertificate: By default Venia requires to work with https
  1. URL rewrite may be necessary or not; depending on the NGINX and Server configuration.

For a full reference on how to comply with the checklist listed above, please refer to the following links. The NGINX configuration is relative to the OS and for these reasons they will not be covered in this article.

NGINX References:

https://blog.devgenius.io/using-nginx-to-serve-react-application-static-vs-proxy-69b85f368e6c

Translating a Magento PWA Venia Theme

  1. Basic Translation

Supporting different languages is a must for merchants that are targeting customers from different countries and/or languages.  Leading also to bigger exposition since the customer base would be significantly expanded.

Venia / Magento PWA theme doesn’t provide internationalization packages out of the box; being the American English the default language (en_US); however, the good news is that translating a Venia web site is a very simple process. 

Let’s take for example the Search button, located at the top right of any recently installed Venia environment, and translate it to Spanish. 

Assuming that the local project has been fully configured:

  1. Copy the original en_US from Venia and paste it into the project root

# cp project_root/node_modules/@magento/venia-ui/i18n  /local_project

  1. Create a new dictionary using the following format: 

language-abreviation_country.json

Example:

es_MX.json

zh_TW.json

  1. Replace the English content with the required translations; let’s use es_MX for Mexican Spanish.

Example:

Original:

“searchTrigger.search”: “Search”

Translation:

“searchTrigger.search”: “Buscar”

  1. Recompile and re-start Venia (development or production are both fine).

After this, the Search button will be fully translated into Spanish.

  1. Custom Translation / Advanced Translation

When attempting to translate new words, extra steps are required in order to translate those new words.

The most simple procedure would be as follows:

  1. Add a new id to both the en_US.json and the custom translation file located in the local root project. The id can follow any pattern.

Example:

en_us.json:

“menu.men”: “Men”

custom.json:

“menu.men”: “Hombres”

2 In the code the following changes need to be made in order to translate the new word.

Example:

import {FormattedMessage} from “react-intl”;

let trans = (

   <FormattedMessage

       id={‘menu.men’}

       defaultMessage={‘Men’}

   />

);


// In this case “trans” is just a variable to hold the translation text result.

3. Recompile and re-start Venia (development or production are both fine.

After this, the custom translation will be used in every component where the custom id is being used.

Finally, the translation process could require more complex steps such as: API calls, coding, etc; but for the steps described above would cover most scenarios on any startup project.

Also, remember to include a custom dictionary as soon as the backend server has enabled it, since some versions of Venia might explicitly expect a dictionary when the backen is using a language different than en_US.

Fastly CDN With Any Magento (Open Source and Commerce On-Premise)

Introduction

Magento generally is not known for the fastest one on the block but this has now changed. Starting from a couple years ago Magento suggested the use of Varnish on production for caching storage and it will significantly increase the speed of your Magento site.

Fastly in addition to its CDN and firewall capabilities, it also includes Varnish functionality. Fastly does mention that it uses Varnish as its core, so it’s basically an advanced and distributed Varnish server. Fastly accelerates the website speed with its CDN networks and caching storage. If Cloudflare is famous for its (free and) fast CDN, Fastly also integrates pretty well with Magento’s full page caching.

We know that Magento Commerce Cloud includes Fastly on its bundle, but now your self-hosted Magento Open source and Magento Commerce sites can also have Fastly. Read more to see how easy it is to configure Fastly for Magento Open Source / Commerce on-premise.

Requirements

Here are the things that you will need to integrate Fastly into self-hosted Magento:

  1. A running Magento 2.3 / 2.4 of Open Source / Commerce On-Premise edition with composer installed
  2. A basic understanding of Magento admin configuration (including cache cleaning)
  3. A registered account on https://www.fastly.com (we tested both free developer trial and paid accounts)
  4. A working Magento 2 Access Key https://marketplace.magento.com/customer/accessKeys/ 
  5. A Fastly Personal API Token with global scope: https://manage.fastly.com/account/personal/tokens 

Extension installation

Installing Fastly’s Magento extension is a straightforward process. Just like any other Magento extensions, you can do the following steps:

  1. Go to https://marketplace.magento.com/fastly-magento2.html 
  2. Select your magento version and checkout:
  3. Now login to your server and go to the root directory of your Magento
  4. Paste the access key in your auth.json file inside your magento install:
  5. Now execute sudo -u www-data composer require fastly/magento (see that I’m using sudo -u www-data to avoid messing with file permission)
  6. Clean magento cache with sudo -u www-data bin/magento cache:flush

Finished! Now you should be able to see Fastly module in Magento admin under Stores – Configuration – Advanced – System – Full Page Cache and you will have a new option called Fastly CDN under Caching Application:

Fastly basic configuration

In order to get your site served by Fastly, you will need to add a new Fastly service and a host. To create a new service, follow these steps:

  1. Login to your Fastly account
  2. Click on Create Service button right on the top right of your dashboard
  3. Insert the domain that you want to use then click Add

To create a new host, do the following:

  1. Click on Origins link on the left sidebar
  2. Insert the host IP address or the hostname, then click Add. Once you have the host configured, then you are ready to do the Magento extension configuration.

Magento extension settings

Once you’ve configured service and host on Fastly, you can go to Stores – Configuration – Advanced – System – Full Page Cache of your Magento admin and you will have a new option called Fastly CDN under Caching Application.

  1. Copy the service ID from your newly-created Fastly service to Fastly Service ID field
  2. Do the same thing for the Fastly API Token (described in the requirement section at the top of this article)
  3. Verify the details by clicking on Test credentials
  4. Save Config – Flush Magento cache
  5. After save, go back to the previous Fastly configuration, then click on Upload VCL to Fastly, tick on Activate VCL after upload, then click Upload
  6. Once again Save Config and Flush Magento cache

Fastly uses VCL for its service configuration. You can always write it by hand, but this Magento extension will do it for you. The only thing that you need to do is make sure to upload VCL after changing any Fastly Configuration.

At this point, Magento should be ready to work with Fastly but you won’t be able to test it until you update your DNS record as explained below.

DNS Configuration

Fastly acts as a proxy for your server. All web requests going to your domain will go through Fastly before actually reaching your server. This way, Fastly can apply firewalls, manipulate requests, filter traffic, and others. In order to do that, you will need to point the domain to Fastly hostname instead of your server directly. 

Fastly has several different hostnames that you can choose depending on your SSL/TLS configuration and/or whether you choose to limit your traffic to a certain network. More details here: https://docs.fastly.com/en/guides/adding-cname-records#choosing-the-right-fastly-hostname-for-your-cname-record

Friendly warning reminder: once you change the DNS, it literally means the traffic will start flowing through the new Fastly service. If you are on production, make sure that everything is good before you switch the DNS.

In short, if you don’t want to use Fastly TLS, then use nonssl.global.fastly.net.

If you need to try Fastly TLS without paying anything, use [name].global.ssl.fastly.net.

And if you already enabled paid account and want to use fully-working fastly TLS, use j.sni.global.fastly.net or k.sni.global.fastly.net.

More details here: https://docs.fastly.com/en/guides/adding-cname-records#tls-enabled-hostnames

Please note that once you change the DNS, it might take some time for the whole internet to propagate your new domain configuration.

If everything goes well, you will be able to start seeing live traffic statistics on your Fastly dashboard. Also, don’t forget that your Magento site is now blazing fast!

Fastly X Magento overview

Overall, we love Fastly. We have been using Cloudflare for our clients and we will also offer Fastly integration for our clients soon. Fastly offers something that Cloudflare doesn’t: seamless Magento integration. Based on our test, Magento running Luma theme can be fully loaded in nearly the blink of an eye. Magento has never been this fast.

Using Fastly is also a timesaver rather than configuring and maintaining your own Varnish server. You probably need to pay at least USD 50 / month for a Fastly paid account while you can build a Varnish server under USD 10 / month, but remember the maintenance cost and all the hassle that you will need to do in the future.

That cost consideration also come in to play when you need to enable something like Image Optimizer. Fastly has it, too and we have confirmed that it is integrated with the Magento extension pretty well.

If you have a need for speed for your high-traffic Magento, go with Fastly. Contact us for assistance and we’re ready to help.