DotclearWatch / Blog - Mot-clé - service

[2.36] Modification du service de base de données

Jean-Christian Denis — Tue, 02 Sep 2025 14:17:00 +0200

Dans Dotclear 2.36 le Container principal est encore plus soyeux avec uniquement de vraies classes comme services, cela entraîne certaines modifications.

Avant la version 2.36 de Dotclear, l'accès à la base de données se faisait par l'appel App::con(); mais d'un point de vu technique cet appel passait par une fonction intermediaire directement dans la pile de services du Container principal, fonctionnel mais pas vraiment joli et surtout trop strict et rigide. C'est pourquoi la version 2.36 de Dotclear introduit un nouveau service du core nommé db() qui fait le lien entre Dotclear et les drivers de base de données. De ce fait, l'appel qui se faisait par App::con() devient App::db()->con(), plus long et donc moins sexy, mais cela va permettre de travailler et d'améliorer les drivers de base de données beaucoup plus facilement.

//App::con()->openCursor('xyz');
App::db()->con()->openCursor('xyz);

Bien entendu l'écriture App::con() est dépréciée mais reste fonctionnelle encore pour quelques siècles.

Ce changement a permis dès la version 2.36 de proposer d'autres drivers de base de données et d'améliorer le processus d'installation.

Le nouveau service App::db()

Le coeur de l'application Dotclear embarque donc un nouveau service qui va permettre de faire le lien entre les drivers de base de données et le reste de Dotclear.

Il est identifié comme suit dans le container :

Identifiant du service : Dotclear\Core\DatabaseInterface
Classe par défaut : Dotclear\Core\Database
Methode du service : App::db()

Son interface montre ses méthodes :

App::db()->con() : l'accès à la base de données
App::db()->newCon() : Une instance isolé de l'accès à une base de données
App::db()->structure() : l'accès à la gestion de structure de base de données
App::db()->combo() : liste des drivers utilisables (sert dans le process d'installation Dotclear)

interface DatabaseInterface
{
    /**
     * Get dabatase connection handler instance.
     *
     * This connection instance uses parameters from config service.
     */
    public function con(): ConnectionInterface;

    /**
     * Get new dabatase connection handler instance.
     *
     * @param   string  $driver         Driver name
     * @param   string  $host           Database hostname
     * @param   string  $database       Database name
     * @param   string  $user           User ID
     * @param   string  $password       Password
     * @param   bool    $persistent     Persistent connection
     * @param   string  $prefix         Database tables prefix
     */
    public function newCon(
        string $driver, 
        string $host, 
        string $database, 
        string $user = '', 
        string $password = '', 
        bool $persistent = false, 
        string $prefix = ''
    ): ConnectionInterface;

    /**
     * Get database structure handler.
     *
     * The handler uses current connexion.
     * Each call to this method MUST return a new instance.
     *
     * @return  Structure   The database structure handler
     */
    public function structure(): Structure;

    /**
     * Get combo of available database drivers.
     *
     * @return  array<string, string>   The drivers name/driver pairs
     */
    public function combo(): array;
}

Cette classe est récente et va surement évoluer dans les versions à venir.

Le gestionnaire de connexion App::db()->con()

Une fois le driver choisi et inscrit dans le fichier de configuration de Dotclear, ses méthodes sont accessibles depuis l'application dans App::db()->con().
Un driver est généralement constitué d'une classe principale qui étend une classe d'abstraction qui étend elle même une interface. Le driver fournit également une classe de gestion de Schema. Toutes ces classes sont disponibles à divers endroits de Dotclear :

Les classes d'abstraction sont dans Dotclear\Database,
Les interfaces dans Dotclear\Interface\Database
Les drivers dans Dotclear\Schema\Database
Les drivers sont ajoutés à un container dédié
Les drivers vérifient l'installation avant d'être proposés

Une nouvelle méthode fait sont appartition dans le gestionnaire de connexion (driver), afin de tester que les conditions requises à son utilisation sont présentes. Sa définition est visible dans l'interface :

/**
 * Check driver requirements.
 *
 * This method MUST throw a DatabaseException if driver can not be used.
 * This method does NOT say a SGBD is installed but only PHP supports it.
 *
 * @since   2.36
 *
 * @throws  \Dotclear\Exception\DatabaseException   if condition does not meet driver requirements
 */
public static function precondition(): void;

Les drivers PDO

PDO est une extension de PHP signifiant PHP Data Objects, c'est une interface d'abstraction de l'accès à des bases de données, en d'autre termes cela doit simplifier l'accès à differents types de base de données depuis une application comme Dotclear. Jusqu'à la version 2.36 Dotclear n'utilisait PDO que pour la connexion à des bases de donnée Sqlite, depuis la version 2.36 il est possible de se connecter à des bases Mysql et PostgreSql à travers les drivers PDO. Les drivers de Dotclear utilisant PDO ne sont pour l'instant que des passerelles de connexion, toutes les fonctionnalités de PDO ne sont pas exploitées, Dotclear ayant déjà son propre système de préparation de requêtes.

Par défaut sur les sytèmes Linux, PHP embarque l'extension PDO avec le pilote pour Sqlite, si ce n'est pas le cas, le site de PHP fournira un peu d'aide à l'installation plus complète de PDO.

Le cas Sqlite

Le driver Sqlite de Dotclear était déjà basé sur PDO, il a simplement été renommé pour correspondre aux autres drivers. Il n'y a rien besoin de modifier, Dotclear se charge de comprendre que si vous avez définie le driver à "sqlite" cela veut dire qu'il faut utiliser "pdosqlite".

Les drivers livrés avec Dotclear

mysqli : Mysql avec les fonctions mysqli_* de PHP
mysqlimb4 : Idem avec le support utf8-mb4
pgsql : PostgreSql avec les classes PgSql de PHP
pdosqlite : Sqlite sous PDO
pdomysql : Mysql sous PDO
pdomysqlmb4 : Mysql sous PDO avec support utf8-mb4
pdopgsql : PostgreSql sous PDO

Lors de l'installation de Dotclear tous les drivers ayant un support dans la version installée de PHP seront proposés pour définir la connexion à la base de données.

Utiliser un driver PDO sur une installation existante

Si votre système embarque les composants PDO pour votre base de données, il est possible de passer sur les drivers PDO simplement en mettant à jour le fichier config.php, il faut remplacer la définiton de DC_DBDRIVER par le nouveau driver. Et l'inverse est également vrai. Voici les equivalents :

mysqli <=> pdomysql
mysqlimb4 <=> pdomysqlmb4
sqlite <=> pdosqlite
pgsql <=> pdopgsql

// define('DC_DBDRIVER', 'mysqli');
define('DC_DBDRIVER', 'pdomysql');

Auncune recommandation ici, rien ne vous oblige aujourd'hui à changer, ce ne sont que des drivers qui permettent le lien entre Dotclear et votre base de données et ils sont tous maintenus pour le moment.

Créer un driver

Pour l'exemple on va prendre un driver utilisant PDO. L'extension PDO de PHP n'est pas magique, chaque type de base de données à ses propres lois et chaque type est diffèrent. Néanmoins Dotclear propose un classe d'abstraction pour simplifier la création d'un driver de base de données utilisant PDO. Par exemple, si vous souhaiter commencer un driver pour MsSql voici ce à quoi ça pourrait ressembler.

On ajoute notre service au container des drivers de base de données et on crée notre classe de service :

<php

namespace /MySpace/PdoMsSql;

use Dotclear\Database\AbstractPdoHandler;
use Dotclear\Helper\Container\Container;
use Dotclear\Helper\Conttainer\Factories;

Factories::addService('database', 'pdomssql', PdoMsSql::class);

class PdoMsSql extends AbstractPdoHandler
{
    public const HANDLER_NAME   = 'MsSql (PDO)';
    public const HANDLER_DRIVER = 'pdomssql';
    public const HANDLER_SYNTAX = 'mssql';
    public const HANDLER_PDO    = 'sqlsrv';

    // ...
}

Il faut ensuite modifier toutes les methodes qui demandent un ajustement par rapport au language MsSql et lui adjoindre un classe de Schema. Bon courage.

Il y aurait beaucoup à dire sur cette partie mais ce serait bien trop long. Les très rares personnes qui souhaiteraient créer leur propre driver de base de données sont sans aucun doute assez callées pour comprendre le code de Dotclear.

[2.36] Modification du service de configuration

Jean-Christian Denis — Tue, 02 Sep 2025 09:26:00 +0200

Avec l'arrivé des authentifications exotiques, de nouvelles directives sont disponibles dans la configuration de Dotclear 2.36

Dotclear 2.36 propose une librairie oAuth2 client qui permet l'authentification depuis des applications tierces, cette librairie a besoin d'un fichier de configuration commun à toute la plateforme multiblogs. Ce fichier suit des régles strictes, il doit se nommer oauth2.php et être présent dans le même répertoire que le config.php.

Dans diffèrentes parties de Dotclear ou même de plugins, il y aura besoin de connaitre le chemin de ce fichier, on peut alors simplement récupérer son chemin complet comme suit :

$path = App::config()->oauth2Path();

Dans diffèrentes parties de Dotclear ou même de plugins, il y aura besoin de savoir si ce fichier existe, on peut alors tester simplement comme suit :

$exists = App::config()->hasOauth2();

oAuth2 n'est pas la seule nouvelle librairie d'authentification tiers, il y a également Webauthn (clé de sécurité) et OTP (Mot de passe à usage unique). Il est possible de désactiver toutes ces authentifiactions exotiques depuis le fichier de configuration de Dotclear, il suffit d'ajouter la définition suivante :

define('DC_AUTH_PASSWORD_ONLY', true);

Pour les plugins, li est possible de connaitre l'état de cette directive afin de désactiver certaines de leurs fonctions avec :

$limited = App:config()->authPasswordOnly();

Le conteneur principal

Jean-Christian Denis — Fri, 13 Oct 2023 08:00:00 +0200

La version 2.28 de Dotclear intégre un nouveau système de conteneur pour l'application qui remplace dcCore.

Grâce aux avancées de Dotclear 2.27, cette nouvelle version 2.28 peut désormais proposer l'accès à la quasi totalité de l'application à partir d'un seul point App::. Le core, aka dcCore, passe en déprécié et ses méthodes et propriétés sont regroupées dans des classes dédiées à un ensemble de tâches de même style. Une nouvelle gestion par conteneur et services accompagnée d'un nouvelle gestion d'exception permet de proposer ces classes à tout moment sans avoir besoin de les instancier. Autre nouveauté de taille qui pourra être exploitée par la suite, ces classes deviennent remplaçables ! Ce qui devra être utilisé pour des classes d'authentification ou de connexion tiers par exemple.

Pour résumer, voici deux exemples simples de la nouvelle façon d'appeler les classes de l'ancien dcCore :

// Avant 2.28 :
dcCore::app()->auth->use_prefs;
// A partir 2.28, dcAuth fait partie du conteneur et ses propriétés deviennent des méthodes :
App::auth()->prefs();

// Avant 2.28 :
dcCore::app()->getAllBlogStatus();
// A partir de 2.28 les méthodes de l'ancien dcCore sont regroupées dans des classes à thème :
App::blogs()->getAllBlogStatus();

Voici la liste complète des classes composants ce nouveau Core de Dotclear :

Configuration

App::config(): ConfigInterface
Cette classe est une nouveauté de dotclear 2.28, elle regroupe toutes les informations de configuration de l'application.

Authentification

App::auth(): AuthInterface
~~dcCore::app()->auth~~
Anciennement dcAuth, c'est la classe de gestion de l'utilisateur.
Deux nouvelles méthodes sont disponibles :

openUserCursor(): Cursor : renvoie un Cursor sur la table des utilisateurs
openPermCursor(): Cursor : renvoie un Cursor sur la table des permissions

L'utilisation d'une classe tiers d'authentification est encore permise en 2.28, mais il faudra utiliser le nouveau système de remplacement de classe par la suite.

Comportement

App::behavior(): BehaviorInterface
~~dcCore::app()->xxxBehaviorxxx(xxx)~~
Nouvelle classe de la version 2.28, elle regroupe toutes les méthodes dépréciées de dcCore en rapport aux behaviors.
L'ancienne méthode getBehaviors() est dédoublée :

getBehavior(string $behavior): array : renvoie un groupe de behaviors,
getBehaviors(): array : renvoie tous les behaviors

Blog

App::blog(): BlogInterface
~~dcCore::app()->blog, new dcBLog()~~
Anciennement dcBlog, c'est la classe de gestion du blog courant. Cette classe subit des changements majeures dans son utilisation.
Désormais cette classe existe toujours dans l'application. Il ne faut plus tester le chargement du blog avec !is_null(dcCore::app()->blog) mais App::blog()->isDefined().
Il ne faut plus créer une nouvelle instance de dcBlog lorsqu'on veut naviguer entre deux blogs en cours de script, Il faut partir de l'instance existante et charger un autre blog dedans, puis recharger le premier si besoin. On peut mettre en id vide pour décharger un blog.
Une nouvelle méthode est donc disponible :

App::blog()->loadFromBlog(string $blog_id): BlogInterface : renvoie l'instance de Blog chargé d'un autre blog

Exemple de chargement :

// On récupère l'ID de blog courant
$old_id = App::blog()->id();
// On charge le blog qu'on souhaite modifier
App::blog()->loadFromBlog('SecondBlog');
// On le modifie
App::blog()->triggerBlog();
// On recharge le blog courant
App::blog()->loadFromBlog($old_id);

De nouvelles méthodes sont disponibles :

openBlogCursor(): Cursor : Ouvre un Cursor sur la table blog
openPostCursor(): Cursor : Ouvre un Cursor sur la table post
openCommentCursor(): Cursor : Ouvre un Cursor sur la table comment
isDefined(): bool : Vérifie si un blog est chargé dans la classe ou non

Les propriétés publiques de la classe passent en déprécié, il faut désormais utiliser les méthodes idoines :

dcCore::app()->blog->id : App::blog()->id(): string
dcCore::app()->blog->uid : App::blog()->uid(): string
dcCore::app()->blog->name : App::blog()->name(): string
dcCore::app()->blog->desc : App::blog()->desc(): string
dcCore::app()->blog->url : App::blog()->url(): string
dcCore::app()->blog->host : App::blog()->host(): string
dcCore::app()->blog->creadt : App::blog()->creadt(): int
dcCore::app()->blog->upddt : App::blog()->upddt(): int
dcCore::app()->blog->status : App::blog()->status(): int
dcCore::app()->blog->settings : App::blog()->settings(): BlogSettingsInterface
dcCore::app()->blog->themes_path : App::blog()->themesPath(): string
dcCore::app()->blog->pblic_path : App::blog()->publicPath(): string

Paramètres de blog

App::blogSettings(): BlogSettingsInterface
~~dcCore::app()->blog->settings, new dcSettings();~~
Anciennement dcSettings, c'est la classe de gestion des paramètres de blog. Cette classe subit également un changement majeur dans son utilisation. Pour créer une nouvelle instance de BlogSettings, il faut utiliser une nouvelle méthode de la classe qui renverra une instance prête à l'emploie :

App::blogSettings()->createFromBlog(?string $blog_id): BlogSettingsInterface : renvoie une nouvelle instance de BlogSettings.

On peut également utiliser App::blog()->settings()->createFromBlog(?string $blog_id).
Ses méthodes en xxxNamespace() passent en déprécié, il faut utiliser leurs méthodes associées xxxWorkspace().

Espace de paramètres de blog

App::blogWorspace(), App::blog()->settings()->get(xxx), App::blog()->settings()->addWorspace(xxx)
Comme la classe précédente une nouvelle méthode fait son apparition pour créer une nouvelle instance de BlogWorkspace :

App::blogWorkspace()->createFromBlog(?string $blog_id, string $workspace, ?MetaRecord $rs = null): BlogWorkspaceInterface : renvoie une nouvelle instance de BlogWorkspace.

Une nouvelle méthode est disponible :

openBlogWorkspaceCursor(): Cursor : renvoie un Cursor sur la table des espaces de paramètres de blog

La méthode dumpNamespace() passe en déprécié, il faut utiliser dumpWorkspace().

Blogs

App:blogs()
~~dcCore::app()->xxxBlogsxxx()~~
Nouvelle classe de la version 2.28, elle regroupe toutes les tâches en rapport à la gestion des blogs.
Changement par rapport à la version 2.27, la méthode getBlog() renverra toujours une instance de Blog. Ceci est dû au changement de comportement de la classe Blog.

Cache

App:cache()
~~dcCore::app()->emptyTemplatesCache(), dcCore::app()->cache~~
Nouvelle classe de la version 2.28, Elle inclue une méthode de l'ancien core :

emptyTemplatesCache(): void : vide le cache des templates

Et une nouvelle méthode pour le cache des dépôts de modules :

emptyModulesStoreCache(): void : vide le cache des dépôts tiers

Elle remplace également la gestion des fichiers et timestamps utilisés pour le cache coté public et qui était dans un simple tableau dcCore::app()->cache :

resetFiles(): void : Raz de la litses des fichiers
addFile(string $file): void : Ajoute un fichier
addFiles(array $files): void : Ajoute plusieurs fichiers
getFiles(): array : Renvoie la liste des fichiers
function resetTimes(): void : Raz des timestamps
addTime(int $time): void : Ajoute un timestamp
addTimes(array $times): void : Ajoute plusieurs timestamps
getTimes(): array : Renvoie la listes des timestamps

Catégories

App::categories(), App::blog()->categories()
~~dcCore::app()->blog->categories, new dcCategories()~~
Anciennement dcCategories, c'est la classe de gestion des catégories d'un blog. Elle inclut désormais la classe NestedTree.
Comme vu sur de précédentes classes une nouvelle méthode fait son apparition pour créer une nouvelle instance de Categories :

App::blog()->categories()->createFromBlog(string $blog_id): CategoriesInterface : renvoie une nouvelle instance de Categories.

Une nouvelle méthode est disponible :

openCategoryCursor(): Cursor : renvoie un Cursor sur la table des catégories

Toutes les propriétés de la classe passent en protected.

Connexion

App::con()
~~dcCore::app()->con~~
Nouvelle classe de la version 2.28, elle permet le lien entre l'ancien chargement de gestionnaire de base de donnée et le nouveau système de chargement des classes du Core. L'utilisation d'une classe tiers de connexion est encore permise en 2.28, mais il faudra utiliser le nouveau système remplacement de classe par la suite.
Elle inclut désormais le préfixe des tables disponibles en faisant App::con()->prefix().

Déprécié

App:deprecated()
Cette classe est disponible dans le Core ou en version statique. Elle permet de loguer en mode DEV d'éventuelles méthodes dépréciées.

Erreur

App::error()
~~dcCore::app()->error~~
C'est la classe de gestion d'erreur non bloquante du Core.
Sa méthode toHTML() passe en dépréciée, il faut utiliser votre propre parser à la place.

Filtre

App::filter()
~~dcCore::app()->wiki, dcCore::app()->xxxWikiXxx(), dcCore::app()->HTMLfilter()~~
Nouvelle classe de la version 2.28, elle regroupe toutes les méthodes et propriétés dédiées à la syntaxe wiki et HTML de texte.

Formateur

App:formater()
~~dcCore::app()->xxxFormaterXxx()~~-
Nouvelle classe de la version 2.28 elle regroupe toutes les méthodes de gestion des formateurs de texte.

Langue

App::lang()
~~dcCore::app()->lang~~
Nouvelle classe de la version 2.28, elle s'occupe de la langue courante.
Deux méthodes sont disponibles :

getLang(): string : renvoie le code de la langue courante
setLang(string $lang): void : enregistre le code de la langue courante.

Lexique

App::lexical()
~~dcUtils::xxxlexicalxxx()~~
Nouvelle classe de la version 2.28, elle regroupe toutes les méthodes en rapport au champs lexical d'une langue.

Log

App::log()
~~dcCore::app()->log~~
Anciennement dcLog, cette classe s'occupe de la gestion de log.
Une nouvelle méthode est disponible :

openLogCursor(): Cursor : Ouvre un Cursor sur la table de log

L'ancienne méthode getTable() passe en dépréciée, il faut utiliser la constante de classe disponible sur App::log()::LOG_TABLE_NAME.

Média

App::media()
~~dcCore::app()->media~~
Anciennement dcMedia, cette classe s'occupe de la gestion des média et comme vu précédemment, il ne faut plus créer une instance de dcMedia mais toujours utiliser celle du Core.
Pour définir le type de media, auparavant dans son constructeur, il faut utiliser la nouvelle méthode :

setFilterMimeType(string $type): void : définit le type de media

Ses propriétés publiques deviennent dépréciées, il faut par exemple utiliser la méthode :

getThumbnailFilePattern(string $type = ''): string : renvoie la définition d'un pattern.

D'autres nouvelles méthodes sont disponibles :

openMediaCursor(): Cursor : ouvre un Cursor sur la table des média
postMedia(): PostMediaInterface : retourne l'instance de PostMedia

Métadonnée

App::meta()
~~dcCore::app()->meta~~
Anciennement dcMeta, cette classe gère les métadonnées de dotclear.
Une nouvelle méthode est disponible :

openMetaCursor(): Cursor : ouvre un Cursor sur la table des métadonnées

Nonce

App::nonce()
Nouvelle classe de la version 2.28, elle regroupe les méthodes en rapport à la validation de formulaires.
L'ancienne méthode formNonce() est dédoublée :

getFormNonce(): string : renvoie le contenu HTML
formNonce(): Hidden : renvoie l'élément de Form de type Hidden

Notification

App::notice()
~~dcCore::app()->notices~~
Anciennement dcNotices, cette classe gère en base les notices.
Une nouvelle méthode est disponible :

openNoticeCursor(): Cursor : ouvre un Cursor sur la table des notifications

Media de billets

App:postMedia(), App::media()->postMedia()
~~dcCore::app()->postmedia~~
Anciennement dcPostMedia, cette classe gère les media de billets.
Une nouvelle méthode est disponible :

openPostMediaCursor(): Cursor : ouvre un Cursor sur la table des media de billets

Les constantes des noms des tables de media et post media sont disponibles dans cette classe :

App::postMedia()::MEDIA_TABLE_NAME
App::postMedia()::POST_MEDIA_TABLE_NAME

A noter que lorsqu'un blog est chargé dans la classe Blog via App::blog()->loadFromBlog(), il est également chargé dans l'instance de la classe PostMedia.

Type de billets

App::postTypes()
~~dcCore::app()->getPostxxxURL(), dcCore::app()->xxxPostType()~~
Nouvelle classe de la version 2.28, elle regroupe les méthodes en relation aux types de billets.
Les anciennes méthodes sont toujours utilisables mais il est recommandé d'utiliser l'autre nouvelle classe de définition d'un type de billet PostType. (cf billet sur dcCore déprécié)

Service REST

App::rest()
~~dcCore::app()->xxxRestXxx()~~
Nouvelle classe de la version 2.28, elle regroupe les méthodes relatives au service REST.

Session

App::session()
Nouvelle classe de la version 2.28, elle adapte l'ancienne classe de gestion de session à la nouvelle gestion de classe de Core.
Une nouvelle méthode est disponible pour créer simplement une nouvelle session à partir d'un nom de cookie (pratique pour les plugins et thèmes) :

App::session()->createFromCookieName(string $cookie_name): SessionInterface

Rétroliens

App::trackback()
Anciennement dcTrackback, cette classe gère les rétroliens et pingback.
Une nouvelle méthode est disponible :

openTrackbackCursor(): Cursor : ouvre un Cursor sur la table des rétroliens

Préférences utilisateur

App::userPrerefences()
Anciennement dcPrefs, cette classe gère les préférences utilisateur. Elle est disponible pour l'utilisateur en cours dans App::auth()->prefs(). Comme nombre de classes de Core, cette classe est toujours disponible et instanciée dans App::userPreferences(), pour avoir une nouvelle instance il faut donc utiliser sa méthode :

createFromUser(string $user_id, ?string $user_workspace = null): UserPreferencesInterface : Créé une nouvelle instance des préférences utilisateur

Espace de préférences utilisateur

App::userWorkspace(), App::auth()->perfs()->get(xxx), App::auth()->prefs()->addWorspace(xxx)
Comme la classe précédente une nouvelle méthode fait son apparition pour créer une nouvelle instance de UserWorkspace :

createFromUser(?string $user_id, string $workspace, ?MetaRecord $rs = null): UserWorkspaceInterface : renvoie une nouvelle instance de UserWorkspace.

Une nouvelle méthode est disponible :

openUserWorkspaceCursor(): Cursor : renvoie un Cursor sur la table des espaces de préférences utilisateur

Utilisateurs

App::users()
Nouvelle classe de la version 2.28, elle regroupe toutes les méthodes relatives aux utilisateurs.

Versions

App::version()
~~dcCore::app()->xxxVersionXxx()~~
Nouvelle classe de la version 2.28, elle gère les version de module (et core) en base.
Une nouvelle méthode est disponible :

openVersionCursor(): Cursor : ouvre un Cursor sur la table des versions

Autres

De plugs certaines classes plus spéciales sont accessibles depuis App::xxx() :

App::backend() : Gestion de l'interface d'administration
App::frontend() : Gestion de l'interface publique
App::url() : Anciennement dcUrlHandler de dcCore::app()->url
App::task() : Uniquement utilisé par les plugins et thèmes pour tester le contexte avec App::task()->checkContext(...)

En savoir plus

dcCore déprécié

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