DotclearWatch / Blog - Mot-clé - process

[2.36] Modification des Utility et Process

Jean-Christian Denis — Sat, 18 Oct 2025 11:47:00 +0200

Depuis Dotclear 2.36 les classes de context sont accessibles directement en tant que méthodes de ces context, cela implique des changements dans leur fontionnement qui se répercutent jusque sur les thèmes et plugins.

L'arborescence de Dotclear contient un nouvel espace de nom Dotclear\Helper\Process qui embarque differentes classes utiles au fonctionnement des Utility et Process :

Dotclear\Helper\Process\AbstractProcess
Dotclear\Helper\Process\AbstractSingleton
Dotclear\Helper\Process\AbstractUtility
Dotclear\Helper\Process\TraitProcess

Utility

Normalement nul besoin de se préoccuper de cette partie, elle appartient au core de Dotclear, mais c'est toujours bon de savoir comment cela fonctionne.

Les Utility (Backend, Frontend, Upragde, Install) sont désormais des Container, leurs Process sont des services, leurs classes de second niveau sont des services et tous sont accessibles depuis des méthodes ( voir Modification des containeurs ) Les Utility étendent la classe abstraite AbstractUtility qui embarque tout ce qu'il faut pour charger leurs services. Enfin les Utility utilisent le trait TraitProcess qui embarque ce qu'il faut pour le bon déroulement du processus requis par le core.

Exemple de l'Utility Backend et de la classe de second niveau Favorites :

<?php

declare(strict_types=1);

namespace Dotclear\Core\Backend;


class Utility extends AbstractUtility
{
    // ...

    public function getDefaultServices(): array
    {
        return [
            Favorites::class   => Favorites::class,
            // ...
        ];
    }

    public function favorites(): Favorites
    {
        return $this->get(Favorites::class);
    }

    // ...
}

Accessible désormais avec :

App::backend()->favorites();

Process

Jusqu'à Dotclear 2.36 toutes les classes de second niveaux du core (les servcies des Utility) et toutes les classes des plugins et thèmes lièes à la gestion de modules devaient étendre la classe Process du core. Depuis Dotclear 2.36 les services des Utility peuvent avoir besoin d'étendre d'autres classes ce qui serait impossible tel quel. La classes abstraite Process s'est donc transformée en trait, afin de pouvoir être utilisé en plus d'autres classes.

Exemple du plugin blogroll de la distribution :

<?php

declare(strict_types=1);

namespace Dotclear\Plugin\blogroll;

use Dotclear\Helper\Process\TraitProcess;

class Backend
{
    use TraitProcess;

    public static function init(): bool
    {
        //...
    }
}

Les plugins dcProxy s'occupent de faire le lien entre les plugins / thèmes qui ne sont pas à jour et l'utilisation du trait.

Ce qu'il faut retenir et que là ou on utilisait :

<?php

declare(strict_types=1);

namespace Dotclear\Plugin\MonPlugin;

Use Dotclear\Core\Process;

class Backend extends Process
{
    //...
}

Il faut utiliser :

<?php

declare(strict_types=1);

namespace Dotclear\Plugin\MonPlugin;

use Dotclear\Helper\Process\TraitProcess;

class Backend
{
    use TraitProcess;

    //...
}

Lancement de l'application

Jean-Christian Denis — Wed, 12 Jul 2023 22:02:00 +0100

La version 2.27 de Dotclear introduit un changement technique de taille dans le moteur de blog.

Avec l'accentuation de l'utilisation des espaces de noms PHP dans le moteur, Dotclear peut désormais travailler autrement. Antérieurement à la version 2.27, les points d'entrées était multiples et déclarés par des fichiers bien précis placés dans des dossiers tout aussi précis. Par exemple chaque page de l'administration avait sa propre page PHP correspondante et était référencée par rapport à ce fichier. A partir de la version 2.27 un simple fichier index.php avec un contenu adéquat permet de faire tout ça. Ce fichier index.php va lancer l'application Dotclear avec les paramètres qui lui correspondent. L'application va ensuite traduire ces paramètres et lancer le processus associé. Schématiquement le déroulement du script donne :
index.php => App => Utility => Process

L'application Dotclear utilise désormais un unique point d'entrée :
Dotclear\App::bootstrap('utility','process');

Un Utility est une partie générale de Dotclear, les correspondances avec les versions antérieures sont:

admin => Backend,
public => Frontend,
upgrade CLI => Upgrade,
install => Install

