J'ai un plugin distribué sur WordPress.org qui est assez populaire. Je dois supprimer le support de PHP 5.2 et je voudrais au moins abandonner le support de PHP 5.2, mais si je pouvais faire le minimum PHP 5.4, des liaisons statiques tardives et des fermetures utiles, serait formidable.
Avant de dire PHP7, gardez à l'esprit que le plugin ne compte que plus de 100 000 sites qui l'exécutent. Pour tous les sites WordPress , 10% des sites sont sur PHP 5.3 ou inférieur. Je ne risque pas de casser 10k sites.
Nous allons ajouter un PHP en-tête de version minimale }, mais cela ne fait rien pour le moment.
Je recherche le bon modèle pour mettre régulièrement à jour les mises à jour de mon plug-in, sauf si la version requise de PHP est définie. Est-ce que quelqu'un a un moyen infaillible de le faire?
Pour l'instant, ce n'est pas possible. Non sans que l'en-tête de version minimum PHP soit mis en œuvre.
Quand cela sera fait, ce sera possible. Jusque-là, vous ne pouvez pas bricoler avec le code du plugin seul.
En théorie, vous pourriez publier une mise à jour qui bloquerait les futures mises à jour de ce plugin si la version PHP n'était pas remplie, mais cela n'empêcherait pas votre plugin de recevoir des mises à jour lorsqu'il n'était pas actif. Donc, cela ne peut pas être fait car les mises à jour des plugins sont effectuées par WordPress, pas par les plugins eux-mêmes.
Je pense que peut être fait.
J'utilise ce processus pour vérifier la version minimale à l'activation du plugin. Vous pouvez utiliser une variante pour vérifier lors d'une mise à niveau (bien que je pense qu'une mise à niveau vers une nouvelle version contenant ce code entraînerait la désactivation du plug-in).
Le code pour vérifier les versions minimales:
function is_requirements_met()
{
$min_wp = '4.6' ; // minimum WP version
$min_php = '5.3' ; // minimum PHP version
// Check for WordPress version
if ( version_compare( get_bloginfo('version'), $min_wp, '<' ))
{
return false ;
}
// Check the PHP version
if ( version_compare(PHP_VERSION, $min_php, '<'))
{
return false ;
}
return true ;
}
.... puis ceci pour désactiver le plugin si les versions ne correspondent pas aux exigences (fonction renvoyée false)
if ( is_plugin_active( plugin_basename(__FILE__)))
{
deactivate_plugins( plugin_basename(__FILE__)) ;
// Hide the default "Plugin activated" notice
if ( isset ($_GET['activate']))
{
unset ($_GET['activate']) ;
}
}
J'affiche ensuite un message d'administrateur pour leur faire savoir que le plug-in a été désactivé:
add_action('admin_notices', 'show_notice') ;
Où la fonction show_notice
affiche un avis de licenciement de l'administrateur.
function show_notice()
{
echo '<div class="notice notice-error is-dismissible"><h3><strong>Plugin </strong></h3><p> cannot be activated - requires at least WordPress 4.6 and PHP 5.3. Plugin automatically deactivated.</p></div>' ;
return ;
}
Fonctionne très bien.
Édité pour ajouter
Et si vous mettiez du code dans votre plugin pour bloquer la mise à jour du plugin (quelque chose comme ceci: https://stackoverflow.com/questions/17897044/wordpress-how-to-disable-plugin-update ).
La nouvelle version du plugin a un stub de préchargement. Il va vérifier PHP version. Si tout va bien, chargez le reste du plugin. Sinon, ne chargez pas le reste du plugin. Le code dans le stub de préchargement fonctionnera dans toutes les versions de PHP.
Le pré-stub ne contient pas de code PHP 7x. Par conséquent, le prétraitement du stub ne provoquera pas d'erreur. Le pré-stub désactivera également le plug-in en utilisant quelque chose de similaire à ma réponse d'origine.
Si PHP version est 7x, le stub pré-chargé charge le reste du plug-in. Et Bob est ton oncle.
F ** k les Luddites;)
Bien que je ne réponde pas directement à la question, ma propre expérience de la migration d'un plugin semi-populaire de 5.2 à 5.3 est qu'il y a beaucoup moins de frictions que ce à quoi on pourrait s'attendre en consultant les statistiques d'utilisation de wordpress.org, et ces frictions sont généralement facilement gérées par le serveur. les propriétaires du site.
Et bien sûr, les personnes qui effectuent des modifications directes sur les sites de production, méritent tout ce qu'elles obtiennent;)
En un sens, à moins que vous ne puissiez afficher un avis important sur l'incompatibilité, vous blessez davantage les utilisateurs que de les aider, car sans cet avis, ils n'auraient aucun moyen de les inciter à mettre à niveau leur environnement de serveur et ne sauront pas qu'ils le feront. ne jamais obtenir de nouvelles fonctionnalités ou mises à jour de sécurité.