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.

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.

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/app-bridge@2“></script>

Referencing to app-bridge@2 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. 

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. 

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.

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:

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: