Jump to content
kurtspirit

Page blanche FO et accès interdit BO après upgrade

Recommended Posts

Posted (edited)

Bonjour,

je viens d'effectuer la mise à jour de mon Presta de la version 1.6.x vers la dernière version 1.7.x.

J'ai bien entendu effectué la mise à jour via le module 1clickupgrade et j'ai eu une alerte :
 

SQL 1.7.0.0 1786 in /* Create a copy without indexes to make ID updates without conflict. */ CREATE TABLE `ps_access_old` AS SELECT * FROM `ps_access`: Statement violates GTID consistency: CREATE TABLE ... SELECT.

SQL 1.7.0.0 1146 in /* Update access tab IDs */ UPDATE `ps_access_old` ao SET `id_tab` = ( /* Update tab ID if possible, leave as is if the tab does not exist anymore */ SELECT IFNULL(`id_new_tab`, ao.`id_tab`) FROM `ps_tab_transit` WHERE `id_old_tab` = ao.`id_tab` ): Table 'dbs56363.ps_access_old' doesn't exist 

J'ai donc lancé le FO après la mise à jour et j'ai une page blanche. J'ai activé le mode debug et j'ai une grosse erreur :

 (1/1) ContextErrorException

Warning: Declaration of BWDisplay::setTemplate($template) should be compatible with FrontControllerCore::setTemplate($template, $params = Array, $locale = NULL)
in Display.php line 48
at ErrorHandler->handleError(2, 'Declaration of BWDisplay::setTemplate($template) should be compatible with FrontControllerCore::setTemplate($template, $params = Array, $locale = NULL)', '/homepages/38/d562708948/htdocs/repairmobilecenter/modules/sendinblue/backward_compatibility/Display.php', 48, array())in backward.php line 38
at require_once()in backward.php line 38
at require('/homepages/38/d562708948/htdocs/repairmobilecenter/modules/sendinblue/backward_compatibility/backward.php')in sendinblue.php line 88
at Sendinblue->__construct()
at ReflectionClass->newInstance()in Container.php line 130
at Container->makeInstanceFromClassName('sendinblue', array('sendinblue' => true))in Container.php line 163
at Container->doMake('sendinblue', array('sendinblue' => true))in Container.php line 176
at Container->make('sendinblue')in ServiceLocator.php line 65
at ServiceLocator::get('sendinblue')in Module.php line 1137
at ModuleCore::coreLoadModule('sendinblue')in Module.php line 1116
at ModuleCore::getInstanceByName('sendinblue')in Hook.php line 880
at HookCore::exec('displayHeader')in FrontController.php line 555
at FrontControllerCore->initContent()in IndexController.php line 37
at IndexControllerCore->initContent()in Controller.php line 281
at ControllerCore->run()in Dispatcher.php line 511
at DispatcherCore->dispatch()in index.php line 28

Je suis retourné vers le BO et j'ai des accès interdits quasiment partout... Je pense que la table ps_access a un soucis mais je ne sais comment le résoudre.

Voici la table ps_access qui me semble étonnamment vide 😕 :

--
-- Structure de la table `ps_access`
--

CREATE TABLE `ps_access` (
  `id_profile` int(10) UNSIGNED NOT NULL,
  `id_authorization_role` int(10) UNSIGNED NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--
-- Index pour les tables exportées
--

--
-- Index pour la table `ps_access`
--
ALTER TABLE `ps_access`
  ADD PRIMARY KEY (`id_profile`,`id_authorization_role`);

/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

 

Pourriez-vous m'aider sur le coup s'il vous plait ? Merci par avance ;)

Jonathan

Edited by kurtspirit (see edit history)

Share this post


Link to post
Share on other sites

Le mécanisme de permission a changé radicalement en 1.7. La table ps_access ne sert pas

Share this post


Link to post
Share on other sites
1 minute ago, doekia said:

Le mécanisme de permission a changé radicalement en 1.7. La table ps_access ne sert pas

Ah ok... alors je n'explique pas du tout le pourquoi de l'accès interdit ainsi que l'erreur FO 😕 

Share this post


Link to post
Share on other sites

Si vous avez fait la mise à jour sur votre boutique en production, je vous recommande de demander à votre hébergeur de restaurer une sauvegarde de vos fichiers et de votre base de données. Pour revenir à l'ancienne version fonctionnelle. Si l'hébergeur fait des sauvegardes, il devrait être en capacité de restaurer votre site avec une sauvegarde de la veille de votre tentative de mise à jour.

