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.

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.

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.

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

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.

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.

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.

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

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

In my case I have added a new layout using modern as a base and replacing all path to new folder. It looked the cleanest way to deal with updates. I can regenerate mail templates with the new layout but I cannot see the new strings in the translation interface. I'm unsing prestashop 8.1 on php 8.2 and linux apache server in developer mode -> true. I have tried to clean all the possible caches and refresh translations catalogs, with no luck.

HI, I got the same problem on my multistore. I can edit the product name only for indivudual store and not for All Shops. the product name field is marked as disabled. Any solution?

I had the same problem. My error was caused by a different shop url in the configuration SEO &URL : shop url domain.com SSL url www.domain.com I have put the same url without www I'm not an expert but it might help someone..