Plantage màj 3.7.5 vers 3.8 : erreur 500 instantiation error

[FlodAriege]

Et là...

... c'est le drame !

Error: 500 Application Instantiation Error

[RobertG]

Lorsque tu restaures un site après plantage sur une mise à jour, tu as intérêt à supprimer le contenu du dossier du site pour ne conserver que le fichier de sauvegarde et kickstart, afin de repartir sur du "propre" et ne pas conserver de ficheirs provenant de la mise à jour.
Pour ça, en général par ftp je sors le fichier jpa pour le ramener à la racine, je crée un dossier "_archive" où je déplace par glisser-déposer tout ce qui vient de l'ancien site. Je le supprime plus tard.
Ainsi, on redémarre sur la copie conforme de l'ancien site, et dans ce cas, seul le cache JCH pourrait poser problème (alors qu'il le fera probablement à tout coup sur une copie du site), le .htaccess n'ayant pas à être modifié.

Sur les sites dont je m'occupe chez 1&1, j'utilise toujours le contenu du htaccess.txt avec la ligne RewriteBase décommentée.
Donc si tu accèdes à la gestion aeSecure du site, tu peux remplacer la partie personnelle du .htaccess par le contenu de ce fichier. Si je comprends bien le hack, il force l'utilisation de index.php

PS : il peut aussi être parfois utile de supprimer avant restauration toutes les tables correspondant au site. J'ai eu le cas de mises à jour plantant en raison de tables partiellement ajoutées par une mise à jour ratée, qui empêchaient une nouvelle tentative d'aboutir.

[FlodAriege]

Robert,
c'est bien ce que j'ai fait ici : partir d'une feuille blanche, dans un nouveau dossier, où j'ai déposé ma sauvegarde.

Quelques infos complémentaires sur le plantage (si ça peut parler à quelqu'une) :

dans l'admin, je lis en haut de page :
Notice: Constant _QQ_ already defined in /homepages/7/***/htdocs/***/libraries/src/Language/Language.php on line 18

puis je vois la liste des menus en liste à puces, mais aucun lien ne fonctionne (erreur 500)

dans le front, je vois :

Notice: Constant JROUTER_MODE_RAW already defined in /homepages/7/***/htdocs/***/libraries/cms/router/router.php on line 17

Notice: Constant JROUTER_MODE_SEF already defined in /homepages/7/***/htdocs/***/libraries/cms/router/router.php on line 24

Warning: Cannot modify header information - headers already sent by (output started at /homepages/7/***/htdocs/***/libraries/cms/router/router.php:17) in /homepages/7/***/htdocs/***/plugins/system/jsntplframework/libraries/joomlashine/template/helper.php on line 1247

Erreur 500

si j'essaie d'accéder à AeSecure (via le lien de menu présent dans le back office), je vois :

Notice: Constant JROUTER_MODE_RAW already defined in /homepages/7/***/htdocs/***/libraries/cms/router/router.php on line 17

Notice: Constant JROUTER_MODE_SEF already defined in /homepages/7/***/htdocs/***/libraries/cms/router/router.php on line 24

Warning: Cannot modify header information - headers already sent by (output started at /homepages/7/***/htdocs/***/libraries/cms/router/router.php:17) in /homepages/7/***/htdocs/***/templates/jsn_boot_pro/error.php on line 10


Ce que j'ai essayé de faire :
1) Remettre le htaccess par défaut
2) Décommenter la ligne :
RewriteBase /

3) en plus de 1 et 2 : remettre en place les lignes :
# 1&1 Hack
RewriteRule !index\.php - [C]
RewriteRule ^ /index.php

4) ajouter encore une ligne :
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?dossier\sousdomaine.monsite\.fr [NC]

5) ajouter encore ces 2 lignes :
RewriteCond %{HTTP_HOST} ^sousdomaine.monsite.fr$
RewriteRule ^(.*) http://www.soudomaine.monsite.fr/$1 [R=301,L]

6) supprimer la ligne ajoutée à l'étape 4

7) remplacer :
RewriteBase /
par :
RewriteBase /nomdossier
puis par :
RewriteBase /nomdossier/

... bref, j'ai bidouillé tout ce que j'ai pu, mais comme je ne sais pas ce que fais... évidemment, ça ne marche pas.

Je crois bien que je vais devoir me contenter de rester à la 3.7.5.

[RobertG]

Si tu as défini un nom de sous-domaine pointant vers le dossier de la copie, tu ne dois utiliser que "RewriteBase /" sans nom de dossier ajouté.
Si on parle bien du clone sur lequel tu veux tester, comme dit plus haut par daneel et manu93fr, supprime le .htaccess ou remets une version standard sans autre modification que la suppression du dièse devant RewriteBase, et accède à l'administration (si ça fonctionne) pour désactiver JCH et la réécriture au vol, ça devrait alors fonctionner.