La mise à jour n'a pas fonctionné correctement, il ne faut jamais faire de mise à jour directement sur la boutique en production.

Dans votre cas, là mise à jour de la base de données ne s'est pas déroulée comme prévue et vous avez des modules incompatibles avec la nouvelle version.

Il vaut mieux faire une copie de votre boutique en local ou sur un autre espace sur votre serveur pour tenter de faire une mise à jour afin d'éviter de tout casser sur la boutique de production. Surtout lorsque vous faites une mise à jour majeure, passer de la 1.6 à la 1.7 ça ne se fait pas en quelques clics et demande généralement beaucoup d'ajustements.

De nombreux sujets et tutoriaux sont disponibles sur le forum, renseignez vous avant de faire des mises à jour.

Share this post


Link to post
Share on other sites
1 minute ago, Janett said:

Si vous avez fait la mise à jour sur votre boutique en production, je vous recommande de demander à votre hébergeur de restaurer une sauvegarde de vos fichiers et de votre base de données. Pour revenir à l'ancienne version fonctionnelle. Si l'hébergeur fait des sauvegardes, il devrait être en capacité de restaurer votre site avec une sauvegarde de la veille de votre tentative de mise à jour.

La mise à jour n'a pas fonctionné correctement, il ne faut jamais faire de mise à jour directement sur la boutique en production.

Dans votre cas, là mise à jour de la base de données ne s'est pas déroulée comme prévue et vous avez des modules incompatibles avec la nouvelle version.

Il vaut mieux faire une copie de votre boutique en local ou sur un autre espace sur votre serveur pour tenter de faire une mise à jour afin d'éviter de tout casser sur la boutique de production. Surtout lorsque vous faites une mise à jour majeure, passer de la 1.6 à la 1.7 ça ne se fait pas en quelques clics et demande généralement beaucoup d'ajustements.

De nombreux sujets et tutoriaux sont disponibles sur le forum, renseignez vous avant de faire des mises à jour.

J'ai fais la mise à jour sur une copie de mon site bien entendu... Je ne suis pas dingue :) . Il s'agit d'un dossier spécifique pour la mise à jour. Faire un rollback n'est pas la solution pour moi sur le coup, il faut que je trouve la solution. J'ai désactivé les modules incompatibles et j'ai donc maintenant un FO pas terrible mais plus d'erreurs affichées.

Pour ce qui est du Back Office, je cherche donc à résoudre ce problème de Accès interdit qui doit bien avoir une raison 😕 .

Merci en tout cas pour la suggestion mais je vais attendre d'avoir de nouvelles propositions de solutions. Je me doute que la mise à jour majeure ne se fait pas en un ou deux clics 😛 .

Share this post


Link to post
Share on other sites

Parfait, je n'avais pas compris cela 👍

Bon pour en revenir à vos soucis de permissions, la table ps_access sert toujours en 1.7

La mise à jour de votre base de données à échouée sur cette partie d'où votre problème. Il va falloir reconstruire les données des tables liées aux permissions pour résoudre le problème.

Il faut commencer par regardé pourquoi cette partie de la mise à jour n'a pas fonctionné dans votre cas, peut être un problème de permissions de votre utilisateur MySQL par exemple. Est ce que vous avez plus d'informations dans vos logs sur cette partie ?

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
5 minutes ago, Janett said:

Parfait, je n'avais pas compris cela 👍

Bon pour en revenir à vos soucis de permissions, la table ps_access sert toujours en 1.7

La mise à jour de votre base de données à échouée sur cette partie d'où votre problème. Il va falloir reconstruire les données des tables liées aux permissions pour résoudre le problème.

Il faut commencer par regardé pourquoi cette partie de la mise à jour n'a pas fonctionné dans votre cas, peut être un problème de permissions de votre utilisateur MySQL par exemple. Est ce que vous avez plus d'informations dans vos logs sur cette partie ?

Dans les logs, j'ai juste ceci :

UPDATE `ps_access_old` ao SET `id_tab` = (
  /* Update tab ID if possible, leave as is if the tab does not exist anymore */
  SELECT IFNULL(`id_new_tab`, ao.`id_tab`) FROM `ps_tab_transit` WHERE `id_old_tab` = ao.`id_tab`
): Table 'dbs56363.ps_access_old' doesn't exist</div>
[2019-04-29 10:03:37] SQL 1.7.0.0 1146 in /* Update access tab IDs */
UPDATE `ps_access_old` ao SET `id_tab` = (
  /* Update tab ID if possible, leave as is if the tab does not exist anymore */
  SELECT IFNULL(`id_new_tab`, ao.`id_tab`) FROM `ps_tab_transit` WHERE `id_old_tab` = ao.`id_tab`
): Table 'dbs56363.ps_access_old' doesn't exist