Ensuite chaque Utility lance un Process qui auparavant était une page, par exemple pour la page d'accueil de l'administration des blogs on aura Backend / Home. Cela peu paraître déroutant pour celui qui pratique Dotclear depuis des années, mais la logique aidant, il est assez simple de se repérer, d'autant plus que coté code, on retrouvera ce schéma. En reprenant l'exemple de la page d'accueil de l'administration qui aura comme paramètre Utility=Backend et Process=Home, on retrouve les espaces de noms et les fichiers physiques suivants :

Utility = Backend, Class = Dotclear\Core\Backend\Utility, Fichier = src/Core/Backend/Utility.php
Process = Home, Class = Dotclear\Process\Backend\Home, Fichier = src/Process/Backend/Home.php

Partant de ce principe pour afficher la page d'accueil de l'administration de Dotclear, il faut dans le fichier index.php indiquer où se trouve l'application et la lancer avec ces deux paramètres :

<?php
// on va cherche l'application Dotclear
require_once implode(DIRECTORY_SEPARATOR, [__DIR__, '..', 'src', 'App.php']);
// on lance l'application pour afficher la page d'accueil de l'administration
Dotclear\App::bootstrap('Backend', 'Home');

Logique.

Ensuite pour naviguer, l'application va tenir compte du paramètre de requête HTTP nommé process et le substituer à celui du fichier index.php, la navigation dans l'admin devient alors possible depuis une seule page index.php.
Coté public c'est encore plus simple car il n'y a pas de process en 2.27, seul l'Utility Frontend est appelé, le gestionnaire d'URL public se chargeant de jouer avec les templates.

A noter que pour les installations existantes qui feront la mise à jour en 2.27, les deux écritures restent valables. Il n'est pas obligatoire de modifier les fichiers index.php des blogs et la partie admin accepte également l'utilisation des anciens points d'entrée.

Le contenu de ce document a été écrit suivant le code de la version 2.27 de Dotclear.

La class Process

Jean-Christian Denis — Tue, 11 Jul 2023 20:41:00 +0100

La classe Process introduite dans les dernières versions de Dotclear devient la norme et est requise quasi partout depuis Dotclear 2.27.

La plupart des classes de plugins et thèmes doivent étendre la classe Process, pour cela il suffit de déclarer son utilisation en début de fichier puis d'étendre votre classe.

<?php
use Dotclear\Core\Process;

class Manage extends Process
{
}

Cette classe est pour l'instant très succincte mais permet de découper le déroulement du script en trois parties.

Première partie

Elle utilise la méthode Process::init() elle permet de vérifier les droits à utiliser votre classe. Elle utilise un mécanisme mémorisant le statut de cette initialisation, verrouillant ou non l'utilisation des méthodes suivantes.

public static function init(): bool
{
    // On enregistre la permissions d'utiliser la classe et on renvoie le résultat
    return self::status(My::checkContext(My::MANAGE));
}

On voit ici l'utilisation de la classe My qui est un outil d'aide à l'écriture des modules simplifiant l'utilisation de certains mécanismes.

Seconde partie

Elle utilise la méthode Process::process() qui est consacrée à la préparation et au traitement des données, telles que celles des formulaires par exemple.

public static function process(): bool
{
    // On vérifie le droit d'effectuer cette partie
    if (!self::status()) {
        return false;
    }

    if (!empty($_POST['id'])) {
        // traitement de mon formulaire

        // On a réussi, on ajoute un message
        Notices::addSuccessNotice(__('Victory'));
        // On redirige vers la page du plugin
        dcCore::->admin->url->redirect('admin.plugin.' . My::id());
    }

    // Cette méthode doit retourner true si on veut exécuter la troisième partie
    return true;
}

La troisième partie

Elle utilise la méthode Process::render() qui est consacré au rendu. C'est à dire à l'affichage dans le navigateur.

public static function render(): void
{
    // On vérifie le droit d'effectuer cette partie
    if (!self::status()) {
        return;
    }

    // On prépare l'affichage du haut de page
    Page::openModule(My::name());

    // On ajoute le menu façon Dotclear
    echo
    Page::breadcrumb(
        [
            __('Plugin')  => '',
            My::name() => '',
        ]
    ) .
    // On affiche d'éventuelle messages
    Notices::getNotices();

    // On ajoute le contenu de la page
    echo __('yeah!');

    // On ajoute l'aide de la page
    Page::helpBlock(My::id());

    // On ferme la page
    Page::closeModule();
}

Ici on voit l'utilisation des classes d'outils My et Page qui vont grandement faciliter l'écriture des plugins et thèmes.

A noter que seule la première méthode init() est obligatoire. Si elle renvoie true, c'est que la classe ne contient pas de méthode process(), la méthode render() sera exécuté.

Le contenu de ce document a été écrit suivant le code de la version 2.27 de Dotclear.