Pete78

$this->_select .= 'sa.quantity as qty'; $this->fields_list = array( ... 'qty' => array( 'title' => $this->l('Quantity'), 'filter_key' => 'a!quantity' ), ... should help...

I solved it with forcing the cache of available carrier list to be flushed. Means: Go to "AdminCartControll.php" and to function getDeliveryOptionList() getDeliveryOptionList() Find row (about 708) $delivery_option_list = $this->context->cart->getDeliveryOptionList(); and replace it with $delivery_option_list = $this->context->cart->getDeliveryOptionList(null,true); If that helps, there might be a bug and need further investigation. Problem occured when "free shipping" was added.

Hi, check this. https://github.com/PrestaShop/PrestaShop/pull/26791

Hi, vielleicht lässt du dir mal ausgeben, was in $params drinnen steht. Das sollte weiterhelfen.

Sorry, wenn ich das uralte Thema hochhole, anbei ein kleines Modul, was ohne Override auskommt und mit neueren PS Versionen funktioniert. Es verwendet den mittlerweile vorhandenen Hook, um den Shopnamen zu entfernen. Vielleicht hilfts ja jemandem noch in Zukunft... modifymailsubject.zip

Unter den Statistiken "Verkäufe und Bestellungen" kann man ja bereits nach Ländern filtern. Ich denke, ein Händler kennt seine Haupt EU Länder, die er dann auswählen muss, so bekommt man recht schnell einen Überblick, ob man "Gefahr" läuft "zu viel" zu exportieren oder nicht. Wenn das nicht ausreicht, dann exportiert man sich eben die Bestellungen für einen Zeitraum mit Bordmitteln und filter danach. Wenn man den neuen Anforderungen gerecht werden will, würde ich unter den Steuerregeln, für z.B. die MwSt. die Ländersteuersätze anpassen. Sobald ein Kunde seine Versandadresse eingibt, sieht er dann ggf. die neuen Bruttopreise für sich. Sollte man das mit einem Geolocation Modul flankieren?

If anybody has this issue due to a failed upgrade or doing manual updates / cherry picking .... : make sure you update your composer classmap files in the vendor/composer/files to have additional classes/interfaces addes as well.

Wurde die Umstellung von 19 auf 16 bereits gemacht, kann man im nachhinein noch runden... ohne gewähr, bitte Backup machen oder ggf. mit einem Produkt testen UPDATE `ps_product` SET `price` = ROUND(1.16*`price`,2)/1.16 where `id_tax_rules_group` = 1; UPDATE `ps_product_shop` SET `price` = ROUND(1.16*`price`,2)/1.16 where `id_tax_rules_group` = 1;

Hi, sowas in der Art wäre doch auch denkbar, damit man nicht ganz so viele Probleme bei den Rundungen hat (gerade ältere PayPal Modul Versionen verschlucken sich ja gerne) Beziehe mich mal auf den ersten Post UPDATE `ps_product` SET `price` = ROUND(1.16*`price`*1.19/1.16,2)/1.16 where `id_tax_rules_group` = 1; UPDATE `ps_product_shop` SET `price` = ROUND(1.16*`price`*1.19/1.16,2)/1.16 where `id_tax_rules_group` = 1; Muss man dann noch für Attribute und unit prices und 5/7% Produkte anpassen bzw. erweitern..

And you should use a frontcrontroller to execute it, not just a plain php file...

I found the answer by myself, inspired by some github search https://github.com/PrestaShop/PrestaShop/issues/15503 global $kernel; if(!$kernel){ require_once _PS_ROOT_DIR_.'/app/AppKernel.php'; $kernel = new \AppKernel('prod', false); $kernel->boot(); } needs to be called before.

Hi, we used to develop some modules which have cronjobs. The file "cron.php" could look like this. <?php include('../../config/config.inc.php'); include(dirname(__FILE__).'/mymodule.php'); if (Tools::getIsset('secure_key')) { //.... //check token etc. //.... $mymodule = new mymodule(); $mymodule->doCronTask(); } In the module file, there could be methods which are calling the deprecated Tools::displayPrice(); or the newer formatPrice method of the Tool class directly. but this leads into Fatal error: Uncaught Exception: Kernel Container is not available in ***/src/Adapter/ContainerFinder.php:77 Stack trace: #0 ***/classes/Tools.php(796): PrestaShop\PrestaShop\Adapter\ContainerFinder->getContainer() #1 ***/classes/Tools.php(773): ToolsCore::getContextLocale(Object(Context)) #2 ***/classes/Tools.php(843): ToolsCore::displayPrice(166.39, Object(Currency), false) #3 ***/classes/Smarty/SmartyLazyRegister.php(83): ToolsCore::displayPriceSmarty(Array, Object(SmartyDevTemplate)) #4 ***/var/cache/dev/smarty/compile/cd/4f/cc/cd4fcc1df816cac896d5dfe8e37d88ba6a9ffd0d_0.file.invoice.tax-tab.tpl.php(94): SmartyLazyRegister->__call('displayPriceSma...', Array) #5 ***/vendor/sm in ***/src/Adapter/ContainerFinder.php on line 77 I guess, it is because no locale is defined in the context. Is there a better way to create a cron job? Do i need to load sth. before the cronjob call? This was working until displayPrice was replaced. I saw, that a couple of modules will run into this problem. Any help appreciated.

Hi, I had the same problem as pourouz, some debugging showed, that a user session cannot be started during update quantity because of an already sent header. Normally this error occurs, when there are some blank or other output is generated too early. I solved this very similar to the above posts with changing in the same AdminCartsController.php file the output of ajaxProcessUpdateQty from echo json_encode(array_merge($this->ajaxReturnVars(), array('errors' => $errors))); to die(json_encode(array_merge($this->ajaxReturnVars(), array('errors' => $errors)))); hope this helps somebody...

Actually, you just have to edit the WebserviceRequest class and add the new resource. Dont forget to give rights to you webservice key https://www.screencast.com/t/Jww6l3vhSDCE

if you put in the 3 credential (signature, user and password) via database in the configuration table, it works.