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

**RobertG** · 01/04/2018, 17h39

Bonjour,

Je découvre grâce à toi cette nouvelle proposition de 1&1.
Je n'ai a priori pas d'idée sur l'intérêt d'un tel upgrade, tout dépendant surtout de l'importance de la fréquentation et de la sollicitation de mémoire.
Sur mon serveur PHPNET, j'atteins, avec mes sites pro, perso et de test (tous peu visités, c'est vrai, mais plus de 20 en tout) une moyenne de consommation mémoire inférieure à 1 Go.
Sur le même serveur d'un client avec une boutique VM et 7 autres sites Joomla! la RAM tourne aux environs de 1 Go aussi.

En utilisant un système de cache et une extension permettant d'utiliser la compression, ça peut éventuellement suffire.
Gzip est bien disponible chez 1&1, en tout cas sur les serveurs où j'ai vérifié, mais Joomla! n'arrive pas à l'activer. aeSecure Premium oui, d'autres peut-être aussi.

Pour tes mises à jour, active le plugin "Sauvegarde avant mise à jour" d'Akeeba s'il ne l'est pas encore, récupère les patchs de mise à jour pour chaque étape de la 3.7.1 à la 3.7.5 : à chaque installation, tu auras une sauvegarde avant chaque mise à jour, donc la possibilité de la restaurer en cas d'incident, sans devoir revenir à la 3.7.1
Une fois en 3.7.5, on est devant un gros problème : pas de patch 3.7 vers 3.8 mais le même pour passer de toutes les versions de 2.5 à 3.7 vers la 3.8 donc réinstallation de tas de fichiers déjà présents et de modifications de tables déjà faites.

Complément : je viens de regarder mon serveur et j'ai une question : que dit la page d'analyse de performances sur ton panel d'administration ?

**FlodAriege** · 01/04/2018, 19h26

Envoyé par RobertG Voir le message

Complément : je viens de regarder mon serveur et j'ai une question : que dit la page d'analyse de performances sur ton panel d'administration ?

C'est-à-dire ?
Si tu parles du graphique en barres qui s'affiche sur la page Niveau de performance de 1&1, alors : toutes les barres sont au vert, avec des valeurs à 100% (sauf un jour à 99%)
C'était ça ta question ?

Pour gzip, je suis un peu perplexe, car tout ceux qui ont mis le nez dans ma config m'ont toujours dit que 1&1 ne l'acceptait pas. Mais il faut que je précise que je suis sur un serveur mutualisé avec un hébergement 1&1 Unlimited Pro.
J'ai Aesecure Premium+
... donc je pourrais peut-être parvenir à optimiser mon site ?
Tu me fais rêver là.

Pour les mises à jour, c'est bien mon intention : passer de version en version sans faire de saut d'étapes.
à suivre...

Et pour PHP, qu'en penses-tu ?

**RobertG** · 01/04/2018, 19h48

Oui, c'était ça ma question. Donc globalement, la puissance de ton serveur est suffisante.
J'ai un Unlimited pour tests, avec niveau 2 de performances.

Ceux qui ont mis le nez dans ta config n'ont pas cherché dans l'onglet "PHP" des infos système et cherché "gzip" ?
Avec aeSecure, active les points 8.1 et 8.2 s'ils ne le sont pas déjà et vérifie avec GTmetrix par exemple si Gzip est toujours considéré comme absent ou pas.
Le site d'une cliente : "Enable gzip compression A (100) AVG SCORE: 84%" Le score est à 100%, ce qui veut dire que Gzip est bien activé et ses scores GTmérix sont de 98% pour PageSpeed et 86% pour YSlow.

Pour PHP, tu peux rester en 5.6 dans un premier temps puis passer en 7.0 avant de mettre à jour de 3.7 à 3.8

**FlodAriege** · 01/04/2018, 23h21

bon ben pour l'instant, ma restauration de sauvegarde a planté sur une erreur 500, donc je verrai ça demain (le temps que je uploade de nouveau une sauvegarde, il y en a pour 2 plombes vu ma connexion ici)
la page d'accueil s'affichait nickel, mais aucun des liens ne fonctionnaient.
j'ai tout viré et je recommence demain.

