Erreur fatale PHP : impossible d'ouvrir le "wp-salt.php" requis lors de l'exécution de la commande WP-CLI en tant que tâche cron dans crontab
P粉253518620
P粉253518620 2024-03-28 09:25:13
0
1
437

Cette question est destinée à être un article informatif que les autres peuvent trouver car heureusement, j'ai déjà trouvé la solution.

J'ai essayé d'exécuter la commande Wordpress-CLI en tant que tâche cron dans crontab sur le serveur Cloudways. La commande s'exécute sans aucun problème directement dans le terminal, mais échoue avec une erreur PHP fatale lorsqu'elle est lancée à l'aide de crontab.

Les commandes de base de Wordpress-CLI sont les suivantes :

wp migeratedb 配置文件 [id]

Étant donné que le contexte dans lequel crontab est exécuté est généralement inconnu et que la variable $PATH peut ne pas être disponible, j'ai modifié la commande pour fournir le chemin absolu nécessaire :

/usr/local/bin/wp migeratedb 配置文件 [id] --path=/absolute/path/to/wordpress/core/files

De même, cette commande modifiée fonctionne également parfaitement sans aucun problème lorsqu'elle est lancée depuis le terminal.

L'entrée finale de la crontab ressemble à ceci :

0 5 * * * /usr/local/bin/wp migeratedb 配置文件 [id] --path=/absolute/path/to/wordpress/core/files

Lorsqu'il est exécuté à partir du planificateur, il produit l'erreur suivante :

PHP Fatal error:  require(): Failed opening required 'wp-salt.php' (include_path='.:/usr/share/php') in phar:///usr/local/bin/wp/vendor/wp-cli/config-command/src/Config_Command.php(444) : eval()'d code on line 34

Après quelques expérimentations, j'ai réalisé cette erreur se produit pour toutes les commandes WP-CLI sauf les très basiques

wp --info

, produisant le résultat suivant :

OS: Linux 4.19.0-21-amd64 #1 SMP Debian 4.19.249-2 (2022-06-30) x86_64
Shell:  /bin/sh
PHP binary: /usr/bin/php7.4
PHP version:    7.4.33
php.ini used:   /etc/php/7.4/cli/php.ini
MySQL binary:   /usr/bin/mysql
MySQL version:  mysql  Ver 15.1 Distrib 10.4.20-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
SQL modes:  
WP-CLI root dir:    phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:  phar://wp-cli.phar/vendor
WP_CLI phar path:   [absolute/path/to/user/home/directory]
WP-CLI packages dir:    
WP-CLI cache dir:   [absolute/path/to/user/home/directory]/.wp-cli/cache
WP-CLI global config:   
WP-CLI project config:  
WP-CLI version: 2.7.1

J'ai également essayé les adaptations suivantes sans succès :

  • Téléchargez le nouveau wp-cli.phar et utilisez-le avec la commande.

  • Afficher et modifier toutes les autorisations des dossiers utilisés

  • Essayez d'exécuter cronjob en tant qu'autre utilisateur

  • Utilisez /usr/bin/php 更改命令来运行 wp-cli.phar

P粉253518620
P粉253518620

répondre à tous(1)
P粉790187507

J'ai finalement compris que cette erreur était liée à la façon dont le fournisseur d'hébergement (dans ce cas Cloudways) avait configuré la configuration WordPress dans le fichier wp-config.php.

Les clés d'autorisation salt et secrètes sont stockées dans un fichier séparé qui est référencé wp-salt.php。它可以通过以下方式直接在配置文件中引用:require('wp-salt.php') dans le message d'erreur. Comme cela ne fait pas partie du noyau de WordPress et que crontab s'exécute dans un environnement différent, il ne peut pas déterminer le répertoire correct où se trouve le fichier et require() échoue avec une erreur fatale.

Pour résoudre ce problème, modifiez la ligne dans wp-config.php 中的行更改为 require(__DIR__.'/wp-salt.php'); en require(__DIR__.'/wp-salt.php'); afin que le fichier soit toujours référencé à partir du même répertoire que le fichier de configuration.

Une autre option consiste à supprimer entièrement la ligne et à la remplacer par le contenu du fichier wp-salt.php, comme le fait le noyau de WordPress.

Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal