10:49 p.m.
Message pour ceux qui connaissent un peu les entrailles de Dotclear.
Dans l'optique d'un ticket qui disait de se passer de "global" et de
mon
ticket sur les bonnes pratiques de codage pour montrer l'exemple aux
plugineurs, je parcourrais le code des plugins pour remplacer les
"global $core" par "$this->core" dans les _prepend.php quand tout
à
coup, une grande lumière blanche venue de dcModules m’apparut !
Pour quoi n'uilise-t-on pas la fonction dcModules::loadModuleFile() pour
charger le _prepend.php alors qu'on le fait pour l'_install.php ?
L'avantage est que cette fonction rend les superglobal accessible, le
travail pour les codeur s'en trouve simplifier, plus besoin de réfléchir
à quoi utiliser. J'irais même jusqu’à rajouter $__autoload dans les
superglobals et la les prepend serait d'une limpidité ! :)
La modif est simple, il suffit de remplacer la ligne 120 de
inc/class.dc.modules.php qui est :
$r = require $m['root'].'/_prepend.php';
par :
$r = $this->loadModuleFile($m['root'].'/_prepend.php');
PS: Pour rappel si on enléve le "global $core" des _prepend.php des
plugins de la distribution (on qu'on désactive ces plugins) la moitié
des plugins de DA ne fonctionnera pas car mal écrit. (Mais normal les
uns copiant sur les autres, toussa)
Z'en pensez ?
11:07 p.m.
Suis en train de fouiller dans le core et a priori ça devrait fonctionner
(pour autant que je puisse en juger), mais à condition de filer le $ns dans
l'appel :
$r = $this->loadModuleFile($m['root'].'/_prepend.php',$ns);
Le 24 septembre 2013 22:49, Denis Jean-Christian <contact(a)jcdenis.fr> a
écrit :
Message pour ceux qui connaissent un peu les entrailles de Dotclear.
Dans l'optique d'un ticket qui disait de se passer de "global" et de
mon
ticket sur les bonnes pratiques de codage pour montrer l'exemple aux
plugineurs, je parcourrais le code des plugins pour remplacer les
"global $core" par "$this->core" dans les _prepend.php quand tout
à
coup, une grande lumière blanche venue de dcModules m’apparut !
Pour quoi n'uilise-t-on pas la fonction dcModules::loadModuleFile() pour
charger le _prepend.php alors qu'on le fait pour l'_install.php ?
L'avantage est que cette fonction rend les superglobal accessible, le
travail pour les codeur s'en trouve simplifier, plus besoin de réfléchir
à quoi utiliser. J'irais même jusqu’à rajouter $__autoload dans les
superglobals et la les prepend serait d'une limpidité ! :)
La modif est simple, il suffit de remplacer la ligne 120 de
inc/class.dc.modules.php qui est :
$r = require $m['root'].'/_prepend.php';
par :
$r = $this->loadModuleFile($m['root'].'/_prepend.php');
PS: Pour rappel si on enléve le "global $core" des _prepend.php des
plugins de la distribution (on qu'on désactive ces plugins) la moitié
des plugins de DA ne fonctionnera pas car mal écrit. (Mais normal les
uns copiant sur les autres, toussa)
Z'en pensez ?
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
11:11 p.m.
Nop tu as louché sur loadNsFile() !
Le 24/09/2013 23:07, Franck Paul a écrit :
Suis en train de fouiller dans le core et a priori ça devrait
fonctionner
(pour autant que je puisse en juger), mais à condition de filer le $ns dans
l'appel :
$r = $this->loadModuleFile($m['root'].'/_prepend.php',$ns);
6:57 a.m.
Ah oui t'as raison :-)
Le 24 septembre 2013 23:11, Denis Jean-Christian <contact(a)jcdenis.fr> a
écrit :
Nop tu as louché sur loadNsFile() !
Le 24/09/2013 23:07, Franck Paul a écrit :
> Suis en train de fouiller dans le core et a priori ça devrait fonctionner
> (pour autant que je puisse en juger), mais à condition de filer le $ns
dans
> l'appel :
>
> $r = $this->loadModuleFile($m['root'].'/_prepend.php',$ns);
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
8:32 a.m.
Où je constate que *tous* mes plugins sont impactés... :-(
... Mais pas avec "global $core" dans _prepend.php, plutôt dans _public.php et
dans widgets.php et/ou widget.php... Du coup j'ignore si c'est grave ou pas. Je
sens que je vais avoir besoin d'aide et/ou d'accompagnement. Voire demander un
diagnostique "sécurité" pour mrvbNextDoor (anciennement OtherBlog) qui peut être
utilisé sous certaines conditions en dehors d'un blog Dotclear.
Le 24/09/2013 22:49, Denis Jean-Christian a écrit :
Message pour ceux qui connaissent un peu les entrailles de Dotclear.
Dans l'optique d'un ticket qui disait de se passer de "global" et de
mon
ticket sur les bonnes pratiques de codage pour montrer l'exemple aux
plugineurs, je parcourrais le code des plugins pour remplacer les
"global $core" par "$this->core" dans les _prepend.php quand tout
à
coup, une grande lumière blanche venue de dcModules m’apparut !
Pour quoi n'uilise-t-on pas la fonction dcModules::loadModuleFile() pour
charger le _prepend.php alors qu'on le fait pour l'_install.php ?
L'avantage est que cette fonction rend les superglobal accessible, le
travail pour les codeur s'en trouve simplifier, plus besoin de réfléchir
à quoi utiliser. J'irais même jusqu’à rajouter $__autoload dans les
superglobals et la les prepend serait d'une limpidité ! :)
La modif est simple, il suffit de remplacer la ligne 120 de
inc/class.dc.modules.php qui est :
$r = require $m['root'].'/_prepend.php';
par :
$r = $this->loadModuleFile($m['root'].'/_prepend.php');
PS: Pour rappel si on enléve le "global $core" des _prepend.php des
plugins de la distribution (on qu'on désactive ces plugins) la moitié
des plugins de DA ne fonctionnera pas car mal écrit. (Mais normal les
uns copiant sur les autres, toussa)
Z'en pensez ?
8:48 a.m.
Normalement tous les plugins resteront compatibles avec cette
modification ! Après ça sera à toi de faire l'effort de nettoyer ton code.
PS: Je ne crois pas que widgets.php suive le même chemin, faudrait que
je regarde.
Le 25/09/2013 08:32, mirovinben a écrit :
Où je constate que *tous* mes plugins sont impactés... :-(
... Mais pas avec "global $core" dans _prepend.php, plutôt dans
_public.php et dans widgets.php et/ou widget.php... Du coup j'ignore
si c'est grave ou pas. Je sens que je vais avoir besoin d'aide et/ou
d'accompagnement. Voire demander un diagnostique "sécurité" pour
mrvbNextDoor (anciennement OtherBlog) qui peut être utilisé sous
certaines conditions en dehors d'un blog Dotclear.
9:19 a.m.
Je suis plus que prêt à faire l'effort demandé pour que mes plugins gardent leur
aspect soyeux et le poil lisse. C'est juste que je ne saisis pas tout du pourquoi et
du comment et ne demande qu'à apprendre...
Le 25/09/2013 08:48, Denis Jean-Christian a écrit :
Normalement tous les plugins resteront compatibles avec cette
modification ! Après ça sera à toi de faire l'effort de nettoyer ton code.
PS: Je ne crois pas que widgets.php suive le même chemin, faudrait que
je regarde.
Le 25/09/2013 08:32, mirovinben a écrit :
> Où je constate que *tous* mes plugins sont impactés... :-(
>
> ... Mais pas avec "global $core" dans _prepend.php, plutôt dans
> _public.php et dans widgets.php et/ou widget.php... Du coup j'ignore
> si c'est grave ou pas. Je sens que je vais avoir besoin d'aide et/ou
> d'accompagnement. Voire demander un diagnostique "sécurité" pour
> mrvbNextDoor (anciennement OtherBlog) qui peut être utilisé sous
> certaines conditions en dehors d'un blog Dotclear.
>
9:24 a.m.
Le 25 septembre 2013 09:19, mirovinben <forum(a)mirovinben.com> a écrit :
Je suis plus que prêt à faire l'effort demandé pour que mes
plugins
gardent leur aspect soyeux et le poil lisse. C'est juste que je ne saisis
pas tout du pourquoi et du comment et ne demande qu'à apprendre...
Pour le pourquoi : beaucoup de plugins aujourd'hui "tombent en marche"
parce qu'ils bénéficient du fait que d'autres plugins aient déclaré un
global $core auparavant.
Pour résumer, il faut voir le chargement des fichiers des plugins dans
l'admin comme :
function charger_plugins() {
foreach ($plugin in $plugins) {
include ($plugin."/_prepend.php");
include ($plugin.'/_admin.php');
}
donc en gros, le code de tous les plugins est mis bout à bout dans une
fonction. Avec de la chance, le premier plugin chargé fait un "global
$core" et tout fonctionne. si le premier plugin chargé ne fait pas de
global (ou si on désactive ceux qui le font), ça va coincer au premier qui
appelle $core.
5:16 p.m.
Et si... je vais surement dire une connerie ou enfoncer une porte déjà ouverte par un
klingoneur, et si donc on chargeait avant tout plugin un "machin" qui déclare
global $core une bonne fois pour toute, plus de plantage si on désactive ceux qui le
font...
Non ?
Le 25/09/2013 09:24, Bruno a écrit :
Le 25 septembre 2013 09:19, mirovinben <forum(a)mirovinben.com> a
écrit :
> Je suis plus que prêt à faire l'effort demandé pour que mes plugins
> gardent leur aspect soyeux et le poil lisse. C'est juste que je ne saisis
> pas tout du pourquoi et du comment et ne demande qu'à apprendre...
>
Pour le pourquoi : beaucoup de plugins aujourd'hui "tombent en marche"
parce qu'ils bénéficient du fait que d'autres plugins aient déclaré un
global $core auparavant.
Pour résumer, il faut voir le chargement des fichiers des plugins dans
l'admin comme :
function charger_plugins() {
foreach ($plugin in $plugins) {
include ($plugin."/_prepend.php");
include ($plugin.'/_admin.php');
}
donc en gros, le code de tous les plugins est mis bout à bout dans une
fonction. Avec de la chance, le premier plugin chargé fait un "global
$core" et tout fonctionne. si le premier plugin chargé ne fait pas de
global (ou si on désactive ceux qui le font), ça va coincer au premier qui
appelle $core.
5:44 p.m.
Et si... je vais surement dire une connerie ou enfoncer une porte
déjà
ouverte par un klingoneur, et si donc on chargeait avant tout plugin un
"machin" qui déclare global $core une bonne fois pour toute, plus de
plantage si on désactive ceux qui le font...
C'est précisément ce que propose jc dans son mail :-)
5:51 p.m.
Donc j'en conclus que...
-1- je n'ai pas dit de connerie... ouf !
-2- je ne cause toujours pas le klingon... bof ?
-3- c'est une super bonne idée (en anorak) qu'il a eu "le" JC
Merci Bruno de ton aide, je finirais la journée plus instruit qu'au lever. :-)
Le 25/09/2013 17:44, Bruno a écrit :
> Et si... je vais surement dire une connerie ou enfoncer une porte
déjà ouverte par un klingoneur, et si donc on chargeait avant tout plugin un
"machin" qui déclare global $core une bonne fois pour toute, plus de plantage si
on désactive ceux qui le font..
>
C'est précisément ce que propose jc dans son mail :-)
10:19 p.m.
Ca y est j'ai tout cassé, si certains rencontrent des problèmes à cause
de ces modifs demain, promis j'irai déneiger le Jura. Pour vous dire
comme je suis serein :)
Le 25/09/2013 19:09, Bruno a écrit :
Le 25 septembre 2013 18:47, Denis Jean-Christian
<contact(a)jcdenis.fr> a
écrit :
> Vous ne direz pas la même chose quand on se rendra compte que j'ai tout
> cassé !
>
Boarf ... franck râlera... j'y ai survécu :P
10:34 p.m.
Tu parles... Tu as surtout regardé la météo, p'tite frappe !
:-p
-----Message d'origine-----
De : dev-bounces(a)list.dotclear.org [mailto:dev-bounces@list.dotclear.org] De
la part de Denis Jean-Christian
Envoyé : mercredi 25 septembre 2013 22:20
À : dev(a)list.dotclear.org
Objet : Re: [Dotclear Dev] [dev] se passer des global dans les _prepend.php
Ca y est j'ai tout cassé, si certains rencontrent des problèmes à cause de
ces modifs demain, promis j'irai déneiger le Jura. Pour vous dire comme je
suis serein :)
10:42 p.m.
Pour les _prepend.php, ok, on vire tout les global …
Mais pour les autres fichiers des plougs ? Côté public, côté admin, les fn
appelées via behaviour, …
?
Le 25 septembre 2013 22:34, Pep <pep(a)callmepep.org> a écrit :
Tu parles... Tu as surtout regardé la météo, p'tite frappe !
:-p
-----Message d'origine-----
De : dev-bounces(a)list.dotclear.org [mailto:dev-bounces@list.dotclear.org]
De
la part de Denis Jean-Christian
Envoyé : mercredi 25 septembre 2013 22:20
À : dev(a)list.dotclear.org
Objet : Re: [Dotclear Dev] [dev] se passer des global dans les _prepend.php
Ca y est j'ai tout cassé, si certains rencontrent des problèmes à cause de
ces modifs demain, promis j'irai déneiger le Jura. Pour vous dire comme je
suis serein :)
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
10:59 p.m.
Tu as remarqué dans mon commit c'est marqué "addresses" et non
"fixes" :)
Il y a beaucoup de chemin avant d'arriver au bon résultat, qui, comme ça
a vu de nez, n'est pas réalisable sans tout casser.
Après on peut se mettre aux espaces de noms, mais je suis trop vieux
pour ça.
Sinon oui, j'ai regardé un peu partout, notamment les behaviors mais je
n'ai pas de solution pour l'instant, je continue mes fouilles.
Le 25/09/2013 22:42, Franck Paul a écrit :
Pour les _prepend.php, ok, on vire tout les global …
Mais pour les autres fichiers des plougs ? Côté public, côté admin, les fn
appelées via behaviour, …
?
11:08 p.m.
Ça veut dire que pour l'instant on ne touche qu'aux _prepend.php des
plugins ?
Ou il faut mettre à niveaux les _install.php, _admin.php, _public.php, … ?
Le 25 septembre 2013 22:59, Denis Jean-Christian <contact(a)jcdenis.fr> a
écrit :
Tu as remarqué dans mon commit c'est marqué "addresses"
et non "fixes" :)
Il y a beaucoup de chemin avant d'arriver au bon résultat, qui, comme ça
a vu de nez, n'est pas réalisable sans tout casser.
Après on peut se mettre aux espaces de noms, mais je suis trop vieux
pour ça.
Sinon oui, j'ai regardé un peu partout, notamment les behaviors mais je
n'ai pas de solution pour l'instant, je continue mes fouilles.
Le 25/09/2013 22:42, Franck Paul a écrit :
> Pour les _prepend.php, ok, on vire tout les global …
>
> Mais pour les autres fichiers des plougs ? Côté public, côté admin, les
fn
> appelées via behaviour, …
>
> ?
>
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
11:18 p.m.
Ha ben si tu vois du global $core à la racine d'un fichier _install.php
c'est que le mec était bourré quand il a écrit son plugin !
Plus sérieusement, cela vaut pour tous les fichiers en _xxx.php qui
passent (depuis des lustres) par la moulinette
dcModules::loadModuleFile(), ils n'ont pas besoin de faire global $core
-- à la racine du fichier bien entendu --
Le 25/09/2013 23:08, Franck Paul a écrit :
Ça veut dire que pour l'instant on ne touche qu'aux
_prepend.php des
plugins ?
Ou il faut mettre à niveaux les _install.php, _admin.php, _public.php, … ?
11:39 p.m.
Ah donc, ce n'est qu'à la racine, en dehors de toute classe et fonction.
Ça limite rudement la portée des modifs.
Le 25 septembre 2013 23:18, Denis Jean-Christian <contact(a)jcdenis.fr> a
écrit :
Ha ben si tu vois du global $core à la racine d'un fichier
_install.php
c'est que le mec était bourré quand il a écrit son plugin !
Plus sérieusement, cela vaut pour tous les fichiers en _xxx.php qui
passent (depuis des lustres) par la moulinette
dcModules::loadModuleFile(), ils n'ont pas besoin de faire global $core
-- à la racine du fichier bien entendu --
Le 25/09/2013 23:08, Franck Paul a écrit :
> Ça veut dire que pour l'instant on ne touche qu'aux _prepend.php des
> plugins ?
>
> Ou il faut mettre à niveaux les _install.php, _admin.php, _public.php, …
?
>
>
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
11:55 p.m.
Et tout casser ? Mais ça va pas la tête ? :-p
Le 25 septembre 2013 23:53, Denis Jean-Christian <contact(a)jcdenis.fr> a
écrit :
Je n'ai pas écrit PHP, si tu veux ça faut les namespaces.
Le 25/09/2013 23:39, Franck Paul a écrit :
> Ah donc, ce n'est qu'à la racine, en dehors de toute classe et fonction.
>
> Ça limite rudement la portée des modifs.
>
>
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
9:24 a.m.
Le 25 septembre 2013 08:32, mirovinben <forum(a)mirovinben.com> a écrit :
Où je constate que *tous* mes plugins sont impactés... :-(
Idem, même si de mon côté il n'y en a que deux ou trois qui sont
diffusés, j'ai pas mal de plougues spécifiques qui se baladent dans la
nature et me feront craindre dorénavant le passage à 2.6 ;)
Les changements pas trop compliqués comme la hiérarchie des titres de
l'aide intégrée m'ont déjà pris pas mal de temps, là je dois
m'attaquer aux filtres sur les listes de billets et leur pagination,
et c'est pas de la tarte pour un stagiaire de devoir se replonger dans
un plougue qui marchait autrement assez bien...
Bref je râle, mais ne vous en faites pas, c'est surtout après moi et
mes limites... et comme Mirovinben je ne cracherais pas sur un coup de
main ^^
--
Philippe
9:26 a.m.
Le 25 septembre 2013 09:24, philippe(a)dissitou.org <philippe(a)dissitou.org> a
écrit :
Le 25 septembre 2013 08:32, mirovinben <forum(a)mirovinben.com> a
écrit :
> Où je constate que *tous* mes plugins sont impactés... :-(
Idem, même si de mon côté il n'y en a que deux ou trois qui sont
diffusés, j'ai pas mal de plougues spécifiques qui se baladent dans la
nature et me feront craindre dorénavant le passage à 2.6 ;)
On parle bien de "bonnes pratiques" là, on ne va rien casser du tout, hein
:)
9:54 a.m.
Le 25 septembre 2013 09:26, Bruno <dsls(a)morefnu.org> a écrit :
On parle bien de "bonnes pratiques" là, on ne va rien
casser du tout, hein
:)
Je ne conteste pas la nécessité d'améliorer le bidule, mais quand je
vois la page du wiki avec le nombre de plugins de da à tester et
surtout le nombre qui *risquent* de ne plus marcher, je suis un peu
inquiet
De mon côté, et tout comme Michel, je suis bien entendu disposé à apprendre :P
--
Philippe
10:01 a.m.
Le 25 septembre 2013 09:54, philippe(a)dissitou.org <philippe(a)dissitou.org> a
écrit :
Le 25 septembre 2013 09:26, Bruno <dsls(a)morefnu.org> a écrit :
> On parle bien de "bonnes pratiques" là, on ne va rien casser du tout,
hein
> :)
Je ne conteste pas la nécessité d'améliorer le bidule, mais quand je
vois la page du wiki avec le nombre de plugins de da à tester et
surtout le nombre qui *risquent* de ne plus marcher, je suis un peu
inquiet
C'est là que je ne comprends pas, il n'y aura pas plus de plugins qui
*risquent* de ne pas marcher après les modifications proposées par JC...
10:53 a.m.
Le 25 septembre 2013 10:01, Bruno <dsls(a)morefnu.org> a écrit :
C'est là que je ne comprends pas, il n'y aura pas plus de
plugins qui
*risquent* de ne pas marcher après les modifications proposées par JC...
Je n'en étais pas là mais plus généralement sur une modification
supplémentaire du mécanisme des plugins, où j'ai l'impression qu'on
avance un peu vite sans mesurer les impacts, mébon je ne comprends pas
toujours tout à vos conversations :P
--
Philippe
10:59 a.m.
Je n'en étais pas là mais plus généralement sur une modification
supplémentaire du mécanisme des plugins, où j'ai l'impression qu'on
avance un peu vite sans mesurer les impacts, mébon je ne comprends
pas
toujours tout à vos conversations :P
JC propose justement une modification pour que les plugins qui jusqu'alors
risquaient d'être cassés si on en désactive d'autres, ne le soient plus.
11:06 a.m.
Le 25 septembre 2013 10:59, Bruno <dsls(a)morefnu.org> a écrit :
JC propose justement une modification pour que les plugins qui
jusqu'alors
risquaient d'être cassés si on en désactive d'autres, ne le soient plus.
Pas tout à fait. Il propose d'utiliser $this->core au lieu de
$GLOBALS['core'] que beaucoup utilisait directement par $core car nombreux
plugins faisait un global $core.
11:22 a.m.
Pas tout à fait. Il propose d'utiliser $this->core au lieu de
$GLOBALS['core'] que beaucoup utilisait directement par $core car
nombreux
plugins faisait un global $core.
Ce n'est pas ce que j'ai compris.
* Utiliser $this->core (et $this->__autoload) est une bonne pratique qu'on
aimerait voir appliquée partout, là où les global $core sont légion et où
parfois ça tombe en marche parce que qu'un autre plugin a déclaré le global
à notre place
* JC propose de charger _prepend.php via dcModules::loadModuleFile, cette
dernière méthode "propage" les globales dans les fichiers qu'elle inclut.
Je vois ça comme une résolution de bug qui permet aux plugins qui ne
déclarent pas $core (ou $__autoload) comme global de fonctionner dans tous
les cas, sans modification.
JC, tu confirmes ?
--
Bruno
2:03 p.m.
Je confirme, cette modification NE CHANGE RIEN aux plugins existant,
qu'ils soient bien écrit ou codé avec des moufles ! (dans le jura il
fait froid) Vous n'aurez pas à les mettre à jour. (à moins d'avoir honte
de coder aussi mal que moi)
Ici je résous plusieurs problématiques d'un seul coup de baguette magique:
- Réduire l'utilisation à tout va de "global",
- Corriger les plugins de la distribution pour montrer le bon exemple
(et sans rien casser).
Le changement est que les plugins (et themes complexes) n'auront plus à
se soucier de faire "$this->core" ou "global $core;" puisque
"$core"
sera accessible et ce, même si les plugins de la distribution sont
désactivés (Ce qui faisait planter la plupart des plugins de DA
aujourd'hui).
Le 25/09/2013 11:22, Bruno a écrit :
Ce n'est pas ce que j'ai compris.
* Utiliser $this->core (et $this->__autoload) est une bonne pratique qu'on
aimerait voir appliquée partout, là où les global $core sont légion et où
parfois ça tombe en marche parce que qu'un autre plugin a déclaré le global
à notre place
* JC propose de charger _prepend.php via dcModules::loadModuleFile, cette
dernière méthode "propage" les globales dans les fichiers qu'elle inclut.
Je vois ça comme une résolution de bug qui permet aux plugins qui ne
déclarent pas $core (ou $__autoload) comme global de fonctionner dans tous
les cas, sans modification.
JC, tu confirmes ?
--
Bruno
2:08 p.m.
Le 25 septembre 2013 14:03, Denis Jean-Christian <contact(a)jcdenis.fr> a
écrit :
Je confirme, cette modification NE CHANGE RIEN aux plugins existant,
qu'ils soient bien écrit ou codé avec des moufles ! (dans le jura il
fait froid) Vous n'aurez pas à les mettre à jour. (à moins d'avoir honte
de coder aussi mal que moi)
Ici je résous plusieurs problématiques d'un seul coup de baguette magique:
- Réduire l'utilisation à tout va de "global",
- Corriger les plugins de la distribution pour montrer le bon exemple
(et sans rien casser).
Le changement est que les plugins (et themes complexes) n'auront plus à
se soucier de faire "$this->core" ou "global $core;" puisque
"$core"
sera accessible et ce, même si les plugins de la distribution sont
désactivés (Ce qui faisait planter la plupart des plugins de DA
aujourd'hui).
Vu que tu confirmes ce que j'avais cru comprendre, tu as mon feu vert :)
2:08 p.m.
Hé. Ho.
Tu me cherches, là ?!
Parce qu'en plus des moufles, j'ai des gants de frappe également (je vais
peut-être même commander une version en béton, tiens...)
-----Message d'origine-----
De : dev-bounces(a)list.dotclear.org [mailto:dev-bounces@list.dotclear.org] De
la part de Denis Jean-Christian
Envoyé : mercredi 25 septembre 2013 14:04
À : dev(a)list.dotclear.org
Objet : Re: [Dotclear Dev] [dev] se passer des global dans les _prepend.php
Je confirme, cette modification NE CHANGE RIEN aux plugins existant, qu'ils
soient bien écrit ou codé avec des moufles ! (dans le jura il fait froid)
Vous n'aurez pas à les mettre à jour. (à moins d'avoir honte de coder aussi
mal que moi)
5:08 p.m.
Je ne sais pas qui il cherche mais il va y avoir du monde en bas de chez lui... :-)
Surtout qu'il me semble qu'il n'habite pas si loin que ça de chez nous... :-p
Le 25/09/2013 14:08, Pep a écrit :
Hé. Ho.
Tu me cherches, là ?!
Parce qu'en plus des moufles, j'ai des gants de frappe également (je vais
peut-être même commander une version en béton, tiens...)
-----Message d'origine-----
De : dev-bounces(a)list.dotclear.org [mailto:dev-bounces@list.dotclear.org] De
la part de Denis Jean-Christian
Envoyé : mercredi 25 septembre 2013 14:04
À : dev(a)list.dotclear.org
Objet : Re: [Dotclear Dev] [dev] se passer des global dans les _prepend.php
Je confirme, cette modification NE CHANGE RIEN aux plugins existant, qu'ils
soient bien écrit ou codé avec des moufles ! (dans le jura il fait froid)
Vous n'aurez pas à les mettre à jour. (à moins d'avoir honte de coder aussi
mal que moi)
5:15 p.m.
Le 25 septembre 2013 17:08, mirovinben <forum(a)mirovinben.com> a écrit :
Je ne sais pas qui il cherche mais il va y avoir du monde en bas de
chez
lui... :-)
Surtout qu'il me semble qu'il n'habite pas si loin que ça de chez nous...
:-p
Le 25/09/2013 14:08, Pep a écrit :
Hé. Ho.
> Tu me cherches, là ?!
Houlala...
Jean-Christian, j'espère pour toi que tu as des amis corses ? Si tu te mets
à dos le gang du Jura, faut au moins ça...
--
Anne / Kozlika
5:18 p.m.
Le temps de déblayer la neige de par chez vous, je peux finir
tranquillement ma terrasse !
Le 25/09/2013 17:08, mirovinben a écrit :
Je ne sais pas qui il cherche mais il va y avoir du monde en bas de
chez lui... :-)
Surtout qu'il me semble qu'il n'habite pas si loin que ça de chez
nous... :-p
Le 25/09/2013 14:08, Pep a écrit :
> Hé. Ho.
> Tu me cherches, là ?!
>
> Parce qu'en plus des moufles, j'ai des gants de frappe également (je
> vais
> peut-être même commander une version en béton, tiens...)
>
10:55 a.m.
Le 25 septembre 2013 09:24, philippe(a)dissitou.org <philippe(a)dissitou.org> a
écrit :
Les changements pas trop compliqués comme la hiérarchie des titres
de
l'aide intégrée m'ont déjà pris pas mal de temps, là je dois
m'attaquer aux filtres sur les listes de billets et leur pagination,
et c'est pas de la tarte pour un stagiaire de devoir se replonger dans
un plougue qui marchait autrement assez bien...
Il faut me le dire les trucs comme ça, si je peux trouver des solutions de
"triche" pour ne pas vous mettre dans l'embarras je le ferai.
C'était quoi exactement ? (en fait je ne me souviens pas avoir touché à ces
niveaux de titre, ça doit être "vieux")
--
Anne / Kozlika
11:09 a.m.
2013/9/25 Kozlika <kozlika(a)gmail.com>
Il faut me le dire les trucs comme ça, si je peux trouver des
solutions de
"triche" pour ne pas vous mettre dans l'embarras je le ferai.
C'était quoi exactement ? (en fait je ne me souviens pas avoir touché à ces
niveaux de titre, ça doit être "vieux")
Je ne sais pas si c'est à ça que faisait allusion Philippe, mais j'ai
constaté que le niveau des titres dans la colonne de droite d'édition d'un
billet à changé. Avec mon plugin shortURL par exemple, je rajoute une
entrée dans cette colonne. Auparavant, j'avais stylé son titre en h3 ;
maintenant avec DC2.6, il me faut le styler en h4...
julien
11:14 a.m.
Le 25 septembre 2013 11:09, Julien Mudry <julien.mudry(a)gmail.com> a écrit :
Je ne sais pas si c'est à ça que faisait allusion Philippe, mais
j'ai
constaté que le niveau des titres dans la colonne de droite d'édition d'un
billet à changé. Avec mon plugin shortURL par exemple, je rajoute une
entrée dans cette colonne. Auparavant, j'avais stylé son titre en h3 ;
maintenant avec DC2.6, il me faut le styler en h4...
Ah... je croyais avoir changé ça bien avant. En fait le titre 2 est celui
de la page complète, on passe à 3 pour signaler que c'est la partie Aide et
du coup les titres composant l'aide sont en h4...
Vu que c'est "ma faute", je peux aider à corriger si certains d'entre
vous
ont des plugins sur lesquels je peux faire des commits ou des PR...
--
Anne / Kozlika
11:44 a.m.
Le 25 septembre 2013 11:14, Kozlika <kozlika(a)gmail.com> a écrit :
Ah... je croyais avoir changé ça bien avant. En fait le titre 2 est
celui
de la page complète, on passe à 3 pour signaler que c'est la partie Aide et
du coup les titres composant l'aide sont en h4...
Le changement n'est pas si vieux, avant les titres qui permettaient de
plier/déplier l'aide étaient les h3
Mais ce n'est pas très gênant de changer deux ou trois pages de html,
alors que du php compliqué comme les listes ou la pagination c'est
plus coton à mon niveau ;) mais je suis en train de m'en sortir
--
Philippe
11:45 a.m.
Le 25 septembre 2013 11:44, philippe(a)dissitou.org
<philippe(a)dissitou.org> a écrit :
Mais ce n'est pas très gênant de changer deux ou trois pages de
html,
Sans oublier que les plougues qui fournissent une aide intégrée se
comptent sur les doigts d'une main, hein, bande de fainéants de
développeurs :P
--
Philippe
11:46 a.m.
Le 25 septembre 2013 11:45, philippe(a)dissitou.org <philippe(a)dissitou.org> a
écrit :
Sans oublier que les plougues qui fournissent une aide intégrée se
comptent sur les doigts d'une main, hein, bande de fainéants de
développeurs :P
Ce qui me fait penser que l'onglet "Documentation développeurs" de
l'aide
générale, qui est censée ne fournir rien d'autre qu'un centre d'aiguillage,
attend toujours preneur...
--
Anne / Kozlika
1:14 p.m.
Le 25 septembre 2013 11:46, Kozlika <kozlika(a)gmail.com> a écrit :
Ce qui me fait penser que l'onglet "Documentation
développeurs" de l'aide
générale, qui est censée ne fournir rien d'autre qu'un centre d'aiguillage,
attend toujours preneur...
Il y a deux mots dans cet onglet qui s'excluent mutuellement, moi je dis :P
--
Philippe
12:36 p.m.
Le 25/09/2013 11:45, philippe(a)dissitou.org a écrit :
Le 25 septembre 2013 11:44, philippe(a)dissitou.org
<philippe(a)dissitou.org> a écrit :
> Mais ce n'est pas très gênant de changer deux ou trois pages de html,
Sans oublier que les plougues qui fournissent une aide intégrée se
comptent sur les doigts d'une main, hein, bande de fainéants de
développeurs :P
Elle est ou la doc qui explique comment on fait une aide intégré ?
--
lipki
4:29 p.m.
Le 25 septembre 2013 12:36, Lepeltier kévin <kevin(a)lepeltier.info> a écrit :
Elle est ou la doc qui explique comment on fait une aide intégré ?
http://fr.dotclear.org/documentation/2.0/resources/plugins/help
--
Philippe
4:34 p.m.
Ah ben tu vois qu'il y avait bien les niveaux de titres en h4 dans la doc !
Le 25 septembre 2013 16:29, philippe(a)dissitou.org <philippe(a)dissitou.org> a
écrit :
Le 25 septembre 2013 12:36, Lepeltier kévin
<kevin(a)lepeltier.info> a
écrit :
> Elle est ou la doc qui explique comment on fait une aide intégré ?
http://fr.dotclear.org/documentation/2.0/resources/plugins/help
--
Philippe
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Anne / Kozlika
5:45 p.m.
Trop grosse la ficelle :P
Si la ficelle est trop grosse, on peut par contre déjà dire que la
variable n'est pas de type string, ok je -> [].
--
Benoit CLERC
benoit(a)kairn.fr
____________________________________
KAIRN
15, rue du Général Lionel de Marmier
31 300 TOULOUSE
Tél : 05 62 57 73 43
Fax : 05 62 57 73 44
____________________________________
Agissez "archidurable", évitez les impressions inutiles.
12:26 p.m.
Le 25/09/2013 16:29, philippe(a)dissitou.org a écrit :
Le 25 septembre 2013 12:36, Lepeltier kévin
<kevin(a)lepeltier.info> a écrit :
> Elle est ou la doc qui explique comment on fait une aide intégré ?
http://fr.dotclear.org/documentation/2.0/resources/plugins/help
Merci ! :D
--
lipki
12:44 p.m.
Oups d'ailleurs je ne l'ai pas mis à jour pour le behavior permettant de
se greffer dans n'importe quel helpblock...
Le 26/09/2013 12:26, Lepeltier kévin a écrit :
Le 25/09/2013 16:29, philippe(a)dissitou.org a écrit :
> Le 25 septembre 2013 12:36, Lepeltier kévin <kevin(a)lepeltier.info> a
> écrit :
>
>> Elle est ou la doc qui explique comment on fait une aide intégré ?
> http://fr.dotclear.org/documentation/2.0/resources/plugins/help
>
Merci ! :D
3886
days inactive
3888
days old
53 comments
11 participants
participants (11)
-
Benoit CLERC -
Bruno -
Denis Jean-Christian -
Franck Paul -
Julien Mudry -
Kozlika -
Lepeltier kévin -
mirovinben -
Nicolas -
Pep -
philippe＠dissitou.org