Je ne pense pas que ça soit bien utile hélas. Je ne sais pas quoi injecter, j'ai bien l'ancienne table ps_access si besoin. Merci à vous :)

Edited by kurtspirit (see edit history)

Share this post


Link to post
Share on other sites

Petite info, j'ai pris l'ancienne table ps_access et extrait les id_profile et id_tab puis injecté dans la database. 

Une fois actualisé, certains menu fonctionnent de nouveau dans le BO comme les produits par exemple, c'est super étrange. Le problème est surtout que les menus d'administrations / configurations ne fonctionnent pas. Il faut que je comprenne ce qui cloche dans cette table, il doit y avoir une valeur qui ne colle pas ou manque à l'appel.

Share this post


Link to post
Share on other sites

L'ancienne table ps_access ne pourra pas fonctionner correctement en 1.7 car des modifications sont nécessaires. C'est justement le but de la mise à jour de cette partie qui a échouée chez vous.

Si on regarde le fichier de mise à jour, on peut voir qu'il y a pas mal d'opération en SQL qui sont faites https://github.com/PrestaShop/PrestaShop/blob/1.7.5.x/install-dev/upgrade/sql/1.7.0.0.sql#L123

Attention il y a toute une série de requêtes jusqu'à la fin de ce fichier qui concernent ces tables ainsi que des scripts PHP qui sont appelés :

/* PHP:add_quick_access_tab(); */;

/* PHP:migrate_tabs_17(); */;

/* PHP:ps_1700_right_management(); */;

C'est tout cette partie SQL + scripts PHP qui a échoué sur votre mise à jour. Vous devez comprendre pourquoi avant de tenter de refaire le process de mise à jour du début.

Vérifier les droits de votre utilisateur MySQL, celui utilisé par Prestashop que vous avez indiqué dans config/settings.inc.php sur 1.6 et /app/config/parameters.php sur 1.7, peut être que cette utilisateur n'a pas les droits d'exécuter certaines actions utilisées par le script d'upgrade.

Share this post


Link to post
Share on other sites
Posted (edited)
8 hours ago, Janett said:

L'ancienne table ps_access ne pourra pas fonctionner correctement en 1.7 car des modifications sont nécessaires. C'est justement le but de la mise à jour de cette partie qui a échouée chez vous.

Si on regarde le fichier de mise à jour, on peut voir qu'il y a pas mal d'opération en SQL qui sont faites https://github.com/PrestaShop/PrestaShop/blob/1.7.5.x/install-dev/upgrade/sql/1.7.0.0.sql#L123

Attention il y a toute une série de requêtes jusqu'à la fin de ce fichier qui concernent ces tables ainsi que des scripts PHP qui sont appelés :

/* PHP:add_quick_access_tab(); */;

/* PHP:migrate_tabs_17(); */;

/* PHP:ps_1700_right_management(); */;

C'est tout cette partie SQL + scripts PHP qui a échoué sur votre mise à jour. Vous devez comprendre pourquoi avant de tenter de refaire le process de mise à jour du début.

Vérifier les droits de votre utilisateur MySQL, celui utilisé par Prestashop que vous avez indiqué dans config/settings.inc.php sur 1.6 et /app/config/parameters.php sur 1.7, peut être que cette utilisateur n'a pas les droits d'exécuter certaines actions utilisées par le script d'upgrade.

Alors au niveau des droits, je n'ai pas de soucis niveau MySQL... Sur Presta je vais vérifier mais j'ai un doute aussi. Je vais voir ça tout de suite et je fais un retour ici.

Merci en tout cas.

 

