j'ai activé le blockcategory dans mon hook_left_column. MAIS il ne s'affiche pas à la première visite , il faut choisir un produit et revenir pour qu'il reste affiché. Certains pensent que cela vient du cache navigateur, mais mes test semblent montrer que non. vider le cache navigateur, partir d'une nouvelle session.... vider les cokkies... vider le cache smarty... la totale

Donc je lis le code.. schématisons

public function hookLeftColumn($params)
    {
				
        if(!$this->setLastVisitedCategory()) {
            return;
        }
        $phpself = $this->context->controller->php_self;
        $current_allowed_controllers = array('category');

blablabla
}

Si je commente ce return, elle s'affiche comme désiré. Mais disons que j'hésite à faire le bourrinr, je vais plus loin...

public function setLastVisitedCategory()
    {
        if(method_exists($this->context->controller, 'getCategory')
            && ($category = $this->context->controller->getCategory())
        ) {
            if(!$category->active) { // c'est pas le bon controller donc on passe à la suite
                return false;  
            }
        }
 $cache_id = 'blockcategories::setLastVisitedCategory'; // normalement vide
        if(!Cache::isStored($cache_id)) {
            if(method_exists($this->context->controller, 'getCategory') // probablement pas
                && ($category = $this->context->controller->getCategory())
            ) {
                $this->context->cookie->last_visited_category = $category->id; // pas de cookie déposé
            }
            elseif(method_exists($this->context->controller, 'getProduct') // non plus, sauf quand
                && ($product = $this->context->controller->getProduct())) { // on a vu une page produit
                if(!isset($this->context->cookie->last_visited_category)
                    || !Product::idIsOnCategoryId($product->id, array(array('id_category' => $this->context->cookie->last_visited_category)))
                    || !Category::inShopStatic($this->context->cookie->last_visited_category, $this->context->shop)
                ) { //// la il ne dépose pas de cookie
                    $this->context->cookie->last_visited_category = (int)$product->id_category_default;
                }
            } //// donc au saute là... ??? mais  pas de cookies non plus....
            Cache::store($cache_id, $this->context->cookie->last_visited_category);
        }
    //// et donc pas pastèque return false... tout le temps.....
        return Cache::retrieve($cache_id);
    }

}

De ce que je comprends... Lorsque l'on arrive sur la page la première fois, il n'y a pas de catégorie disponible donc on demande d'activer la dernière catégorie visitée, ce qui ne donne rien et renvient rien et donc return vide....
il n'y a pas de dépôts de cookie lors de cette navigation... je vais prendre le temps d'investiguer

"" je ne sais pas si c'est vraie ou pas, ce navigateur de m* firefox à jour, me dit qu'il n'y pas de cookie alors même qu'il y en a puisque je me suis logué sur un site... p*tain je devrais regarder d'un autre navigateur...

en ce moment je n'ai pas le temps de faire dans la dentelle alors je vai commenter à la bourrin, mais il faudrait se pencher plus sur la question, ce que je ferais si le soucis persiste et que personne ne voit la solution évidente.

Modifiez le fichier modules/themeconfigurator/themeconfigurator.php @397
Remplacer

Db::getInstance()->delete(_DB_PREFIX_.'themeconfigurator', 'id_item = '.(int)$id_item);

par

Db::getInstance()->delete('themeconfigurator', 'id_item = '.(int)$id_item);

Même si vous connaissez le contrôleur et tentez de l'appeler vous obtiendrez un "accès interdit" même en SuperAdmin
https://domain.com/admin-lab17/index.php?controller=AdminTabs

Vous pouvez reprendre le contrôle de votre BO avec l'override suivante:

/override/controllers/admin/AdminTabsController.php

<?php

class AdminTabsController extends AdminTabsControllerCore
{

    public function access($action, $disable = false)
    {
        return Profile::getProfileAccess($this->context->employee->id_profile, Tab::getCurrentTabId());
    }

}

Videz votre cache, vous pouvez a nouveau piloter votre menu du BO, en saisissant l'url directe et acceptant l'alerte de sécurité.

TIP: Insérer le contrôleur( ajouter menu) avec comme parent Configure afin d'avoir l'entrée directe dans le menu

