Plus d'accès au back end Joomla avec message d'erreur

[sevbv]

Bonjour à tous et à toutes,
Je suis perplexe car je n'arrive plus à accéder au back end de mon site. Je ne me suis pas connectée depuis plusieurs mois. Je n'ai fait aucune mise à jour, je n'ai rien installé et j'ai essayé plusieurs logins. J'ai toujours le message "DateTime::__construct(): Failed to parse time string (jerror) at position 0 (j): The timezone could not be found in the database"

Voilà ce que j'ai essayé :
- Accès par PHPmyadmin pour refaire un nouveau super user + password. Cela n'a pas fonctionné
- Accès par un vpn pour voir si l'IP était bloquée. Pas de succès
- Accès par un autre PC en dehors de chez moi. Pas de succès
- Recherche via PHPmyadmin des plugins pour voir s'il y aurait une sécurité d'installée. Impossible de trouver le _plugin ou _plg. J'ai bien _extensions mais il n'y a aucune extension avec la mention d'authentification.
- Je sais qu'il y a Akeeba. Pourtant je ne trouve pas de traces du modules dans _mod


Je n'ai pas de retour ni de contact à jour avec le développeur qui l'a installé au printemps 2015

Merci de votre aide et conseils,
Bonne fin de journée,
Séverine

[RobertG]

Bienvenue !

En quelle version de Joomla! le site est-il actuellement ? Si elle est ancienne, peut-être y a-t-il un conflit avec la version de PHP, qui aurait changé chez ton hébergeur ?
Peut-on avoir l'URL d'accès au site ?

Si Akeeba est installé, tu dois pouvoir trouver des sauvegardes (si elles ont été faites et à moins que le webmaster les ait paramétrées ailleurs) dans le dossier administrator/components/com_akeeba/backup, pas dans un module.

[sevbv]

Bonsoir RobertG,
Merci pour la réponse rapide et me souhaiter la bienvenue !
Le site est en joomla 3.0 (je viens de vérifier via FTP) et chez OVH, la console indique PHP 4.4. Il n'y a pas eu de mise à jour de ma part depuis ma dernière connexion.
Je n'ai pas accès au back end alors je ne sais pas comment accéder au dossier que tu mentionnes ?
Via PHPmyadmin, j'ai juste retrouvé cette table (voir PJ) à propos de Akeeba
Le site est www.wopawap.com. Je voulais accéder au back end pour le remettre de nouvelles références.

[lomart]

Bonsoir,

Effectivement le site est en 3.0
Il faudra évoluer pour rester compatible avec les nouvelles versions de PHP qui seront quasi obligées chez les hébergeurs. PHP 4.4 est très vieux

Il faudrait peut-être poser la question à OVH. D'expérience sur le forum, on les contacte, ils disent qu'ils ne sont pas concernés par l'erreur et ensuite ça remarche ! bizarre

[RobertG]

L'accès aux sauvegardes se fait par ftp, dans le dossier cité.
Je doute que le site tourne toujours sous PHP 4.4 : il faut vérifier par ftp dans le fichier .htaccess ou le fichier .ovhconfig s'il y a une version définie pou PHP, que la console OVH ne prend pas en compte. Il faut en effet une version de PHP 5.3.1 au minimum pour Joomla! 3 sinon on a cette mention au lieu du site 'Your host needs to use PHP 5.3.1 or higher to run this version of Joomla!'

Il faudrait modifier avec un éditeur de texte simple (bloc-notes ou notepad++) le fichier configuration.php en passant la variable "debug" de 0 à 1 et "eror_reporting" de "default" ou "none" à "development" afin d'essayer de repérer quel est le fichier responsable de cette erreur.

[manu93fr]

Bonsoir,

chez OVH, la console indique PHP 4.4.

