doekia

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

Pourtant le première ligne est assez éloquente PHP Version 7.2.34 PHP Version 7.4.33

I do not see anay duplicates on canonical. Such keyword exists twite on your page, but on one is the true <link rel="canonical" ... /> The second occurence is inside a js script "page":{"title":"","canonical":"https:\/\/lovegames.es\/26-accesorios-pene" However, even with multiple canonical, should they have same unique disposition, there will be no arm at all like most of the link tags by the way.

Probablement parce que id-de-la-regle-de-taxe n'a jamais voulu dire id-de-la-taxe

nom du domaine ?

même sans robots.txt ces pages n'ont aucun impact SEO, mais, sauf dans les délires des "agences SEO"

Les liens vers les pages authentifié sont normalement en nofollow et même sans cela cela n'a absolument aucun impact SEO puisque ces 2 pages ne doivent pas être indexées

Je ne vais pas pouvoir vous aider, je ne comprends pas ce que vous avez fait. Le changement mentionné consistait à joindre une ligne pour enlever la concaténation interdite en déclaration.

Jointez la ligne comme suis 'description' => 'Show a warning message when the user wants to update his shop configuration',

Le if (0) correspond à une manière pour cleaner de corriger d'urgence un code de hacking connu. Vous avez alors eu une alerte rouge qui vous demandait de verifier/restaurer le fichier. Vous avez ici lancé 7x le cleaner sans restaurer. Pourquoi if (0) ? Parce que cela permet de rendre le hack inopérant sans en connaitre la syntaxe exacte et d'avoir un spectre de protection d'URGENCE plus large

y a t-il un moyen de bloquer ceux qui ont passé l'état d'ivresse manisfeste ?!?

clairement l'url du blog ici https://aprodom.com/blog contient déjà un espace insécable