Prestashop: Bad links if installed in subfolder

[mvorisek]

Describe the bug
If PrestaShop is installed in subfolder, some links ignore the subfolder.

To Reproduce
Steps to reproduce the behavior:

1. Install and check left menu in BO
2. some links like "Orders > Orders" are ok, some like "Advanced Parameters > Performance" start with / and ignore installation in subfolder and link to bad location

PS if installed via CLI, the
$_SERVER['REQUEST_URI'] = '/install/index_cli.php';
line in
install-dev/index_cli.php
needs to be updated to
$_SERVER['REQUEST_URI'] = '/SUBFOLDER/install/index_cli.php';
no other change is required.

Additional information
PrestaShop version: 1.7.6.2, 1.6.x is not affected
PHP version: 7.2

[khouloudbelguith]

Hi @mvorisek,

In your BO => Shop Parameters => Traffic & SEO page, what is your exact shop URL configuration?

Thanks!

[mvorisek]

In your BO => Shop Parameters => Traffic & SEO page, what is your exact shop URL configuration?

I can not even open this page, Is there any link with format like: /admin-dev/index.php?controller=?

[mvorisek]

@khouloudbelguith I seached for Base URI in the code, which seems to be related with physical_uri in a twig template.

physical_uri is defined in the database, see:

So it seems like a bug in the backoffice not the settings itself. Can you please verify and fix?

[khouloudbelguith]

@mvorisek, It is ok on my side, I did not manage to reproduce the issue with PS1.7.6.2.
I attached a screen record
https://drive.google.com/file/d/1YKFEgmIM3lKtVBxCYwlCkwRJUmeFZpKp/view
Thanks to check & feedback.

[mvorisek]

@khouloudbelguith Thank you. The issue is presented if PS is run under nginx (on Windows). I have tested it by installing PS on WIndows using wamp and BO is fine. Then I copied the data folder, cleared cache/ folder and served the BO using nginx. Then this issue, ie. bad links, occurs.

I will isolate the problem. The nginx may not set some env. vars which are set by Apache and expected by PS.

[khouloudbelguith]

@mvorisek, This is a config file by default, we provide an example of configuration here:
https://github.com/PrestaShop/PrestaShop/blob/develop/docs/docker/nginx_fpm/prestashop-nginx/prestashop-nginx.conf
It is provided by PrestaShop & you should edit it to be compatible with your server.
For example, you should edit the root: https://github.com/PrestaShop/PrestaShop/blob/develop/docs/docker/nginx_fpm/prestashop-nginx/prestashop-nginx.conf#L5
You should edit the admin folder name
https://github.com/PrestaShop/PrestaShop/blob/develop/docs/docker/nginx_fpm/prestashop-nginx/prestashop-nginx.conf#L56
You must write your own rules as we do for Apache. You must not use a rewrite where you don't need it.
More because it's an example and you can customize this part by everything you want.

Thanks!

[mvorisek]

@khouloudbelguith Thank you, I have identified the issue using that template. The issue was that the env. vars passed by nginx were working for other PHP projects as the projects probably used solely $_SERVER['REQUEST_URI'] variable. But in our particular case nginx passed the full path of a PHP script as a root directory and some $_SERVER variables were different than usual or not even set:

I am closing this issue now as this should be resolved in our nginx dev/Windows configuration.

[khouloudbelguith]

@mvorisek, thanks for your feedback.
Feel free to open a new one when needed.

Thanks!

[mvorisek]

I am reopening this issue as there is another closely related issue.

If you log in thru the web form it directs you to http://localhost/subdir/admin-dev/index.php?controller=AdminDashboard&token=....

