DotclearWatch / Blog - Mot-clé - 2.27

Sortie de Dotclear 2.27

Jean-Christian Denis — Sun, 13 Aug 2023 10:00:00 +0200

Ce dimanche 13 Août 2023 sort la version 2.27 du moteur de blogs Dotclear.

En plus de la sortie de cette version 2.27, le 13 Août est la date anniversaire de Dotclear et cette année le moteur de blog fête ses 20 ans d'existence ! Vous pouvez aller lui souhaiter un bon anniversaire sur le billet d'annonce officielle.

C'est également l'occasion pour la plateforme non-officielle dotclear.watch de faire son lancement, en proposant aux développeurs toute une série de billets dédiés à l'explication des évolutions de cette version 2.27.

Fichier Install d'un module

Jean-Christian Denis — Sun, 16 Jul 2023 20:51:00 +0100

Le fichier Install.php, placé dans le dossier src du module, permet d'effectuer ses opérations d'installation et de mise à jour.

Le fichier Install.php fait partie du processus reconnu par le gestionnaire de modules, il est donc automatiquement pris en compte coté admin si il existe.

Il est placé dans le sous dossier src du module,
Il contient une classe du nom de Install,
Il est dans l'espace de nom PHP Dotclear\Plugin\monPlugin ou Dotclear\Theme\monTheme,
La classe doit étendre la classe Process,
Seules les méthodes init() et process() sont utilisées,

Ce fichier est chargé en préambule de la page d'accueil de l'admin, de la page de gestion de l'apparence du blog, et de la page de gestion des plugins. Généralement il permet d'enregistrer des paramètres, de créer des tables, etc.
La méthode init() de la classe doit vérifier que la version installée n'existe pas ou qu'elle est à mettre à jour, elle doit renvoyer false si il n'y a pas besoin d'effectuer ces opérations d'installation / mise à jour. Pour aider, la classe My embarque un contexte qui permet cela My::checkContext(My::INSTALL).

Exemple du plugin blogroll de la distribution qui ajoute une table à la base de données :

<?php
declare(strict_types=1);

namespace Dotclear\Plugin\blogroll;

use dcCore;
use Dotclear\Core\Process;
use Dotclear\Database\Structure;
use initBlogroll;

class Install extends Process
{
    public static function init(): bool
    {
        return self::status(My::checkContext(My::INSTALL));
    }

    public static function process(): bool
    {
        if (!self::status()) {
            return false;
        }

        $schema = new Structure(dcCore::app()->con, dcCore::app()->prefix);

        $schema->{initBlogroll::LINK_TABLE_NAME}
            ->link_id('bigint', 0, false)
            ->blog_id('varchar', 32, false)
            ->link_href('varchar', 255, false)
            ->link_title('varchar', 255, false)
            ->link_desc('varchar', 255, true)
            ->link_lang('varchar', 5, true)
            ->link_xfn('varchar', 255, true)
            ->link_position('integer', 0, false, 0)

            ->primary('pk_link', 'link_id')
            ->index('idx_link_blog_id', 'btree', 'blog_id')
            ->reference('fk_link_blog', 'blog_id', 'blog', 'blog_id', 'cascade', 'cascade')
        ;

        (new Structure(dcCore::app()->con, dcCore::app()->prefix))->synchronize($schema);

        return true;
    }
}

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

Fichier Config d'un module

Jean-Christian Denis — Sun, 16 Jul 2023 14:03:00 +0100

Le fichier Config.php, placé dans le dossier src du module, simplifie la gestion de sa configuration.

Le fichier Config.php fait partie du processus reconnu par le gestionnaire de modules, il est donc automatiquement pris en compte dans l'administration si il existe.

Il est placé dans le sous dossier src du module,
Il contient une classe du nom de Config,
Il est dans l'espace de nom PHP Dotclear\Plugin\monPlugin ou Dotclear\Theme\monTheme,
La classe doit étendre la classe Process,
Les 3 méthodes init() et process() et render() sont utilisées,

Cette classe simplifie la gestion de la configuration d'un module dans le sens où la partie construction de la page est déjà effectuée par le gestionnaire de modules. Seul le traitement des valeurs et le contenu du formulaire sont à la charge de la classe Config. Un lien vers cette page sera ajouté à la liste de plugins ou sur les thèmes de la page de gestion d'apparence du blog. Un lien sera également ajouté en bas de page principale de gestion du plugin si elle existe.

Exemple complet du fichier config du thème customCSS de la distribution :

<?php
namespace Dotclear\Theme\customCSS;

use dcCore;
use Dotclear\Core\Backend\Notices;
use Dotclear\Core\Process;
use Dotclear\Helper\File\Path;
use Dotclear\Helper\Html\Html;
use Dotclear\Helper\L10n;
use Exception;
use form;

class Config extends Process
{
    public static function init(): bool
    {
        if (My::checkContext(My::CONFIG)) {
            My::l10n('main');
            dcCore::app()->admin->css_file = Path::real(dcCore::app()->blog->public_path) . '/custom_style.css';

            if (!is_file(dcCore::app()->admin->css_file) && !is_writable(dirname(dcCore::app()->admin->css_file))) {
                throw new Exception(
                    sprintf(
                        __('File %s does not exist and directory %s is not writable.'),
                        dcCore::app()->admin->css_file,
                        dirname(dcCore::app()->admin->css_file)
                    )
                );
            }
            self::status(true);
        }

        return self::status();
    }

    public static function process(): bool
    {
        if (!self::status()) {
            return false;
        }

        if (isset($_POST['css'])) {
            @$fp = fopen(dcCore::app()->admin->css_file, 'wb');
            fwrite($fp, $_POST['css']);
            fclose($fp);

            Notices::message(__('Style sheet upgraded.'), true, true);
        }

        return true;
    }

    public static function render(): void
    {
        if (!self::status()) {
            return;
        }

        $css_content = is_file(dcCore::app()->admin->css_file) ? file_get_contents(dcCore::app()->admin->css_file) : '';

        echo
        '<p class="area"><label>' . __('Style sheet:') . '</label> ' .
        form::textarea('css', 60, 20, Html::escapeHTML($css_content)) . '</p>';
    }
}

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

