Récemment
-
multiples déclinaisons sur produit [RÉSOLU]
Bugs & Améliorations20 -
ONePageCheckout
BUG connus4 -
Informations générales
PhenixSuite2 -
timepicker absent dans le BO
Bugs & Améliorations11 -
Installation Phenixsuite depuis 1.6.1.24
Questions relatives à l'installation/upgrade4 -
Passage au Webp qui n'a pas fonctionné
Bugs & Améliorations11 -
erreur 500 module paypal
Bugs & Améliorations8 -
probleme page de commande ONE PAGE
Bugs & Améliorations3 -
Traduction module Colissimo en admin
Bugs & Améliorations2 -
Erreur module block_cart en php8.2 mais pas en php7.4
Bugs & Améliorations14 -
Bug page de commande
Bugs & Améliorations4 -
Nouveautés possibles ?
Nouvelles fonctionnalités2 -
bug installation bdd
Questions relatives à l'installation/upgrade26 -
Configuration de wamp compatible presta.1.6.1.24 et PhenixSuite 1.6.2.25
Discussion générale61 -
Responsive sur liste des produits dans les commandes
Bugs & Améliorations2 -
affichage incorrect de produit personnalisé au panier
Bugs & Améliorations3 -
Erreur PHP à l'installation du module cedconnector
Bugs & Améliorations2 -
Problème calcul HT
Bugs & Améliorations18 -
MAJ .htaccess Apache 2.4 et 2.2
Nouvelles fonctionnalités5 -
Erreur SQL 1.6.2.23 -> 1.6.2.25
Questions relatives à l'installation/upgrade2
[1.6.1.17] Données erronées dans le tableau de bord
-
En version 1.6.1.17, les CA journaliers sont "évolutifs" en fonction de la dernière date de changement de statut d'une commande.
Pour retrouver le fonctionnement normal, soit:
- appliquer ce patch: https://github.com/PrestaShop/PrestaShop/pull/8335
- soit remettre le fichier controllers/admin/AdminStatsController.php de la version 1.6.1.16
Le bug report est ici: http://forge.prestashop.com/browse/PSCSX-9335
-
Petit patch correctif pour les produits les plus vus dans cette page également (Bug si dates sélectionnées == date du jour et ne trie pas les résultats dans l'ordre souhaité)
Dans dashproducts.php ligne 482, remplacez le bloc else par celui-cielse { return Db::getInstance(_PS_USE_SQL_SLAVE_)->executeS(' SELECT p.id_object, pv.counter FROM `'._DB_PREFIX_.'page_viewed` pv LEFT JOIN `'._DB_PREFIX_.'date_range` dr ON pv.`id_date_range` = dr.`id_date_range` LEFT JOIN `'._DB_PREFIX_.'page` p ON pv.`id_page` = p.`id_page` LEFT JOIN `'._DB_PREFIX_.'page_type` pt ON pt.`id_page_type` = p.`id_page_type` WHERE pt.`name` = \'product\' '.Shop::addSqlRestriction(false, 'pv').' AND DATE_FORMAT(dr.`time_start`, "%Y-%m-%d") >= "'.pSQL($date_from).'" AND DATE_FORMAT(dr.`time_end`, "%Y-%m-%d") <= "'.pSQL($date_to).'" ORDER BY pv.counter DESC LIMIT '.(int)$limit); }
-
@eolia Salut , mon code commence comme ca ( { else )
le tien ( else { ) le quel est bon ? merci
-
{ else c'est impossible en php...
-
Salut ok, je t'envoi le code que j'ai ou le fichier ?
dashproducts.php
Je confirme j'ai ca :
}
else
return Db::getInstance(PS_USE_SQL_SLAVE)->executeS('
SELECT p.id_object, pv.counter
FROM'._DB_PREFIX_.'page_viewed
pv
LEFT JOIN'._DB_PREFIX_.'date_range
dr ON pv.id_date_range
= dr.id_date_range
LEFT JOIN'._DB_PREFIX_.'page
p ON pv.id_page
= p.id_page
LEFT JOIN'._DB_PREFIX_.'page_type
pt ON pt.id_page_type
= p.id_page_type
WHERE pt.name
= 'product'
'.Shop::addSqlRestriction(false, 'pv').'
AND dr.time_start
BETWEEN "'.pSQL($date_from).'" AND "'.pSQL($date_to).'"
AND dr.time_end
BETWEEN "'.pSQL($date_from).'" AND "'.pSQL($date_to).'"
LIMIT '.(int)$limit);
}public function getMostSearchTerms($date_from, $date_to, $limit = 10) { if (!Module::isInstalled('statssearch')) return array();
-
On est bien d'accord, j'ai la même chose^^
Donc tu remplaces le bloc else avec le code que je t'ai fourni plus haut...
-
@eolia Merci ^^ Bonne pâques
-
Je n'arrive pas à comprendre qu'il faille polluer pendant 3 jours le topic pour quelque chose qui se résout d'un simple test A/B en 2 mn et qui au final consiste à faire très exactement ce qui est écrit. Ni plus, ni moins
-
Ce message a été supprimé !