doekia

{if $product->id%2}

PhenixSuite fait le choix d'être compatible mais aussi d'aller sur les toutes dernières versions de PHP. A certains moment il y a des choix qui sont incompatibles. Quel module peux bien fonctionner en 1.2 à 1.7 et être incompatible PhenixSuite ? Je n'en ai rencontré aucun et lorsque certains modules 1.6 ou 1.7 ont été adaptés pour Phenix cela c'est avéré être 3 lignes dans 90% des cas.

Avec le message d'erreur il sera peut-être possible d'aider. Avez-vous activé le debug pour avoir un message d'erreur encore plus pertinent ?

Je répare des boutiques infectées environ une fois par semaine. Je n'en ai vu AUCUNE dont le vecteur d'infection soit lié à la version de PHP.

Il ne peut exister de garantie qu'un hack ne revienne pas. A ce jeu même les gouvernements arrivent à se faire infecter - une fois corrompu certain éléments nocifs peuvent nous seulement être passé sous le radar, mais il faut également comprendre que le site a été répertorié auprès des hackers. Ils vont donc - et ce pendant longtemps - essayer toute sorte de faille qui sinon ne seraient pas testées/envisagées, voire attirer des hackers plus chevronnés. Déverminer, avec un bon niveau de confiance, un site c'est, malgré des outils, entre 8 à 48h acharnées. C'est difficilement à faible coût. Et non repartir de zéro ne résout pas le problème, car si vous aviez un vecteur, il y a de forte chance que vous réintroduisiez ce même vecteur.

Vous avez bien mis la version autoupgrade mentionnée ?

Prestashop ne gérant quasiment pas les IPv6, j'ai des doutes qu'il existe des modules pour cela. Par ailleurs votre .htaccess peut probablement répondre à votre besoin avec par exemple une rewrite map basée sur vos critères qui laisse continuer le index.php ou renvoi vers une page type 403. Dans tous les cas, selon moi, on sort du périmètre e-commerce pour entrer dans celui d'un WAF.

Le plus simple étant de faire l'inverse. Ne rien envoyer sur expédié et laisser le mail automatique AVEC le numéro de suivi informer le client que le colis est chez le transporteur.

De toute manière la question est vite résolu puisque ce module n'est plus certifié. En effet il doit recevoir un audit et une certification annuelle, ce qui n'a pas été renouvelé depuis 2019. Le module avait d'ailleurs la fâcheuse tendance à décider que vous aviez "triché" sur votre déclaration compte tenu d'action naturelle de Prestashop. Et cela affectait TOUTES les commandes à la premier mise à jour restructurant les tables commande. Toutes ces raisons ont mené Prestashop à supprimer le module de leur catalogue.

Je me demande même si on ne risque pas quelques cafouillage du dispatcher du plus bel effet. en 1.7 vous êtes obligé de laisser l'id_product_attribute dans l'url,, c'est optionnel en 1.6, mais le parser utilise bien plus de scénario de regex de manière assez séquentielle 'product_rule' => array( 'controller' => 'product', 'rule' => '{category:/}{id}{-:id_product_attribute}-{rewrite}{-:ean13}.html', 'keywords' => array( 'id' => array('regexp' => '[0-9]+', 'param' => 'id_product'), 'id_product_attribute' => array('regexp' => '[0-9]+', 'param' => 'id_product_attribute'), 'rewrite' => array('regexp' => '[_a-zA-Z0-9\pL\pS-]*', 'param' => 'rewrite'), 'ean13' => array('regexp' => '[0-9\pL]*'), 'category' => array('regexp' => '[_a-zA-Z0-9-\pL]*'), 'categories' => array('regexp' => '[/_a-zA-Z0-9-\pL]*'), 'reference' => array('regexp' => '[_a-zA-Z0-9-\pL]*'), 'meta_keywords' => array('regexp' => '[_a-zA-Z0-9-\pL]*'), 'meta_title' => array('regexp' => '[_a-zA-Z0-9-\pL]*'), 'manufacturer' => array('regexp' => '[_a-zA-Z0-9-\pL]*'), 'supplier' => array('regexp' => '[_a-zA-Z0-9-\pL]*'), 'price' => array('regexp' => '[0-9\.,]*'), 'tags' => array('regexp' => '[a-zA-Z0-9-\pL]*'), ), ),

Par contre, je suis surpris, vous n'êtes pas sur la page panier là. Si c'est un statut de commande, alors non vous ne pouvez pas supprimer une commande, et vous ne DEVEZ JAMAIS essayer de le faire.

Pourquoi long? Choisissez une plage de date, bulk selection tous sélectionner bulk action delete Dans le code 1.6 et j'imagine que c'est pareil dans les version ultérieures, il y a ceci public function delete() { if ($this->OrderExists()) { //NOT delete a cart which is associated with an order return false; } ...

Prestashop fait cela nativement (suppression des paniers abandonnés sans commande), il faut juste filtrer les date pour exclure les paniers récent. Sélectionnez TOUS vos panier, cliquez delete il ne supprimera que les orphelins

Sinon le code essaie ici tout simplement de transformer le contenu d'un cookie en contenu d'un fichier, c'est assez malin car il n'y a après 1er infection plus besoin de faire de POST pour injecter un payload.

Je ne saurais trop rappeler certains principes fondamentaux en terme de sécurité. Non pas dire que ce ne serait pas ce que vous avez fait mais pour rappeler certaines règles qui sont souvent méconnues et s'avèrent un vecteur majeur de faille sur le long terme. https://tweet.phenixsuite.com/thread/501