Annonce

Écrire une réponse

Veuillez écrire votre message et l'envoyer

Cliquez dans la zone sombre de l'image pour envoyer votre message.

Retour

Résumé de la discussion (messages les plus récents en premier)

flop25
2017-08-24 22:39:05

[Github] Piwigo issue #670 en fait
je n'avais pas lu mysql 5.7 sur le premier post alors que je connais ces pb Désolé
En fait votre Piwigo est très ancien fait prouvé avec l'interclassement non utf8 : j'ai eu moi même des soucis d'interclassement avec ma très très vieille db

Baba B
2017-08-24 22:32:38

Bonjour,

J'ai identifié l'origine du problème: mySQL 5.7 ne supporte pas par défaut les dates avec des valeurs positionnées à "0000-00-00". D'autre part, à chaque mise à jour de structure d'une des tables, mySQL s'assure que cette contrainte est respectée pour toutes les valeurs par défaut et pour les valeurs déjà positionnées dans la table.

Ne souhaitant pas modifier ce comportement par défaut pour mySQL, j'ai donc passé en revue toutes les tables de piwigo et mis à jour les tables contenant des champs au format datetime ou date pour respecter cette consigne.

La migration s'effectue maintenant correctement, la commande d'optimisation également et la page d'édition d'un utilisateur s'affiche.

Ci-dessous, la liste des commandes passées sur la table avant migration. Liste testée avec une base 2.8.0 restaurée suite à la première tentative de migration. Dans le cas de mon site, le préfixe est pwg. A mettre à jour en fonction de votre configuration.

Code:

ALTER TABLE pwg_user_infos CHANGE registration_date registration_date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP; 
ALTER TABLE pwg_comments CHANGE date date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;
UPDATE pwg_groups SET lastmodified=CURRENT_TIMESTAMP();
ALTER TABLE pwg_history CHANGE date date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;
ALTER TABLE pwg_images CHANGE date_available date_available DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;
UPDATE pwg_images SET lastmodified=CURRENT_TIMESTAMP();
ALTER TABLE pwg_old_permalinks CHANGE date_deleted date_deleted DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;
ALTER TABLE pwg_rate CHANGE date date DATE NOT NULL DEFAULT '1970-01-01';
ALTER TABLE pwg_sessions CHANGE expiration expiration DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;
UPDATE pwg_tags SET lastmodified=CURRENT_TIMESTAMP();
ALTER TABLE pwg_upgrade CHANGE applied applied DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;

Dans le même temps, j'en ai profité pour exporter la base de données dans une nouvelle base avec le bon interclassement et jeux de caractères via la commande SQL suivante.

Code:

CREATE DATABASE pwg CHARACTER SET utf8 COLLATE utf8_general_ci

Quelques informations qui m'ont permis de diagnostiquer le problème et que je n'ai pas trouvées sur le site

  1/ Les scripts d'upgrade se trouvent dans le répertoire install et sont suffixés par le numéro de version. Ainsi, le script install/upgrade-2.9.0.php est lancé pour lancer la migration vers la version 2.9.0.

  2/ Les opérations de migration sont divisées en plusieurs scripts contenus dans le répertoire install/db. Ils sont préfixés par un numéro qui se retrouve dans la table *_upgrade. Les résultats individuels de chacun de ces scripts ne se retrouvent pas dans cette table. Si une erreur se produit, seule la première sera visible dans le fichier d'erreur du serveur web.
  Ces scripts contiennent notamment les requêtes SQL qui sont exécutées pour la migration. Ainsi, la requête suivante mentionnée dans le dernier post levait l'erreur ERROR 1067 (42000): Invalid default value for 'registration_date' si elle était effectuée directement sur la base de données avant migration.
 

Code:

  ALTER TABLE pwg_user_infos
  ADD COLUMN last_visit datetime default NULL,
  ADD COLUMN last_visit_from_history enum('true','false') NOT NULL default 'false'

Après ces investigations, j'ai trouvé un ticket fortement similaire à ce cas. Selon ma compréhension, le problème a été corrigé pour une nouvelle installation de piwigo mais pas (encore ?) pour une migration.
Le ticket est le [Github] Piwigo issue #443 corrigé dans la version 2.8.1 http://fr.piwigo.org/releases/2.8.1.


Bonne fin de journée et merci à tous pour votre aide

flop25
2017-08-23 22:17:58

si je peux me permettre, pouvez vous exécutez la requêts Sql suivante dans votre gestionnaire de base de données, sur la base en question

ALTER TABLE `pwg_user_infos`
  ADD COLUMN `last_visit` datetime default NULL,
  ADD COLUMN `last_visit_from_history` enum('true','false') NOT NULL default 'false' ;

et pouvez vous aller voir -tjrs dans votre gestionnaire de bdd- les utilisateurs et leurs permissions ? Est ce que l'utilisateur autorisé sur pwg_user_infos a les droits pour effectuer un ALTER ?

ddtddt
2017-08-23 13:11:30

Bonjour,

Tu peux m'envoyer le lien en MP

Baba B
2017-08-23 10:50:46

ddtddt a écrit:

Bonjour,

user guest est bien toujours présent dans la base de données ?

Oui, je confirme

ddtddt
2017-08-21 22:53:28

Bonjour,

user guest est bien toujours présent dans la base de données ?

Baba B
2017-08-18 10:56:37

Bonjour,
Toutes les lignes avec un id supérieur ou égal à 149 ont été supprimées avant les tests.

ddtddt
2017-08-18 09:01:37

Bonjour,

peux tu recomencer en supprimant également le 149

Baba B
2017-08-16 09:04:11

Oui, les trois symptômes évoqués dans le premier post sont identiques.

ddtddt
2017-08-15 19:55:02

Baba B a écrit:

Les lignes sont réapparues dans la table *_upgrade.

Y-a-t-il d'autres éléments à vérifier pour s'assurer que la mise à jour est complète ?
Merci encore

Le message d'erreur est exactement le même ?

Baba B
2017-08-12 14:11:42

Les lignes sont réapparues dans la table *_upgrade.

Y-a-t-il d'autres éléments à vérifier pour s'assurer que la mise à jour est complète ?
Merci encore

ddtddt
2017-08-12 12:59:20

Baba B a écrit:

Opération effectuée.
Les messages persistent...

Il a fait les mise à jour ?

Baba B
2017-08-12 11:54:59

Opération effectuée.
Les messages persistent...

ddtddt
2017-08-12 11:15:13

Bonjour,

tu rajoutes

upgrade.php à ton site il devrait lancer les mise à jour

si cela ne fonctionne pas ajoute en conf local

$conf['check_upgrade_feed'] = true;

Baba B
2017-08-12 07:39:01

Merci,

J'ai supprimé les lignes avec un id >= 149.
Pour un upgrade, je passe traditionnellement par l'interface d'administration qui me détecte la nouvelle version.

Pour cette fois-ci, la page d'accueil m'indique que je suis dans la dernière version de Piwigo.

Comment puis-je procéder ?

Pied de page des forums

Propulsé par FluxBB

github twitter newsletter Faire un don Piwigo.org © 2002-2024 · Contact