**manu93fr** · 01/04/2018, 23h42

Envoyé par FlodAriege Voir le message

la page d'accueil s'affichait nickel, mais aucun des liens ne fonctionnaient.

C'est souvent du au fichier htaccess qu'il faut juste désactiver

**daneel** · 02/04/2018, 01h11

Bonjour,

A mon avis, tu n'iras pas plus vite en augmentant le niveau sauf à mettre le prix. En terme de comparaison, on peut aller jusqu'à 5 fois plus rapidement que ta configuration actuelle pour des hebergements équivalent à 3 euro par mois. L'essentiel, c'est de trouver le juste milieu entre les besoins, la performance réelle, l'optimisation et la compatibilité.

A lire le détail de leur propositions, elles sont un peu plus adaptées qu'avant. Mais ayant fait l’expérience à plusieurs reprises, j'arrive à des performances extraordinaires rien qu'en utilisant 2go de memoire et un processeur atom. Donc le plus petit des dédiés bien configurés sur online ou ovh pourrait fort bien dépasser toute ces configurations si on est à moins de 100 visites par jour (techniquement, il y a un moment où l'optimisation a aussi ses limites ).

1&1 se situe donc parmi les hébergeurs low-cost mutualisé. Des offres basses mais pas tant que ça avec de l'espace illimité (dès que l'on met un peu plus que l'offre basic). Quand on parle d'illimité, c'est surtout qu'il déduise que tu ne servira pas comme espace de stockage vu que c'est contraire à leur règlement (noté dans leur conditions), evidemment ils sont toujours gagnants. Le partenariat avec cloudflare leur permet d'ajouter un cdn gratuit et le système railgun suivant la configuration qui permet de booster les sites.
source : http://newsroom.1and1.fr/2017/03/28/...ormance/#_ftn1

A toi de voir la stratégie à adopter, entre rester comme ça, changer de niveau ou d'hébergeur mais je crois bien que la priorité c'est de passer en dernière version de joomla et en php 7. Apparemment tu pourrais activer le cache opcode de php7 et d'autres facteurs de performance : https://community.1and1.com/php-7/

fichier php.ini à la racine de ta config 1&1

Code:

zend_extension=opcache.so;
opcache.enable=1;opcache.memory_consumption=32;
opcache.interned_strings_buffer=8;
opcache.max_accelerated_files=3000;
opcache.revalidate_freq=180;
opcache.fast_shutdown=0;
opcache.enable_cli=0;
opcache.revalidate_path=0;
opcache.validate_timestamps=2;
opcache.max_file_size=0;
opcache.file_cache= .../homepages/tonchemin/htdocs/.opcache;
opcache.file_cache_only=1;

Perso, je choisirai une offre incluant le cdn si cela ne dépasse pas ton budget.

