Skip to main content

Magento

Magento 1

This page is based on the Magento 2 configuration, but many of the settings should have an equivalent setting in Magento 1.

Magento and Clonable work perfectly together. To make the integration even smoother, we recommend using our Magento extension.

Ghost Stores​

Magento and Clonable integrate through a so-called "Ghost Store". A Ghost Store is essentially an untranslated store view that you let Clonable translate. This means that, for example, for Germany, you create a new store view but keep the content in Dutch. This provides flexibility to configure a language in the Magento backend without having to manually translate the content.

What Clonable does​

Clonable handles everything related to frontend translations, meaning everything a visitor can see on the website, such as:

  • All texts
  • URLs
  • SEO data

What Magento does​

Magento remains responsible for managing the store view and for backend translations that Clonable cannot access. These include:

  • Email translations
  • Managing products and categories for specific countries
  • Other language-specific logic

Store View Configuration​

Configuring a Ghost Store is quite simple, you do it the same way you would normally add a new store view. It’s important, however, to correctly set up the web configuration for the store view. The most important thing is that the base URLs of the store view are correct. For a new domain or subdomain, this simply becomes the new domain for your foreign store view.

For subfolders, it’s important to add the subfolder to the Base URLs. Magento can also automatically add a Store Code to URLs. If you have this option enabled, make sure that the Base URLs in the store view match those in your Default Config. Add Store Code to Urls setting

Store View Proxy​

For a Ghost Store to function correctly, a proxy needs to be configured. Depending on the type of clone you have, there are two possible setup options.

New Domain or Subdomain​

If your new language version is hosted on a new domain or subdomain, you only need to configure the DNS settings.
You can follow Clonable’s standard DNS setup instructions for this.

Subfolder Configuration​

Setting up a subfolder clone is slightly more complex and requires access to the NGINX configuration of your Magento website.

To ensure that Clonable can translate the subfolder (for example /it/), it’s important to correctly forward incoming traffic for that subfolder to Clonable.

What to change below​

Your configuration may differ

Below is an example of an NGINX configuration for a subfolder. Your website’s configuration may look slightly different (for example, split across multiple files), but generally it should be quite similar.

You likely already have an existing NGINX configuration for your website, so you only need to add the Clonable configuration to it.
In the example below, the blocks you’ll need are highlighted.

Replace the following values in the example:

  • /it/ → your clone’s subfolder (for example /en/ for English)
  • magento.testshops.nl → your website’s hostname (include www. if your site uses it)
upstream fastcgi_backend {
    server  unix:/run/php/php8.1-fpm-magento.sock;
}

upstream upstream_clonable {
    # server 89.41.171.180:443; # Uncomment this line and comment the next line to use IPv4 instead of IPv6
    server [2a01:7c8:e001:d9:0:0:0:e778]:443;
    keepalive 8;
}

server {
    listen 443 ssl http2;
    server_name magento.testshops.nl;

    ssl_certificate /etc/letsencrypt/live/magento.testshops.nl/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/magento.testshops.nl/privkey.pem;
    set $MAGE_ROOT /home/magento/magento2/;
    include /home/magento/magento2/nginx.conf;
    
    ################## ~!README!~ #######################
    # Add the location blocks below together with the upstream block to your
    # own NGINX configuration. Do not copy the lines above, similar lines should already
    # be present in your own configuration. We also recommend adding Clonable-Clone-Subfolder
    # to your Vary header to prevent caching issues. This template is to be used for reference.
    # Please read the comments carefully and make changes if necessary.
    #####################################################


    # Static HTML and JSON files may need to be translated, so we should route
    # them via Clonable

    location ~ ^/it/static/.*\.(html|json)$ {
        if ($http_clonable_request_id = "") {
            rewrite ^(.*)$ /clonable$1 last;
        }

        # Let the default /static/ handler handle these requests.
        # Note: if the static folder is always served from the subfolder, or if there is no subfolder,
        # remove the line below and replace it with the content from that block.
        rewrite ^/it/(.*)$ /$1 last;
    }

    # Normal static content can be served directly.
    # If some content does need to be processed (eg substitution rules), add the file
    # to the location block above in the regex.
    # Note: if the static folder is always served from the subfolder, or if there is no subfolder,
    # do not include the block below, but instead use the already existing block for this location.
    location /it/static/ {
        rewrite ^/it/(.*)$ /$1 last;
    }

    # This location block intercepts requests to the chosen subfolder, adjust if necessary
    location /it/ {
        # Check if this request is coming from clonable. If not, forward to Clonable. Otherwise, handle normally.
        if ($http_clonable_request_id = "") {
            rewrite ^(.*)$ /clonable$1 last;
        }

        # Match the content below with the default behaviour in your location block for the
        # root (/). The line below is taken from the default NGINX configuration, but may be
        # different if NGINX is set up as a reverse proxy. In case you are also using Varnish,
        # be sure to also read the chapter about Varnish.
        try_files $uri $uri/ /index.php$is_args$args;
    }

    # This location block is used to forward requests to Clonable
    location /clonable/ {
        internal;  # Prevents outside access
        rewrite ^/clonable(.*) $1 break; # Remove clonable prefix before proxying

        # SNI
        proxy_ssl_server_name on;
        proxy_ssl_name magento.testshops.nl;
        proxy_set_header Host magento.testshops.nl;
        # Use http 1.1 for proxy connections
        proxy_http_version 1.1;
        # SSL protocols for upstream connections
        proxy_ssl_protocols TLSv1.2 TLSv1.3;
        proxy_pass https://upstream_clonable;
        # Increase default buffer sizes;
        proxy_buffer_size          128k;
        proxy_buffers              4 256k;
        proxy_busy_buffers_size    256k;
    }
    
}

Validate the Proxy Connection​

If you’ve configured the proxy correctly, you should see the clonable-{header_name} headers in the response. These indicate which Clonable server is being used and what language the site should display in.

Clonable HTTP headers example

For subfolder configuration​

For subfolder clones, it’s important to verify that the URL path matches the clonable-original-path. In the example below, the URL: magento.testshops.nl/de/ matches the clonable-original-path header.

If the value of clonable-original-path is just a slash (/), it means Clonable is translating content from the wrong store view. This means there’s an error in your subfolder configuration or in the web settings of your store view.

Store View and Content Validation​

It might look like the proxy is working correctly, but if all subpages redirect to your website’s homepage, Magento is likely returning a 404. This usually happens when Magento doesn’t correctly recognize where the store view is configured — in other words, the store view isn’t properly set up in Magento.

Last updated on