But if the index.php is removed, i.e. using server autoindex feature (like: http://localhost/subdir/admin-dev/?controller=AdminDashboard&token=...) the links in the BO change from:

• http://localhost/ps/pslrel18/adminX/index.php/configure/advanced/system-information/?_token=...
  to
• http://localhost/configure/advanced/system-information/?_token=...
  instead of/expected:
• http://localhost/ps/pslrel18/adminX/index.php/configure/advanced/system-information/?_token=...
  or
• http://localhost/ps/pslrel18/adminX/configure/advanced/system-information/?_token=...

Can you please verify on your side too?

Related with: https://github.com/PrestaShop/PrestaShop/issues/16707

[khouloudbelguith]

@mvorisek,
The first URL provided: http://localhost/subdir/admin-dev/index.php?controller=AdminDashboard&token=, it is the URL of the Dashboard page.
I removed the index.php from the URL => the dashboard page is reloaded again with this URL: https://prestashop.tn/ps/ps_17/admin-dev/?controller=AdminDashboard&token=
I navigated to the Information page which has the URL: https://prestashop.tn/ps/ps_17/admin-dev/configure/advanced/system-information/?_token=
About the Information page, it is migrated to Symfony, so, the URL by default of this page is different from the Dashboard page, there is no index.php in the URL.
https://drive.google.com/file/d/10NDib4mj7WG4HCHiH3pxsym-qbi63-8F/view
Thanks!

[khouloudbelguith]

@mvorisek, we should close one of these issues: #16631 & #16707 Thay are similar.
Thanks!

[mvorisek]

@khouloudbelguith Thank you for the videos!

https://github.com/PrestaShop/PrestaShop/issues/16701 is different, it should resolve not adding "index.php" by default (added for example when you log in).

This issue is related with unsual but fully valid server config. Here is complete analysis:

Three different configurations or more precisely env. variables passed from nginx. Only the first one is currently fully working, the 2nd produces 500 error from (entry) adminX/index.php file, the 3rd is working with the index.php in the path, but once it is removed, it does not route correctly.

Notice that all varaibles are fully ok, the issue is only when the request path (URL after host and before query string) does not match the relative path of the entry file. (i.e. web root directory does not match the root in the request URL)

[mvorisek]

So the only problematic variables are:

• DOCUMENT_ROOT, used only in https://github.com/PrestaShop/PrestaShop/blob/33684a3828f66e3a0e91ed53a8239813dcef41dd/classes/helper/HelperOptions.php#L64 and it's usage should be replaced
• PHP_SELF is used on several places
• SCRIPT_NAME is used also on several places

Both PHP_SELF and SCRIPT_NAME variables are (from definition found on the internet) relative to the web server root and therefore they does not need to match the relative request URL part.

[khouloudbelguith]

@mvorisek, thanks for these clarifications.

Notice that all varaibles are fully ok, the issue is only when the request path (URL after host and before query string)

So, how can I reproduce the issue?, in my case, it is OK.

Thanks!

[mvorisek]

@khouloudbelguith see the analysis/image in https://github.com/PrestaShop/PrestaShop/issues/16631#issuecomment-562359088 . For simple test use nginx with PHP CGI, set root and place data in directory like in the analysis.

This issue is presented also on linux, just replace the C: with any linux path.

[khouloudbelguith]

@mvorisek, Here is the PHP info file of my environment
phpinfo().pdf
To reproduce the issue, I need to edit the $_SERVER['DOCUMENT_ROOT'] or all variables in your screenshot
My path is : /var/www/html
Thanks!

[mvorisek]

@khouloudbelguith Edit your nginx config with location matching some subdirectory like /ps/ (see REQUEST_URI in my examples) and have root directive poiting to some subdirectory not names ps.

If you want, you to install PS in var/www/html, copy PS data there, so that the main directory is like var/www/html/prestashop. In nginx setup var/www/html/prestashop as a root and make the eshop accessible under http://host/ps/ and admin under http://host/ps/admin-dev.

[khouloudbelguith]

@mvorisek, so I need to edit the Nginx configuration file?
default.conf.zip
example here: https://github.com/PrestaShop/PrestaShop/blob/develop/docs/server_config/nginx.conf.dist

Thanks!

[mvorisek]

Yes, edit the nginx config to make it working with subdirectory to produce the variables like in the analysis.

I have isolated the issue and it is solely here (I checked every occurence of the problematic variables all PS code plus complete vendor dir):
https://github.com/symfony/symfony/blob/4a9926aa6847c4f578752ef928e5fab6f3acb58c/src/Symfony/Component/HttpFoundation/Request.php#L1766

To replicate/understand this issue simple modify the admin-dev/index.php file, where an instance of the Symfony\Component\HttpFoundation\Request class is created, - add this code:

(\Closure::bind(function() use($request) {
    var_dump($_SERVER['SCRIPT_FILENAME']);
    var_dump($_SERVER['SCRIPT_NAME']);
    var_dump($_SERVER['PHP_SELF']);
    var_dump($this->getRequestUri()); // used in Symfony\Component\HttpFoundation\Request::prepareBaseUrl()
    var_dump($request->getBaseUrl()); // calls Symfony\Component\HttpFoundation\Request::prepareBaseUrl() on the first time
}, $request, \Symfony\Component\HttpFoundation\Request::class))();
exit;

after this line:
https://github.com/PrestaShop/PrestaShop/blob/a2b701a6778189739feaa78d6d8fee5b245f639a/admin-dev/index.php#L80

And here are current results:

• access from view-source:http://localhost/ps/pslrel18/adminX/
string(65) "C:/data/psmigr/ps_dev/pslrel18/adminX/index.php" string(26) "/pslrel18/adminX/index.php" string(26) "/pslrel18/adminX/index.php" string(20) "/ps/pslrel18/adminX/" string(20) "/ps/pslrel18/adminX/" string(0) ""
• access from view-source:http://localhost/ps/pslrel18/adminX/something
string(65) "C:/data/psmigr/ps_dev/pslrel18/adminX/index.php" string(26) "/pslrel18/adminX/index.php" string(26) "/pslrel18/adminX/index.php" string(29) "/ps/pslrel18/adminX/something" string(29) "/ps/pslrel18/adminX/something" string(0) ""
• access from view-source:http://localhost/ps/pslrel18/adminX/index.php
string(65) "C:/data/psmigr/ps_dev/pslrel18/adminX/index.php" string(26) "/pslrel18/adminX/index.php" string(26) "/pslrel18/adminX/index.php" string(29) "/ps/pslrel18/adminX/index.php" string(29) "/ps/pslrel18/adminX/index.php" string(29) "/ps/pslrel18/adminX/index.php"

Currently the Symfony\Component\HttpFoundation\Request class can handle properly only the case when the webserver root is matching the request URL root. Notice the last var_dump in each result.

I will of course reporting this directly to Symfony package. Can you please replicate and do we fix this in PrestaShop?

[mvorisek]

Reported: https://github.com/symfony/symfony/issues/34866

[khouloudbelguith]

@mvorisek,

To replicate/understand this issue simple modify the admin-dev/index.php file, where an instance of the Symfony\Component\HttpFoundation\Request class is created

I have this result:

$_SERVER['SCRIPT_FILENAME'] => string(38) "/var/www/html/1762/admin-dev/index.php"

$_SERVER['SCRIPT_NAME'] => string(25) "/1762/admin-dev/index.php"

$_SERVER['PHP_SELF'] => string(25) "/1762/admin-dev/index.php"

$this->getRequestUri() => string(90) "/1762/admin-dev/index.php?controller=AdminDashboard&token=1ba90d0ef1108de463be6d26b3f806e8"

$request->getBaseUrl() => string(25) "/1762/admin-dev/index.php"

Aldo, when using this test var_export($_SERVER);
I have this output
array ( 'HOME' => '/var/cache/nginx', 'PHP_MD5' => '', 'DEV_USERNAME' => '', 'PHP_URL' => 'https://secure.php.net/get/php-7.2.10.tar.xz/from/this/mirror', 'SUPERVISOR_GROUP_NAME' => 'php-fpm', 'GPG_KEYS' => '1729F83938DA44E27BA0F4D3DBDB397470D12172 B1B44D8F021E4E2D6021E995DC9FF8D3EE5AF27F', 'PATH' => '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin', 'SUPERVISOR_SERVER_URL' => 'unix:///dev/shm/supervisor.sock', 'LUAJIT_INC' => '/usr/include/luajit-2.1', 'SHLVL' => '0', 'SUPERVISOR_ENABLED' => '1', 'PHP_CPPFLAGS' => '-fstack-protector-strong -fpic -fpie -O2', 'PHP_SHA256' => '01c2154a3a8e3c0818acbdbc1a956832c828a0380ce6d1d14fea495ea21804f0', 'PHP_VERSION' => '7.2.10', 'NGINX_VERSION' => '1.14.0', 'LUA_MODULE_VERSION' => '0.10.13', 'LUAJIT_LIB' => '/usr/lib', 'php_conf' => '/usr/local/etc/php-fpm.conf', 'fpm_conf' => '/usr/local/etc/php-fpm.d/www.conf', 'SUPERVISOR_PROCESS_NAME' => 'php-fpm', 'DEVEL_KIT_MODULE_VERSION' => '0.3.0', 'PHP_INI_DIR' => '/usr/local/etc/php', 'LD_PRELOAD' => '/usr/lib/preloadable_libiconv.so php', 'PHP_CFLAGS' => '-fstack-protector-strong -fpic -fpie -O2', 'PHP_EXTRA_CONFIGURE_ARGS' => '--enable-fpm --with-fpm-user=www-data --with-fpm-group=www-data --disable-cgi', 'PHPIZE_DEPS' => 'autoconf dpkg-dev dpkg file g++ gcc libc-dev make pkgconf re2c', 'HOSTNAME' => 'd3a3dba23d65', 'PWD' => '/var/www/html', 'php_vars' => '/usr/local/etc/php/conf.d/docker-vars.ini', 'PHP_LDFLAGS' => '-Wl,-O1 -Wl,--hash-style=both -pie', 'PHP_ASC_URL' => 'https://secure.php.net/get/php-7.2.10.tar.xz.asc/from/this/mirror', 'USER' => 'nginx', 'HTTP_COOKIE' => 'PrestaShop-1bcb9bce465d8c9b19555e8a4a269bd1=def502007707c5e805fa8042f5f1b8615a40f4fb8ba3e6268bc90520b802381eb9f8fb4ca85d5876ba9eff8a107d4777993669659f37412438fa37efb95dbc10149ce89536f65b325f09a5f5c104cbe5d09cda02656cdec8bcffc61407bb4297ccae655026d4cdb1c07279ea8f589db2fb3fec30dd74e201ad600d30c1e834fae33090b12435bea3c78632da8dcc8941fcf6f5fb063075db126fce0b7962a5f7df34b247e6eb55bf4d4f4e14a771f0742511290d5ca722832ff19b815ae6e53f4ae10e4a1aeb0a4c7db40e8330460bc93c40f54d52a0fe38210a5e712852b912a8ed53b37a930b995da9827a2aeedc57c7c59f275a3989b139a47488a83aabac556a3005fdf257a9678eb108cf4626bf6245a632f5992d7f087a51c10de3a1bec9af807d0b703ed4a36354def0fd741d3c3f192b0d4384f3cb0a619acc99af357750e8e8ee; PHPSESSID=738599b74fdf30f71470fd1a91e9f102', 'HTTP_ACCEPT_LANGUAGE' => 'en,fr-FR;q=0.9,fr;q=0.8,it;q=0.7,ar;q=0.6,en-US;q=0.5,ca;q=0.4', 'HTTP_ACCEPT_ENCODING' => 'gzip, deflate', 'HTTP_ACCEPT' => 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3', 'HTTP_USER_AGENT' => 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36', 'HTTP_UPGRADE_INSECURE_REQUESTS' => '1', 'HTTP_CACHE_CONTROL' => 'max-age=0', 'HTTP_CONNECTION' => 'keep-alive', 'HTTP_HOST' => '0.0.0.0:8081', 'REDIRECT_STATUS' => '200', 'SERVER_NAME' => 'prestashop.com', 'SERVER_PORT' => '80', 'SERVER_ADDR' => '10.1.38.3', 'REMOTE_PORT' => '57675', 'REMOTE_ADDR' => '10.1.38.1', 'SERVER_SOFTWARE' => 'nginx/1.14.0', 'GATEWAY_INTERFACE' => 'CGI/1.1', 'REQUEST_SCHEME' => 'http', 'SERVER_PROTOCOL' => 'HTTP/1.1', 'DOCUMENT_ROOT' => '/var/www/html', 'DOCUMENT_URI' => '/1762/admin-dev/index.php', 'REQUEST_URI' => '/1762/admin-dev/index.php?controller=AdminLogin&token=31da87a5ab20f205aec4e9faec918d57', 'CONTENT_LENGTH' => '', 'CONTENT_TYPE' => '', 'REQUEST_METHOD' => 'GET', 'QUERY_STRING' => 'controller=AdminLogin&token=31da87a5ab20f205aec4e9faec918d57', 'SCRIPT_NAME' => '/1762/admin-dev/index.php', 'SCRIPT_FILENAME' => '/var/www/html/1762/admin-dev/index.php', 'FCGI_ROLE' => 'RESPONDER', 'PHP_SELF' => '/1762/admin-dev/index.php', 'REQUEST_TIME_FLOAT' => 1576062492.591545, 'REQUEST_TIME' => 1576062492, 'argv' => array ( 0 => 'controller=AdminLogin&token=31da87a5ab20f205aec4e9faec918d57', ), 'argc' => 1, )
But it seems ok
https://drive.google.com/file/d/12SqJmcSgsoalfXV_QvU7QONjk4nLwBlh/view
I edited my /etc/nginx/sites-available/default.conf file like this

# pass the PHP scripts to FastCGI server listening on socket
        #
        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php-fpm.sock;
                fastcgi_param SCRIPT_FILENAME /var/www/html/1762/admin-dev/index.php;
                fastcgi_param SCRIPT_NAME /1762/admin-dev/index.php;
                fastcgi_index index.php;
                include fastcgi_params;
        }