Pour ce qui est des notices, on peut les oublier. Oublie aussi l'utilisation d'aeSecure sur ce site de test, de toutes manières, son .htaccess est désactivé, et sauf erreur de ma part, il enregistre des infos de localisation du site, or il n'est plus à sa place originelle.

Tu signales une erreur sur une extension JSN : il y a eu des plantages de mises à jour liée à des extensions de cet auteur : récupère les mises à jour sur son site et applique-les avant toute nouvelle tentative de mise à jour de Joomla!

[FlodAriege]

Alors :
J'ai remis le htaccess par défaut, en décommentant simplement RewriteBase (bizarre, car c'est ce que j'ai fait à l'étape tout à l'heure mais bon...)
Cette fois c'est un peu différent : l'admin s'affiche, mais je n'ai plus aucun menu nulle part, je n'ai qu'un écran bleu.
JCH était déjà désactivé avant cette dernière mise à jour, quant à aesecure (auquel j'accède car c'est le seul lien de menu qui subsiste dans l'admin), il est désactivé.

Quant à JSN, c'est l'éditeur de mon template, et j'avais vérifié avant de lancer la mise à jour : j'avais bien la dernière mise à jour du template ET de son framework... donc je ne vois pas trop quoi faire à vrai dire ... D'autant que je viens de revérifier sur mon site en production : template et framework affiche 'dernière version' et il n'y a donc aucun lien cliquable pour accéder à un quelconque téléchargement...

EDIT : et pour qu'on soient surs de tous parler de la même chose, ci-joint une capture d'écran de mon administration

[RobertG]

Compte tenu du nombre d'incidents avec des extensions JSN, templates ou autres, j'ai un doute sur la certitude de la présence de la dernière version disponible. As-tu contrôlé sur le site JoomlaShine ?

Au besoin, contacte-moi en privé pour que je jette un œil sur la copie du site.

[FlodAriege]

Salut,
Le week-end dernier j'ai eu un chat avec leurs services malheureusement c'était plutôt un interlocuteur commercial qui m'a renvoyée vers mon back office, lequel affiche "latest version" (template et framework).
Pour pouvoir te répondre, je viens donc de poser la question sur leur forum technique : où (diable) sont (passés) les téléchargements ??
Je t'envoie l'adresse du clone en MP.
Merci.

[RobertG]

Le point sur la question : à partir de la dernière sauvegarde fonctionnelle de ce clone, version 3.7.5 testée en local, aeSecure, SEF et .htaccess désactivés, toutes extensions mises à jour sauf JQuery Easy qu'il faut passer manuellement de 1.6 à 2, base à jour, il restait à tenter, après sauvegarde, une mise à jour en 3.8.6
Rien à faire, ni en transfert direct ni par chargement du pack d'update. Je n'ai pas noté le message d'erreur, et j'ai écrasé avec les fichiers du pack.

Une fois fait, impossible de gérer le site : les liens de menus ne montraient que leurs chaînes, pas leur traduction, les liens provoquaient des erreurs (500 ? j'ai oublié...). Impossible d'accéder à la page de correction de la base, je suis donc passé par postupdate.php pour le faire et l'administration est redevenue accessible.

Côté site, un warning sur un plugin à mettre à jour (il n'utilise pas le système intégré), ce qui a résolu cette erreur, et un module (idem) qui n'a pas de mise à jour mais dont la correction du code n'a pris que quelques secondes.

Je me suis plus tard aperçu que le chemin vers le dossier "tmp" n'était que "tmp" et pas celui, complet, qu'on avait pour "logs" dans le fichier de configuration de ce même site. Est-ce la cause d'une partie des problèmes ? Je ne saurais l'affirmer, car je n'étais pas allé vérifier les permissions des dossiers avant cette tentative de mise à jour !

A propos : est-il possible de réduire le nombre de versions des items Flexicontent ? La base en comporte plus de 50.000 soit plus de 75 Mo de données,alors qu'il n'y a que 484 éléments dans la gestion de Flexi. (je n'utilise pas ce composant)

[FlodAriege]

Bonjour à toutes et tous,

Alors voilà : RobertG m'a sortie de la panade, et a réussi à mettre mon site à jour.
Non sans peine (cf son post juste au-dessus).
J'aurais bien été infichue de réaliser toutes ces opérations, très techniques de mon point de vue, et serai restée plantée sur 3.7.5 sans son intervention.
Je l'ai déjà remercié, mais je tiens ici à le remercier de nouveau, et publiquement :
Merci à mon sauveur 2018 : RobertG


Il me reste quelques points à vérifier, et notamment :

Je me suis plus tard aperçu que le chemin vers le dossier "tmp" n'était que "tmp" et pas celui, complet, qu'on avait pour "logs" dans le fichier de configuration de ce même site. Est-ce la cause d'une partie des problèmes ? Je ne saurais l'affirmer, car je n'étais pas allé vérifier les permissions des dossiers avant cette tentative de mise à jour !

Dois-je faire quelque chose à ce sujet ?
Veux-tu que je vérifie, avant d'envoyer mon domaine pointer vers la version 3.8.6, les permissions des dossiers sur l'ancienne version en 3.7.5 qui est toujours en ligne ?

A propos : est-il possible de réduire le nombre de versions des items Flexicontent ? La base en comporte plus de 50.000 soit plus de 75 Mo de données,alors qu'il n'y a que 484 éléments dans la gestion de Flexi. (je n'utilise pas ce composant)

Pour ça, je dois interroger Flexicontent.
Mais pour ce faire, il faudrait que je comprenne un peu mieux de quoi on parle.
Si tu devais poser la question sur leur forum, comment la rédigerais-tu ?
(car pour moi,, un item Flexicontent est juste un article, et s'ils existent en plusieurs versions, je ne sais pas à quel endroit ces versions sont stockées)

Je te laisse répondre puis je passerai ce post en résolu.
(je crains toujours, en faisant ça, d'empêcher d'autres réponses, mais je me fais peut-être des idées)



J'en profite pour redire combien je suis attachée à la communauté des contributeur-rices sur ce forum, et donc combien Joomla! est une vraie solution libre, avec tout le support francophone nécessaire

[RobertG]

Si tu te contentes de faire pointer le nom de domaine vers le dossier de la nouvelle version, rien à faire pour le dossier "tmp", il est défini correctement. Rien ne t'empêche cependant de vérifier sur l'ancien.

Pour ce qui est de Flexicontent, c'est la table "#__flexicontent_items_versions" qui dépasse 75 Mo et compte plus de 50.000 lignes pour 484 éléments publiés ou non. N'utilisant pas Flexicontent et n'ayant pas passé de temps à chercher où un tel versionning y est défini, je te laisse voir avec eux.

[FlodAriege]

J'ai la réponse de Flexicontent, mais pour moi c'est du chinois (écrit en anglais, mais pour moi c'est quand même du chinois):

Hello

https://unix.stackexchange.com/questions/4105/how-do-i-count-all-the-files-recursively-through-directories

Open a linux command box into your server
and go to Joomla folder:

Execute
find -maxdepth 1 -type d | while read -r dir; do printf "%s:\t" "$dir"; find "$dir" -type f | wc -l; done
then
cd somefolder
when somefolder is the folder listing the large >10,000 of files

then execute again
then CD again


Toi comprendre ce que ça vouloir dire ??

[RobertG]

Ou tu as mal posé la question, ou alors celui qui t'a répondu a compris de travers ou pensait à autre chose !
La réponse concerne une recherche du nombre de fichiers dans les dossiers, donc l'autre question qui était de savoir pourquoi il y en a tant dans ton site.

Ce sont des lignes dans la base de données qu'on cherche à éliminer, dans la table "#__flexicontent_items_versions", ce qui n'a strictement rien à voir.

[FlodAriege]

Je repose la question autrement (sans doute n'ai-je pas été assez claire la 1ère fois), et je reviens avec la réponse dès que je l'ai.

[FlodAriege]

Alors :
de peur de mal traduire les termes techniques relatifs à la base de données, je préfère laisser la réponse en version originale.
La voici :

100 versions per item x 10 fields (core or custom) x 500 items = 50,000 rows
or
25 versions per item x 40 fields (core or custom) x 500 items = 50,000 rows

there is 1 row per field value


1. in component configuration, you can reduce the number of version to 5
2. then you can backup DB , go to you DB tool e.g. phpmyadming
and (empty / truncate) tables:
"*_flexicontent_items_versions"
"*_flexicontent_versions"

do not delete the table, only "truncate" them
FC code will (should) handle the empty version tables without any issues

Donc, pour ce qui est de paramétrer Flexicontent pour qu'il réduise le nombre de versions à l'avenir, je vais savoir gérer.

Par contre... pour ce qui est de faire du ménage dans la base de données sans l'esquinter, là c'est une autre paire de manches.
Je veux bien une petite explication de texte les copains

Merci d'avance.
Et... bonne semaine !

[RobertG]

Si je comprends bien, ont te demande de changer les paramètres de versioning (je n'ai rien vu pour quand j'y ai jeté un œil), mais ça ne suffira pas pour que Flexicontent fasse lui-même le ménage.

On te conseille donc de vider totalement les deux tables citées, ce qui est très simple : ouvre la base depuis l'administration de ton compte 1&1, clique sur le nom de la base en haut de la colonne de gauche, puis fais une sauvegarde, avant dans la colonne principale (la plus large), de chercher ces tables. Sur leur ligne, il y a un bouton "vider" sur lequel il suffit de cliquer puis de valider le choix pour que tout le contenu de la table soit supprimé.