No input file specified. Backoffice url prefix is not working.

[ramazza]

Hi, With my configuration of the production server there is a problem with the multishop prefix on the backoffice area. I have 4 stores in the multishop.  

The production server has a php8.1.21, linux server configured with all the advised php.ini values. Prestashop 8.1.1. Friendly URL on (if OFF everything works) 

Some pages on the backoffice works with /it/admin6dmi8eow3ikei9b23 and some others always give me "No input file specified" error. 
If I remove the /it prefix all pages work. 

The same code in my localhost with php 8.2 works in both cases (with or without /it/admin).

I have noticed that the backoffice menu has some link with /it/ and some other without. But after it's added in the navigation the other pages goes in error. 

I have regenerated the htaccess already, but I have no idea about what should I check now! 

Thanks in advance

[musicmaster]

The backoffice does not use language prefixes. So I am puzzled that you see some links there that have them. These are obviously bugs. You should provide more information about them.

 

Edited October 20, 2023 by musicmaster (see edit history)

[ramazza]

Some links of the Admin menu have it/ Ex: Shipping (with):  arpel.local/it/admin630thdmi8eow3ikei9b/index.php?controller=AdminCarriers&token=...

Design (without): arpel.local/admin630thdmi8eow3ikei9b/index.php/improve/design/themes/?_token=p4V...

I have a multistore setup (I have attached the shop_url table).  It must me related to the multistore since I'm currently in EN language on the backoffice while the prefix is it/ (which is the the first multistore). 

I have noticed that the virtual url is defined for all the shops (because I need it). This is definetly the reason because of this behaviour. If I delete the the virtual_uri from the first shop (leave it ""), the admin menu goes back to all clean from prefix. 

I don't know if this a bug or I have to leave a shop without prefix.. ??? I would actually like all the multistore with prefix like it was in the prev version 1.6 https://arpel.eu/

 

 

 

.htaccess

[musicmaster]

This is the first time ever that I have seen someone use the virtual_uri field. Given that it is so seldom used I wouldn't be astonished if it contained some bugs.

So I cannot help you with this. I would suggest fielding an error report for that backoffice carrier page in the Prestashop Github.

[Zohaib-fk]

Hi,

The language code is designed to work in the front office, therefore, it will not work in the back office even if we make the changes in a database table or htaccess, it will give errors. We can choose different languages from employee management in the back office and see menus, and fields in different languages.

Also, there is an option in the back office to switch to different shops and respective domains to manage multiple shops with multiple domains.

Below are the documentation links for your reference.

https://docs.prestashop-project.org/1.7-documentation/user-guide/managing-multiple-stores

https://devdocs.prestashop-project.org/8/development/multistore/

 

[ramazza]

On 10/21/2023 at 9:51 PM, Zohaib-fk said:

Hi,

The language code is designed to work in the front office, therefore, it will not work in the back office even if we make the changes in a database table or htaccess, it will give errors. We can choose different languages from employee management in the back office and see menus, and fields in different languages.

Also, there is an option in the back office to switch to different shops and respective domains to manage multiple shops with multiple domains.

Below are the documentation links for your reference.

https://docs.prestashop-project.org/1.7-documentation/user-guide/managing-multiple-stores

https://devdocs.prestashop-project.org/8/development/multistore/

 

This is not the case, the prefix is using probably come from the virtual url table used in the multishop configuration. If I remove the first shop record "virtual_uri", the backoffice start to work correctly. 

I have solved with a an .htaccess redirect, but of course it's not a solution. 
 

[Zohaib-fk]

It's good to know you got the solution as per your requirements using the .htaccess redirect.

I tried to find any table name or record using the keyword "virtual_uri" in the database but I could not find anything.

Attached screenshot for your reference.

 

[ramazza]

1 hour ago, Zohaib-fk said:

It's good to know you got the solution as per your requirements using the .htaccess redirect.

I tried to find any table name or record using the keyword "virtual_uri" in the database but I could not find anything.

Attached screenshot for your reference.

 

You can find the virtual_uri field in the ps_shop_url table (with multishop configuration). I have attached the screenshot of my configuration. 
Looks like if you set a virtual uri for all the shops, the admin links take in some cases the first virtual_uri of the this table records. 

[Zohaib-fk]

Thanks for the screenshot. I think there must be documentation about the use of the column name "virtual_uri". How it works, where to use it and some other information.

[ps8modules.com]

