- Statut : non résolu
- Ce sujet contient 29 réponses, 3 participants et a été mis à jour pour la dernière fois par luciole135, le il y a 12 années et 10 mois.
-
AuteurMessages
-
26 février 2012 à 18 h 55 min #818999
Oui, cela ne fonctionne pas, en faisant ainsi le message ne s’affiche jamais.
26 février 2012 à 19 h 00 min #81900026 février 2012 à 19 h 04 min #819001Oui, ce qui est bizarre, c’est que je me suis dit COMME à l’activation, la version de la BD stockée dans les options à la désactivation n’est pas lue correctement à l’activation, ALORS logiquement, je ne devrais même pas à avoir à modifier la version de la BD à la désactivation.
J’ai fait l’essai, j’ai supprimé, la modif de la version de la BD à la désactivation et là surprise, lors de l’activation la version de la BD est correctement lue à l’activation.
Alors, je me demande d’où vient le problème, ne serais-ce pas un problème ayant lieu lors de la désactivation ?
26 février 2012 à 19 h 43 min #819002oui, dans l’exemple donné, cela ne fonctionnera que lors de la première activation, je te propose une autre version sur le même modèle
register_activation_hook( __FILE__, ‘activate’ );
function activate() {
// systématiquement mettre à 1 pour la validation
update_option(‘luciole-activate’, ‘1’);
}
if (get_option(‘luciole-activate’) == ‘1’)
add_action(‘admin_notices’, ‘message’);
function message() {
if (get_option(‘luciole-activate’) == ‘1’) {
delete_option(‘luciole-activate’);
echo ‘<div class="updated"><p><strong>‘ . __(‘Settings activated.’, ‘luciole-domain’ ). ‘</strong></p></div>‘;
}
}26 février 2012 à 21 h 09 min #819003Oui, cela fonctionne tout comme le test sur la version de la base de données.
C’est à dire que cela affiche effectivement un message à l’activation, mais je n’arrive toujours pas à différencier les cas de nouvelle création de la base de données (suite à une nouvelle installation du plugin) et celle de simple réactivation du plugin.
Ainsi, je dois donc faire un message commun aux deux cas, du genre « table de données créée / mise à jour ».
Je ne sais pas si on peux différencier le cas de toute nouvelle installation (toute première activation) et celles des autres activations !
😉27 février 2012 à 8 h 09 min #819004ah, d’accord, alors il faut faire différemment si tu veux différencier les deux
register_activation_hook( __FILE__, ‘activate’ );
function activate() {
if (get_option(‘luciole-activate’) == ‘installed_activation’ )
update_option(‘luciole-activate’, ‘update_activation’);
else
update_option(‘luciole-activate’, ‘install_activation’);
}
if (get_option(‘luciole-activate’))
add_action(‘admin_notices’, ‘message’);
function message() {
$opt = get_option(‘luciole-activate’);
if ( $opt == ‘install_activation’ || $opt == ‘update_activation’){
update_option(‘luciole-activate’, ‘installed_activation’);
$msg = __(‘Settings activated: ‘, ‘luciole-domain’ );
$msg .= ($opt == ‘install_activation’) ? __(‘New install’, ‘luciole-domain’ ) : __(‘Update’, ‘luciole-domain’ );
echo « <div class='updated'><p><strong>$msg</strong></p></div>« ;
}
}27 février 2012 à 12 h 30 min #819005Merci Guy d’être venu à la rescousse 👏
27 février 2012 à 12 h 40 min #819006Attends attends, j’ai pas testé, il faudra que Luciole s’y mettre 🙂
27 février 2012 à 17 h 39 min #819007Vous êtes un boss !
👏
28 février 2012 à 16 h 00 min #819008Je viens de m’apercevoir d’un petit bug :
Quand je crée une nouvelle installation, tout est parfait, le premier message est celui de la création, les autres sont ceux de la mise à jour.Mais, lorsque j’installe la nouvelle version du plugin sur une installation déjà existante (donc une base de données existant), cela affiche table crée et non pas table mise à jour.
C’est le seul petit bug !
28 février 2012 à 16 h 18 min #819009oui, c’est logique, dans l’algorithme plus haut, il est supposé que l’option est enregistrée quand l’extension a déjà été activée.
Pour le faire fonctionner sur une ancienne installation sans indicateur d’activation, il faut que tu ajoutes un test sur quelque chose de connu qui t’indiquera que l’extension était installée, cela peut être la présence d’une table, la présence d’une option spécifique à l’extension, à toi de choisir. A ce moment la fonction activate deviendra:
function activate() {
$old_Install = false;
if ( get_option(‘luciole-activate’) == ‘installed_activation’)
$old_Install = true;
else {
// faire test sur une valeur spécifique ancienne install
if ( test OK ) $old_Install = true;
}
// faire initialisation
if ($old_Install == true)
update_option(‘luciole-activate’, ‘update_activation’);
else
update_option(‘luciole-activate’, ‘install_activation’);
}1 mars 2012 à 18 h 24 min #819010Oui, cela fonctionne très bien tant que je ne fais pas la suppression des options des anciennes versions du plugin. En effet, en MySQL, le codage de la table wp_option (utf8_general_ci) rend les recherches insensible à la casse.
Et du coup la suppression des anciennes options, supprime aussi les nouvelles options.Voilà, en mettant cette suppression entre commentaires comme ci dessous, cela fonctionne très bien, je n’ai pas encore trouvé comment faire une recherche MySQL sensible à la casse, je cherche.
function DailyStat_activate()
{
global $wpdb, $DailyStat_Option;
$table_name = DAILYSTAT_TABLE_NAME;
$old_Install = false;
if ( $DailyStat_Option[‘DailyStat_activate’] == ‘installed_activation’)
$old_Install = true;
elseif ($wpdb->get_var(« SHOW TABLES LIKE ‘$table_name' ») == $table_name)
$old_Install = true;
/*
if ($DailyStat_Option[‘DailyStat_DB_Version’] DAILYSTAT_DB_VERSION)
{
$wpdb->query(« DELETE FROM $wpdb->options WHERE option_name LIKE ‘%dailystat%' »);
$wpdb->query(‘OPTIMIZE TABLE ‘ . $wpdb->options);
luc_dailystat_CreateTable();
};
*/
if ($old_Install == true)
$DailyStat_Option[‘DailyStat_activate’] = ‘update_activation’;
else
$DailyStat_Option[‘DailyStat_activate’] = ‘install_activation’;
update_option(‘DailyStat_Option’, $DailyStat_Option);
}1 mars 2012 à 19 h 23 min #819011Bon, j’ai trouvé comment faire, il suffit de faire un COLLATE en MySQL :
$wpdb->query(« DELETE FROM $wpdb->options WHERE option_name LIKE COLLATE utf8_bin ‘%dailystat%' »);
Et là, cela fonctionne parfaitement.
1 mars 2012 à 21 h 12 min #819012je n’ai pas compris pourquoi tu avais besoin de comparer avec la casse 🙂 mais oui, la collation influe sur les résultats, et c’est vrai que par défaut c’est en utf8_general_ci, donc insensible à la casse
1 mars 2012 à 21 h 21 min #819013Guy wrote:je n’ai pas compris pourquoi tu avais besoin de comparer avec la casse 🙂 mais oui, la collation influe sur les résultats, et c’est vrai que par défaut c’est en utf8_general_ci, donc insensible à la casseCar mes nouvelles options s’appelent DailyStat_Option et sont sérialisées dans un tableau alors que les anciennes commencent toutes par dailystat en minuscule et étaient individuelles -en les sérialisant, je minimise l’accès à la base de données-, mais si je ne respecte pas la casse, les nouvelles options sont supprimées et du coup l’algorithme ne fonctionne pas !
Merci encore.
👏 -
AuteurMessages
- Vous devez être connecté pour répondre à ce sujet.