Dans modules/ganalytics/ganalytics.php dans la fonction ganalytics::public function hookActionCartSave()
Remplacer (en fin de fonction)

$gacart[$id_product] = $ga_products;
$this->context->cookie->ga_cart = serialize($gacart);

par

$gacart[$id_product] = $ga_products;
$this->context->cookie->ga_cart = str_replace(array('¤','|'),'-',serialize($gacart));

Pour palier ce problème il suffit de supprimer le menu contextuel de tinymce
Supprimer le répertoire /js/tiny_mce/plugins/contextmenu

Après suppression il est de nouveau possible de choisir la langue utilisée par le navigateur.

Le contrôleur provoque une erreur 500 et ne remonte aucune données

Smarty exception:
0():Missing '$template' parameter

Pour corriger le problème, modifier le fichier controllers/front/StatisticsController.php, ajoutez cette fonction dans la classe:

    public function run()
    {
        $this->init();
        $this->postProcess();
        die(Tools::getValue('id_connections').'!'.Tools::getValue('id_guest'));
    }

Vous devez remplacer la ligne:

$query->select('p.`id_product`');

par

$query->select('DISTINCT p.`id_product`');

Ce bug est également lié à celui-ci: https://bb.enter-solutions.net/topic/1070/1-6-1-0-too-many-tables-mysql-can-only-use-61-tables-in-a-join-backoffice-créer-éditer-un-produit

