Dotclear

Adapter son code pour la 2.24 n° 21

Aujourd’hui on s’écarte un peu des modifications indispensables pour évoquer l’utilisation des variables globales sur les pages de l’administration. En effet j’ai entrepris, avec la 2.24, de réduire autant que possible ces dernières en ouvrant la possibilité de stocker celles-ci comme propriétés  […]

Lire la suite

Adapter son code pour la 2.24 n° 20

Suite des nouvelles constantes qui définissent les noms des tables de la base de données : dcAuth::USER_TABLE_NAME équivalent à user dcAuth::PERMISSIONS_TABLE_NAME équivalent à permissions dcBlog::BLOG_TABLE_NAME équivalent à blog dcBlog::POST_TABLE_NAME équivalent à post dcBlog::COMMENT_TABLE_NAME  […]

Lire la suite

Adapter son code pour la 2.24 n° 19

Cette fois-ci ça sera plus simple puisqu’il s’agit de la disparition1, quasi intégrale, dans la prochaine 2.24 de la gestion des services XML-RPC, utilisés pour interfacer une application tierce de publication avec Dotclear. N’est conservé que le strict minimum pour gérer les pingbacks. Par  […]

Lire la suite

Adapter son code pour la 2.24 n° 18

À l’image des signatures des fonctions de rappel des behaviors évoqués dans le billet précédent, certaines classes utilitaires ont elles aussi été modifiées pour éviter d’utiliser la variable $core ou dcCore::app() en paramètre de leur constructeur. Cela dit, pour éviter, encore une fois, de trop  […]

Lire la suite

Adapter son code pour la 2.24 n° 17

Depuis la disparition de la variable $core et son remplacement par dcCore::app() un certain nombre de fonctions de rappel des behaviors n’ont plus besoin qu’on passe cette variable en paramètre, comme c’était fréquemment le cas auparavant. Pour assurer la compatibilité, de nouveaux noms de behavior  […]

Lire la suite

Haut de page