[pierrepercee]

#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: #1.9.4.3
#~ Url du site :
#~ Hébergeur / Soft :
#~ Informations Système :
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~

Lors de la migration d'un site local en ligne, il m'arrive de faire une installation "à vide" en ligne pour récupérer un config.php fonctionnel. Cela fonctionne parfaitement et évite de "bricoler" le fichier config.php. La dernière fois, je mets en ligne et j'ai une erreur m'indiquant que la page n'est pas disponible à cette adresse. Logiquement, je me dis ce n'est pas un problème de connexion à la base de données, cela doit provenir de mon htaccess ou de mon config.php.
En fait lors de l'installation "à vide" du cms en local, j'ai par inadvertance supprimé un caractère du préfixe des tables.
Là, les choses se compliquent....La connexion à la base se fait, mais le cms ne peut effectuer d'opération....
L'erreur renvoyée n'est pas vraiment appropriée.
Je ne sais pas à quoi peut bien servir la possibilité de changer le préfixe des tables lors de l'installation (le nom de la base me paraît être un élément "d'identité" suffisant).
Il faudrait ou supprimer la possibilité de changer le préfixe, ou renvoyer un code erreur(désolé, c'était hier et je ne me souviens plus exactement de l'erreur renvoyée en anglais) un peu plus parlant, qui évite de se casser les dents pendant 20 minutes....
Ce n'est qu'un détail mais cela peut fortement pénaliser des utilisateurs non avertis...
Si cela peut aider certains !

[Eklo]

Changer le prefixe des tables permet tout simplement d'installer plusieurs sites cmsms sur une même base de données, c'est indispensable.

[bess]

