3. Configuration de wamp compatible presta.1.6.1.24 et PhenixSuite 1.6.2.25

    Récemment


Configuration de wamp compatible presta.1.6.1.24 et PhenixSuite 1.6.2.25


  • Bah écoutez, vous pouvez faire vos propres expériences mais je ne vois pas comment vous allez contrôler l'intégrité des données en utilisant cette manière de faire.

    On installe Phenix si on désire partir de zéro, sinon on effectue un upgrade, je ne vois pas pourquoi se compliquer la vie ainsi.

    0
  • J

    Et bien si justement, il y a de très bonnes raisons.
    Autrement, pourriez-vous développer un module ou une requête exportant les données produit / commandes / clients, compatible avec phenixsuite, et quel en serait le coût ?
    Cela pourrait en intéresser d'autres je pense.

    0

  • Il faudra m'expliquer ces raisons.
    Je ne vais pas développer un module dont je ne saisis pas l'intérêt.

    Si vous voulez repartir sur une boutique propre:

    • Upgradez vers Phenix
    • Basculez sur le thème par défaut
    • Désinstallez/supprimez tous les modules non natifs
    • Videz le répertoire des overrides.

    Ca prend 10 min au max.

    0
  • J

    Bon, il va falloir alors que je clone mon site sur wamp et que j'arrive à l'y faire fonctionner.
    J'avais fait une tentative dans ce sens l'année dernière, mais cela ne fonctionnait pas sur wamp. Probablement à cause d'incompatibilités.
    Je vais essayer à nouveau, vu que je ne veux pas le faire en direct.

    0

  • Si vous le cloner sur Wamp respectez la version PHP de votre site pour commencer.
    Vous n'avez pas la possibilité de le cloner chez votre hébergeur ? (sous-domaine dev.votre-site.com) Ce qui est la manière habituelle de procéder.

    0
  • J

    Je n'ai pas encore utilisé cette fonctionnalité, mais je vais m'y coller. Je viens de crér un sous-domaine, à la racine "dev"

    0

  • Une fois votre ftp copié et votre base de données importée, mettez à jour le fichier /config/settings.inc.php (pour indiquer les identifiants de la nouvelle base) et mettez à jour la table ps_shop_url avec votre sous-domaine à la place du nom de domaine actuel.

    0

  • J'ai déjà tout expliqué ici:
    https://www.prestashop.com/forums/topic/519979-tutorial-comment-transférer-mon-site-local-distant-ou-linverse/

    0
  • J

    OK. Merci. Je vais lire.

    0
  • J

    C'est fait. Le clone en ligne est fonctionnel.
    J'ai téléchargé votre module autoupgrade.
    J'ai désactivé eicaptcha.
    Vu que j'ai un phenixsuite vierge sur wamp, je compare les réglages avant de lancer l'upgrade.
    Je vois que tous les réglages dans "Performances" sont sur "non" (sauf smarty) et ne sont pas tous les mêmes que sur ma version.
    Je me demande s'il faut que je mette tout sur "non"
    a8508835-bbf3-4efa-a9d8-6bc08f875db1-image.png

    0

  • Peu importe ces réglages pour la mise à jour, par contre, une fois celle-ci terminée il est préférable de les passer tous sur oui.

    0
  • J

    ok
    J'ai ce message :
    "You are using PHP 7.1.33 version. The latest PHP version supported by PhenixSuite is PHP 8.2.2. To make sure you’re ready for the future, we recommend you to upgrade to PHP 7.4 minimum after complete upgrade."

    Je peux modifier la version de php, mais je ne suis pas sure de pouvoir le faire sans changer celle de la version en ligne. Je vais vérifier et consulter mon hébergeur.

    0
  • J

    L'upgrade est fait sur le clone et tout a l'air de s'être bien passé, bien qu'il y ait quelques alertes dans le message final.
    Prochaine étape : faire un contrôle plus poussé.

    Il faudra aussi que je détermine si cela change quelque chose (améliorations) pour search console (quand cette version sera publié sur le site principal). Car si tous les voyants y sont au vert, il y a des alertes orange sur lesquelles je dois travailler, pour les produits, vu que Google réclame plus.

    Merci Eolia pour l'accompagnement.

    0

  • Phenix intègre les json-ld pour les produits, cela devrait vous rassurer.

    0
  • J

    J'ai procédé à l'upgrade sur le site principal et la mise à jour a été facile.
    Par contre, je me rends compte que je n'avais pas fait assez de tests sur le clone.
    Je découvre des fonctionnalités en panne :

    Certains liens qui ne fonctionnent plus.

    • Dans le menu : le lien ne fonctionne pas pour "promotion et soldes". En fait la page "/promotions" semble avoir disparue (le lien vers les nouveautés lui fonctionne). Pour l'instant je l'ai supprimé du menu en attendant de trouver.

    • Dans le slider les liens vers les pages de marques ne fonctionnent plus non plus, d'ailleurs plus aucun lien de marque/fabricant ne fonctionne.
      En inspectant une fiche de fabricant (catalogue/fabricant) je vois qu'il n'y a pas d'url. (Il y a bien le descriptif, les balises et les mots-clé).

    Il y a aussi eicaptacha qui fait un message d'erreur quand on essaie d'envoyer un message via le formulaire de contact et qui bloque l'envoi. Pour l'instant je l'ai désactivé afin que le formulaire puisse être utilisé.

    Voilà où j'en suis des constats. Je veux bien des pistes pour résoudre ces problèmes.

    0

  • Prenez le temps de regarder les différents paramétrages de Phenix:
    294c731a-be1c-4d9e-b613-a02353987713-image.png

    Concernant eicaptcha je vous conseille de le désinstaller complètement (idem si vous avez un module de gestion de cookies).
    Phenix a des protections natives (voir les Paramètres avancés => Performances => onglet sécurité)
    39c980b0-0df1-455b-9f9f-02c7c48d3f83-image.png
    et un script pour la gestion des cookies (Préférences => clients)
    0a101a68-3042-4648-9511-6120707fb87a-image.png

    0
  • J

    Merci.
    Effectivement, j'aurais du vérifier dans les préférences. Il était tard dans la nuit...

    Pour les cookies, je suppose qu'il faut d'abord avoir un module, ou bien un simple CMS suffit ?

    Je constate aussi des différences dans les statistiques. Notamment, celles des paniers abandonnés ne s'actualisent pas. J'ai le même nombre depuis hier, sans nouveaux paniers abandonnés. En principe se sont ceux de la dernière demi-heure.

    Dans phpmyadmin :
    Je vois que dans la table cart_rule, toutes les dates sont à 0000-00-00 00:00:00 / date_add
    Dans ps_cart, il y a des dates.

    De par ailleurs, il faudra aussi que je trouve le moyen de faire du ménage dans la table des paniers, où l'on ne peut pas faire des coupes, vu qu'il y a aussi ceux qui sont associés à des commandes.

    0
  • J

    Pour la table cart_rule, je pense que c'est la fonction AUTO_INCREMENT qui a sauté et qui probablement responsable.

    0
  • J

    En fait, ce n'est pas la table cart_rule qui n'a pas AUTO_INCREMENT, mais ps_cart_cart_rule. Donc c'est logique, vu qu'elle contient 2 clés primaires sur id_cart_rule et id_cart.
    Mais je n'ai pas l'explication pourquoi ses dates sont toutes à zéro.

    0
  • J

    Je continue mes reherches.

    J'ai récupéré le message d'erreur qui s'était affiché pendant l'installation :

    Erreurs
    SQL 1.6.2.24 1075 in ALTER TABLE ps_customer_message CHANGE id_customer_message id_customer_message int(11) unsigned NOT NULL auto_increment, CHANGE id_employee id_employee int(11) unsigned DEFAULT NULL: Incorrect table definition; there can be only one auto column and it must be defined as a key
    Erreur(s) détectée(s) pendant la mise à jour.

    Je vois qu'il n'y a pas auto_increment, et pas de clés.

    Eolia, est-ce que je peux imputer la structure de la table d'origine de phenixsuite :

    -- Structure de la table ps_customer_message

    DROP TABLE IF EXISTS ps_customer_message;
    CREATE TABLE IF NOT EXISTS ps_customer_message (
    id_customer_message int(11) UNSIGNED NOT NULL AUTO_INCREMENT,
    id_customer_thread int(11) DEFAULT NULL,
    id_employee int(11) UNSIGNED DEFAULT NULL,
    message mediumtext NOT NULL,
    file_name varchar(255) DEFAULT NULL,
    ip_address varchar(32) DEFAULT NULL,
    ipv4_compat bigint(20) DEFAULT NULL,
    user_agent varchar(128) DEFAULT NULL,
    date_add datetime NOT NULL,
    date_upd datetime NOT NULL,
    private tinyint(4) NOT NULL DEFAULT 0,
    read tinyint(1) NOT NULL DEFAULT 0,
    PRIMARY KEY (id_customer_message),
    KEY id_customer_thread (id_customer_thread),
    KEY id_employee (id_employee)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

    A celle de la table de mon site :
    Structure de la table ps_customer_message

    DROP TABLE IF EXISTS ps_customer_message;
    CREATE TABLE ps_customer_message (
    id_customer_message int(10) UNSIGNED NOT NULL,
    id_customer_thread int(11) DEFAULT NULL,
    id_employee int(10) UNSIGNED DEFAULT NULL,
    message mediumtext CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL,
    file_name varchar(18) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL,
    ip_address varchar(16) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL,
    user_agent varchar(128) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL,
    date_add datetime NOT NULL,
    date_upd datetime NOT NULL,
    private tinyint(4) NOT NULL DEFAULT 0,
    read tinyint(1) NOT NULL DEFAULT 0
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

    Ca ferait déjà une table de réparée. Mais je ne suis pas sure.

    0
Se connecter pour répondre
 
bug26 1.624 front-office11 1.58 1.75 système5 paypal4 smtp3 https3 performance3 hack3 administration3 transporteurs3 module2 dashboard2 promotions2