Jump to content

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

ramazza

By ramazza
in Configuring and using PrestaShop

 Share

Recommended Posts

ramazza Rookie

ramazza

Posted
Posted

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

Link to comment
Share on other sites
ramazza Rookie

ramazza

Posted
  • Author
Posted

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/

 


 

 

Screenshot_20231021_162747.png

.htaccess

Link to comment
Share on other sites
Zohaib-fk Proficient

Zohaib-fk

Posted
Posted

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/

 

Link to comment
Share on other sites
ramazza Rookie

ramazza

Posted
  • Author
Posted
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. 
 

Link to comment
Share on other sites
Zohaib-fk Proficient

Zohaib-fk

Posted
Posted

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.

 

hghfghfgghfgh.png

Link to comment
Share on other sites
ramazza Rookie

ramazza

Posted
  • Author
Posted
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.

 

hghfghfgghfgh.png

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. 

shop_url.png

Link to comment
Share on other sites
ps8modules Grand Master

ps8modules

Posted
Posted

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.

Link to comment
Share on other sites
ramazza Rookie

ramazza

Posted
  • Author
Posted
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. 

Link to comment
Share on other sites
ramazza Rookie

ramazza

Posted
  • Author
Posted

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. 

Link to comment
Share on other sites
ramazza Rookie

ramazza

Posted
  • Author
Posted
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. 

Link to comment
Share on other sites
  • 1 month later...
ramazza Rookie

ramazza

Posted
  • Author
Posted

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. 

  • Like 1
Link to comment
Share on other sites
  • 10 months later...
simbus82 Newbie

simbus82

Posted
Posted
On 12/9/2023 at 1:59 PM, musicmaster said:

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.

It’s actually quite common for a multistore setup to have different price listings or sub-stores, especially when multiple languages are needed per store. In this case, it’s essential to achieve URLs structured like this:

  • www.mysite1.com/it/it
  • www.mysite1.com/it/en
  • www.mysite1.com/it/de
  • www.mysite1.com/us/it
  • www.mysite1.com/us/en
  • www.mysite1.com/us/fr

 

  • www.mysite2.com/it/it
  • www.mysite2.com/it/en
  • www.mysite2.com/it/de
  • www.mysite2.com/us/it
  • www.mysite2.com/us/en
  • www.mysite2.com/us/fr

(format: site/store/language, same PS Backoffice)

Removing the virtual_uri from the default website disrupts this ideal URL structure, which is crucial for SEO.

I’m facing the same issue and am working to reopen a related issue on GitHub: GitHub Issue #34793.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...