EDIT : Je viens de regarder et pas grand chose de mauvais en apparence :( . Nouveauté aussi : quand je clique trop "rapidement" sur les menus, j'ai une erreur :

[PrestaShopException]

Link to database cannot be established: SQLSTATE[HY000] [1203] User o56363 already has more than 'max_user_connections' active connections
at line 127 in file classes/db/DbPDO.php

122.     public function connect()
123.     {
124.         try {
125.             $this->link = $this->getPDO($this->server, $this->user, $this->password, $this->database, 5);
126.         } catch (PDOException $e) {
127.             throw new PrestaShopException('Link to database cannot be established: ' . $e->getMessage());
128.         }
129. 
130.         $this->link->exec('SET SESSION sql_mode = \'\'');
131. 
132.         return $this->link;

    DbPDOCore->connect - [line 330 - classes/db/Db.php]
    DbCore->__construct - [line 241 - classes/db/Db.php] - [4 Arguments]
    DbCore::getInstance - [line 48 - config/alias.php]
    pSQL - [line 340 - classes/shop/Shop.php] - [1 Arguments]
    ShopCore::initialize - [line 119 - config/config.inc.php]
    require - [line 42 - admin/index.php] - [1 Arguments]

ça sent pas bon cette histoire. Je vais tenter le rollback puisque je crois encore avoir accès à cette partie et tenter à nouveau la mise à jour.

Edited by kurtspirit (see edit history)

Share this post


Link to post
Share on other sites
Posted (edited)

Alors je viens de faire un rollback tout va bien en 1.6.1.18. Avant que je lance de nouveau une mise à jour via le module, dois-je faire des choses particulières?  J'ai bien entendu désactivé la boutique mais je sais pas si il y a autre chose?

Merci beaucoup !

Edit : désolé je fais des edit à chaque fois que je tente un truc ... J'ai essayé de nouveau un upgrade et j'ai une erreur directement maintenant à la mise à jour :

[Ajax / Server Error for action upgradeDb] textStatus: "error " errorThrown:"Internal Server Error " jqXHR: " "

Je sais pas d'où ça vient encore... J'ai essayé de faire une désactivation du backup auto comme j'ai pu lire sur la partie anglophone mais ça change rien au résultat... Je désespère :(

Edited by kurtspirit (see edit history)

Share this post


Link to post
Share on other sites
2 hours ago, kurtspirit said:

 


Link to database cannot be established: SQLSTATE[HY000] [1203] User o56363 already has more than 'max_user_connections' active connections

 

Votre serveur MySQL semble être un peu surchargé ! Vous êtes sur du mutualisé ?

Vraisemblablement vos soucis de mise à jour sont en partie liés à MySQL qui ne tient pas la charge.

Vous devriez tenter de faire la mise à jour sur un serveur plus puissant et mieux configuré ou de faire cela en local.

Share this post


Link to post
Share on other sites

Les précédentes migrations de Prestashop était mineures, la 1.7 est une version majeure avec beaucoup de changements notamment au niveau de la base de données.

C’est pour cela que le script fait des opérations assez lourdes sur la base lors du passage à la 1.7 et cela nécessite d’avoir un serveur bien configuré et pas trop bridé.

Autrement dit soit un serveur moyen gamme soit un serveur local pour une migration d’une version inférieure à la 1.7

En local, il faut veiller avoir une configuration PHP optimale en suivant les prerequis pour la 1.7

Share this post


Link to post
Share on other sites
2 minutes ago, Janett said:

Les précédentes migrations de Prestashop était mineures, la 1.7 est une version majeure avec beaucoup de changements notamment au niveau de la base de données.

C’est pour cela que le script fait des opérations assez lourdes sur la base lors du passage à la 1.7 et cela nécessite d’avoir un serveur bien configuré et pas trop bridé.

Autrement dit soit un serveur moyen gamme soit un serveur local pour une migration d’une version inférieure à la 1.7

En local, il faut veiller avoir une configuration PHP optimale en suivant les prerequis pour la 1.7

Je vais tenter l'upgrade via le local là et je vous dis tout ça :) . Merci pour le coup de pouce en tout cas !

Share this post


Link to post
Share on other sites
Posted (edited)
22 minutes ago, Janett said:

Les précédentes migrations de Prestashop était mineures, la 1.7 est une version majeure avec beaucoup de changements notamment au niveau de la base de données.

C’est pour cela que le script fait des opérations assez lourdes sur la base lors du passage à la 1.7 et cela nécessite d’avoir un serveur bien configuré et pas trop bridé.

Autrement dit soit un serveur moyen gamme soit un serveur local pour une migration d’une version inférieure à la 1.7

En local, il faut veiller avoir une configuration PHP optimale en suivant les prerequis pour la 1.7

Question : est-il possible de désactiver le SSL via un fichier config ou la DB ? La mise à jour s'est bien passée en local mais j'ai un soucis avec le SSL. Merci ;)

Trouvé merci ;) Dans la table PS_CONFIGURATION tout bêtement ! Tout fonctionne en local hormis le Front Office mais c'est due à beaucoup de modules non compatible.

