extend dans coreBlogGetPosts

AkhThoT · 2010-01-15 09:04:18

Voici un problème que j'ai rencontré dans mon plugin ItsaRiddle en utilisant ce qui suit pour modifier les contents et extraits des billets à la volée :

public static function coreBlogGetPosts(&$rs)
	{
		$rs->extend('rsItsaRiddle');
	}

C'est le dernier plugin qui aura 'étendu' les billets qui aura droit de citer, par écrasement et donc par défaut on perd en 2.1.6 l'affichage sous forme d'imagette des émoticones et (mais aussi) la troncature des flux rss.

Moe m'a donné ce lien : http://jean-christophe.dubacq.fr/post/stacker car ce plugin stacker donne une solution.

Osku m'a donné cet autre lien : http://dev.dotclear.org/2.0/ticket/797 même sujet même solution.

Pour ma part j'ai préféré cette solution (en attendant de savoir si stacker doit s'imposer ou non comme solution unique) :

public static function coreBlogGetPosts(&$rs)
	{
		$f = $rs->extensions();
		$GLOBALS['PrvExtCItsaRiddle'] = $f['getContent'];
		$GLOBALS['PrvExtEItsaRiddle'] = $f['getExcerpt'];
		
		$rs->extend('rsItsaRiddle');
	}

&

	public static function getContent($rs,$absolute_urls=false)
	{
		global $core;

		$c = call_user_func_array($GLOBALS['PrvExtCItsaRiddle'],
			array($rs,$absolute_urls));
...

Donc si vous proposé des plugins utilisant cette capacité de dotclear à 'étendre' les billets, vous voilà prévenu ;-)

Dsls · 2010-01-15 09:23:49

Tu peux aussi jouer avec un autre behavior moins contraignant : publicBeforeContentFilter (ou After, selon ce que tu souhaites faire).

Exemple :

<?php

$core->addBehavior('publicBeforeContentFilter',array('behaviorContent','publicBeforeContentFilter'));

class behaviorContent {
	public static function publicBeforeContentFilter ($core,$tag,$args)
	{
		global $_ctx;
		if ($tag == "EntryContent") {
				// Traitement voulu sur le contenu, en altérant $args[0]
				$args[0] = str_replace('texte a remplacer','mon texte a moi',$args[0]);
		}		
	}
}
?>

Cela a l'avantage de ne pas trop alourdir la totalité les requêtes getPosts, mais uniquement lorsque EntryContent (ou un autre tag) est utilisé, ie. en partie publique

AkhThoT · 2010-01-15 09:34:41

Dsls a écrit :

Tu peux aussi jouer avec un autre behavior moins contraignant : publicBeforeContentFilter (ou After, selon ce que tu souhaites faire).

Oui mais voilà ce behavior je l'ai pas trouvé dans la doc (ou alors j'ai mal cherché), donc pas évident de savoir si cela peut me convenir ... ;-) Bon maintenant que je connais son existence c'est plus pareil, merci !

Cela a l'avantage de ne pas trop alourdir la totalité les requêtes getPosts, mais uniquement lorsque EntryContent (ou un autre tag) est utilisé, ie. en partie publique

C'est vrai que je dois alourdir des requêtes inutilement, mais lesquelles exactement ... parce que c'est bien à ce niveau que le core prévoit la transformation des émoticônes et la truncature du flux, donc ;-)

Dsls · 2010-01-15 09:43:54

AkhThoT a écrit :

C'est vrai que je dois alourdir des requêtes inutilement, mais lesquelles exactement ... parce que c'est bien à ce niveau que le core prévoit la transformation des émoticônes et la truncature du flux, donc ;-)

Le problème est que le but premier du behavior coreBlogGetPosts est de permettre d'étendre les resultsets, et pas d'en écraser les méthodes existantes, sinon effectivement les plugins vont se marcher sur les pieds.

Il manque peut-être effectivement un behavior spécifique pour des plugins type stacker ou le tien. En attendant, je pense que l'approche la plus propre et celle qui a le moins d'effets de bord est l'utilisation des behaviors publicBeforeContentFilter /publicAfterContentFilter.

AkhThoT · 2010-01-15 10:12:16

Dsls a écrit :

Il manque peut-être effectivement un behavior spécifique pour des plugins type stacker ou le tien. En attendant, je pense que l'approche la plus propre et celle qui a le moins d'effets de bord est l'utilisation des behaviors publicBeforeContentFilter /publicAfterContentFilter.