Thanks to check & feedback.

[mvorisek]

But your server root is matching the request root.

Change your config to serve PrestaShop under scheme://host/test/ from root /var/www/html/1762/
.

The variables should be then like:

$_SERVER['SCRIPT_FILENAME'] => string(38) "/var/www/html/1762/admin-dev/index.php"
$_SERVER['SCRIPT_NAME'] => string(25) "/admin-dev/index.php"
$_SERVER['PHP_SELF'] => string(25) "/admin-dev/index.php"

Notice:

• request URL path "/test/" is not longer matching the PrestaShop folder name
• the missing 1762/ in the SCRIPT_NAME and PHP_SELF, these paths are relative to the web server root, not the request URL (by CGI definition)

[khouloudbelguith]

@mvorisek, Could you confirm this error?
edited my /etc/nginx/sites-available/default.conf file like this

# pass the PHP scripts to FastCGI server listening on socket
        #
        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php-fpm.sock;
                fastcgi_param SCRIPT_FILENAME /var/www/html/1762/test/admin-dev/index.php;
                fastcgi_param SCRIPT_NAME /1762/test/admin-dev/index.php;
                fastcgi_index index.php;
                include fastcgi_params;
        }

When I navigate to the BO => Advanced Parameters => Performances
I have this error

https://drive.google.com/file/d/1UKD-XgCyq92VhFTVMil5CeRm30Uue-c8/view

Thanks!

[mvorisek]

Yes and I already reported and provided a PR to Symfony. I expect they will merge the PR in the next 3.4.x build/release. This issue should wait until the PR in Symfony is merged and then a PR to update the composer.lock of this project should be submitted.

[khouloudbelguith]

@mvorisek, thanks for your feedback.
I have the same issue with PS1.7.5.2.
Ping @matks, @PrestaShop/prestashop-core-developers what do you think of this error: https://github.com/PrestaShop/PrestaShop/issues/16631#issuecomment-564602008

Thanks!

[matks]

Reported: symfony/symfony#34866

Thanks for doing this 👍

@khouloudbelguith as @mvorisek said this is likely to be an issue on Symfony. Once Symfony is updated we should use the latest version and the bug will be gone without any modification of prestashop code