Fichier Frontend d'un module

Jean-Christian Denis — Sun, 16 Jul 2023 13:48:00 +0100

Le fichier Frontend.php, placé dans le dossier src du module, permet de préparer le nécessaire à son fonctionnement en partie public.

Le fichier Frontend.php fait partie du processus reconnu par le gestionnaire de modules, il est donc automatiquement pris en compte coté public si il existe.

Il est placé dans le sous dossier src du module,
Il contient une classe du nom de Frontend,
Il est dans l'espace de nom PHP Dotclear\Plugin\monPlugin ou Dotclear\Theme\monTheme,
La classe doit étendre la classe Process,
Seules les méthodes init() et process() sont utilisées,

Généralement cette classe est utilisée pour préparer des variables nécessaires au fonctionnement du module, déclarer ses templates, ajouter ses behaviors, pour la partie publique des blogs.

Exemple du fichier Frontend.php du plugin blogroll de la distribution :

<?php
declare(strict_types=1);

namespace Dotclear\Plugin\blogroll;

use dcCore;
use Dotclear\Core\Process;

class Frontend extends Process
{
    public static function init(): bool
    {
        return self::status(My::checkContext(My::FRONTEND));
    }

    public static function process(): bool
    {
        if (!self::status()) {
            return false;
        }

        dcCore::app()->tpl->addValue('Blogroll', [FrontendTemplate::class, 'blogroll']);
        dcCore::app()->tpl->addValue('BlogrollXbelLink', [FrontendTemplate::class, 'blogrollXbelLink']);

        dcCore::app()->addBehaviors([
            'initWidgets'        => [Widgets::class, 'initWidgets'],
            'initDefaultWidgets' => [Widgets::class, 'initDefaultWidgets'],
        ]);

        return true;
    }
}

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

Fichier Backend d'un module

Jean-Christian Denis — Sun, 16 Jul 2023 13:36:00 +0100

Le fichier Backend.php, placé dans le dossier src du module, permet de préparer le nécessaire à son fonctionnement pour sa partie administration.

Le fichier Backend.php fait partie du processus reconnu par le gestionnaire de modules, il est donc automatiquement pris en compte dans l'administration si il existe.

Il est placé dans le sous dossier src du module,
Il contient une classe du nom de Backend,
Il est dans l'espace de nom PHP Dotclear\Plugin\monPlugin ou Dotclear\Theme\monTheme,
La classe doit étendre la classe Process,
Seules les méthodes init() et process() sont utilisées,

Généralement cette classe est utilisée pour préparer des variables nécessaires au fonctionnement du module, ajouter ses menus, favoris, behaviors, pour la partie administration des blogs.

Exemple du fichier Backend.php du plugin aboutConfig de la distribution :

<?php
declare(strict_types=1);

namespace Dotclear\Plugin\aboutConfig;

use Dotclear\Core\Backend\Menus;
use Dotclear\Core\Process;

class Backend extends Process
{
    public static function init(): bool
    {
        return self::status(My::checkContext(My::BACKEND));
    }

    public static function process(): bool
    {
        if (self::status()) {
            My::addBackendMenuItem(Menus::MENU_SYSTEM);
        }

        return self::status();
    }
}

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

Fichier Prepend d'un module

Jean-Christian Denis — Sun, 16 Jul 2023 10:38:00 +0100

Le fichier Prepend.php, placé dans le dossier src du module, permet de préparer le nécessaire à son fonctionnement.

Le fichier Prepend.php fait partie du processus reconnu par le gestionnaire de modules, il est donc automatiquement pris en compte si il existe.

Il est placé dans le sous dossier src du module,
Il contient une classe du nom de Prepend,
Il est dans l'espace de nom PHP Dotclear\Plugin\monPlugin ou Dotclear\Theme\monTheme,,
La classe doit étendre la classe Process,
Seuls les méthodes init() et process() sont utilisées,

Généralement cette classe est utilisée pour préparer des variables nécessaires au fonctionnement global du module ou pour ajouter des behaviors, à la fois coté admin et coté public. Si ces définitions sont propres à l'admin ou au public, il faut utiliser les fichiers Backend.php ou Frontend.php.

Exemple du fichier Prepend.php du plugin blogroll de la distribution :

<?php
declare(strict_types=1);

namespace Dotclear\Plugin\blogroll;

use dcCore;
use Dotclear\Core\Process;

class Prepend extends Process
{
    public static function init(): bool
    {
        return self::status(My::checkContext(My::PREPEND));
    }

    public static function process(): bool
    {
        if (!self::status()) {
            return false;
        }

        dcCore::app()->url->register('xbel', 'xbel', '^xbel(?:\/?)$', [FrontendUrl::class, 'xbel']);

        return true;
    }
}

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

Fichier release de Dotclear

Jean-Christian Denis — Fri, 14 Jul 2023 23:01:00 +0100

Avec la version 2.27 de Dotclear, un nouveau fichier release.json fait son apparition.

Ce fichier au format json, présent à la racine de l'installation, définit les variables susceptibles de changer d'une version à l'autre. Dans les versions précédentes de Dotclear, elles étaient définies dans des constantes principalement dans le fichier inc/_prepend.php. Bien que définies autrement ces valeurs sont toujours accessibles à partir des mêmes constantes. On peut également les lire à partir de la méthode release() de la classe App, ces valeurs sont "chargées" une seule fois et ne peuvent être modifiées pendant toute l'exécution du script..

<?php
use Dotclear\App;

// renvoie '2.27'
echo App::release('release_version');

// renvoie '8.1'
echo App::release('next_php');

// renvoie 'berlin,blowup,blueSilence,customCSS,ductile'
echo App::release('distributed_themes');

Toutes les valeurs renvoyées par cette méthode sont de type string. Les valeurs sous forme de tableau du fichier release seront concaténées sous forme de chaîne.

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

Fichier de dépôt tiers

Jean-Christian Denis — Fri, 14 Jul 2023 20:25:00 +0100

Depuis quelques versions le gestionnaire de modules de Dotclear supporte les dépôts tiers. Le fichier dcstore.xml se trouvant à la racine du module permet de définir ce dépôt.