Il y a surement d'autres plugins concernés. Mais je prends note que cette méthode d'étendre les resultsets fait partie du fonctionnement privé du core (et plutôt au niveau de la lecture des tables, qu'à la présentation du contenu des billets) ... ;-)
Par contre, je ne modifierai mon plugin avec publicBeforeContentFilter que si j'ai des remontées négatives de la part d'éventuels d'utilisateurs.

JcDenis · 2010-01-15 10:20:00

Akhthot, si ton plugin ne modifie que la partie publique, je te conseil vivement d'utiliser publicBeforeContentFilter ou publicAfterContentFilter, en effet:

coreBlogGetPosts => étendre les résultats,
publicAfterContent => modifier les résultats,

J'utilise se dernier pour le plugin enhancePostContent qui sert justement à remplacer du contenu.

Moe · 2010-01-15 10:36:57

publicBeforeContentFilter a plusieurs avantages et un inconvénient majeur : il est appelé à chaque affichage pour faire la même opération. À votre avis est-ce que ça serait intéressant d'enregistrer les billets dans un état "brut" et dans un état "traité" ? Par exemple, on place une balise :bidule: dans le billet, Dotclear l'enregistre telle quel dans la colonne "billet brut" et ensuite il applique les filtres les uns après les autres, suivant l'ordre qu'on a choisi. Comme ça on peut facilement "étendre" les billets et le traitement n'est pas effectué à chaque affichage. Un bouton permet de régénérer tous les billets si on a changé un filtre.

Dsls · 2010-01-15 10:41:44

Moe a écrit :

À votre avis est-ce que ça serait intéressant d'enregistrer les billets dans un état "brut" et dans un état "traité" ?

On a déjà plus ou moins ça en base : post_content serait l'état "brut', post_content_xhtml l'état "traité"...

Moe · 2010-01-15 10:49:37

Dsls : ça c'est que pour le mode Wiki non ? Est-ce qu'on peut déjà modifier le billet entre ces 2 états ou c'est le behavior qui manque dont tu parlais plus tôt ?

JcDenis · 2010-01-15 10:51:16

Moe a écrit :

publicBeforeContentFilter a plusieurs avantages et un inconvénient majeur : il est appelé à chaque affichage pour faire la même opération. À votre avis est-ce que ça serait intéressant d'enregistrer les billets dans un état "brut" et dans un état "traité" ? Par exemple, on place une balise :bidule: dans le billet, Dotclear l'enregistre telle quel dans la colonne "billet brut" et ensuite il applique les filtres les uns après les autres, suivant l'ordre qu'on a choisi. Comme ça on peut facilement "étendre" les billets et le traitement n'est pas effectué à chaque affichage. Un bouton permet de régénérer tous les billets si on a changé un filtre.

Je change tous les jours les réglages des filtres (oui je ne sais pas ce que je veux!) et j'ai pas envie à chaque fois de régénérer les 500 billets, à mon avis on n'affiche rarement plus d'une vingtaine de billets par page et donc le traitement est certes plus lent mais ça reste raisonnable.

Moe · 2010-01-15 10:59:37

JcDenis : si tu appelais un behavior en modifiant tes filtres, tu n'aurais rien à faire. Ça fera quelques centaines de billets à traiter en une fois. Faut voir si c'est plus efficace de traiter une fois X billets que de les traiter en permanence à l'affichage.

AkhThoT · 2010-01-15 11:37:22

JcDenis a écrit :

Akhthot, si ton plugin ne modifie que la partie publique, je te conseil vivement d'utiliser publicBeforeContentFilter ou publicAfterContentFilter, en effet:
coreBlogGetPosts => étendre les résultats,
publicAfterContent => modifier les résultats,
J'utilise se dernier pour le plugin enhancePostContent qui sert justement à remplacer du contenu.

Il faut donc que je fasse le test pour savoir s'il y a une différence au final ...

Dsls · 2010-01-15 12:12:05

Moe a écrit :

Dsls : ça c'est que pour le mode Wiki non ? Est-ce qu'on peut déjà modifier le billet entre ces 2 états

Le mode xhtml se contente de recopier post_content dans post_content_xhtml, mais rien n'empêche de surcharger adminPostAfterUpdate pour faire ce qu'on souhaite.

ou c'est le behavior qui manque dont tu parlais plus tôt ?

Pas exactement. Ce que tu suggères est une modification à la soumission en base, et stockée en base. coreBlogGetPosts et public[Before|After]ContentFilter agissent après récupération des données en base et modifient tout 2 les données dynamiquement. Le behavior que je voyais serait plutôt appelé directement dans le getContent des resultsets, mais là j'avoue que c'est peut-être au final redondant avec public[Before|After]ContentFilter ...

AkhThoT · 2010-01-15 12:43:58

Dsls a écrit :

Cela a l'avantage de ne pas trop alourdir la totalité les requêtes getPosts, mais uniquement lorsque EntryContent (ou un autre tag) est utilisé, ie. en partie publique

Comme je n'implémente les appels que dans _public.php pas de souci avec la partie admin ...
Par contre sur la home voici ce que je totalise comme appel :
- 461 appels à publicBeforeContentFilter dont seul 12 pour EntryContent
- 12 appels à getContent et 8 appels à getExcerpt
Et sur un post :
- 59 appels à publicBeforeContentFilter dont seul 3 pour EntryContent
- 3 appels à getContent et 2 appels à getExcerpt
Donc de prime abord au niveau alourdissement ;-)

