Vous vous souvenez qu’hier on a codé le formulaire pour activer et désactiver le plugin pour le blog actif. C’était le fichier index.php.
Dans la foulée on a aussi prévu une procédure pour gérer les actions à faire en cas d’installation et/ou de mise à jour (fichier _install.php).
Or cette dernière prévoit d’inscrire la valeur par défaut de l’activation pour tous les blogs. Il est donc inutile, comme on l’avait prévu initialement de le faire en début de gestion du formulaire puisque c’est la valeur par défaut pour la plateforme qui sera fournie si le réglage n’existe pas pour le blog actif.
Le code correspondant était celui-ci (dans index.php) :
$core->blog->settings->addNamespace('a11yConfig');
if (is_null($core->blog->settings->a11yConfig->active)) {
try {
// Add default settings values if necessary
$core->blog->settings->a11yConfig->put('active', false, 'boolean', 'Active', false);
$core->blog->triggerBlog();
http::redirect($p_url);
} catch (Exception $e) {
$core->error->add($e->getMessage());
}
}
Donc on ne conservera que la première ligne, utile pour pouvoir accéder à l’espace de nom (qui concerne les paramètres associés au blog)[1].
Le code complet du fichier index.php devient donc cela :
<?php
/**
* @brief a11yConfig, a plugin for Dotclear 2
*
* @package Dotclear
* @subpackage Plugins
*
* @author Franck Paul, Biou and contributors
*
* @copyright Franck Paul carnet.franck.paul@gmail.com
* @copyright GPL-2.0 https://www.gnu.org/licenses/gpl-2.0.html
*/
if (!defined('DC_CONTEXT_ADMIN')) {return;}
// Get current options
$core->blog->settings->addNamespace('a11yConfig');
$ac_active = (boolean) $core->blog->settings->a11yConfig->active;
if (!empty($_POST)) {
try
{
$ac_active = !empty($_POST['ac_active']);
# Everything's fine, save options
$core->blog->settings->addNamespace('a11yConfig');
$core->blog->settings->a11yConfig->put('active', $ac_active);
$core->blog->triggerBlog();
dcPage::addSuccessNotice(__('Settings have been successfully updated.'));
http::redirect($p_url);
} catch (Exception $e) {
$core->error->add($e->getMessage());
}
}
?>
<html>
<head>
<title><?php echo __('a11yConfig'); ?></title>
</head>
<body>
<?php
echo dcPage::breadcrumb(
[
html::escapeHTML($core->blog->name) => '',
__('a11yConfig') => ''
]);
echo dcPage::notices();
echo
'<form action="' . $p_url . '" method="post">' .
'<p>' . form::checkbox('ac_active', 1, $ac_active) . ' ' .
'<label for="ac_active" class="classic">' . __('Active a11yConfig') . '</label></p>' .
'<p>' . $core->formNonce() . '<input type="submit" value="' . __('Save') . '" /></p>' .
'</form>';
?>
</body>
</html>
Conclusion : il faut savoir tailler dans le code quand c’est nécessaire ;-)
Note
[1] On parle de namespace
ou espace de nom pour les réglages associés à un blog et de workspace
ou espace de travail pour les préférences utilisateur.
1 De Bernard -
J’avais oublié hier mais ça m’est revenu…
ligne 29 :
$core->blog->triggerBlog();
sert bien à mettre à jour le formulaire ?
2 De Bernard -
Quant (ligne 55)
$core->formNonce()
il s’agit bien d’une méthode obligatoire relative à la “sécurité” dans la gestion des réponses d’un formulaire sous Dotclear ?3 De Franck -
Non, ça permet d’indiquer que le blog (son contenu ou sa représentation publique) est susceptible d’avoir été modifié et qu’il faudra donc invalider le cache.
4 De Franck -
Quant au formNonce() en effet ça permet d’inclure dans la formulaire une signature spécifique à la page et à la session en cours, histoire d’éviter que des petits-malins interviennent au milieu du processus :-)
5 De Bernard -
Si je comprends bien les méthodes
trigger...
(blog/comment/comments) sont systématiquement à utiliser lorsqu’il existe un risque potentiel de modification par une action extérieure à l’administration - ici par ex écriture à partir du résultat d’un formulaire avant toute actionredirect
où, ici,$p_url
est l’url de la page d’admin du plugin en cours6 De Franck -
extérieure ou interne à l’administration, peu importe. Dès qu’on considère que le contenu (billets, pages, commentaires, méta-données, …) est susceptible d’avoir été modifié.