- WordPress :5.8
- Statut : non résolu
- Ce sujet contient 12 réponses, 3 participants et a été mis à jour pour la dernière fois par illy86, le il y a 2 années et 3 mois.
-
AuteurMessages
-
1 août 2022 à 16 h 06 min #2412706
Bonjour,
Ma configuration WP actuelle
- Version de PHP/MySQL : Thème utilisé : Astra
- Extensions en place : Elementor, Elementor Pro, WPML, All in One SEO, Updraft Plus, TinyPng, Akismet, Better search replace, Coming soon, Cookie notice, Duplicate page, Export media library, Loco translate, Redirection, Sucuri, WP All import, WP Rocket, WP sitemap, WP Sweep
- Nom de l’hébergeur : OVH
- Adresse du site : http://www.lesdomainesdeprovence.fr
- Version de WordPress : 6.0.1
Problème(s) rencontré(s) : Le site a été mis automatiquement à jour vers WordPress 6.0.1. Il m’est alors impossible de me connecter à l’administration car il y a une redirection infinie. La page se recharge.
J’ai activé le mode debug et récupéré cette erreur :
PHP Fatal error: Uncaught RuntimeException: Unable to claim actions. Database error. in /home/rdmbvdt/www/wp-content/plugins/wp-rocket/inc/Dependencies/ActionScheduler/classes/data-stores/ActionScheduler_DBStore.php:683
J’ai donc désactivé WP Rocket via FTP mais j’ai toujours le même problème et obtient maintenant cette erreur :
PHP Fatal error: Uncaught RuntimeException: Unable to claim actions. Database error. in /home/rdmbvdt/www/wp-content/plugins/all-in-one-seo-pack/vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_DBStore.php:675
Comment faire ?
Aurais-je la même erreur avec tous les plugins ?
Que se passe t-il ?
Merci pour votre aide.
1 août 2022 à 16 h 23 min #2412707C’est woocommerce qu’il faut désactiver temporairement
1 août 2022 à 16 h 26 min #2412711WooCommerce a été désinstallé du site.
Sur l’erreur que je transmets, il s’agit de all in one. Et le problème intervient dans la même table : ActionScheduler_DBStore.php
Une idée ?
1 août 2022 à 16 h 36 min #2412717L’erreur que vous transmettez marque spécifiquement woocommerce…
Oui réparer les tables de la base via phpmyadmin (cochez les tables et sélectionner en bas réparer) et si ça ne donne rien, recharger une sauvegarde
1 août 2022 à 16 h 45 min #2412718Merci, j’essaierai la réparation.
Je dispose de sauvegardes updraft plus antérieures, j’ai donc besoin de l’accès au back office pour la restaurer …
A moins qu’il n’existe un moyen que je ne connaisse pas ?
1 août 2022 à 16 h 51 min #2412720Mais, pour l’avoir testé sur un autre site, WordPress aura certainement fait également une mise à jour de la BDD.
Donc, restaurer une ancienne version de la BDD ne risque t-il pas de poser problème ?
1 août 2022 à 16 h 57 min #2412721La table ActionScheduler_DBStore n’existe pas. Ai-je mal compris le message ?
Voilà un peu plus d’informations :
[01-Aug-2022 12:55:55 UTC] PHP Fatal error: Uncaught RuntimeException: Unable to claim actions. Database error. in /home/rdmbvdt/www/wp-content/plugins/all-in-one-seo-pack/vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_DBStore.php:675
Stack trace:
#0 /home/rdmbvdt/www/wp-content/plugins/all-in-one-seo-pack/vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_DBStore.php(599): ActionScheduler_DBStore->claim_actions(0, 25, NULL, Array, »)
#1 /home/rdmbvdt/www/wp-content/plugins/all-in-one-seo-pack/vendor/woocommerce/action-scheduler/classes/ActionScheduler_QueueRunner.php(153): ActionScheduler_DBStore->stake_claim(25)
#2 /home/rdmbvdt/www/wp-content/plugins/all-in-one-seo-pack/vendor/woocommerce/action-scheduler/classes/ActionScheduler_QueueRunner.php(132): ActionScheduler_QueueRunner->do_batch(25, ‘Async Request’)
#3 /home/rdmbvdt/www/wp-includes/class-wp-hook.php(307): ActionScheduler_QueueRunner->run(‘Async Request’)
#4 /home/rdmbvdt/www/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters( », Array)
in /home/rdmbvdt/www/wp-content/plugins/all-in-one-seo-pack/vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_DBStore.php on line 675
[01-Aug-2022 12:55:55 UTC] Erreur de la base de données WordPress : UPDATE command denied to user ‘rdmbvdt27’@’10.31.20.95’ for table ‘mod652_options’ pour la requête UPDATEmod652_options
SEToption_value
= ‘1659358615’ WHEREoption_name
= ‘action_scheduler_lock_async-request-runner’ faite par shutdown_action_hook, do_action(‘shutdown’), WP_Hook->do_action, WP_Hook->apply_filters, ActionScheduler_QueueRunner->maybe_dispatch_async_request, ActionScheduler_OptionLock->set, update_option1 août 2022 à 18 h 08 min #2412732Pas d’idées ?
1 août 2022 à 18 h 18 min #2412733Bonjour,
J’ai eut une mésaventure semblable. En allant sur l’interface client OVH j’ai constaté que mon quota de bdd était plein. Du coup OVH refusait d’écrire à nouveau dans la base et donc je bouclais en permanence. En me connectant à la base mysql j’ai pu identifier la table responsable et j’ai pu dégonflé ma bdd. Après mise à jour de la mesure OVH j’ai pu me reconnecté. OVH aurait pu me prévenir avant !
1 août 2022 à 18 h 26 min #2412734Bonjour Fred17,
Merci pour cette réponse. Il s’agit du site d’une de mes clientes, je me connecterai donc sur son compte d’hébergement demain pour vérifier ceci.
Comment avez-vous « dégonflé » la table responsable ?
1 août 2022 à 18 h 36 min #2412738La table enregistrait les mails envoyés par le site. J’ai donc supprimer un certain nombre d’enregistrement les plus anciens.
1 août 2022 à 18 h 37 min #2412739Merci pour l’info !
J’essaierai de trouver ce qui prend de la place de mon côté.
1 août 2022 à 18 h 47 min #2412742J’ai vérifié, le quotat est dépassé de 0.8Mo.
Merci beaucoup !
-
AuteurMessages
- Vous devez être connecté pour répondre à ce sujet.