+1 concernant la nécessité de gérer cmsmadesimple avec un préfixe (comme n'importe quel logiciel en fait)

prend la table commune : "user"

combien de logiciels l'utilisent ? forum, cms, wiki, blog, ... tous utilisent ce genre de table

alors tu installes un forum et un cms sur ton site, et PAF le chien plus rien ne marche ?

[pierrepercee]

Plusieurs sites sur une même base de données...honnêtement vu ce que coûtent les services d'hébergement aujourd'hui et au regard des risques de ce type de démarche, comment dire... pour un particulier désargenté qui fait un site sur ses vacances, je ne discute pas, mais cela ne me viendrait même pas à l'idée de proposer cela à un client. Ici et là pour 6 euros/mois on a 3 ou 4 bases Mysql....
Vu ce que "pompe" un seul site sur une base de données Mysql proposée avec un hébergement mutualisé, il doit falloir apprendre aux internautes à être patients...ce qui n'est pas leur vertu première hein
Je n'avais pas vu la chose sous cet angle.....
Bess, je n'ai pas parlé de supprimer la préfixation des tables, mais bien de ne pas permettre de la changer, ce qui est très différents. Une préfixation en cmsms_tkxcd aurait bien beu de chances d'être problématique non.
Dans tous les cas, cette fonctionnalité semble importante pour nombre d'entre nous, il faut donc la conserver mais faire en sorte qu'en cas d'incompatibilité entre le contenu du config.php et la préfixation réellement présente un message d'erreur pertinent soit retourné

[jissey]

salut,
ben quand un message d'erreur te dit que la connexion à la bdd a échoué, il y a un certain nombre de choses à vérifier. Et la cohérence entre les paramètres du fichier de config et la bdd est sans doute la première chose à vérifier.
Il y a beaucoup de personnes qui utilisent des hébergements gratuits et qui sont adeptes de cmsms.
C'est même une grande partie des utilisateurs.
Pour les autres, les pros ou ceux qui s'achètent un hébergement à 70€ l'année, ils sont suffisamment connaisseurs pour se dépatouiller.
Bien sûr comme à chaque fois, chaque nouveau cas nous fait perdre du temps, mais on avance

[pierrepercee]

Je me suis mal exprimé ou tu m'as mal lu Le message en anglais d'erreur était (je viens de refaire en local pour vérifier) "The requested URL was not found on this server." ce qui est très loin, tu en conviendras de te mettre sur la bonne piste. Je ne comprends d'ailleurs pas bien comment un tel message peut être retourné dans ce cas là. C'est une requête sql qui échoue à priori....
Ce n'est pas une urgence, c'est un problème ponctuel... mais qui peut bien embêter des développeurs expérimentés pendant un certain temps. Dans ces cas là, il faut remercier Wimerge pour la comparaison rapide des deux fichiers config.php (local et distant). Sur le message d'erreur retourné, à moins de s'appeler Einstein ou Madame Irma (c'est plus probable) je ne vois pas bien comment aller intuitivement gratter de ce côté là !

Donc si des utilisateurs de CMSMS ont le message d'erreur "The requested URL was not found on this server" en migrant un site local vers un serveur en ligne en utilisant le config.php de l'ancien site en ligne par exemple, ils peuvent utilement vérifier dans le config.php que la ligne

Code :

"$config['db_prefix'] = 'cms_';"

correspond bien à la préfixation de leurs tables en ligne !

[jce76350]

"The requested URL was not found on this server.

Es-tu sur que ce message vient de CMScms ou de Apache ??
Ce message est uniquement en Admin ou /et sur le site Web ??

J'ai fait des tests sur le v 1.10 en modifiant $config['db_prefix'] = 'xxxx';
et le message "The requested URL was not found on this server." est uniquement sur le site WEB (message apache)
sur l'admin un page connexion est proposé en version css themes\default
Et si login +pass --> Nom d'utilisateur ou mot de passe incorrect !!

Donc il me semble que ta conclusion

Donc si des utilisateurs de CMSMS ont le message d'erreur ...

est erronée

D'autre part pour installer sur un nouveau serveur, le WiKi indique bien
$config['db_prefix'] = 'cms_'; // Attention au préfix
D'où l'intérêt de lire la doc avant

[pierrepercee]

Bonsoir,

Il s'agit d'une version 1.9.4.3. Je croyais avoir compris qu'il était encore un peu tôt pour utiliser la 19.10 en production... J'ai bien compris qu'il s'agissait d'un message du serveur. C'est ce qui pose problème d'ailleurs, l'erreur de la requête sql due au nom de table qui ne correspond pas devrait être interceptée bien en amont, avant que le serveur ne retourne un message d'erreur inexploitable. Mes conclusions ne sont donc pas erronées. A priori lorsque l'on réinstalle un site, si l'on se connecte sur la partie publique, une erreur de ce type devrait renvoyer un message d'erreur idoine. Si vous pensez le contraire, disons que nos conceptions divergent.

[jce76350]

Je croyais avoir compris qu'il était encore un peu tôt pour utiliser la 19.10

je suppose la 1.10 ?
elle est bonne à mette en production avec les règles élémentaires

C'est ce qui pose problème d'ailleurs, l'erreur de la requête sql due au nom de table qui ne correspond pas devrait être interceptée bien en amont

ben Non l'adresse de la page Web, c'est une requête seulement HTTP donc qui ne passe pas par le SQL
Et donc comme le serveur apache ne trouve pas la page (URL) , il renvoi un message The requested URL was not found on this server.


[Résolu] au début du titre de votre 1er message lorsqu'une solution a été trouvée.

[bess]

je pondère ton message Jce76350 car j'ai bel et bien dit d'attendre une 1.10.1 avant de se jeter sur la production

La version 1.10 est une version majeure avec tout les inconvénients des nouvelles versions majeures que l'on connait. Inutile de se voiler la face, les versions majeures sont toujours les plus buggées, donc inutile de se jeter sur cette version pour mettre en prod, il est plus sérieux de laisser les utilisateurs les plus aguerrit passer devant.

C'est mon avis, il peut être partagé ou non par les lecteurs. Toujours est il que pierrepercee n'a pas inventé cette recommandation

dernier point (qui sera amené à changer prochainement d'ailleurs) le forum conserve le support 1.9.4.3 + 1.6.10/11 + 1.10.0, donc de manière pragmatique, rien n'empêche pierrepercee de conserver sa version (le temps que la team fr décide de supprimer le support 1.9.4.3 ce qui ne va plus tarder)

[jce76350]

La version 1.10 est une version majeure

Oui mais ... contrairement aux anciennes versions il y a eu une très très longue période de tests avant la sortie, et si on n'utilise que des modules qui ont fait leur preuves, il n'y a pas de restrictions, et à condition, par sécurité, de respecter les règles élémentaires ....
De plus si on veut que les bugs éventuels sortent, il faut bien des installations.
Après chacun fait comme il veut

Nota pour le moment la 1.10.01 corrige des bricoles

[bess]

je suis entièrement d'accord avec toi sur ces points suivant :

- la 1.10.0 s'avère être très stable et aura été bien plus testée que toutes les autres version de cmsmadesimple (hourra)
- il faut du volontaire pour éprouver cette version en prod, même en dehors de la phase de test
- si on installe du module compatible il n'y a pas de soucis

le point faible réside cependant dans le fait que certains développeurs peu regardant n'ont pas pris le temps de mettre à jour leur module pour le passage.

Je n'ai aucune statistique à donner mais combien de module n'ont pas de release depuis juin/juillet ?

Autant de source de merde pour les webmasters, d'autant que la plupart des développeurs n'utilisent pas le versionning min/max de cmsmadesimple dans leur module... bref un module soit disant compatible qui ne l'est pas...

Encore une fois je suis entièrement d'accord avec toi : à l'heure actuelle on va pouvoir dire "ouf, allez c'est bon tout le monde passe en 1.10" mais il y a un mois lorsque j'ai écrit l'avertissement "faisez gaffe aux pigeons bourrés" (comprenne qui pourra trouver cette subtile référence) on était pas dans le même environnement

et je réitère mes félicitations à toi et à tous les autres béta testeur sans qui on n'en serait pas à :

pour le moment la 1.10.01 corrige des bricoles

[pierrepercee]

On s'éloigne un peu du sujet là... Ma pratique est la suivante, pour les changements de version importants j'attends 3 semaines / 1 mois avant de migrer en production, c'est le temps nécessaire à la sortie de modules mis à jour et éventuellement d'une version corrective.
JCE, si vous trouvez normal qu'une erreur de requête SQL ne soit pas interceptée avec en retour le message d'erreur idoine sur l'url qui va bien, encore une fois, au risque de me répéter, nos conceptions divergent.
Je ne sais pas si Apache perd ses petits parce que la requête fait échouer un "include" (je n'ai pas même eu la curiosité d'aller voir...) mais dans tous les cas l'erreur devrait être gérée proprement avant qu'Apache ne nous gratifie de ce message.

Ce n'est pas grave, cela n'en lève rien aux grandes qualités de notre CMS préféré.... mais c'est bien une approche (je dirais plutôt une absence d'approche) discutable.

[bess]

petite hypothèse sur le fait que tu reçoive ce message

The requested URL was not found on this server.

Cette erreur est due au fait que l'url que tu tape ne correspond à aucune page "référencées" dans apache. Quelles sont les pages référencées ?

en premier il y a les fichiers existant dans les répertoires existant qui correspondent à ton url (c'est évident)
en second il y a les reroutages via .htaccess qui pointeront vers une autre url (chez nous index.php?page=...)

le soucis je penses c'est que comme index.php n'est pas fonctionnel (connexion bdd ko), au moment ou il essai de pointer vers index.php?page=toto, il n'y a pas de code HTTP 200 (=ok) qui est retourné par la page comme d'ordinaire mais un "c'est la merde y a rien qui marche"

ton navigateur ne reconnaissant pas le code "c'est la merde y a rien qui marche", il en déduit (faussement) que le serveur répond pas/mal

The requested URL was not found on this server.

[pierrepercee]

Merci pour le détail de l'explication Bess, je vois les choses de la même façon