En réalité l'emplacement de ce fichier n'est pas dans le module mais là où est hébergé le dépôt tiers ! Par commodité et comme souvent le dépôt tiers est un dépôt github en le plaçant dans le module, le développeur garantit qu'il sera présent sur son dépôt.
L'emplacement final de ce fichier est renseigné dans le fichier de définition du module dans le paramètre 'repository'.
Son contenu est écrit en xml et est calqué sur le dépôt officiel Dotaddict.org. Voici l'exemple du plugin tweakStore :

<?xml version="1.0"?>
<modules xmlns:da="http://dotaddict.org/da/">
  <module id="tweakStores">
    <name>Tweak stores</name>
    <version>0.8</version>
    <author>Jean-Christian Denis and Contributors</author>
    <desc>Helper to manage external repositories</desc>
    <file>https://github.com/JcDenis/tweakStores/releases/download/v0.8/plugin-tweakStores.zip</file>
    <da:dcmin>2.26</da:dcmin>
    <da:details>https://plugins.dotaddict.org/dc2/details/tweakStores</da:details>
    <da:support>https://github.com/JcDenis/tweakStores</da:support>
  </module>
</modules>

Pas besoin d'explication sur son contenu, il reprend en grande partie les informations présentes dans define.php du module en ajoutant le lien vers le fichier Zip du module.
N.D.L.R : En théorie un fichier de dépôt tiers pourrait contenir les informations de plusieurs modules, en pratique, je n'ai pas testé.

Il existe des plugins qui permettent de créer automatiquement ce fichier et également des scripts. (Liens non exhaustifs à titre d'exemple.)

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

Fichier init d'un module

Jean-Christian Denis — Fri, 14 Jul 2023 19:54:00 +0100

Le fichier _init.php d'un module permet principalement d'initialiser des constantes sans même que le module soit chargé. Ce fichier se place à la racine du module.

Le rôle de ce fichier est de pouvoir charger des constantes avant même que le module soit chargé afin de partager avec d'autres modules certaines valeurs et ceci même si le module est désactivé.
Ce fonctionnement est spécial et ce fichier ne doit contenir que le minimum d'informations qui devront si possible ne pas changer à chaque version du module. (Sinon tout l'intérêt de ce fichier est perdu.)
Généralement la classe contenue dans ce fichier permet de définir des noms de permissions ou de tables.
Exemple tiré du plugin blogroll de la distribution :

<?php
// aucun espace de nom PHP n'est déclaré

// Cette classe sera accessible à tous les autres modules
class initBlogroll
{
    // On définit le nom de la permission liée à blogroll
    public const PERMISSION_BLOGROLL = 'blogroll';

    // On définit le nom de la table de base de données de blogroll
    public const LINK_TABLE_NAME = 'link';
}

Il est recommandé de garder des noms de classe et de constantes dans le style de l'exemple ci-dessus.
Cette classe va permettre par exemple au plugin blogroll lui même de définir ses permissions dans son fichier de définition :

<?php
 
$this->registerModule(
    // ...
    [
        'permissions' => dcCore::app()->auth->makePermissions([
            initBlogroll::PERMISSION_BLOGROLL,
        ]),
        'type'        => 'plugin',
    ]
);

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

Les classes de module My

Jean-Christian Denis — Fri, 14 Jul 2023 10:27:00 +0100

Dotclear version 2.27 propose pour les plugins et thèmes des classes d'aide pour simplifier l'écriture du code.

Deux classes My (qui étendent une troisième commune nommé MyModule) sont disponibles, MyPlugin pour les plugins et MyTheme pour les thèmes, elle fournissent des méthodes statiques qui vont simplifier l'écriture des modules.

Inclusion

Pour les utiliser il suffit d'inclure dans le dossier src du module un fichier My.php avec le contenu suivant :

<?php
/**
 * Mettre ici les informations de licence.
 */
declare(strict_types=1);

namespace Dotclear\Plugin\monPlugin;

use Dotclear\Module\MyPlugin;

class My extends MyPlugin
{
}

A adapter pour un thème. Il possible d'ajouter ses propres méthodes à cette classe tant que ça n'interfère pas avec celles de MyPlugin, MyTheme et MyModule.

Utilisation

Ensuite il sera possible d'utiliser toutes les méthodes de MyPlugin (MyTheme) dans les classes du plugin (thème).

<?php
namespace Dotclear\Plugin\monPlugin;

use Dotclear\Core\Process;
use Dotclear\Core\Backend\Page;

// Page principale de gestion du plugin
class Manage extends Process
{
    public static function init(): bool
    {
        // On vérifie que l'utilisateur à le droit d'exercer dans ce contexte
        return self::status(My::checkContext(My::MANAGE));
    }

    public static function process(): bool
    {
        if (!empty($_POST['step'])) {
            // ...

            // On redirige la page à l'aide de My
            My::redirect(['step' => 2]);
        }
    }

    public static function render(): void
    {
        // On utilise la classe My pour trouver le nom du plugin et des fichiers
        Page::openModule(
            My::name(),
            My::cssLoad('backend')
        );
    }
}

Méthodes

My::define()

protected static function define(): dcModuleDefine

Cette méthode renvoie l'instance de définition du module.

My::checkContext()

protected static function checkContext(int $context): bool

Cette méthode permet de vérifier que l'utilisateur à le droit d'exercer dans un certain contexte, elle renvoie true si l'utilisateur à assez de droits, false sinon. Elle prend en paramètre le contexte qui doit être vérifier. La liste des contextes prédéfinis est disponible dans les constantes de la classe My :