Edited by kurtspirit (see edit history)

Share this post


Link to post
Share on other sites

Dernier post pour éviter trop de spams... J'ai donc la boutique plus ou moins en place, j'ai juste le FO qui ne contient plus rien après désactivation du module sendinblue qui posait soucis, j'ai juste mon logo et un vide puis Propulsé par Prestashop...

Au-delà de ça, j'ai encore un soucis en BO... Tout fonctionne sauf le catalogue de module (dommage :( ) , il me provoque une erreur :

Compile Error: Cannot declare class AeucCMSRoleEmailEntity, because the name is already in use

Avez-vous une idée de comment virer cette erreur s'il vous plait ? J'ai regardé sur le forum mais pas vu de solutions probantes.

Merci :)

Share this post


Link to post
Share on other sites

Il faut tenter de réinitialiser le thème afin qu’il n’active que les modules dont il a besoin sur les bons hooks et ça devrait être bon. La page de gestion des thèmes dans la 1.7 a été refaite récemment, je ne sais plus comment ça fonctionne sur les 1.7.5, essayer de chercher une option de réinitialisation sinon tenter de le désinstaller puis de réinstaller.

Sinon en 1.7.5, il y a une option de rajouter dans l’adresse &action=resetToDefaults&theme_name=classic à la fin de l’url de la page de gestion des thèmes qui fonctionne mais je ne trouve pas le bouton où le lien pour la déclencher sans modifier l’url... 

Vous avez peut être 2 fois le module de mise en conformité légale. Le soucis lors de la migration c’est souvent que les anciens modules 1.6 restent installés en plus des nouveaux de la 1.7 et évidemment ça pose problème... Comme ici avec la classe AeucCMSRoleEmailEntity. De toute façon le module de mise en conformité légale de la 1.7 ne fonctionne pas bien, il faut donc l’enlever.

Share this post


Link to post
Share on other sites
2 hours ago, Janett said:

Il faut tenter de réinitialiser le thème afin qu’il n’active que les modules dont il a besoin sur les bons hooks et ça devrait être bon. La page de gestion des thèmes dans la 1.7 a été refaite récemment, je ne sais plus comment ça fonctionne sur les 1.7.5, essayer de chercher une option de réinitialisation sinon tenter de le désinstaller puis de réinstaller.

Sinon en 1.7.5, il y a une option de rajouter dans l’adresse &action=resetToDefaults&theme_name=classic à la fin de l’url de la page de gestion des thèmes qui fonctionne mais je ne trouve pas le bouton où le lien pour la déclencher sans modifier l’url... 

Vous avez peut être 2 fois le module de mise en conformité légale. Le soucis lors de la migration c’est souvent que les anciens modules 1.6 restent installés en plus des nouveaux de la 1.7 et évidemment ça pose problème... Comme ici avec la classe AeucCMSRoleEmailEntity. De toute façon le module de mise en conformité légale de la 1.7 ne fonctionne pas bien, il faut donc l’enlever.

Bonjour,

merci énormément à vous. J'ai réussi à accéder enfin au catalogue de modules en désactivant manuellement le module : advancedeucompliance. Plus qu'à trouver comment réinitialiser le thème voir si ça me remet les menus et produits en page parce-que là c'est le vide intersidéral ;) . Merci encore !

  • Like 1

Share this post


Link to post
Share on other sites

Tentez de suivre la méthode en modifiant l’adresse de la page de gestion des thèmes comme indiqué ça devrait marcher. C’est à dire que vous aller sur la page de gestion des thèmes dans le back office puis vous copier coller ce que j’ai indiqué à la fin de l’adresse de cette page dans la barre d’adresse.

  • Like 2

Share this post


Link to post
Share on other sites
On 5/1/2019 at 1:16 PM, Janett said:

Tentez de suivre la méthode en modifiant l’adresse de la page de gestion des thèmes comme indiqué ça devrait marcher. C’est à dire que vous aller sur la page de gestion des thèmes dans le back office puis vous copier coller ce que j’ai indiqué à la fin de l’adresse de cette page dans la barre d’adresse.

Le thème apparait enfin ;) Merci beaucoup. Je vais passer à la mise en place d'un nouveau thème et essayer de mettre en ordre à peu près tout. Une fois fait, j'essaierai le transfert sur le FTP hébergeur voir si mon serveur est capable de supporter la version 1.7....

Merci énormément pour toute l'aide, je n'aurai pas réussi sans vous !

Belle journée et merci encore.

Jonathan.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More