Le code en cause réside dans classes/SpecificPriceRule.php fonction SpecificPriceRule::getAffectedProducts()

} elseif ($condition['type'] == 'category') {
   $query->leftJoin('category_product', 'cp'.(int)$id_condition, 'p.`id_product` = cp'.(int)$id_condition.'.`id_product`')
     ->where('cp'.(int)$id_condition.'.id_category = '.(int)$condition['value']);
} elseif ($condition['type'] == 'supplier') {

Vous devez remplacer cette section par:

                    } elseif ($condition['type'] == 'category') {
                        if ($once) {
                            $query->innerJoin('specific_price_rule_condition_group', 'sprg', 'sprg.id_specific_price_rule='.(int)$this->id);
                            $query->innerJoin('specific_price_rule_condition','sprc', 'sprc.type = "category" and sprc.id_specific_price_rule_condition_group = sprg.id_specific_price_rule_condition_group');
                            $query->innerJoin('category_product', 'cp', 'p.`id_product` = cp.`id_product` and cp.id_category = sprc.value');
                            $once = false;
                        }
                    } elseif ($condition['type'] == 'supplier') {

Ajoutez ensuite la ligne $once = true; juste avant le foreach:

                // Add the conditions
                $once = true;
                foreach ($condition_group as $id_condition => $condition) {

Enfin créez un index dans votre schéma (sql):

ALTER TABLE `ps_specific_price_rule_condition`
ADD INDEX `id_specific_price_rule_condition_group_type` (`id_specific_price_rule_condition_group`, `type`);

Ce bug est également lié à celui-ci: https://bb.enter-solutions.net/topic/1071/1-6-1-0-duplicate-entry-xxxxxx-for-key-id_product_2-insert-into-ps_specific_price-backoffice-créer-éditer-un-produit-specificpricerule-php

'img_ps_dir' => 'http://'.Tools::getMediaServer(_PS_IMG_)._PS_IMG_,

Par

'img_ps_dir' => Tools::getShopProtocol().Tools::getMediaServer(_PS_IMG_)._PS_IMG_,

idem dans /classes/pdf/HTMLTemplateSupplyOrderForm.php à la ligne 175.

Appliquer ce patch:
https://github.com/PrestaShop/PrestaShop/commit/d5a728c869e8931d33e9b8d752322f4c07471a0d#diff-5fbca4f1456bafff9d3bd87107eedb61

Ce bug affecte la version 1.6.1.16 (corrigé 1.6.1.17)

Remplacer dans classes/Cart.php à la ligne 271:

        Db::getInstance()->execute('
                        DELETE `' . _DB_PREFIX_ . 'customized_data`
                        FROM `' . _DB_PREFIX_ . 'customized_data` cd, `' . _DB_PREFIX_ . 'customization` c
                        WHERE cd.`id_customization` = c.`id_customization`
                        AND `id_cart` = ' . (int) $this->id
        );

par

        Db::getInstance()->execute('
                        DELETE cd
                        FROM `' . _DB_PREFIX_ . 'customized_data` cd, `' . _DB_PREFIX_ . 'customization` c
                        WHERE cd.`id_customization` = c.`id_customization`
                        AND `id_cart` = ' . (int) $this->id
        );

Il est possible (utile) de rendre l'erreur sous-jacente compréhensible en appliquant le patch suivant:
https://github.com/PrestaShop/PrestaShop/pull/8475/files

js/admin/products.js

				if ((in_array(status, wrong_statuses) || in_array(request.status, wrong_status_code)) && !self.page_reloading) {

					var current_tab = '';
					try {
					if (request.responseText !== 'undefined' && request.responseText && request.responseText.length) {
						current_tab = $(request.responseText).filter('.product-tab').attr('id').replace('product-', '');
					}
					jAlert((current_tab ? 'Tab : ' + current_tab : '') + ' (' + (request.status ? request.status + ' ' : '' ) + request.statusText + ')\n' + reload_tab_description + request.responseText, reload_tab_title);
					self.page_reloading = true;
					self.has_error_loading_tabs = true;
					clearTimeout(tabs_running_timeout);

par

				if ((in_array(status, wrong_statuses) || in_array(request.status, wrong_status_code)) && !self.page_reloading) {
					var current_tab = '';
					try {
					if (request.responseText !== 'undefined' && request.responseText && request.responseText.length) {
						current_tab = $(request.responseText).filter('.product-tab').attr('id').replace('product-', '');
					}
					} catch(e){};
					jAlert((current_tab ? 'Tab : ' + current_tab : '') + ' (' + (request.status ? request.status + ' ' : '' ) + request.statusText + ')\n' + reload_tab_description, reload_tab_title);
					self.page_reloading = true;
					self.has_error_loading_tabs = true;
					clearTimeout(tabs_running_timeout);

Patchez également js/jquery/plugins/alerts/jquery.alerts.css

#popup_message {
	padding-left: 48px;
}

par

#popup_message {
	padding-left: 48px;
	max-height: 350px;
	overflow: auto;
}

La cause: https://github.com/PrestaShop/PrestaShop/commit/18f57b62e897ed5b472e51f7ed69ce4e390d105e#diff-7d7493bae4eba5d548b7f7f88d16d7ea

Corriger la ligne 5025 de controllers/admin/AdminProductsController.php
Remplacer:
if (Pack::isPack((int)$item_id || $product->id == (int)$item_id)) {
par
if (Pack::isPack((int)$item_id) || $product->id == (int)$item_id) {

Pour admettre les emails accentués, il faut désactiver la génération d'erreur en cas de grammaire non reconnu.

Dans le fichier tools/swift/classes/Swift/Mime/Headers/MailboxHeader.php aux alentours de la ligne @344

    private function _assertValidAddress($address)
    {
        if (!preg_match('/^'.$this->getGrammar()->getDefinition('addr-spec').'$/D',
            $address)) {
            if (0) throw new Swift_RfcComplianceException(
                'Address in mailbox given ['.$address.
                '] does not comply with RFC 2822, 3.6.2.'
                );
        }
    }

Le cartouche tout en bas de la page.

De plus de nombreux navigateur autofill les champs.

Il suffit alors de cliquer par mégarde sur le bouton enregistrer pour que désormais, à chaque appel de la page SAV, le BO tente la synchronisation qui échouera après plusieurs minutes.

Le plus simple pour annuler ce défaut est d'exécuter la requête sql suivante:

delete from PREFIX_configuration where name like 'PS\_SAV\_IMAP\_%' where id_shop=99;

Ajustez cette requête à votre shop!

Il s'agit d'un bug "implanté" dans le générateur de .htaccess.

Il faut patcher classes/Tools.php, remplacer dans la fonction generateHtaccess() la ligne:
fwrite($write_fd, "RewriteCond %{REQUEST_FILENAME} -s [OR]\n");
par
fwrite($write_fd, "RewriteCond %{REQUEST_FILENAME} -f [OR]\n");