NPDS : Gestion de contenu et de communauté
Content & Community Management System (CCMS) robuste, sécurisé, complet, performant, parlant vraiment français, libre (Open-Source) et gratuit.
36 visiteur(s) et 0 membre(s) en ligne.
Autres infos
Activité du Site
Pages vues depuis 25/05/2001 : 108 401 059
- Nb. de membres 8 693
- Nb. d'articles 1 695
- Nb. de forums 26
- Nb. de sujets 8
- Nb. de critiques 92
Index du forum »» Version future »» REvolution 16.3
Nouveau sujet
REvolution 16.3#26786Répondre
2Contributeur(s)
3 Modérateur(s)
fliaigre
Bonjour,
Je suis en cours de test de REvolution 16.3 et je bloque sur un point.
Lorsqu'il s'agit de se connecter sur un site existant en rev13. Plus besoin de transformer la base en utf8 si j'ai bien compris. Mais si je veux me connecter à mes identifiants et mots de passe ça ne fonctionne pas, a priori.
La raison les tables authors et user ont pas mal changé.
Du coup comment passer d'une base rev 13 vers une base rev 163?
Je suis en cours de test de REvolution 16.3 et je bloque sur un point.
Lorsqu'il s'agit de se connecter sur un site existant en rev13. Plus besoin de transformer la base en utf8 si j'ai bien compris. Mais si je veux me connecter à mes identifiants et mots de passe ça ne fonctionne pas, a priori.
La raison les tables authors et user ont pas mal changé.
Du coup comment passer d'une base rev 13 vers une base rev 163?
jpb
Yo
si je comprends bien tu veux que cela fonctionne avec des fichiers de 16.3 et une base 13 ...
cela ne peut pas fonctionner à cause des changements de structure entre une base 13 et une base 16 (et donc toujours pas de script pour faire cette mise à jour de la base...)
_donc en faisant abstraction des problème d'encodage ..._
en partant avec les fichier d'une 16.3
sauvegarde ta base
vide la
importe l'archive sql
et réimporte tes données (ça passera dans la plupart des tables et justement sauf pour celle qui auront des changements de structures ...et donc la il faudra que tu identifies ces changements) car dans certains cas des données de la base ne seront plus nécessaires et dans d'autres elles manqueront ...)
si je comprends bien tu veux que cela fonctionne avec des fichiers de 16.3 et une base 13 ...
cela ne peut pas fonctionner à cause des changements de structure entre une base 13 et une base 16 (et donc toujours pas de script pour faire cette mise à jour de la base...)
_donc en faisant abstraction des problème d'encodage ..._
en partant avec les fichier d'une 16.3
sauvegarde ta base
vide la
importe l'archive sql
et réimporte tes données (ça passera dans la plupart des tables et justement sauf pour celle qui auront des changements de structures ...et donc la il faudra que tu identifies ces changements) car dans certains cas des données de la base ne seront plus nécessaires et dans d'autres elles manqueront ...)
fliaigre
Salut Jpb,
Avant toute chose, merci pour le travail que vous faites bénévolement. J'imagine bien que c'est un gros travail. Je dis ça pour tempérer les critiques que je vais formuler derrière.
Le problème jpb c'est que depuis Rev 16 il n'y a plus de mise à jour possible avec la génération 13, ni même entre la 16.2 et la 16.3.
Alors pour quelqu'un qui démarre ça ne pose pas forcément de problème mais ceux qui, comme moi, utilisent npds depuis son origine ça pose un gros problème. Nous avons des communautés importantes et donc des bases de données très grosses. Ces bases ne se manipulent pas comme des bases de données de quelques Mo.
Si je parle de mon cas. Je suis en Rev 13 parce que j'attendais les évolutions des versions 16. Le soucis c'est que Rev 13 n'est pas compatible avec Php7. La limite c'est 5.6 qui demande de mettre la base en utf8. Mais il n'existe pas pour 5,6(enfin je pense) d'exemple de templates responsive. Etant chez Infomaniak je ne peux pas muter vers les nouveaux hébergements parce qu'ils commencent à 5.6, je ne peux pas mettre le site en https et je vois bien que sans le SSL et sans thème responsive Google ne fait pas de cadeau.
Je ne sais pas si, dans l'équipe de développement, vous avez des gens comme moi. Une bonne connaissance de Npds, une grande ancienneté dans la gestion de communauté, pas de compétences en terme de développement, cela vous permettrait d'entendre la parole de l'utilisateur.
Je vais vérifier un truc. Partir d'une 16.2 à partir d'une base Rev 13. Il me semble qu'il y a moins de problème avec la base. En fait ce qui coince avec la 16.3 ce sont, a priori, les deux tables que j'ai cité. du fait de la modification de la gestion des mots de passe.
Je ne veux pas que vous preniez mes remarques pour de critiques gratuites. C'est juste pour faire entendre le point de vue d'un utilisateur.
Avant toute chose, merci pour le travail que vous faites bénévolement. J'imagine bien que c'est un gros travail. Je dis ça pour tempérer les critiques que je vais formuler derrière.
Le problème jpb c'est que depuis Rev 16 il n'y a plus de mise à jour possible avec la génération 13, ni même entre la 16.2 et la 16.3.
Alors pour quelqu'un qui démarre ça ne pose pas forcément de problème mais ceux qui, comme moi, utilisent npds depuis son origine ça pose un gros problème. Nous avons des communautés importantes et donc des bases de données très grosses. Ces bases ne se manipulent pas comme des bases de données de quelques Mo.
Si je parle de mon cas. Je suis en Rev 13 parce que j'attendais les évolutions des versions 16. Le soucis c'est que Rev 13 n'est pas compatible avec Php7. La limite c'est 5.6 qui demande de mettre la base en utf8. Mais il n'existe pas pour 5,6(enfin je pense) d'exemple de templates responsive. Etant chez Infomaniak je ne peux pas muter vers les nouveaux hébergements parce qu'ils commencent à 5.6, je ne peux pas mettre le site en https et je vois bien que sans le SSL et sans thème responsive Google ne fait pas de cadeau.
Je ne sais pas si, dans l'équipe de développement, vous avez des gens comme moi. Une bonne connaissance de Npds, une grande ancienneté dans la gestion de communauté, pas de compétences en terme de développement, cela vous permettrait d'entendre la parole de l'utilisateur.
Je vais vérifier un truc. Partir d'une 16.2 à partir d'une base Rev 13. Il me semble qu'il y a moins de problème avec la base. En fait ce qui coince avec la 16.3 ce sont, a priori, les deux tables que j'ai cité. du fait de la modification de la gestion des mots de passe.
Je ne veux pas que vous preniez mes remarques pour de critiques gratuites. C'est juste pour faire entendre le point de vue d'un utilisateur.
jpb
Tes remarques ne sont pas des critiques gratuites, elles sont tout à fait pertinentes ...
Je suis bien conscient de cette lacune que réprésente le manque du/des scripts de mise à jours qui pénalise hélas nos plus vieux utilisateurs ... C'est juste le reflet de la capacité/limite de l'équipe de développement ...
je ne pense pas que la taille des bases soit un problème en soit ....
pour info l'état de l'avancée : https://github.com/npds/npds_migration
... cela ne demande qu'a être finalisé ...
####
La raison les tables authors et user ont pas mal changé. <== oui entre 16.2 et 16.3
un champ a été ajouté dans ces deux tables
hashkey tinyint(1) NOT NULL DEFAULT '0',
et la longueur des champ password (pwd et pass) augmenté à 60 ....
Je suis bien conscient de cette lacune que réprésente le manque du/des scripts de mise à jours qui pénalise hélas nos plus vieux utilisateurs ... C'est juste le reflet de la capacité/limite de l'équipe de développement ...
je ne pense pas que la taille des bases soit un problème en soit ....
pour info l'état de l'avancée : https://github.com/npds/npds_migration
... cela ne demande qu'a être finalisé ...
####
La raison les tables authors et user ont pas mal changé. <== oui entre 16.2 et 16.3
un champ a été ajouté dans ces deux tables
hashkey tinyint(1) NOT NULL DEFAULT '0',
et la longueur des champ password (pwd et pass) augmenté à 60 ....
Message édité par : jpb / 08-01-2022 14:17
Message édité par : jpb / 08-01-2022 14:17
fliaigre
Si ça peut aider quelqu'un voici comment j'ai procédé pour passer ma base de 13 à 16.3
1/Sauvegarde de la base existante
2/Importation avec phpmyadmin de la base existante
3/Modification des tables axistantes Ajout/Suppression/Modification des champs en tenant compte de la base rev 16.3 d'installation en local.
Voici la liste tables à modifier :
• Table authors : supprimer des champs + ajouter un champ après psw hashkey tinyint(1) NOT NULL DEFAULT '0',
• Table 'counter' ajouter un champ `id_stat` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
• Table `seccont supprimer des champs
• Table user supprimer des champs + ajouter un champ après pass hashkey tinyint(1) NOT NULL DEFAULT '0',
• Table user status renommer rank en rang
Sauvegarder la base seulement les données
On va utiliser une base d'installation 16.3, elle n'est donc pas vide donc avant d'importer les données il faudra vider les tables dans lesquelles ont doit importer des données.
16.3 demande trois tables supplémentaires table `droits`,table ‘fonctions‘ , table ‘ip_loc’ bien sur ne pas vider celle-ci
Importer dans la base 16.3 les données issues de la base 13.
Si vous n'avez rien oublié ça devrait bien se passer.
Ensuite il vous reste à personnaliser le thème.
Il est possible de procéder autrement en ajoutant les données dans le fichier sql de la base 16 ou en remplaçant dans le fichier sql structure et données de la 13:
par
Pour être sur copiez/collez depuis le fichier sql de la 16.
Toutes les manipulations de Suppression/Modification/Création de champ se font facilement avec phpmyadmin.
Je l'ai fait avec une petite base de 3 Mo environ. je persiste à dire qu'avec une base de plusieurs centaines de MO c'est bien plus lourd en importation de données.
1/Sauvegarde de la base existante
2/Importation avec phpmyadmin de la base existante
3/Modification des tables axistantes Ajout/Suppression/Modification des champs en tenant compte de la base rev 16.3 d'installation en local.
Voici la liste tables à modifier :
• Table authors : supprimer des champs + ajouter un champ après psw hashkey tinyint(1) NOT NULL DEFAULT '0',
• Table 'counter' ajouter un champ `id_stat` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
• Table `seccont supprimer des champs
• Table user supprimer des champs + ajouter un champ après pass hashkey tinyint(1) NOT NULL DEFAULT '0',
• Table user status renommer rank en rang
Sauvegarder la base seulement les données
On va utiliser une base d'installation 16.3, elle n'est donc pas vide donc avant d'importer les données il faudra vider les tables dans lesquelles ont doit importer des données.
16.3 demande trois tables supplémentaires table `droits`,table ‘fonctions‘ , table ‘ip_loc’ bien sur ne pas vider celle-ci
Importer dans la base 16.3 les données issues de la base 13.
Si vous n'avez rien oublié ça devrait bien se passer.
Ensuite il vous reste à personnaliser le thème.
Il est possible de procéder autrement en ajoutant les données dans le fichier sql de la base 16 ou en remplaçant dans le fichier sql structure et données de la 13:
DROP TABLE IF EXISTS users_status;
CREATE TABLE users_status (
uid int(11) NOT NULL auto_increment,
posts int(10) DEFAULT '0',
attachsig int(2) DEFAULT '0',
rang int(10) DEFAULT '0',
level int(10) DEFAULT '1',
open tinyint(1) DEFAULT '1' NOT NULL,
groupe varchar(34),
PRIMARY KEY (uid)
);
INSERT INTO users_status VALUES ( .........);
par
DROP TABLE IF EXISTS `users_status`;
CREATE TABLE IF NOT EXISTS `users_status` (
`uid` int(11) NOT NULL AUTO_INCREMENT,
`posts` int(10) DEFAULT '0',
`attachsig` int(2) DEFAULT '0',
`rang` int(10) DEFAULT '0',
`level` int(10) DEFAULT '1',
`open` tinyint(1) NOT NULL DEFAULT '1',
`groupe` varchar(34) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
PRIMARY KEY (`uid`)
) ENGINE=MyISAM AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
INSERT INTO users_status VALUES ( .........);
Pour être sur copiez/collez depuis le fichier sql de la 16.
Toutes les manipulations de Suppression/Modification/Création de champ se font facilement avec phpmyadmin.
Je l'ai fait avec une petite base de 3 Mo environ. je persiste à dire qu'avec une base de plusieurs centaines de MO c'est bien plus lourd en importation de données.
fliaigre
Sinon j'utilise le module block-User_Info version rev il fonctionne mais il envoie des notices avec php 7.4
Exemple en lignes 119 et 120 il y a
block-User_Info Warning: Use of undefined constant username - assumed 'username' (this will throw an Error in a future version of PHP) in C:\wamp64_2\www\revolution_163\modules\block-User_Info\block-User_Info.php on line 119 et plusieurs lignes
Exemple en lignes 119 et 120 il y a
$ibid[$i][username] = $session[username];
$ibid[$i][time] = $session[time];
il faut que les indice de tes tableaux (quand ce ne sont pas des variables) soit protégés par des '' ou des "" suivant le contexte
par exemple :
$ibid[$i]['username']
sinon php prend l'indice pour une constante ..... et comme elle n'est pas définie ...
par exemple :
$ibid[$i]['username']
sinon php prend l'indice pour une constante ..... et comme elle n'est pas définie ...
jpb
Citation : fliaigre
Si ça peut aider quelqu'un voici comment j'ai procédé pour passer ma base de 13 à 16.3
1/Sauvegarde de la base existante
2/Importation avec phpmyadmin de la base existante
3/Modification des tables axistantes Ajout/Suppression/Modification des champs en tenant compte de la base rev 16.3 d'installation en local.
Voici la liste tables à modifier :
• Table authors : supprimer des champs + ajouter un champ après psw hashkey tinyint(1) NOT NULL DEFAULT '0',
• Table 'counter' ajouter un champ `id_stat` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
• Table `seccont supprimer des champs
• Table user supprimer des champs + ajouter un champ après pass hashkey tinyint(1) NOT NULL DEFAULT '0',
• Table user status renommer rank en rang
Sauvegarder la base seulement les données
On va utiliser une base d'installation 16.3, elle n'est donc pas vide donc avant d'importer les données il faudra vider les tables dans lesquelles ont doit importer des données.
16.3 demande trois tables supplémentaires table `droits`,table ‘fonctions‘ , table ‘ip_loc’ bien sur ne pas vider celle-ci
Importer dans la base 16.3 les données issues de la base 13.
Si vous n'avez rien oublié ça devrait bien se passer.
Ensuite il vous reste à personnaliser le thème.
Il est possible de procéder autrement en ajoutant les données dans le fichier sql de la base 16 ou en remplaçant dans le fichier sql structure et données de la 13:
par
Pour être sur copiez/collez depuis le fichier sql de la 16.
Toutes les manipulations de Suppression/Modification/Création de champ se font facilement avec phpmyadmin.
Je l'ai fait avec une petite base de 3 Mo environ. je persiste à dire qu'avec une base de plusieurs centaines de MO c'est bien plus lourd en importation de données.
Si ça peut aider quelqu'un voici comment j'ai procédé pour passer ma base de 13 à 16.3
1/Sauvegarde de la base existante
2/Importation avec phpmyadmin de la base existante
3/Modification des tables axistantes Ajout/Suppression/Modification des champs en tenant compte de la base rev 16.3 d'installation en local.
Voici la liste tables à modifier :
• Table authors : supprimer des champs + ajouter un champ après psw hashkey tinyint(1) NOT NULL DEFAULT '0',
• Table 'counter' ajouter un champ `id_stat` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
• Table `seccont supprimer des champs
• Table user supprimer des champs + ajouter un champ après pass hashkey tinyint(1) NOT NULL DEFAULT '0',
• Table user status renommer rank en rang
Sauvegarder la base seulement les données
On va utiliser une base d'installation 16.3, elle n'est donc pas vide donc avant d'importer les données il faudra vider les tables dans lesquelles ont doit importer des données.
16.3 demande trois tables supplémentaires table `droits`,table ‘fonctions‘ , table ‘ip_loc’ bien sur ne pas vider celle-ci
Importer dans la base 16.3 les données issues de la base 13.
Si vous n'avez rien oublié ça devrait bien se passer.
Ensuite il vous reste à personnaliser le thème.
Il est possible de procéder autrement en ajoutant les données dans le fichier sql de la base 16 ou en remplaçant dans le fichier sql structure et données de la 13:
DROP TABLE IF EXISTS users_status;
CREATE TABLE users_status (
uid int(11) NOT NULL auto_increment,
posts int(10) DEFAULT '0',
attachsig int(2) DEFAULT '0',
rang int(10) DEFAULT '0',
level int(10) DEFAULT '1',
open tinyint(1) DEFAULT '1' NOT NULL,
groupe varchar(34),
PRIMARY KEY (uid)
);
INSERT INTO users_status VALUES ( .........);
par
DROP TABLE IF EXISTS `users_status`;
CREATE TABLE IF NOT EXISTS `users_status` (
`uid` int(11) NOT NULL AUTO_INCREMENT,
`posts` int(10) DEFAULT '0',
`attachsig` int(2) DEFAULT '0',
`rang` int(10) DEFAULT '0',
`level` int(10) DEFAULT '1',
`open` tinyint(1) NOT NULL DEFAULT '1',
`groupe` varchar(34) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
PRIMARY KEY (`uid`)
) ENGINE=MyISAM AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
INSERT INTO users_status VALUES ( .........);
Pour être sur copiez/collez depuis le fichier sql de la 16.
Toutes les manipulations de Suppression/Modification/Création de champ se font facilement avec phpmyadmin.
Je l'ai fait avec une petite base de 3 Mo environ. je persiste à dire qu'avec une base de plusieurs centaines de MO c'est bien plus lourd en importation de données.
tu as aussi ça :
fusion des tables mainblock et adminblock ....
https://github.com/npds/npds_dune/commit/c4784ca2f2dc42b6421115b97a61e50f89dedb2d#diff-a5b056716fd3d0d00a69f81c2c72be952a448f51c5148616a3e22c22bfb035cb
fliaigre
Super
Il me reste une notice :
Je suppose que c'est une histoire de syntaxe
En tout cas merci pour ton aide
Il me reste une notice :
Warning: mktime() expects at most 6 parameters, 7 given in C:\wamp64_2\www\revolution_163\modules\block-User_Info\block-User_Info.php on line 249
248 $today = getdate();
249 $today = mktime ( 0, 0, 0, $today['mon'] , $today['mday'], $today['year'], -1);
250$yesterday = $today - (60*60*24);
Je suppose que c'est une histoire de syntaxe
En tout cas merci pour ton aide
jpb
oui tu as un paramètre en trop ! ... reste à savoir lequel lol ...
voici les 6 paramètres que tu peux avoir...
int $hour,
?int $minute = null,
?int $second = null,
?int $month = null,
?int $day = null,
?int $year = null
à quoi sert le -1 (si tu veux faire un calcul il doit etre en dehors ...
$today = mktime ( 0, 0, 0, $today ['mon'] , $today['mday'], $today['year']) -1 ; (ici le -1 enlève une seconde ... ...)
voici les 6 paramètres que tu peux avoir...
int $hour,
?int $minute = null,
?int $second = null,
?int $month = null,
?int $day = null,
?int $year = null
à quoi sert le -1 (si tu veux faire un calcul il doit etre en dehors ...
$today = mktime ( 0, 0, 0, $today ['mon'] , $today['mday'], $today['year']) -1 ; (ici le -1 enlève une seconde ... ...)
Message édité par : jpb / 09-01-2022 11:20
Message édité par : jpb / 09-01-2022 11:23
Message édité par : jpb / 09-01-2022 11:25
jpb
Citation : fliaigre
OK donc mainblock et adminblock sont rassemblées dans block.
C'est ça?
OK donc mainblock et adminblock sont rassemblées dans block.
C'est ça?
yes au total sans module tu dois avoir 66 tables ...