Je considère 1&1 comme un hébergement stable (mieux que d'autres mutu) mais pas forcement performant, du moins pas il n'est pas dans les premiers de ma liste.
Aujourd'hui, je tiens compte d'autres paramètres comme des disques dur ssd, un cache performant, une puissance et bande passante adaptée à la fréquentation.
Le prix est à prendre en compte uniquement avec la configuration dans sa globalité (ce qui inclus également la réactivité du support).

En résumé oui pour l'évolution mais je te conseille php7 en premier, le reste suivra (tu as le temps). Le dernier conseil serait de desactiver aesecure et ses modifications dans le htaccess, jchoptimize et autres extensions le temps des mises à jour. S'assurer de la compatibilité du template en n'oubliant pas d'afficher les erreurs afin de corriger les problèmes préalables (vérifier également la console du navigateur).

Voila, si cela peut te faire avancer sur tes décisions, sache que je peux te partager le paramétrage avec cloudflare (le cdn) si tu l'utilise à l'avenir

Yann

**FlodAriege** · 02/04/2018, 12h45

Envoyé par manu93fr Voir le message

C'est souvent du au fichier htaccess qu'il faut juste désactiver

Salut,
J'ai viré le .htaccess, et maintenant je n'ai plus d'erreur 500 mais... des erreurs 404

Je réactive aesecure, et là je reviens à des erreurs 500.

Rappel: ma sauvegarde est sur un sous-domaine (bon sang ! pourtant je l'ai déjà fait, et je n'ai pas eu ce problème à l'époque...)

qu'est-ce que j'oublie ??

EDIT : j'ai bidouillé le .htaccess que j'ai sur mon site en production en modifiant le nom du dossier dans lequel le sous-domaine est installé et en ajoutant le sous-domaine à l'adresse du site et il semblerait que ça fonctionne :
Là où c'était écrit :

RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?vieuxdossier\.monsite\.fr [NC]

J'ai rectifié ainsi :

RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?nouveaudossier\sousdomaine.monsite\.fr [NC]

Plus d'erreur 500 ni 404.

Nouveau problème : tout le monde me dit de désactiver le htaccess pour faire les mises à jour.
Mais quand je le désactive plus rien ne fonctionne.
Comment faire ???????????

**daneel** · 02/04/2018, 13h32

Envoyé par FlodAriege Voir le message

Nouveau problème : tout le monde me dit de désactiver le htaccess pour faire les mises à jour.
Mais quand je le désactive plus rien ne fonctionne.

Il ne faut pas desactiver le fichier htaccess car ton site a besoin de la réécriture et de certains paramètres.
Seulement, entre la version htaccess de base livré avec joomla et celle que tu utilise, il y a certainement beaucoup plus de paramètres
d'où les problèmes rencontrés...

Le mieux serait d'avoir un htaccess avec le strict nécessaire pour les maj et de l'autre la version super-optimisé avec tes modifs, aesecure, jch, etc...

Comme je te l'ai dit, desactive également les extensions et éléments d'optimisation, compression, minification puis reactive après avoir effectué les mises à jour
et vérifie qu'il n'y a pas d'erreur (avant et après) en affichant le rapport (mode dev) via la configuration du site ainsi que dans la console du navigateur (avant et après).

Si tu as des déjà des erreurs dans ton site, le fait de mettre à jour ne va pas arranger les choses. Il faut traiter les problèmes avant...
C'est mon avis et c'est ce que je fait habituellement sur les "vieux" sites.

Yann

ps: pour info, tu as aussi une erreur dans la console du navigateur sur les fichiers compressé par jch.

**FlodAriege** · 02/04/2018, 14h14

Envoyé par daneel Voir le message

Il ne faut pas desactiver le fichier htaccess car ton site a besoin de la réécriture et de certains paramètres.
Seulement, entre la version htaccess de base livré avec joomla et celle que tu utilise, il y a certainement beaucoup plus de paramètres
d'où les problèmes rencontrés...

Le mieux serait d'avoir un htaccess avec le strict nécessaire pour les maj et de l'autre la version super-optimisé avec tes modifs, aesecure, jch, etc...

Oui, j'ai vu ça mais... tu es bien placé pour savoir que j'ai un .htaccess qui n'est pas sorti de mon brillant esprit lol mais de celui des contributeurs ici, à commencer par toi.
D'où mon immense difficulté à repérer dans ce code ce qui est indispensable au bon fonctionnement de ce qui relève de la "simple" optimisation...
J'ai bien tenté avec le htaccess par défaut, mais sans succès.
Là je me heurte de plein fouet à mon incompétence.

Envoyé par daneel Voir le message

Comme je te l'ai dit, desactive également les extensions et éléments d'optimisation, compression, minification puis reactive après avoir effectué les mises à jour
et vérifie qu'il n'y a pas d'erreur (avant et après) en affichant le rapport (mode dev) via la configuration du site ainsi que dans la console du navigateur (avant et après).

J'ai tenté de désactiver Aesecure mais ça faisait tout planter (problème du htaccess j'imagine).

J'ai désactivé JCH.
... à part ça je ne vois pas ce que je peux désactiver de plus (aucune option de compression ou minification n'étant activée dans mon template par exemple)

J'ai réglé de rapport d'erreur à "développement"

J'ai passé le cache de "conservateur" à "désactivé"

Envoyé par daneel Voir le message

Si tu as des déjà des erreurs dans ton site, le fait de mettre à jour ne va pas arranger les choses. Il faut traiter les problèmes avant...
C'est mon avis et c'est ce que je fait habituellement sur les "vieux" sites.

Les seules erreurs qui s'affichent depuis que j'ai passé le rapport d'erreur à "développement", c'est :

Notice: Undefined property: stdClass::$facebookmeta_fbuserprofile in /homepages/7/***/htdocs/***/plugins/system/socialmeta/socialmeta.php on line 762
Notice: Undefined property: stdClass::$facebookmeta_twitteruser in /homepages/7/***/htdocs/***/plugins/system/socialmeta/socialmeta.php on line 790
Je crois me souvenir qu'il s'agit d'un petit problème avec flexicontent, mais sans réelle importance (tellement peu qu'elle n'est pas sur la liste de leurs priorités)

Et, en bas d'écran :
Only variables should be assigned by reference in /homepages/7/***/htdocs/***/modules/mod_cookiesaccept/mod_cookiesaccept.php on line 24

Tu dois connaître Cookies Accept, inutile que je t'explique de quoi il s'agit. Je n'ai pas le sentiment que cette erreur soit bien grave, non ?

Envoyé par daneel Voir le message

ps: pour info, tu as aussi une erreur dans la console du navigateur sur les fichiers compressé par jch.

Merci pour ce signalement.
Je viens d'ouvrir un ticket chez JCH, j'espère qu'il pourra m'aider... parce que pour moi ces messages d'erreur c'est du chinois...

Donc, si je résume :
A ce stade j'ai bien l'impression que mon plus gros problème, c'est cette histoire de htaccess.
Tant que je ne pourrai pas en implanter un assez basique pour ne pas créer de problème, mais contenant les instructions minimum pour permettre le fonctionnement, je risque fort de voir mes mises à jour planter...
je suis un peu (... beaucoup...) découragée, là.
Je ne sais même pas si ça vaut le coup que j'essaie de faire ces mises à jour...

**daneel** · 02/04/2018, 14h57

ok ok

pourquoi ne pas essayer de mettre ce htaccess de coté et de récuperer celui livré avec le code original.
en ajoutant uniquement tes spécifités comme le www, le sous-repertoire et redirection https...

RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?nouveaudossier\sousdomaine.monsite\.fr [NC]
RewriteRule ....

attention, je crois que ta version actuelle ne fonctionne qu'en php 5.6 donc la bascule php 7 sera faite après les
mises à jour joomla & extension (il faut confirmer que le template soit également compatible php 7 ).

Je n'ai pas beaucoup de temps aujourd'hui mais dans la semaine on pourra revoir le htaccess au complet
pour clôturer cet épisode... pour maintenant, cela peut attendre 2-3 jours

**manu93fr** · 02/04/2018, 15h04

Salut,
J'ai viré le .htaccess, et maintenant je n'ai plus d'erreur 500 mais... des erreurs 404

Oui parce qu'il faut dans le meme temps remettre le paramètre de réécrituve au vol des urls sur NON

Je ne savais pas que tu avais un htaccess "blindé" ... je suis du meme avis que Daneel, si tu en remets un en place sur le site de test pour ta mise a jour, remets celui de Joomla! par defaut pour évité les effets de bord et désactive tous les plugin d'optimisation

**RobertG** · 02/04/2018, 15h37

C'est un point en effet auquel on ne pense pas lorsqu'on restaure ailleurs un site où JCH Optimize est utilisé : son cache.
J'en ai parlé dans une autre discussion, sur certains sites (je n'ai pas réussi à savoir pourquoi), JCH utilise un dossier cache dans "media/plg_jchoptimize" que la sauvegarde Akeeba embarque, nécessitant de désactiver JCH après restauration, ou de penser à exclure le contenu du dossier dans les paramètres du profil Akeeba.

Dans la procédure de restauration, Akeeba propose (par défaut ?) de restaurer le .htaccess d'origine, et là, chez 1&1, il ne faut pas oublier ensuite de décommenter la ligne "RewriteBase" pour éviter cette erreur 500.

**FlodAriege** · 02/04/2018, 15h56

Envoyé par daneel Voir le message

ok ok

pourquoi ne pas essayer de mettre ce htaccess de coté et de récuperer celui livré avec le code original.
en ajoutant uniquement tes spécifités comme le www, le sous-repertoire et redirection https...

RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?nouveaudossier\sousdomaine.monsite\.fr [NC]
RewriteRule ....

Je suis en train d'essayer de repérer les lignes indispensables, toutes celles qui sont en lien avec REWRITE

Envoyé par daneel Voir le message

attention, je crois que ta version actuelle ne fonctionne qu'en php 5.6 donc la bascule php 7 sera faite après les
mises à jour joomla & extension (il faut confirmer que le template soit également compatible php 7 ).

juste avant de lancer la màj vers 3.8, je viens de basculer en php 7.1:
a a fait planter pas mal de choses, et notamment mon megamenu qui n'a pas l'air d'apprécier.
j'ai descendu d'un cran à php 7.0 : tout est rentré dans l'ordre

(quand j'étais en 7.1 j'ai vu un message d'erreur relatif à tooltip gc, que je n'utilise plus et que j'ai donc désinstallé)

Envoyé par daneel Voir le message

Je n'ai pas beaucoup de temps aujourd'hui mais dans la semaine on pourra revoir le htaccess au complet
pour clôturer cet épisode... pour maintenant, cela peut attendre 2-3 jours

Merci de ta proposition, c'est vraiment sympa de ta part.
je vais faire de mon mieux pour ne pas avoir besoin de t'embêter, mais si je plante vraiment, je reviens vers toi pour ne pas me noyer

**FlodAriege** · 02/04/2018, 16h07

Envoyé par RobertG Voir le message

C'est un point en effet auquel on ne pense pas lorsqu'on restaure ailleurs un site où JCH Optimize est utilisé : son cache.
J'en ai parlé dans une autre discussion, sur certains sites (je n'ai pas réussi à savoir pourquoi), JCH utilise un dossier cache dans "media/plg_jchoptimize" que la sauvegarde Akeeba embarque, nécessitant de désactiver JCH après restauration, ou de penser à exclure le contenu du dossier dans les paramètres du profil Akeeba.

... et crois-tu que je puisse simplement tenter de supprimer ce dossier (ou son contenu) ?

(Là on parle (je le dis surtout pour moi) du site en production, qui est issu de la restauration d'une sauvegarde après le gros plantage de ma dernière tentative de màj vers j!3.8
Donc ce que tu dis s'applique plein pot à mon cas de figure.)

Envoyé par RobertG Voir le message

Dans la procédure de restauration, Akeeba propose (par défaut ?) de restaurer le .htaccess d'origine, et là, chez 1&1, il ne faut pas oublier ensuite de décommenter la ligne "RewriteBase" pour éviter cette erreur 500.

C'est exact, je me souviens bien avoir vu une case cochée par défaut dans la procédure de restauration Akeeba avec restauration du htaccess par défaut.
Ne sachant pas trop ce qui provoquait l'erreur 500, j'ai carrément remis le htaccess de mon site en production en modifiant ce qui avait besoin de l'être (puisque le sous-domaine sur lequel je tente les mises à jour est sur un dossier différent de celui du site en production).
Si je te comprends bien, et ça rejoint ce que dit Daneel, il m'aurait suffi de remettre en fonction les lignes Rewrite en les décommentant.

NB: j'ai depuis (2014 je crois) une ligne 1&1 Hack ainsi rédigée dans mon htaccess :
# 1&1 Hack
RewriteRule !index\.php - [C]
RewriteRule ^ /index.php

Je ne sais pas si elle est toujours utile.
A vrai dire j'ai l'impression d'avoir des lignes en double dans mon htaccess : il faudrait que je lance une analyse (je ne sais pas trop avec quel outil, peut-être excel avec mise en forme conditionnelle des doublons)

PS : je suis en train d'envoyer les fichiers et dossiers de la 3.8 vers mon serveur. C'est long, il doit effectivement y avoir un paquet de fichiers là dedans (comme tu me le disais plus haut dans ce post). je croise les doigts très fort : si ça plante ma 1ère tentative de correction portera sur le htaccess. Sinon je pourrai toujours restaurer la sauvegarde 3.7.5, dernière version à laquelle je suis arrivée sans souci.

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

[RÉGLÉ] Plantage màj 3.7.5 vers 3.8 : erreur 500 instantiation error

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Annonce

Partenaire de l'association