Topics tagged with 1.6

[1.6.0.5 - 1.6.1.18] Fatal error lors de la suppression d'image du themeconfigurator

doekia — Invalid Date

Lors de la suppression d'image du themeconfigurator vous obtenez l'erreur:
Call to a member function rowCount() on boolean
ou
Table 'presta16.ps_ps_themeconfigurator' doesn't exist avec le mode debug activé

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);

[1.5.x],[1.6.x],[1.7.x] Pas de redirection canonical pour page manufacturer & supplier

doekia — Invalid Date

@doekia Attention il y a eu une grosse coquille dans le code publié plus tôt. Il est maintenant corrigé mais pensez à le vérifier si vous avez appliqué le patch précédemment

[1.6.x.x]+ BO - Sélection de langue pour contrôle orthographique impossible dans tinyMCE

doekia — Invalid Date

Dans une boutique multi-langue, lors de l'utilisation de tinymce (description produit, ...), la langue du contrôle orthographique du navigateur ne peux être choisi, le menu contextuel remplaçant le menu du navigateur.

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.

[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)

doekia — Invalid Date

Lorsqu'il existe des règles catalogues avec des conditions sur catégories, à l'enregistrement d'un produit, vous rencontrez cette erreur.
Le code impliqué réside dans SpecificPriceRule.php fonction SpecificPriceRule::getAffectedProducts()

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

[1.6.1.0]+ Too many tables, MySQL can only use 61 tables in a join - Backoffice, créer/éditer un produit (SpecificPriceRule.php)

doekia — Invalid Date

Lorsque vous avez plus de 59 catégories dans une condition de règle catalogue, PrestaShop crash lors de l'enregistrement produit. Le problème peut survenir avec moins de règles catégories, si vos règles utilisent d'autres conditions (features, attributes, suppliers, manufacturers,

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

[1.5.0.17+] Erreur de protocole lors de la génération de pdf

eolia — Invalid Date

Si votre boutique est en https et que la génération des pdf crashe car le tpl utilise $img_ps_dir modifier la ligne 141 de /classes/pdf/HTMLTemplate.php en remplaçant:

'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.

[1.5.0.17]+ Redirection vers http forcée suite à redirection shop domain (en https)

eolia — Invalid Date

header('Location: '. Tools::getShopProtocol() . $url);

[1.6.1.18] Nombre de visites erroné sur tableau de bord

doekia — Invalid Date

Premièrement il faut réaliser que Google à des moyens de "flicage" plus sophistiqué afin de repérer un même internaute. Deuxièmement Google à cette capacité à reconnaître les visites qui ne sont que des robots et qui par construction créent de fausses visites. Enfin il y a depuis toute la branche 1.6 un quasi double comptage des visiteurs.

[1.4.0.17]+ Tools::redirect() n'accepte pas les query string de l'url

eolia — Invalid Date

Merci @doekia qui m'a enlevé une belle épine du pied :slight_smile:

[1.6.0.5]+ Reference error: $ is undefined dans le BackOffice

doekia — Invalid Date

Le code à corriger a été changé afin de ne pas interférer avec certains contrôleurs (Category avec les scènes activés par exemple), qui implémentent du code dans setMedia() pour lequel init() doit avoir été exécuté au préalable (Product::initPricesComputation())

[1.6.1.12]- Header de cross-orgin invalide avec les CDN

okom3pom — Invalid Date

Merci perso comme un con j'avais ajouté en dessous sans me demander pourquoi : # ~~end~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again Header set Access-Control-Allow-Origin "*" Voilà c'est corrigé.

[1.5.5.0]+ Ajax error lors de ma mise à jour des ranges transporteur (AdminCarrierWizard)

eolia — Invalid Date

Pensez également à contrôler la valeur de max_input_vars (par défaut à 1000 si non configurée sur le serveur) dans le cas d'un nombre important de zones / tranches de poids / prix Cette variable correspond au nombre maximum de champs acceptés par le serveur lors de la soumission d'un POST. Mettez-là à 10 000 et vous serez tranquilles également pour les traductions

[1.6.0.9] BO: Paniers, Bad query lors de l'ajout d'un filtre 'paniers abandonnés'

doekia — Invalid Date

Lors de l'ajout du filtre 'paniers abandonnés', la page sort l'erreur:
Bad SQL query
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'id_order = 'Panier abandonné' ORDER BY a.id_cart DESC LIMIT 0,50' at line 15

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

[1.6.1.16] Unknown table `ps_customized_data` in MULTI DELETE

doekia — Invalid Date

L'erreur apparaît lors de la suppression de panier depuis le BO, ou lorsque le mode debug est activé en suppression de produit au panier.

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
        );

[1.6.X.X] Le module loyalty s'affiche sur les articles en promotion

okom3pom — Invalid Date

Pour les versions 1.6.1.X $(document).ready(function() { $(document).on('change', '#our_price_display', function(e){ updateLoyaltyView(priceWithDiscountsDisplay); }) updateLoyaltyView(priceWithDiscountsDisplay); }); function updateLoyaltyView(new_price) { if (typeof(new_price) == 'undefined' || typeof(productPriceWithoutReduction) == 'undefined') return; var points = Math.floor(new_price / point_rate); var total_points = points_in_cart + points; var voucher = total_points * point_value; if (none_award == 0 && productPriceWithoutReduction != new_price) { $('#loyalty').html(loyalty_already); } else if (!points) { $('#loyalty').html(loyalty_nopoints); } else { var content = loyalty_willcollect + " "+points+' '; if (points > 1) content += loyalty_points + ". "; else content += loyalty_point + ". "; content += loyalty_total + " "+total_points+' '; if (total_points > 1) content += loyalty_points; else content += loyalty_point; content += ' ' + loyalty_converted + ' '; content += ''+formatCurrency(voucher, currencyFormat, currencySign, currencyBlank)+'.'; $('#loyalty').html(content); } } Fonctionne également si un produit à une remise que sur une déclinaison.

[1.6+] BO, ajax error dans la page produit - pas d'autre explication de l'erreur

doekia — Invalid Date

En Prestashop 1.6, même en mode debug, il est impossible de connaître la cause exacte de l'erreur qui provoque une erreur ajax.

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;
}

[1.6.1.15+] pack produits - impossible de créer ou mise à jour supprimant le pack

doekia — Invalid Date

Depuis la version 1.6.1.15, un patch à rendu les packs totalement non fonctionnels coté BO.

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) {

[1.6+] email accentué => Fatal: Address in mailbox given does not comply with RFC 2822, 3.6.2

doekia — Invalid Date

Prestashop utilise la librairie Swift version 4 pour envoyer les mails.
Cette librarie applique un contrôle de la grammaire selon la RFC 2822 (avril 2001).
Cette RFC a été remplacé par la RFC 6531 (février 2012).
La librarie Swift n'intègre cette grammaire qu'a partir de la version 5.5+ (via package symfony).

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.'
                );
        }
    }

[1.5+] Page SAV anormalement lente (plusieurs secondes)

doekia — Invalid Date

La page de SAV peut être synchronisée avec un messagerie IMAP, hélas même lorsque l'on ne souhaite pas faire cette synchronisation il arrive souvent qu'on active ce dispositif par erreur car les réglages se font sur la même page que les réponses au demandes SAV.

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!

[1.5+] Erreur 404 lors de l'accès à un fichier vide

doekia — Invalid Date

Lors de l'accès à un fichier vide (signature, ownership verification, ...) vous êtes redirigé sur la page 404 avec le status de réponse 404.

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");