Vous n'êtes pas identifié(e).
13 février 2024 Sortie de Dotclear 2.29
Voila cela fait quelques temps que je cherche des moyens simples et rapides de préparer des plugins aux changements de settings d'une des prochaines versions de Dotclear (2.2 ?).
Bon normalement ce changement devrait se faire en douceur car les settings auront une période transitoire qui accepte les deux écritures. Bref je voudrais quand même pouvoir ne pas utiliser des plugins qui ne sont pas écrit pour cette nouvelle version.
Une des façons qui bloque l'utilisation d'un plugin dés la mise à jour de Dotclear est la suivante:
Je modifie mon fichier de plugin _define.php comme suit:
<?php
if (!defined('DC_RC_PATH')){return;}
if (version_compare(DC_VERSION,'2.2','>='))
{
$this->disabled['monPloug'] = array(
'root' => dirname(__FILE__),
'root_writable' => is_writable(dirname(__FILE__))
);
if (!file_exists(dirname(__FILE__).'/_disabled')) {
@file_put_contents(dirname(__FILE__).'/_disabled','');
}
}
else
{
$this->registerModule(
/* Name */ "monPloug",
/* Description*/ "Un super top ploug pas compatible",
/* Author */ "Boulet",
/* Version */ '0.0.1-alpha',
/* Permissions */ 'admin'
);
}
?>Cela a pour effet de désactiver "instantanément" le plugin.
Vous en pensez quoi ?
Cordialement,
_JC | Intérimaire | En mode invisible
Hors ligne
En gros, tu veux empêcher les gens d'utiliser tes plugins s'ils sont en 2.2 ? Je ne comprends pas la logique.
Oui enfin je veux empêcher des bugs et surtout obliger les gens à mettre à jour les plugins à ce moment la sans polluer un blog ou admin de warnings et autre.
D'ailleurs ce serait plutôt pour empêcher le plugin avec une futur version "post transitoire" (2.3 ?).
Pour l'instant ce ne sont que des réflexions hein :)
Je cherche une solution simple pour que ce ne soit pas Bagdad lors des prochaines mise à jour. Après c'est peut-être du coté du Dotclear que se trouve la solution.
Cordialement,
_JC | Intérimaire | En mode invisible
Hors ligne
PS: Pour l'instant je n'empêche que l'installation d'un nouveau "vieux" plugin à travers le fichier _install.php en ajoutant ça :
...
# Check DC version (dev on)
if (!version_compare(DC_VERSION,'2.1.5','>='))
{
throw new Exception('Plugin called monPloug 0.1 requires Dotclear 2.1.5 or higher.');
}
# Check DC version (new settings)
if (version_compare(DC_VERSION,'2.2','>='))
{
throw new Exception('Plugin called monPloug 0.1 requires Dotclear up to 2.2.');
}
...rePS: Idem ici il faudrait mettre '2.3'
Cordialement,
_JC | Intérimaire | En mode invisible
Hors ligne
Ah oui mais non : il est préférable que le _define.php reste un simple _define.php, c'est-à-dire l'enregistrement des informations de plugin/thème (et non, je ne redirai pas que je regrette ces bons vieux desc.xml, mais bon...).
Si tu veux rendre le plugin inopérant en fonction de ta version de Dotclear (par exemple), tu peux le faire depuis le fichier _prepend.php de ton plugin. Il suffit de faire un simple return; dans le code principal pour que le plugin ne se retrouve pas pris en compte par Dotclear.
Who Cares ?
Hors ligne
Ah oui mais non : il est préférable que le _define.php reste un simple _define.php, c'est-à-dire l'enregistrement des informations de plugin/thème (et non, je ne redirai pas que je regrette ces bons vieux desc.xml, mais bon...).
Si tu veux rendre le plugin inopérant en fonction de ta version de Dotclear (par exemple), tu peux le faire depuis le fichier _prepend.php de ton plugin. Il suffit de faire un simple return; dans le code principal pour que le plugin ne se retrouve pas pris en compte par Dotclear.
Oui mais dans ce cas j'ai par exemple quand même le menu à gauche enfin si je ne dis pas trop de bétises, le plugin est quand même chargé dans $core->plugins, bref il faudrait ajouter une condition sur toutes les pages du plugin ce qui n'est pas top.
Cordialement,
_JC | Intérimaire | En mode invisible
Hors ligne
Je suis pas sûr que désactiver un plugin soit plus informatif que d'afficher des messages d'erreur. Si il y a des messages d'erreur, c'est moche mais l'utilisateur verra que quelque chose cloche. Si le plugin est désactivé, il ne comprendra pas forcément ce qu'il se passe.
- les règles du forum : http://forum.dotclear.net/viewtopic.php?id=39494
- la galaxie de Dotclear 2 : http://fr.dotclear.org/documentation/2.0/links
Hors ligne
Je suis pas sûr que désactiver un plugin soit plus informatif que d'afficher des messages d'erreur. Si il y a des messages d'erreur, c'est moche mais l'utilisateur verra que quelque chose cloche. Si le plugin est désactivé, il ne comprendra pas forcément ce qu'il se passe.
Ouais enfin sur un multiblog c'est pas top.
Je reste un peu perplexe sur tout ça, j'ai du mal à imaginer comment s'effectuera la transition chez différentes personnes...
Cordialement,
_JC | Intérimaire | En mode invisible
Hors ligne
Ouais enfin sur un multiblog c'est pas top.
Si le responsable du multiblog fait attention pendant la mise à jour, y'a pas de raison que ça se passe mal.
Je reste un peu perplexe sur tout ça, j'ai du mal à imaginer comment s'effectuera la transition chez différentes personnes...
Si les développeurs ont le temps de mettre leurs plugins à jour avant la sortie de la version officielle, ça devrait aller. Pour les plugins non mis à jour, il y aura moyen de cacher les erreurs en modifiant la configuration de PHP, ça nécessite d'ajouter 2 lignes dans le fichier de configuration. Il y aura toujours des problèmes mais c'est inhérent aux mises à jour, ça n'arrive pas qu'avec Dotclear.
- les règles du forum : http://forum.dotclear.net/viewtopic.php?id=39494
- la galaxie de Dotclear 2 : http://fr.dotclear.org/documentation/2.0/links
Hors ligne
Oui mais dans ce cas j'ai par exemple quand même le menu à gauche enfin si je ne dis pas trop de bétises, le plugin est quand même chargé dans $core->plugins, bref il faudrait ajouter une condition sur toutes les pages du plugin ce qui n'est pas top.
Non.
La présence d'un _prepend.php retournant NULL (le fameux return; seul) est supposée bloquer le chargement du plugin.
C'est valable côté frontend et/ou admin. Nul besoin d'avoir de test supplémentaire dans toutes les pages du plugin, bien au contraire.
Who Cares ?
Hors ligne
Il y aura toujours des problèmes mais c'est inhérent aux mises à jour, ça n'arrive pas qu'avec Dotclear.
Bien d'accord et en tant que développeur de ploug, je me renseigne un peu et vous demande vos avis :)
Cordialement,
_JC | Intérimaire | En mode invisible
Hors ligne
JcDenis a écrit :Oui mais dans ce cas j'ai par exemple quand même le menu à gauche enfin si je ne dis pas trop de bétises, le plugin est quand même chargé dans $core->plugins, bref il faudrait ajouter une condition sur toutes les pages du plugin ce qui n'est pas top.
Non.
La présence d'un _prepend.php retournant NULL (le fameux return; seul) est supposée bloquer le chargement du plugin.
C'est valable côté frontend et/ou admin. Nul besoin d'avoir de test supplémentaire dans toutes les pages du plugin, bien au contraire.
Ha ben la tu m'intéresses, j'avais fait un test ou la page se chargeait quand même, les fichiers _admin.php, etc du ploug étaient quand même connus... J'ai dû faire une boulette.
Cordialement,
_JC | Intérimaire | En mode invisible
Hors ligne
Bonsoir,
Le top ce serait lors de la mise à jour de dotclear dans l'interface d'administration, un rappel que des plugins peuvent avoir à être mis à jour eux aussi, du fait de certaines modifications ayant un impact (voir détailler succinctement les messages d'erreur qui pourraient apparaître) et en plus lister les plugins les plus courants (utilisés) à mettre à jour impérieusement.
Non ? Après tout ce n'est que du texte ;-)
Passez à l'occasion si vous n'avez pas peur de vous faire mal aux yeux http://akhthot.free.fr
Hors ligne
Vous n'êtes pas identifié(e).