Dsls · 2010-01-15 13:09:50

les 461 appels en question sont fait au parsing du template html, une fois le fichier php généré en cache, il ne subsistera après que 12 interventions sur EntryContent. Idem pour post...

AkhThoT · 2010-01-15 13:12:42

Match nul 1 partout ! ;-)

JcDenis · 2010-01-18 15:16:29

Corrigez moi si je me trompe mais pour faire court:
Avec coreBlogGetPosts on ecrase tout et
avec publicBeforeContentFilter on mixe tout.

J'ai testé coreBlogGetPosts sur un futur ploug et c'est vrai que l'approche est pas mal non plus mais j'ai des doutes, par exemple avec cette méthode impossible d'utiliser le plugin planet + le mien... non?

AkhThoT · 2010-01-18 15:28:46

JcDenis a écrit :

Corrigez moi si je me trompe mais pour faire court:
Avec coreBlogGetPosts on ecrase tout et
avec publicBeforeContentFilter on mixe tout.
J'ai testé coreBlogGetPosts sur un futur ploug et c'est vrai que l'approche est pas mal non plus mais j'ai des doutes, par exemple avec cette méthode impossible d'utiliser le plugin planet + le mien... non?

J'ai proposé une méthode pour ne rien écraser en début de fil, chaque plugin ayant la responsabilité de sauvegarder ce qu'il écrase pour l'appeler lui-même avant ou après son traitement ...

En ce qui concerne planet , il fait quoi et comment exactement ?

JcDenis · 2010-01-18 15:38:09

En ce qui concerne le plugin planet il remplace ni plus ni moins getAuthorLink(), getAuthorCN(), getURL() et reprend getContent() et le complète.
Quand au mien il reprend getContent() pour le mettre de getExcerpt() et remplace getContent() (oui c'est bizarre mais il créé le post aussi bien avant)

AkhThoT · 2010-01-18 15:43:49

Donc si tu veux t'en sortir il faut que dans l'ordre d'exécution des coreBlogGetPosts tu arrives après planet, alors tu seras compatible (en utilisant ma méthode par-exemple) ;-)

Il faudrait que l'on trouve une solution à ce problème, non ?

AkhThoT · 2010-01-22 10:15:27

Nouveau rebondissement ;-)

En effet, si dans le tableau de bord vous avez choisi de tronquer les flux l'appel à getContent de la classe rsExtPostPublic appel la fonction context::remove_html() qui comme son nom l'indique fait sauter les balises html du content du billet !

Et ça c'est pas bon pour mon plugin puisque cela fait apparaitre très lisiblement la réponse à la devinette dans le flux !!!!!!

Bon dans le code de dotclear il y a un commentaire assez explicite ;-)

class rsExtPostPublic extends rsExtPost
{
	public static function getContent(&$rs,$absolute_urls=false)
	{
		# Not very nice hack but it does the job :)
		if (isset($GLOBALS['_ctx']) && $GLOBALS['_ctx']->short_feed_items === true) {
			$_ctx =& $GLOBALS['_ctx'];
			$c = parent::getContent($rs,$absolute_urls);
			$c = context::remove_html($c);
			$c = context::cut_string($c,350);
			
			$c =
			'<p>'.$c.'... '.
			'<em><a href="'.$rs->getURL().'">'.__('Read').'</em> '.
			html::escapeHTML($rs->post_title).'</a></p>';
			
			return $c;
		}
		
		if ($rs->core->blog->settings->use_smilies)
		{
			return self::smilies(parent::getContent($rs,$absolute_urls),$rs->core->blog);
		}
		
		return parent::getContent($rs,$absolute_urls);
	}
	