sur la console Ovh, ce n'est pas un souci d'avoir 4.4 .... a mon avis, ton fichier .htaccess ou .ovhconfig appelle une version php5 sinon aucune chance que le site Joomla! fonctionne
Pour ton souci, je ferai une sauvegarde complète du site a la main (FTP + base de donnée) pour travailler dessus sans compromettre le site en ligne car en version J!3.0, tu pars d'assez loin ... et il s'en ai passé des trucs !
... tu peux aussi tenter de restaurer une archive Akeeba Backup que tu trouveras dans ton FTP normalement ... de memoire /administrator/components/com_akkeba ..... tu cherches un dossier backup

[sevbv]

Bonsoir,

Effectivement le site est en 3.0
Il faudra évoluer pour rester compatible avec les nouvelles versions de PHP qui seront quasi obligées chez les hébergeurs. PHP 4.4 est très vieux

Il faudrait peut-être poser la question à OVH. D'expérience sur le forum, on les contacte, ils disent qu'ils ne sont pas concernés par l'erreur et ensuite ça remarche ! bizarre

Bonsoir Iomart, la dernière fois que j'ai appelé OVH, l'interlocuteur m'a clairement dit "qu'il googlait mon message d'erreur pour comprendre"... Ce n'est pas forcément le reflet de l'expertise mais j'abonde dans ton sens où ils vont me dire que cela n'a rien à voir avec eux ! Toutefois, je le garderai en recours on ne sait jamais !
Merci de ta réponse !

[lomart]

Toutefois, je le garderai en recours on ne sait jamais !

Moi, je les mettrais dans le circuit maintenant. Il se passe tellement de choses bizarres chez OVH en ce moment

[sevbv]

Bonsoir Manu et merci Robert,

Je vous joins deux captures d'écrans : une de la console OVH avec le PHP 4 et aussi du FTP

Pour le dossier backup , les deux fichiers .htacess et web.config sont verrouillés. Pas d'autres fichiers ? Je n'en sais pas plus !
J'ai bien passé les lignes sur le fichier configuration.php avec debug en '1' et 'error-reporting' de 'default' à 'development'. Pourrais tu me dire ce que je dois faire par la suite ?

Encore merci de votre aide.

Je me permets de coller le fichier root .htaccess aussi.

## Mod_rewrite in use.

RewriteEngine On

## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site block out the operations listed below
# This attempts to block the most common type of exploit `attempts` to Joomla!
#
# Block out any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block out any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.

## Begin - Custom redirects
#
# If you need to redirect some pages, or set a canonical non-www to
# www redirect (or vice versa), place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
## End - Custom redirects

##
# Uncomment following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).
##

# RewriteBase /

## Begin - Joomla! core SEF Section.
#
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
#
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the request is for something within the component folder,
# or for the site root, or for an extensionless URL, or the
# requested URL ends with one of the listed extensions
RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw))$ [NC]
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
## End - Joomla! core SEF Section.

[RobertG]

Deux pistes trouvées et à explorer : les chemins des dossiers logs et tmp mal définis dans le fichier configuration.php et cette discussion avec une solution proposée par daneel : https://forum.joomla.fr/node/187045

Le fichier .htaccess cité (racine) me semble incomplet, et il n'y a absolument aucune sauvegarde dans le dossier par défaut "backup". Reste à savoir s'il y en a ailleurs.

[sevbv]

Bonsoir RobertG,
Merci pour les deux pistes.
J'ai essayé la suggestion proposée par Daneel, sans succès J'ai fait une mauvaise manip et non seulement je n'accède plus au back end mais le site ne s'affiche plus correctement.
J'ai mis le chmod en 777 à la racine et appliqué à tout le site. Le site affichait une erreur 403. J'ai remis le chmod en 755. Le site s'affiche sans médias en mode html.
Du coup, j'ai fait un restaure de la sauvegarde d'hier ? Le site devrait s'afficher de nouveau.

Pour OVH, ce n'était pas leur jour aujourd'hui et je sens que le support va bien être saturé pendant les prochaines 24h...