0 : INSTALL : Install context
1 : PREPEND : Prepend context
2 : FRONTEND : Frontend context
3 : BACKEND : Backend context (usually when the connected user may access at least one functionnality of this module)
4 : MANAGE : Manage context (main page of module)
5 : CONFIG : Config context (config page of module)
6 : MENU : Menu context (adding a admin menu item)
7 : WIDGETS : Widgets context (managing blog's widgets)
8 : UNINSTALL : Uninstall context (réservé pour le plugin Uninstaller)

My::checkCustomContext()

protected static function checkCustomContext(int $context): ?bool

Cette méthode est appelée en début de la méthode précédente checkContext et peut être réécrite dans la classe My du module si on en a besoin. Elle permet d'utiliser ses propres droits, ou de modifier des droits de contexte de la méthode précédente. Si checkCustomContext() renvoie null alors les contextes de la classe précédente seront testés.
Exemple avec le fichiers My du plugin userPrefs de la distribution :

<?php
declare(strict_types=1);

namespace Dotclear\Plugin\userPref;

use dcCore;
use Dotclear\Module\MyPlugin;

class My extends MyPlugin
{
    protected static function checkCustomContext(int $context): ?bool
    {
        // allways limit to super admin
        return defined('DC_CONTEXT_ADMIN')
            && dcCore::app()->auth->isSuperAdmin();
    }
}

My::path()

public static function My::path(): string

Cette méthode renvoie le chemin du dossier du module.

My::id()

protected static function My::id(): string

Cette méthode renvoie l'identifiant du module.

My::name()

protected static function My::name(): string

Cette méthode renvoie le nom traduit du module.

My::settings()

public static function settings(): ?dcNamespace

Cette méthode renvoie l'instance de l'espace de paramètres du module. Le module doit utiliser son ID comme nom d'espace de paramètre pour pouvoir utiliser cette méthode.

My::prefs()

public static function prefs(): ?dcWorkspace

Cette méthode renvoie l'instance de l'espace de préférences du module. Le module doit utiliser son ID comme nom d'espace de préférences pour pouvoir utiliser cette méthode.

My::l10n()

public static function l10n(string $process): void

Cette méthode charge les locales du module pour un process donné (main, public, plugin, etc...).

My::fileURL()

public static function fileURL(string $resource, bool $frontend = false): string

Cette méthode retourne l'URL d'un fichier de module. Cette méthode tient compte du contexte courant (admin, public). Pour forcer le retour de l'URL public dans le contexte admin, il suffit de mettre le paramètre $frontend à true.
A noter que pour les thèmes, cette méthode renvoie toujours l'URL publique.

My::cssLoad()

public static function cssLoad(string $resource, string $media = 'screen', ?string $version = ''): string

Cette méthode retourne le code HTML pour inclure un fichier CSS $resource du module.

Si le paramètre $resource ne commence pas par un / le fichier sera cherché dans le sous dossier css du module,
Si l'extension du fichier n'est pas incluse à $resource, elle sera ajoutée,
Le type de $media peut-être précisé, par défaut ce sera screen,
Un numéro de version peut-être ajouté à la fin de l'url de ressource (gestion de cache)

// Renvoie le code pour le fichier .../monPlugin/css/frontend.css
My::cssload('frontend');
// Renvoie le code pour le fichier .../monPlugin/style.css
My::cssLoad('/style.css');

My::jsLoad()

public static function jsLoad(string $resource, ?string $version = '', bool $module = false): string

Tout comme My::cssLoad() cette méthode renvoie le code HTML pour ajouter un fichier JS du module. Le paramètre $module si il est à true permet de charger $resource comme un module JS.

My::addBackendMenuItem() (plugins uniquement)

public static function addBackendMenuItem(string $menu = Menus::MENU_PLUGINS, array $params = [], string $scheme = '(&.*)?$', ?string $id = null): void

Cette méthode permet d'ajouter rapidement le module aux menus de l'administration.
Le menu est à choisir parmi ceux définis dans les constantes de Dotclear\Core\Backend\Menus et par défaut celui des plugins :

Menus::MENU_BLOG => 'Blog',
Menus::MENU_SYSTEM => 'System',
Menus::MENU_PLUGINS => 'Plugins',

Les paramètres :

$params sert à ajouter des paramètres à l'URL du menu,
$scheme permet de personnaliser la surbrillance du menu,
$id permet de spécifier un id pour l’icône de tableau de bord (Utile aux behaviors).

My::icons() (plugins uniquement)

public static function icons(string $suffix = ''): array

Cette méthode renvoie un tableau des chemins complets vers les icônes du modules.

My::manageURL() (plugins uniquement)

public static function manageUrl(array $params = [], string $separator = '&'): string

Cette méthode renvoie l'URL de la page principale de gestion du module. Des paramètres spéciaux peuvent être ajoutés avec $params, et le séparateur des paramètres peut être modifié avec le paramètre $separator.

My::redirect() (plugins uniquement)

public static function redirect(array $params = [], string $suffix = ''): void

Cette méthode effectue une redirection en prenant l'URL de base du module, à laquelle il est possible d'ajouter des paramètres $params. Le paramètre $suffix permet d'ajouter par exemple le renvoi vers un onglet spécifique.

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

La classe d'erreur

Jean-Christian Denis — Fri, 14 Jul 2023 09:11:00 +0100

Dotclear version 2.27 introduit une classe d'erreur nommée Fault en remplacement de la fonction __error() et du fichier error.php.

La classe Dotclear\Fault n'est pas à proprement parler un gestionnaire d'erreur, elle ne se substitue pas aux Exception et Error. Elle va simplement permettre à l'application d'uniformiser son comportement sur certains défauts (erreurs) connus. Normalement seules la classe Dotclear\App et les classes Dotclear\Core\Xxx\Utility l'utilisent. Elle est utilisée lors de défauts ne permettant pas de continuer la bonne exécution du script.

Constantes

La classe définit des constantes de niveau d'erreur, ces niveaux seront reportés en code de réponse HTTP le cas échéant, et sont toutes de niveau supérieur à 500 (Internal server error).

550 : UNDEFINED_ISSUE : Uncoded or undefined error (before as 0)
555 : SETUP_ISSUE : Server configuration issue (before as 0)
560 : CONFIG_ISSUE : Dotclear configuration file issue (before as 10)
565 : DATABASE_ISSUE :Database connexion issue (before as 20)
570 : BLOG_ISSUE : Blog definition issue (before as 30)
575 : TEMPLATE_CREATION_ISSUE : Template file creation issue (before as 40)
580 : THEME_ISSUE : Theme issue (before as 50)
585 : TEMPLATE_PROCESSING_ISSUE : Template processing issue (before as 60)
590 : BLOG_OFFLINE : Blog is offline (before as 70)

Lancement

Il y a deux façons lancer un défaut, par la création d'une instance en passant en arguments le titre, le message et le niveau, ou de manière statique en passant en arguments le titre et l'exception.

<?php
use Dotclear\Fault;

// Dynamique
if (!defined('DC_CONTEXT_ADMIN')) {
    new Fault('Server error', 'Site temporarily unavailable', Fault::SETUP_ISSUE);
}
// Statique
try {
    if ($a < 1) {
        throw new Exception('a est inferieur à 1', Fault::CONFIG_ISSUE);
    }
    if ($a > 10) {
        throw new Exception('a est supérieur à 10', Fault::CONFIG_ISSUE);
    }
 } catch (Exception $e) {
    Fault::throw('Mauvaise valeur de a', $e);
 }

Retour

La classe permet plusieurs façons de reporter le défaut.

Si le script est exécuté en mode CLI (ligne de commande) comme pour une mise à jour depuis une console, la classe répondra par un simple message dans la console.
Si le script est exécuté normalement, une page web indiquant le niveau d'erreur, son titre et un message explicatif sera retourné avec en code de réponse HTTP le niveau d'erreur.
Si au moment du lancement de la classe la constante DC_DEBUG est déjà définie et est à true, l'erreur php sera retournée, comme si la classe n'existait pas.

Personnalisation

Il est possible de personnaliser la page web de défaut. Pour cela il faut renseigner la constante DC_ERRORFILE en la définissant avec le chemin complet vers un fichier qui sera inclu dans la méthode retournant le défaut. Ce fichier devra rendre à la sortie standard de PHP (echo) du code HTML complet et valide. Les variables $summary, $message et $code lui sont accessibles.

Reponse HTML de la classe Fault

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

Fichier de désactivation d'un module

Jean-Christian Denis — Fri, 14 Jul 2023 00:39:00 +0100

Le fichier de désactivation en dur d'un module se nomme _disabled, c'est un fichier vide qui est placé à la racine du module.

Normalement ce fichier n'est pas à manipuler, le gestionnaire de modules se charge de l'ajouter suivant des prérequis ou des actions définies.
Le gestionnaire de module va lire le fichier de définition du module et si les prérequis du module ne sont pas remplis, il désactivera le module en ajoutant le fichier _disabled à sa racine.
Depuis l'interface d'administration du blog, dans la liste des plugins ou des thèmes installés, il est possible de désactiver ou de réactiver des modules.
Une fois ce fichier présent, seul le fichier de définition du module est lu.

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

Gestion d'URL d'administration

Jean-Christian Denis — Thu, 13 Jul 2023 23:08:00 +0100

La version 2.27 de Dotclear embarque des changements côté URL, dont certains non rétro compatibles.

Déprécié

Avec le passage aux espaces de noms PHP, la classe dcAdminURL devient Dotclear\Core\Backend\Url.
Et son instance se déplace également de dcCore::app()->adminurl vers dcCore::app()->admin->url.
A noter que grâce au plugins dcProxyV1, les anciens noms restent accessibles.

Obsolète

Dûe à la mise en place de la nouvelle structure de l'application, l'utilisation des URLs écrites directement est proscrite. C'est à dire que partout où un plugin écrivait 'plugin.php?p=monPlugin' le code ne fonctionnera plus. Il faut impérativement utiliser le gestionnaire d'URL dcCore::app()->admin->url et ses méthodes.

<?php
// dcCore::app()->adminurl->get('admin.plugin.monPlugin', ['var' => 1]);
dcCore::app()->admin->url->get('admin.plugin.monPlugin', ['var' => 1]);
// ou encore mieux
My::manageURL(['var' => 1]);

// Http::redirect('plugin.php?p=monPlugin&var=1);
dcCore::app()->admin->url->redirect('admin.plugin.monPlugin', ['var' => 1]);
// ou encore mieux
My::redirect(['var' => 1]);

Pourquoi ? Parce que l'ajout du Process en cours est fait automatiquement par ce biais. Le code ci-dessus renverra l'URL /index.php?process=Plugin&p=monPlugin&var=1.

Nouveauté

Une nouvelle URL débarque dans le gestionnaire, celle de déconnexion, elle permet de se déconnecter de l'interface d'administration même en cas de plantage d'un plugin ou d'un thème. Son identifiant est 'admin.logout'. Si vous souhaitez par exemple déconnecter l'utilisateur depuis votre script il suffit de faire dcCore::app()->redirect('admin.logout');.

Pour des raisons d'uniformisation, l'identifiant d'URL 'admin.popup_posts' sera a terme remplacé par 'admin.popup.posts' et un autre nouvel identifiant 'admin.help.charte' peu utilisé est ajouté.

Attention

Ce n'est pas tout, en rapport au gestionnaire d'URL et à la nouvelle structure de l'application, certains formulaires ne fonctionneront pas comme il faut. En effet les formulaires utilisant la method GET ne peuvent embarquer dans l'URL le process, du moins il le perd en chemin ! (Merci monsieur HTML) Il faut donc impérativement ajouter un champ caché contenant process=xxx ou xxx est l'identifiant de la page qu'il souhaite atteindre enregistré dans le gestionnaire d'URL. Exemple pour la page principale d'un plugin il faudra ajouter dans le formulaire new Form\Hidden('process', 'Plugin'); ou form::hidden('process', 'Plugin'); ou '<input type="hidden" name="process" value="Plugin" />'. Dans la majorité des cas, les formulaires utilisant la méthode POST, ainsi que les filtres de listes tiennent compte du process.

A noter que la classe My d'aide des modules propose des méthodes simplifiant l'accès aux URLs du module.

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

Déplacement de classes

Jean-Christian Denis — Wed, 12 Jul 2023 20:10:00 +0100

Pour cette version 2.27, continuant la transition vers les espaces de noms PHP, de nombreuses classes dont principalement celles d'administration se sont vues déplacer dans le dossier src.

Voici la liste des classes changeant de nom dans cette version.

Pour la partie administration :

    'adminBlogFilter'      => 'Dotclear\Core\Backend\Filter\FilterBlogs',
    'adminBlogList'        => 'Dotclear\Core\Backend\Listing\ListingBlogs',
    'adminCommentFilter'   => 'Dotclear\Core\Backend\Filter\FilterComments',
    'adminCommentList'     => 'Dotclear\Core\Backend\Listing\ListingComments',
    'adminGenericFilterV2' => 'Dotclear\Core\Backend\Filter\Filters',
    'adminGenericListV2'   => 'Dotclear\Core\Backend\Listing\Listing',
    'adminMediaFilter'     => 'Dotclear\Core\Backend\Filter\FilterMedia',
    'adminMediaList'       => 'Dotclear\Core\Backend\Listing\ListingMedia',
    'adminMediaPage'       => 'Dotclear\Core\Backend\MediaPage',
    'adminModulesList'     => 'Dotclear\Core\Backend\ModulesList',
    'adminPostFilter'      => 'Dotclear\Core\Backend\Filter\FilterPosts',
    'adminPostList'        => 'Dotclear\Core\Backend\Listing\ListingPosts',
    'adminPostMiniList'    => 'Dotclear\Core\Backend\Listing\ListingPostsMini',
    'adminUserFilter'      => 'Dotclear\Core\Backend\Filter\FilterUsers',
    'adminUserList'        => 'Dotclear\Core\Backend\Listing\ListingUsers',
    'adminThemesList'      => 'Dotclear\Core\Backend\ThemesList',
    'adminUserPref'        => 'Dotclear\Core\Backend\UserPref',
    'dcActions'            => 'Dotclear\Core\Backend\Action\Actions',
    'dcAdmin'              => 'Dotclear\Core\Backend\Utility',
    'dcAdminBlogPref'      => 'Dotclear\Core\Backend\BlogPref',
    'dcAdminCombos'        => 'Dotclear\Core\Backend\Combos',
    'dcAdminFilter'        => 'Dotclear\Core\Backend\Filter\Filter',
    'dcAdminFilters'       => 'Dotclear\Core\Backend\Filter\FiltersLibrary',
    'dcAdminHelper'        => 'Dotclear\Core\Backend\Helper',
    'dcAdminNotices'       => 'Dotclear\Core\Backend\Notices',
    'dcAdminURL'           => 'Dotclear\Core\Backend\Url',
    'dcBlogsActions'       => 'Dotclear\Core\Backend\Action\ActionsBlogs',
    'dcCommentsActions'    => 'Dotclear\Core\Backend\Action\ActionsComments',
    'dcPostsActions'       => 'Dotclear\Core\Backend\Action\ActionsPosts',
    'dcFavorites'          => 'Dotclear\Core\Backend\Favorites',
    'dcMenu'               => 'Dotclear\Core\Backend\Menu',
    'dcPage'               => 'Dotclear\Core\Backend\Page',
    'dcPager'              => 'Dotclear\Core\Backend\Listing\Pager',
    'dcThemeConfig'        => 'Dotclear\Core\Backend\ThemeConfig',

Pour la partie publique :

    'dcPublic' => 'Dotclear\Core\Frontend\Utility',

Pour la partie Core :

    'dcNsProcess' => 'Dotclear\Core\Process',
    'dcUpgrade' => 'Dotclear\Core\Upgrade\Upgrade',

Pour utiliser ces classes il faut ajouter en début de fichier la déclaration use suivi du nom complet de la classe.
Par exemple :

<?php
use Dotclear\Core\Backend\Notices;

// dcAdminNotices::addSuccessNotice(__('Youhou'));
Notices::addSuccessNotice(__('Youhou'));

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

Les dépréciés

Jean-Christian Denis — Wed, 12 Jul 2023 19:54:00 +0100

La version 2.27 de Dotclear apporte son lot de dépréciés. Et leur nombre augmente par rapport aux dernières versions.

Autoloader

dcCore::autoload() => Autoloader::me()
Il faut désormais appeler directement Autoloader::me()

Erreur

_ _error() => new Dotclear\Fault()
Il faut utiliser la classe dédiée Fault avec soit le constructeur new Dotclear\Fault() ou bien la forme statique Dotclear\Fault::throw()

Déconnection

logout=1 => process=Logout
La déconnection a maintenant une URL dédiée. Pour l'appeler, il faut utiliser le gestionnaire d'URL dcCore::app()->admin->url->redirect('admin.logout') qui donnera dans l'URL &process=Logout
Astuces : Si un plugin ou un thème bloque l'accès à l'admin, il est possible de simplement ajouter à la fin de l'URL de votre navigateur ?process=Logout et vous pourrez vous reconnecter en mode sans échec.

Variable $init de process

dcNsProcess::$init => Process::status()
Introduite en 2.26 cette variable posait des problèmes, elle a été remplacé par la méthode Dotclear\Core\Process::status() qui sert à la fois en lecture et en écriture.

Ajout de menu

dcAdminHelper::addMenuItem() => dcCore::app()->admin->menus->addItem()
Avec l'arrivée des espaces de noms PHP dans la partie administration, les menus font partie d'un objet nommé Menus et donc il faut passer par lui pour ajouter des menus avec dcCore::app()->admin->menus->addItem().
Pour les plugins il est recommandé d'utiliser la classe My et la méthode My::addBackendMenuItem()..

Constantes de menu

dcAdmin::MENU_FAVORITES => Menus::MENU_FAVORITES,
dcAdmin::MENU_BLOG => Menus::MENU_BLOG,
dcAdmin::MENU_SYSTEM => Menus::MENU_SYSTEM,
dcAdmin::MENU_PLUGINS => Menus::MENU_PLUGINS,

Ici encore suite à l'arrivée du nouvel objet Menus, les constantes associées sont déplacées dedans. Le nom complet de la classe est Dotclear\Core\Backend\Menus. Il est possible de les appeler depuis l'instance dcCore::app()->admin->menus::MENU_XXX

Les notices

dcPage::notices() => Notices::getNotices(),
dcPage::addMessageNotice() => Notices::addMessageNotice(),
dcPage::addSuccessNotice() => Notices::addSuccessNotice(),
dcPage::addWarningNotice() => Notices::addWarningNotice(),
dcPage::addErrorNotice() => Notices::addErrorNotice(),
dcPage::message() => Notices::message(),
dcPage::success() => Notices::success(),
dcPage::warning() => Notices::warning(),
dcPage::error() => Notices::error(),

Toutes les méthodes de dcPage (nouvellement Page) en rapport aux notices sont dépréciées, il faut désormais utiliser les méthodes de la classe d'origine Dotclear\Core\Backend\Notices dont les signatures restent les mêmes.

Fichiers de modules

dcPage::cssModuleLoad() => My::cssLoad(),
dcPage::jsModuleLoad() => My::jsLoad(),
dcUtils::cssModuleLoad() => My::cssLoad(),
dcUtils::jsModuleLoad() => My::jsLoad(),

Encore une fois la classe My dédiée aux modules vient prendre le relai de ces deux méthodes. La différence est que, la structure des modules devenant plus stricte, ces deux nouvelles méthodes ont uniquement besoin du nom du fichier à charger. Il n'est plus nécessaire de fournir le nom du module ni celui du sous répertoire. Pour les css les fichiers sont rangés dans le dossier css, pour les js, les fichiers sont rangés dan le dossier js. Propre.
Exemple avec un partie de la méthode process de la classe Manage d'un module :

<?php
//...
Page::openModule(
    My::name,
    // charge le fichier MonPlugin/js/backend.js
    My::jsLoad('backend') .
    // charge le fichier MonPlugin/css/style.css
    My::cssLoad('style')
);

De core à admin

dcCore::app()->adminurl => dcCore::app()->admin->url,
dcCore::app()->favs => dcCore::app()->admin->favs,
dcCore::app()->menu => dcCore::app()->admin->menus,

Comme annoté dans le code depuis quelques versions certaines instances se trouvant historiquement dans dcCore auraient dû aller dans dcCore::app()->admin, c'est chose faite en 2.27.

Points d'entrées

dotclear/inc/public/_prepend.php
dotclear/inc/admin/_prepend.php
tous les fichiers dotclear/admin/xxx.php

Tous les points d'entrée qui étaient représentés par des fichiers sont dépréciés, ils sont remplacés par un seul fichier index.php qui lance l'application Dotclear.

Coté public, ce sera l'index.php de définition du blog qui lancera l'application.
Coté admin, ce sera l'index.php de l'URL d'administration qui s'en chargera.

Cas particulier, la mise à jour en ligne de commande se déplace de dotclear/inc/dbschema/upgrade-cli.php vers dotclear/admin/upgrade/upgrade-cli.php :

user@server: /var/www/dotclear$ php admin/upgrade/upgrade-cli.php inc/config.php

Propriétés du core

Nombre de propriétés de dcCore utilisent en 2.27 l'état 'uninitialized' c'est à dire qu'il ne faut plus tester leur nullité mais leur présence, cela se traduit par exemple par :

is_null(dcCore::app()->auth) ou dcCore::app()->auth === null => isset(dcCore::app()->auth)

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

Fichier de définition d'un blog

Jean-Christian Denis — Tue, 11 Jul 2023 23:45:00 +0100

Avec la version 2.27 de Dotclear le fichier index.php de définition d'un blog évolue.

Là ou le fichier ressemblait à cela :

<?php
define('DC_BLOG_ID','blog'); # identifiant unique du blog
require dirname(__FILE__).'/../dotclear/inc/public/prepend.php'; # chemin vers prepend.php
?>

Il ressemblera à ceci :

<?php
define('DC_BLOG_ID','blog'); // identifiant unique du blog
require_once implode(DIRECTORY_SEPARATOR, [__DIR__, '..', 'dotclear', 'src', 'App.php']); // chemin vers l'application dotclear
Dotclear\App::bootstrap('Frontend'); // lancement de l'application côté public (Frontend)

Bien entendu les deux écritures de ce fichier sont valables pour quelques versions encore.
Les changements ci-dessus sont dû à l'utilisation du nouveau point d'entrée unique de Dotclear.

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

Fichier de définition d'un module

Jean-Christian Denis — Tue, 11 Jul 2023 21:14:00 +0100

Le fichier de définition se situe à la racine du module, il se nomme _define.php et il va donner à Dotclear toutes les informations indispensables à sa compréhension. Il est en très grande partie commun aux thèmes et aux plugins.

Son contenu peut être le suivant :

<?php
/**
 * Mettre ici les informations de licence
 */
$this->registerModule(
    'Le module', // Nom (requis)
    'Un module qui ne fait rien', // Description (requis)
    'Jean-Christian Denis and contributors', // Auteur (requis)
    '1.0',  // Version (requis)
    [
        'requires' => [
            ['php', '8.1'], // Version minimum de PHP (optionnel)
            ['core', '2.26'], // Version miminum de Dotclear (recommandé)
            ['UnAutreModule', '1.1'], // Dépendance à un autre module (optionnel)
        ],
        'priority' => 1000, // priorité, nombre entier positif (optionnel)
        'permissions' => dcCore::app()->auth->makePermissions([
            dcCore::app()->auth::PERMISSION_CONTENT_ADMIN,
        ]), // Permissions (recommandé)
        'type' => 'plugin', // type de module, plugin ou theme (requis)
        'settings'    => [
            'blog' => '#params.LeModule', // plugin, sa configuration est sur la page de paramètres du blog
            'self' => '', // plugin, sa page de gestion est sa page de configuration
            'pref' => '#user-options.LeModule', // plugin, sa configuration est dans les préférences utilisateur
        ],
        'parent' => 'ductile', // thème, son parent (optionnel)
        'tplset' => 'mustek', // thème, le jeu de template à utiliser (optionnel)
        'standalone_config' => true, // thème, utilisation de sa propre configuration (optionnel)
        'support' => 'https://github.com/JcDenis/LeModule', // Lien vers la page du support (recommandé)
        'details' => 'https://plugins.dotaddict.org/dc2/details/LeModule', // Lien vers la page de détails (recommandé)
        'repository' => 'https://raw.githubusercontent.com/JcDenis/LeModule/master/dcstore.xml', // Lien vers la définition du dépôt tiers (optionnel)
        'widgettitleformat'     => '', // formatage de widget (optionnel)
        'widgetsubtitleformat'  => '', // formatage de widget (optionnel)
        'widgetcontainerformat' => '', // formatage de widget (optionnel)
    ]
);

Attention : Ce fichier est appelé très tôt dans le code, à l'intérieur d'une méthode, il peut être appelé plusieurs fois et d'autres script peuvent l'appeler, à cause de tout cela seules les classes dcAuth, dcCore et celles contenues dans les fichiers _init.php des modules peuvent être utilisées dans ce fichier.

A noter : Si la page de configuration du plugin est dans un fichier src/Config.php, Dotclear l'indiquera de manière automatique, il n'est pas nécessaire de l'indiquer dans la définition des paramètres settings.

La présence du fichier define.php est obligatoire.

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

Structure d'un module

Jean-Christian Denis — Tue, 11 Jul 2023 21:09:00 +0100

Avec la version 2.27 de Dotclear la structure de plugins et thèmes devient plus rigide. Cette structure deviendra obligatoire assez rapidement.

La structure générale d'un module est quasi commune aux plugins et aux thèmes. Elle se définit comme suit.

Nom

Depuis la mise en place des espaces de nom pour les modules, le nom du répertoire racine du module sera son ID et son espace de nom PHP. De ce fait il est proscrit tous caractères autres que des chiffres et lettres et le nom doit commencer par une lettre.

Invalide : mon-plugin, 1to3plugin,
Valide : monplugin, MonPlugin2,

Fichiers à la racine du module :

_define.php : Fichier de définition
_disabled : Fichier de désactivation
_init.php : Fichier de définition d'initialisation
CHANGELOG.md : récapitulatif des modifications/versions
dcstore.xml : Fichier de définition de dépôt distant
icon.svg : Icône
icon-dark.svg : Icône sombre
LICENSE : Licence
README.md : Document d'introduction

Répertoires à la racine du module :

css : Feuilles de styles
default-templates : Templates
img : Images
js : Scripts javascript
locales : Traductions
src : Espace de nom contenant tous les fichiers .php

Fichiers du dossier src :

Backend.php : ex _admin.php Préparation de la partie admin,
Config.php : ex _config.php Configurateur,
Frontend.php : ex _public.php Préparation de la partie publique
Install.php : ex _install.php Processus d'installation
Manage.php : ex index.php Page de gestion principale
My.php : fonctions prédéfinies d'aides au code
Prepend.php : ex _prepend.php Préparation générale
Widgets.php : ex _widgets.php Gestion des widgets par le plugin widgets

Bonnes pratiques

Il est vivement recommandé (possible obligation à l'avenir) d'utiliser l'ID du module pour l'identifiant de ses paramètres dans les espaces de paramètres (blog settings) et les espaces de préférences (user pref).
Il est recommandé de séparer les behaviors trop volumineux des fichiers Backend.php / Frontend.php et de les mettre dans un fichier BackendBehaviors.php / FrontendBehaviors.php.
De manière générale le nom de fichier et donc de classe doit être en rapport avec sa fonction, par exemple une classe contenant toutes les méthodes en rapport aux templates coté public sera nommé FrontendTemplate.

Ce document est en cours d'écriture, il est incomplet.

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.

2.27

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

Sortie prévue le 13 Aout 2023, cette version est l'occasion de fêter les 20 ans de Dotclear !

Résumé

Cette version comprend un nombre très important de changements coté code, elle accélère sa transition vers les espaces de noms PHP avec toute la partie administration qui les utilise désormais. (Tout comme les plugins et les thèmes) Le moteur lui même a entamé sa transition et maintenant il n'y a plus qu'un unique point d'entrée dans le code pour tout !

Nouveautés :

Nouvelle gestion du moteur suivant le schéma App => Utility => Process,
Quasi obligation d'utilisation de la classe Process,
Nouvelle gestion des URLs d'administration,
Nouvelle gestion d'erreur du core,
Nouveau fichier de release,
Modification du fichier de définition de blog index.php,
Déplacement de nombreuses classes, principalement liées à d'administration,
Nombreuses variables, fonctions, méthodes et classes dépréciés
La structure des plugins et thèmes qui a pas mal bougé depuis quelques versions,
Nouvelle classe outils My pour les modules,
Nouvelles classes outils Form qui ajoutent de nombreuses balises HTML,
Nouvelle fonction JS pour le service Rest.
Prévisualisation de thèmes dans l'admin.

Définitions :

Le langage autour de Dotclear a également évolué en même temps que son code. De quoi parle-t-on ?
Désormais on peut parler d'App, de Process, d'Utility, de Backend, Frontend, etc. Traduction:

App : L'application dotclear dans son ensemble, c'est également le nom de la classe qui est désormais le point de départ du script PHP,
Utility : Ce sont les classes maitresses, chaque Utility gère une partie de Dotclear, admin, public, cli, install,
Process : Alors là ça va se compliquer, du coté Dotclear ce sont les sous parties d'un Utility, par exemple pour faire simple, coté admin, un Process correspondra à une page (Preferences, Blogs, Posts...). Mais un process est également ajouté à un grand nombre de classes dans le Core de Dotclear et aussi dans les thèmes, les plugins, il permet de séquencer le script. En savoir plus sur la classe Process.
Backend : La partie admin,
Frontend : La partie public.

Incompatibilités :

Les plugins et thèmes n'utilisant pas le gestionnaire d'URL dcCore::app()->admin->url (ou le déprécié dcCore::app()->adminurl) pour les redirections et formulaires, risquent de ne pas envoyer vers la page souhaitée.
Les formulaires utilisant la méthode GET doivent ajouter un champ caché contenant process=xxx où xxx est l'identifiant la page qu'il souhaite atteindre enregistré dans le gestionnaire d'URL. Exemple pour la page générale d'un plugin il faudra ajouter dans le formulaire new Form\Hidden('process', 'Plugin'); ou encore form::hidden('process', 'Plugin');.

Information importante pour les développeurs :
C'est la dernière version compatible avec PHP 7.4 ! La prochaine version majeure de Dotclear prévue pour novembre .2023 nécessitera PHP 8.1.

Les informations distillées ici sont non exhaustives et pourront être compléter à l'avenir.