	public static function getExcerpt(&$rs,$absolute_urls=false)
	{
		if ($rs->core->blog->settings->use_smilies)
		{
			return self::smilies(parent::getExcerpt($rs,$absolute_urls),$rs->core->blog);
		}
		
		return parent::getExcerpt($rs,$absolute_urls);
	}

Le fait d'enlever des balises html dans le content parce que le flux est tronqué ne me semble pas être un bon choix, même si je suis d'accord qu'il n'est pas simple de trouver où tronquer le flux avec les balises :-)

Pour l'instant je ne vois qu'une solution interdire de tronquer les flux ... et donc éventuellement écrire sa propre fonction de tronquage de flux ...

Moe · 2010-01-22 10:22:30

Pourquoi tu n'utilises pas publicBeforeContentFilter qui évite les collisions entre plugins ?

AkhThoT · 2010-01-22 10:37:24

Moe a écrit :

Pourquoi tu n'utilises pas publicBeforeContentFilter qui évite les collisions entre plugins ?

Parce que cela ne change rien au problème :-) (j'ai essayé, quand même)

Lorsque tu choisis de tronquer les flux, dotclear fait sauter les balises html du content, or dans l'une ou l'autre fonction je ne trouve plus ce que je cherche à savoir : <span itseriddle=" ...

JcDenis · 2010-01-22 16:28:52

Et si tu étends la class rsExtPostPublic à la place, un truc dans ce genre:

$core->addBehavior('coreBlogGetPosts',array('monPlougPublicBehaviors','coreBlogGetPosts'));

class monplougPublicBehaviors
{
	public static function coreBlogGetPosts(&$rs)
	{
		$rs->extend('rsExtMonPlougPosts');
	}
}

class rsExtMonPlougPosts extends rsExtPostPublic
{
	public static function getContent(&$rs,$absolute_urls=false)
	{
//...
	}
}

AkhThoT · 2010-01-22 17:27:40

JcDenis a écrit :

Et si tu étends la class rsExtPostPublic à la place, un truc dans ce genre: ...

J'ai pas bien saisi en quoi cela changerait quelque chose :-) A moins que tu ne penses que je puisse juste avant de sortir de ma routine appeler le getContent original (j'essayerai)

Par contre cela ne change rien au fait que la troncature des flux fait sauter les balises html du content dans le fichier xml du feed ! Il n'y a que moi qui y voit un inconvénient ?

Dotclear

Forum Dotclear

Annonce

#1 2010-01-15 09:04:18

extend dans coreBlogGetPosts

#2 2010-01-15 09:23:49

Re : extend dans coreBlogGetPosts

#3 2010-01-15 09:34:41

Re : extend dans coreBlogGetPosts

#4 2010-01-15 09:43:54

Re : extend dans coreBlogGetPosts

#5 2010-01-15 10:12:16

Re : extend dans coreBlogGetPosts

#6 2010-01-15 10:20:00

Re : extend dans coreBlogGetPosts

#7 2010-01-15 10:36:57

Re : extend dans coreBlogGetPosts

#8 2010-01-15 10:41:44

Re : extend dans coreBlogGetPosts

#9 2010-01-15 10:49:37

Re : extend dans coreBlogGetPosts

#10 2010-01-15 10:51:16

Re : extend dans coreBlogGetPosts

#11 2010-01-15 10:59:37

Re : extend dans coreBlogGetPosts

#12 2010-01-15 11:37:22

Re : extend dans coreBlogGetPosts

#13 2010-01-15 12:12:05

Re : extend dans coreBlogGetPosts

#14 2010-01-15 12:43:58

Re : extend dans coreBlogGetPosts

#15 2010-01-15 13:09:50

Re : extend dans coreBlogGetPosts

#16 2010-01-15 13:12:42

Re : extend dans coreBlogGetPosts

#17 2010-01-18 15:16:29

Re : extend dans coreBlogGetPosts

#18 2010-01-18 15:28:46

Re : extend dans coreBlogGetPosts

#19 2010-01-18 15:38:09

Re : extend dans coreBlogGetPosts

#20 2010-01-18 15:43:49

Re : extend dans coreBlogGetPosts

#21 2010-01-22 10:15:27

Re : extend dans coreBlogGetPosts

#22 2010-01-22 10:22:30

Re : extend dans coreBlogGetPosts

#23 2010-01-22 10:37:24

Re : extend dans coreBlogGetPosts

#24 2010-01-22 16:28:52

Re : extend dans coreBlogGetPosts

#25 2010-01-22 17:27:40

Re : extend dans coreBlogGetPosts

Pied de page des forums

Sites map