hi
It can be done simply with a module.
Just use the displayAdminLogin hook and on the login page to the administration, add the list of stores you want to log in to and set the language of the administration.
As already written here, the virtual_uri field is valid for the front office.

[ramazza]

7 minutes ago, ps8moduly.cz said:

hi
It can be done simply with a module.
Just use the displayAdminLogin hook and on the login page to the administration, add the list of stores you want to log in to and set the language of the administration.
As already written here, the virtual_uri field is valid for the front office.

I don't want to use any prefix for the backoffice. I'm reporting the fact that a standard 8.1 installation with multishop and virtual_uri for the frontend has problems in the backoffice. 

[ps8modules.com]

[musicmaster]

Does your shop have overrides?

[ramazza]

55 minutes ago, musicmaster said:

Does your shop have overrides?

no, it's the same on the fresh installation with multishop and virtual uri setted for all the shops

 

[musicmaster]

What is a "fresh installation"? No extra modules? Not even carrier modules?

[ramazza]

Just standard modules like ps_languageselector, ps_customeraccoutlinks, ps_bestseller, and other standard ones. But nothing that can be related with the backoffice link creation on the standard admin menu.

The fact is the adminCarrier and the adminCustomerThreads links in the backoffice menu have the first virtual_uri of the ps_shop_url table as  prefix:

http://localhost/prestashop/it/admin811inc0yorxte25a2sc/index.php?controller=AdminCarts&token=d901e3...

It must be related with the way these link are generated comparing to the other ones that have a sort of a SEF address:     http://localhost/prestashop/admin811inc0yorxte25a2sc/index.php/sell/orders/credit-slips/?_token=MNi...

For SEF address the problems don't appear, while for standard old style &controller=... the prefix is added. 

[musicmaster]

What is SEF address?

[ramazza]

6 minutes ago, musicmaster said:

What is SEF address?

All not working links are on the style=> /index.php?controller=AdminCarts&token=d901e3... 

While the one that works (without prefix) are on the style index.php/sell/orders/credit-slips/?_token=MNi...

I mean for SEF that has the /sell/orders/ part instead of normal GET variables. Those part are processed by a router somewhere, they are not simply url variables. 
Sorry for my english is it wasn't clear. 

[musicmaster]

I would need access or a copy of the database to check this out. You can pm me if you want.

[ramazza]

Hi @musicmaster.
I'm now having serious trouble with my shop prestashop 8.1.1.
I have the table ps_shop_url with 4 shops with different virtual_uri setted.
In the standard ps_mainmenu module (just as an example) the from creation create an action link:

line 1114  $helper->currentIndex = $this->context->link->getAdminLink('AdminModules', false) .
            '&configure=' . $this->name . '&tab_module=' . $this->tab . '&module_name=' . $this->name;

This call classes/Link  ->getAdminBaseLink() 

line 938 return $base.$shop->getBaseURI();

in the classes/shop/Shop class  the function is defined in this way

public function getBaseURI()
    {
        return $this->physical_uri . $this->virtual_uri;
    }

which, of course, contains virtual_uri. BUT it should not contain it for admin links (correct??).

 I'm experimenting this modifcation of the main classes/Link line 911  

 public function getAdminBaseLink($idShop = null, $ssl = null, $relativeProtocol = false)
    {
        if (null === $ssl) {
            $ssl = Configuration::get('PS_SSL_ENABLED') && Configuration::get('PS_SSL_ENABLED_EVERYWHERE');
        }

        if (Configuration::get('PS_MULTISHOP_FEATURE_ACTIVE')) {
            if (null === $idShop) {
                $idShop = $this->getMatchingUrlShopId();
            }

            //Use the matching shop if present, or fallback on the default one
            if (null !== $idShop) {
                $shop = new Shop($idShop);
            } else {
                $shop = new Shop((int) Configuration::get('PS_SHOP_DEFAULT'));
            }
        } else {
            $shop = Context::getContext()->shop;
        }

        if ($relativeProtocol) {
            $base = '//' . ($ssl && $this->ssl_enable ? $shop->domain_ssl : $shop->domain);
        } else {
            $base = (($ssl && $this->ssl_enable) ? 'https://' . $shop->domain_ssl : 'http://' . $shop->domain);
        }

        return $base.'/';     //REMOVED: . $shop->getBaseURI();
    }

So far it's working. 

[musicmaster]

That seems a logical solution. As far as I understand you are quite unusual in  having some virtual_uri for all shop. In most cases the first shop - that is also used for the backoffice - has no virtual_uri and the other shops have. And then the problem doesn't arise.