Trying to setup cs-cart on cloudpanel. It's an NGINX control panel. Any Vhost Ideas?


I’m trying to setup cs-cart (rather move it from cpanel) on an NGINX control panel.
As I moved the site from Cpanel (apache) I realised that most files on cs-cart actually are placed on various places and are being redirected to root. For example favicon.ico and I suppose all other files.

I suppose .htaccess took care of that in cpanel but how do I make that in NGINX?

I have a vhost file that is something like that:

server {
  listen 80;
  listen [::]:80;
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  return 301$request_uri;

server {
  listen 80;
  listen [::]:80;
  listen 443 ssl http2;
  listen [::]:443 ssl http2;


  if ($scheme != "https") {
    rewrite ^ https://$host$uri permanent;

  location ~ /.well-known {
    auth_basic off;
    allow all;


  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_hide_header X-Varnish;
    proxy_redirect off;
    proxy_max_temp_file_size 0;
    proxy_connect_timeout      720;
    proxy_send_timeout         720;
    proxy_read_timeout         720;
    proxy_buffer_size          128k;
    proxy_buffers              4 256k;
    proxy_busy_buffers_size    256k;
    proxy_temp_file_write_size 256k;

  location ~* ^.+\.(css|js|jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|woff2|eot|mp4|ogg|ogv|webm|webp|zip|swf|map)$ {
    add_header Access-Control-Allow-Origin "*";
    expires max;
    access_log off;

  if (-f $request_filename) {

server {
  listen 8080;
  listen [::]:8080;

  try_files $uri $uri/ /index.php?$args;
  index index.php index.html;

  location ~ \.php$ {
    include fastcgi_params;
    fastcgi_intercept_errors on;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    try_files $uri =404;
    fastcgi_read_timeout 3600;
    fastcgi_send_timeout 3600;
    fastcgi_param HTTPS "on";
    fastcgi_param SERVER_PORT 443;
    fastcgi_param PHP_VALUE "{{php_settings}}";

  if (-f $request_filename) {

Ok so that doen’t work. I suppose nothing is supported in this config. What do I need to add to that vhost to make the cs-cart installation work?


Please take a look at the nginx configuration in the following article:


I’ve seen that article. I suppose I need to merge those configurations.

However, in the mean time, I did another thing… I installed a test version of cs-cart to see what error might come up during installation. I installed it on the same server I’m trying to migrate to that uses nginx instead of apache.

I did get a warning:
The URL rewrite engine is disabled. Subpath-based storefront URLs will not work
But that did not cause any more issues and installation went through just fine.

After that, the cs-cart installation took me to administrator where I could log in and everything proceeded as planned. I can see the storefront, backend, items… no issues whatsoever.

So… it seems that the nginx config I have is ok. cs-cart can run on it.
Why am I facing the issue when moving over a site from Apache to nginx?

I got a suggestion that there are referrences in the database that require some htaccess referrals.
On the php log however it’s packed with access denied errors. It doesn’t seem to be unable to find files. There are warnings that access is denied on several points in the php files, and there is also an error like so:

TypeError: Tygh\Storefront\RelationsManager::__construct(): Argument #3 ($schema) must be of type array, bool given, called in /home/site/htdocs/ on line 136 and defined in /home/site/htdocs/

That error does explain the issue. Im new to php and cs cart. But am a dev and programmer. That is a type error, data types…and it says in that line of php it should be an array data type and looks like a boolean has has been used instead.

Oh thank you for replying.

I too am a php programmer. I know what that error means but my point is why does it pop up?
It shouldn’t! The site works flawlesly on the apache server and once I pack it up and migrate it over to the nginx server, this error pops up.

It makes no sense for a php code to produce an array on one server and a boolean (problably unset) construct on another. I changed no code and migrated the database 1 to 1. Why would that pop up?

Ok… lets elaborate on this…

Since the level of debugging is exactly that… I’ll try to see if I can interpret the issue based on the data given.

So this construct: RelationsManager of type __construct is defined in app/Tygh/Storefront/RelationsManager.php with the following function:

public function __construct(Connection $db, $name_resolver, array $schema = [])
    $this->db = $db;
    $this->name_resolver = $name_resolver;
    $this->schema = $schema;

See there? It takes data from the $db

It’s then called here in app/Tygh/Providers/StorefrontProvider.php in the following function:

$app['storefront.relations_manager'] = function (Container $app) {
    return new RelationsManager(

and should return an array, but it’s bool (probably false)

Well… if connection with the db is not done properly… then… RelationsManager might actually return something erratic like false or whatever…

Would that be an indication that connection to the db is not done properly?

That would explain all those access denied warnings as well (I haven’t posted them here… they are like 70 such warnings per visit!)

Sorry yes i didn’t mean to sound “knowledgeable” I was just thinking reading that error explicitly.

My guess would be along the same lines as yours tbh on db connection. Can you test the connection what connection error if any does it get?
Can you use postman with cs-c? To test what is returned?


Don’t worry you sound polite and helpful. Please don’t think I took any offence. I simply introduced myself.

I ran a couple of tests, like changing passwords and using wrong ones on the old server and similar errors popped up but not the same. That could be of course normal since they do have different cores. I cannot tell if the db is connecting to the website on the new server though.

My tesing still has inconclusive results so I need to test a bit more and come back tomorrow.
I have a few things in mind I can try and will update this thread accordingly.

1 Like

Ok I ran some tests… First of all let me tell you that there is no issue accessing the database. That’s out of the way. When I use incorrect database connection data, I get a pretty clear “cannot connect to database” error in the php error log and nothing more. So the errors I get are totally from trying to access the site and I keep hitting some kind of wall…

So I dove into the actual error log. I cleared it and made one single attempt to visit the home page.

The error log was 40k long…
I only contained 2 errors.
One error was repeated 128 times and was the following:

PHP Warning:  include(): Failed opening '/home/example/public_html/app/addons/store_locator/schemas/sharing/' for inclusion (include_path='/home/example-new/htdocs/') in /home/example-new/htdocs/ on line 2471

See that? That’s repeated 128 times and tries to refer a file in /home/example/public_html/... somewhere. However the home folder structure in my new server is not .../public_html/... but rather: /home/example-new/htdocs/

But where does it take all those references? those 128 hits are the same error for the same line in app/functions/fn.common.php (line 2471) where the code is:

foreach (Registry::get($cache_key) as $file) {
        if ($type == 'php') {
            $schema = $include_once ? include_once($file) : include($file);
        } else {
            $schema .= file_get_contents($file);

Some sort of cache pulling function from a cache registry. It seems though that this registry is fixed on old referrences.

Maybe resetting this registry?

Or finding out where all those old home folder references are stored?

The second error is the TypeError I’ve mentioned before:

Here it is:

TypeError: Tygh\Storefront\RelationsManager::__construct(): Argument #3 ($schema) must be of type array, bool given, called in /home/example-new/htdocs/ on line 136 and defined in /home/example-new/htdocs/

That one appears only once per visit and I have the code in my previous post for both RelationsManager.php:47 and StorefrontProvider.php on line 136.

So that’s it. Two errors. Albeit one appears 128 times, it’s basically one error.

Anyone who might have encountered that before and can help I would really appreciate it.

aaaaand Found it!

Sorry for that! Really excited to have found the issue. So here it is:

It seems that there are a lot of referrences to the absolute path of the home folder in various php files in cs-cart. Mainly these are referrences in cached php files (i.e. in locations like /var/cache/...

In my case there were more than 1000 references to the old home location.
So I ran the following in terminal:

grep -Ril "home/example/public_html" /home/example-new/htdocs/ > ~/backups/20240129_grep_log_before.txt | grep -Ril "home/example/public_html" /home/example-new/htdocs/ | xargs sed -it "s+home/example/public_html+home/example-new/htdocs/" | grep -Ril "home/example/public_html" /home/example-new/htdocs/ > ~/backups/20240129_grep_log_after.txt

What the script above does

  1. It lists all files that an occurence of home/example/public_html. That’s the old absolute path of the home folder. It saves that list into a txt file in the backup folder as a referrence.
  2. It then lists the same files again and uses sed to replace the occurences of the old folder to the new one.
  3. Finally it makes a new txt file which should be empty if all occurences have been replaced.

Please if you need to migrate, make sure you use that line of terminal commands at your own risk. Also please make sure that you have a backup ready in case that this command corrups … something.
Furthermore, after the control panel is available again, please clean all cache files and thumbnails from the admin interface.

If you also migrate to a new url, make sure to change it in the admin interface so that you won’t be redirected to the old homepage url.

Hi! Sorry I didn’t get to this topic sooner, unfortunately I haven’t had much time to visit the forum over the last week.

There is no need to manually change the cache. If for some reason the path to the installation changes, you’ll need to delete the cache from your installation, or even not copy the var/cache folder at all.

Or… yeah do that, as I did on my next migration.

I was not aware of how the cache works when I made the first move. Since I only had the backup and not the old installation available I had to go that route to avoid messing up references. It seems that one of two solutions is the best:

  1. Before moving the site, first close the storefront, and immediately clear cache and thumbnails. That way, even if you move the cache folder, it will be empty. Then make a backup and move that one.

  2. Another solution is to not move the /var/cache folder. It seems that nothing breaks if cs-cart does not detect it. It will just create a new one.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.