Dotclear

Vous n'êtes pas identifié(e).

Annonce

13 février 2024 Sortie de Dotclear 2.29

#26 2009-03-13 16:29:12

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Ah bé oui, mais en fait là ce n'est pas interprété comme du javascript mais comme du php, alors forcément ça ne va pas. Il faudrait à mon avis que tu retournes un truc du genre :

$p = '<script type="text/javascript">$.cookie("ReadOrNot", '.$_ctx->post_id.':1, { path: "/", expires: 100 })</script>';
echo $p;

Hors ligne

#27 2009-03-13 16:32:06

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

PS : un exemple de javascript qui laisse un cookie : http://forum.dotclear.net/viewtopic.php … 21#p236021

Hors ligne

#28 2009-03-13 16:54:02

fix
Membre
Inscription : 2005-01-20
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

En effet, la ligne suivante fonctionne :

$p = '<script type="text/javascript">$.cookie("ReadOrNot", <?php echo $_ctx->posts->post_id; ?>, { path: "/", expires: 100000 });</script>';

Elle inscrit dans le cookie l'id du billet affiché sur la page post.html. Le problème est qu'il ne faudrait pas récrire le cookie, mais seulement le compléter ! À chaque fois, le contenu du cookie est effacé, et est remplacé par le nouvel id du billet...

Hors ligne

#29 2009-03-13 17:08:01

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

fix a écrit :

Le problème est qu'il ne faudrait pas récrire le cookie, mais seulement le compléter ! À chaque fois, le contenu du cookie est effacé, et est remplacé par le nouvel id du billet...

Ce n'est pas grave si tu as un cookie par billet, et ce sera plus simple à récupérer, cf #24 ;)

Hors ligne

#30 2009-03-13 21:38:53

fix
Membre
Inscription : 2005-01-20
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Après des heures de tests divers, je suis laborieusement parvenu à ce bout de code à insérer dans post.html :

<script type="text/javascript">
	if ($.cookie('dc_posts_read')) {
		var post_read_cookie = $.cookie('dc_posts_read');
	} else {
		var post_read_cookie = '.';
	}
	$.cookie("dc_posts_read", post_read_cookie.<?php echo $_ctx->posts->post_id; ?>.'.', { path: "/", expires: 100000 });
</script>

Mais ça ne fonctionne pas ! Je souhaiterais mettre les ids des billets lus dans le cookie les uns derrière les autres, séparés par des points... Le cookie n'est pas créé, car il est considéré comme vide !

Et j'ai eu beau triturer et retourner dans tous les sens, je ne vois pas pourquoi ça ne fonctionne pas.

Il faut dire que le javascript n'est pas vraiment mon fort :( Quelqu'un pourrait m'aider ?

Hors ligne

#31 2009-03-14 08:14:19

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Je me répète, mais un cookie par billet me semble plus facile à gérer :)

J'ai fait quelques tests ici avec ce code dans _public.php de mon thème :

$core->tpl->addValue('CreateReadOrNotCookie', array('tplMyThemeAdditions', 'CreateReadOrNotCookie'));

class tplMyThemeAdditions
{
	public static function CreateReadOrNotCookie()
	{
		$p = '<script type="text/javascript">
		$(document).ready( function () {
		$.cookie("<?php echo $_ctx->posts->post_id; ?>", "1", { path: "/", expires: 100000 });
		
		});
		</script>';
		return $p;
	}
}

et l'appel dans le head de post.html

{{tpl:CreateReadOrNotCookie}}

SI tu navigues de billet en billet, tu verras qu'il y a un cookie par billet visité dont le nom est l'id du billet et la valeur est 1

Manque plus qu'à vérifier que le cookie existe dans home.html et les autres fichiers, et ça devrait aller,  ;)

Hors ligne

#32 2009-03-14 14:02:35

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

J'avais un peu de temps pour jouer avec, voici la méthode complète :

1) dans _public.php

$core->tpl->addValue('CreateReadOrNotCookie', array('tplMyThemeAdditions', 'CreateReadOrNotCookie'));
$core->tpl->addValue('ReadOrNotCookie', array('tplMyThemeAdditions', 'ReadOrNotCookie'));

class tplMyThemeAdditions
{
	public static function CreateReadOrNotCookie()
	{
		$p = '<script type="text/javascript">
		$(document).ready( function () {
		$.cookie("p<?php echo $_ctx->posts->post_id; ?>", "1", { path: "/", expires: 100000 });
		
		});
		</script>';
		return $p;
	}
	public static function ReadOrNotCookie()
	{
		$p =
		'<?php '.
		'$id = $_ctx->posts->post_id;'.
		'if ($_COOKIE[\'p\'.$id.\'\']) {echo " read";} '.
		' ?>';
		return $p;
	}
}

Par rapport au code précédent, j'ai ajouté un p avant le nom du cookie

2) dans post.html, insérer juste avant </head>

{{tpl:CreateReadOrNotCookie}}

3) dans category.html, home.html et autres fichiers pour les listes de billets, à la place du titre du billet dans la boucle <tpl:Entries>

<h2 id="p{{tpl:EntryID}}" class="post-title{{tpl:ReadOrNotCookie}}"><a
    href="{{tpl:EntryURL}}">{{tpl:EntryTitle encode_html="1"}}</a></h2>

cela ajoute un attribut class="post-title read"

Ensuite, il faut styler .read dans la css

En action ici : les titres des billets lus sont grisés.

Je suppose que je pourrais aussi créer le cookie en php pour plus de cohérence, mais je te laisse améliorer le machin si tu veux ;)

Hors ligne

#33 2009-03-14 15:02:19

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Il y a sans doute un souci avec l'utilisation des cookies de cette manière : sur Wikipedia je lis que

Les cookies sont soumis a plusieurs contraintes :

    * Leur nombre total est limité à 300 ;
    * La taille maximale d'un cookie est de 4 ko ;
    * Il ne peut exister au maximum que 20 cookies par domaine.

Du coup, il me semble que cette astuce trouvera vite ses limites :( Un sorcier pourrait-il confirmer ou infirmer ?

en lisant la norme rfc2965 je vois que ces limites sont des minimales, et ne sais plus que penser...

Dernière modification par Philippe (2009-03-14 15:08:21)

Hors ligne

#34 2009-03-14 16:45:29

fix
Membre
Inscription : 2005-01-20
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

4ko, ça fait 4*1024 caractères ??? C'est ça ? Donc 4096/4 (nombre de caractères d'un id de billet + 1 caractère pour le délimiteur) = jusqu'à 1024 id de billets dans un seul cookie... pour un seul lecteur du blog, ce qui n'est déjà pas si mal ! Est-ce que revenir à 1 seul cookie pour tous les ids se révèlerait quand même être une solution potentielle ? Ou est-ce malgré tout une mauvaise idée ???

Si j'étais parti là dessus, c'est qu'1 seul cookie est beaucoup plus facile à gérer que plusieurs dizaines : ainsi, sur mon Firefox, je supprime TOUS les cookies à la fermeture SAUF 7 ou 8 que j'autorise (comme celui pour ce forum, par exemple)...

Hors ligne

#35 2009-03-15 19:40:35

fix
Membre
Inscription : 2005-01-20
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Pour créer un seul cookie regroupant tous les ids, le code suivant fonctionne à 1 détail près :

public static function CreateReadOrNotCookie()
	{
		$p = '<?php $id = $_ctx->posts->post_id;'."\n".
		'if (strrpos($_COOKIE[\'dc_posts_read\'],\'p\'.$id.\'.\') === false) {'."\n".
		'echo \'<script type="text/javascript">$(document).ready( function () { $.cookie("dc_posts_read", "\'.$_COOKIE[\'dc_posts_read\'].\'p\'.$id.\'.", { path: "/", expires: 100000 }); });</script>\';'."\n".
		'}'."\n".
		'?>';
		return $p;
	}

Le problème est que si je navigue entre plusieurs billets, les ids sont bien ajoutés tant qu'ils n'existent pas encore dans le cookie.
En revanche, si on revient sur un post déjà lu, le cookie est recréé sans les ids que l'on a visités depuis. Je suppose que c'est dû au cache !
Un exemple :
- j'ai 3 billets :
      * billet 1 : id=50
      * billet 2 : id = 70
      * billet 3 : id = 90
- je vais sur le billet 1 : le cookie est "p50."
- je vais sur le billet 2 : le cookie est "p50.p70."
- je vais sur le billet 3 : le cookie est "p50.p70.p90."
---> jusqu'ici tout va bien !
- je reviens sur le billet 2 : le cookie redevient "p50.p70." !!!
---> le cookie semble recréé tel qu'il était au moment de la 1°visite du biilet 2 !!!
- je reviens sur le billet 1 : le cookie redevient "p50." !!!
---> le cookie semble recréé tel qu'il était au moment de la 1°visite du biilet 1 !!!

N'y aurait-il pas une sorte de "mise en cache" du cookie ??? Ou une autre explication ???...

Hors ligne

#36 2009-03-16 13:56:54

fix
Membre
Inscription : 2005-01-20
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Je ne parviens plus à avancer. J'ai quelques questions : quelqu'un saurait-il y répondre ???

1. Le scénario que j'ai évoqué dans le billet précédent #35 est-il plausible ? Peut-on raisonnablement imaginer que le code générant le cookie est mis en cache avec le reste de la page ? Le fait de mettre ce code comme code javascript (je veux dire entre des balises <script etc...>) ne peut permettre d'éviter ça ?

2. Étant données les limitations du principe du cookie rappelées par amalgame dans le billet #33, je peux peut-être envisager de revenir au principe de la base de données... mais cela n'est-il pas trop "coûteux" en termes de performances ? N'est-ce pas gênant d'ajouter un appel à la base de données pour y lire le contenu de la table et y écrire (s'il ne s'y trouve déjà) le n° de l'id du billet, et ce à chaque chargement du fichier post.html ? De même, cela suppose 1 accès à la table à chaque chargement de la page home.html (et peut-être aussi archive_month.html etc.). Qu'en pensez-vous ???

3. Je me demande si cette dernière solution (passer par la base de données) ne posera pas non plus de problème lors de l'export des tables (je veux parler de la maintenance de son blog, lorsqu'on en fait une sauvegarde) : sauvegarder une table comme celle-là ne servirait à rien du tout. Y a-t-il un moyen d'indiquer de ne pas le faire ? Ou l'export du blog ne prend-il de toutes manières pas en compte les tables autres que celles par défaut dans DC2 ?

Merci d'avance pour vos réponses...

Hors ligne

#37 2009-03-16 14:02:29

fix
Membre
Inscription : 2005-01-20
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

En réfléchissant un peu, le principe de la base de données ne peut fonctionner que sur un site sur lequel on s'authentifie, de manière à distinguer qui a déjà lu quoi...

Ça me fait de toutes façons un peu bizarre d'arriver sur une page (comme celle de Netvibes) sur laquelle je ne suis pas allé depuis 2 mois, et de me rendre compte que toutes les informations concernant ma navigation (l'onglet sur lequel j'ai quitté, les billets que j'ai consultés ou pas, l'endroit auquel j'ai arrêté ma partie de mahjong) ont été conservées... quelque part, en tout cas pas sur mon ordi.

Le principe du cookie semble donc quand même meilleur pour faire ce genre de choses.

Je me permets donc d'insister : le cookie est-il effectivement mis en cache par Dotclear ??? (cf. mon billet #35...)

Hors ligne

#38 2009-03-16 14:37:35

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Je dirais que le cookie, étant sur le poste client, n'a rien à voir avec le cache de Dotclear, qui lui est sur le serveur ;)

Hors ligne

#39 2009-03-16 15:13:57

fix
Membre
Inscription : 2005-01-20
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

...et donc... ?
Serait-il possible de tester le code #35 et voir si le même résultat est constaté ?
Je ne me l'explique pas !

Hors ligne

#40 2009-03-16 15:28:53

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

fix a écrit :

Serait-il possible de tester le code #35 et voir si le même résultat est constaté ?

En tout cas on ne peut pas le tester sur ton site, qui est privé ;) Je crois que tu n'as pas un souci de cache mais seulement un souci avec la fonction strrpos, et je ne saurais pas vraiment t'aider sur ce coup-là. Voila pourquoi je préconisais un cookie par billet, avec les inconvénients que nous avons déjà vus :(

Il faudrait peut-être chercher si la chaîne pX existe plus simplement.

Dernière modification par Philippe (2009-03-16 15:30:22)

Hors ligne

#41 2009-03-16 16:11:27

fix
Membre
Inscription : 2005-01-20
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Je ne crois vraiment pas que le problème vienne de là : si j'affiche le contenu du cookie AVANT MÊME la condition if (), on s'aperçoit que le cookie ne contient plus tous les ids, comme expliqué dans le billet #35.

Essayer avec strpos au lieu de strrpos, par exemple, ne change donc rien (testé).

Hors ligne

#42 2009-03-16 17:00:04

Mirovinben
M comme Mathusalem
Lieu : Dole (Jura)
Inscription : 2007-02-06
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Fix : Juste une idée comme ça (ça fait longtemps que je n'ai pas bidouillé les cookies et je n'ai peut-être pas tout capté de tes essais) : lire le cookie à l'ouverture du billet, stocker le contenu du cookie dans un tableau, ajouter l'info concernant le billet et réécrire le cookie ainsi mis à jour à partir des données du tableau quand tu quittes le billet... ???

Hors ligne

#43 2009-03-16 17:22:15

fix
Membre
Inscription : 2005-01-20
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Mmmm... J'ai lu pas mal de choses ces jours-ci sur les cookies en javascript ou en php, mais je ne sais pas comment on fait "lire le cookie À L'OUVERTURE" et "récrire le cookie QUAND ON QUITTE le billet"...

Hors ligne

#44 2009-03-16 18:08:18

Moe
Responsable du mini-bar
Lieu : France
Inscription : 2004-09-19
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Je sais pas si ça va répondre à ta question mais dans l'administration de Dotclear, c'est l'événement onbeforeunload qui est utilisé : http://dev.dotclear.org/2.0/browser/tru … m-close.js

Hors ligne

#45 2009-03-18 12:43:15

fix
Membre
Inscription : 2005-01-20
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

J'ai tenté une solution entièrement en javascript... mais le cookie n'est même pas créé... Aussi bien dans la solution en PHP (#30) qu'en javascript ci-dessous, dès que je veux vérifier la présence de l'id dans le cookie, le billet n'est plus créé !

public static function CreateReadOrNotCookie()
{
	$p = '<script type="text/javascript" language="JavaScript">
	<!--
	function getCookieVal(offset)
	{
		var endstr=document.cookie.indexOf (";", offset);
		if (endstr==-1) endstr=document.cookie.length;
		return unescape(document.cookie.substring(offset, endstr));
	}
	function LireCookie(nom)
	{
		var arg=nom+"=";
		var alen=arg.length;
		var clen=document.cookie.length;
		var i=0;
		while (i<clen)
		{
			var j=i+alen;
			if (document.cookie.substring(i, j)==arg) return getCookieVal(j);
			i=document.cookie.indexOf(" ",i)+1;
			if (i==0) break;
		}
		return null;
	}
	$(document).ready( function () {
	var readposts=LireCookie("nombredevisites");
	if (readposts.indexOf(\'<?php echo "p.".$_ctx->posts->post_id."."; ?>\')==-1) {
	$.cookie("dc_posts_read", "p<?php echo $_ctx->posts->post_id; ?>.", { path: "/", expires: 100000 });
	}
	});
	//-->
	</script>';
	
	return $p;
}

Il suffit de retirer la condition qui vérifie si l'id existe déjà dans le cookie, et le cookie est correctement créé !

if (readposts.indexOf(\'<?php echo "p.".$_ctx->posts->post_id."."; ?>\')==-1) {

Je n'y comprends rien...

Hors ligne

#46 2009-03-18 12:47:23

fix
Membre
Inscription : 2005-01-20
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Pfff... Il faut évidemment lire var readposts=LireCookie("dc_posts_read"); et non pas var readposts=LireCookie("nombredevisites");
, mais ça ne change rien au problème !

Hors ligne

#47 2012-10-03 00:24:55

Floxit
Membre
Lieu : France
Inscription : 2009-01-26
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Bonsoir Fix,

Je constate que tu as pas mal bossé sur la chose, et je jouissais déjà de ton apprentissage et du partage de tes trouvailles sur le forum, jusqu'à la dernière page où la solution ultime ne semble pas avoir été découverte. En allant voir ton blog, il semblerait qu'il soit à l'abandon, est-ce que je me trompe ?

Je voulais savoir si, en fin de compte, tu as réussi à sortir un code capable d'interagir avec les cookies, jquery et dotclear, sans base de données ou fichier texte stocké sur le FTP ?

Sinon, je ne vois qu'une solution : attribuer un ID aléatoire au nouveau visiteur, le stocker dans un cookie, et ensuite stocker les ids des articles lus dans une base de données.

Merci encore, en espérant que tu donneras encore signe de vie... et d'espoir ! ;-)

Hors ligne

#48 2012-10-03 03:30:48

fix
Membre
Inscription : 2005-01-20
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

Je suis toujours vivant. Pour ce qui est d'espérer, surtout n'arrête pas : tant qu'y a de la vie...

Par compte, je n'ai absolument pas le temps en ce moment de me repencher là dessus. J'ai moi-même un ou deux sujets en attente... Pour autant que je me souvienne, j'avais laissé tombé les cookies, je ne te serai donc pas d'une grande utilité.

D'autres sans doute pourront néanmoins t'apporter leur aide ici ?

Bon courage !

Hors ligne

#49 2012-10-03 19:12:22

Floxit
Membre
Lieu : France
Inscription : 2009-01-26
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

...il y a de l'espoir ! :-D

Effectivement, j'ai constaté ton activité après t'avoir répondu, tu es sans doute bénéfique pour la communauté. En tout cas, tu as donné une bonne piste. Je pense personnellement me pencher vers la solution dont je parlais pour utiliser mon système de notification, à la sauce Facebook. ;-)

J'en profiterai donc pour partager le résultat si cela fonctionne, pour ceux qui chercheraient à produire le même résultat.

Hors ligne

#50 2012-10-08 17:15:08

Floxit
Membre
Lieu : France
Inscription : 2009-01-26
Site Web

Re : Widgets plus évolués : créer des états lu/non lu

.... ou pas :-/

Re cher Fix, Amalgame & co qui ont contribué à l'évolution de cette fonctionnalité bien sympa aujourd'hui (si elle marche un jour héhé),

Voilà voilà, avec mon faible niveau en programmation, si mon code semble fonctionner correctement, je suis toujours confronté encore et toujours au même problème : le cache. Manifestement, le problème se trouve toujours au niveau de Dotclear.

Je m'explique : j'ai donc bien réussi à coder dans une seule fonction pour le moment la gestion du cookie. Je crée le cookie s'il n'existe pas, une routine vers la table dc_post_read me sort le dernier id + 1 (on pourrait faire un id de session à la sauce php aussi, mais j'appréciais avoir mes id à la suite). Si le cookie existe, je vérifie si l'id du lecteur a déjà l'id du post enregistré dans la base. Si non, insert(), si oui, update() (au timestamp actuel pour indiquer au lecteur quand il a consulté cet article la dernière fois). J'ai abandonné l'idée des IPs qui causent d'autres soucis, d'autant plus que je ne veux pas forcer mes quelques lecteurs à indiquer un pseudo ou quoi que ce soit. Bref, à ce niveau là, tout se passe bien, le cookie se crée très bien, la base de données se remplit lentement...

Parcontre, pour une raison inconnue, il semble que le script a tourné en rond la nuit car il durait plus de 5 minutes (dans les alertes php de mon hébergeur)... Depuis que j'ai supprimé le fichier _prepend.php manifestement inutile (avec $con et global $core je suppose que je n'avais pas besoin de plus) et sorti le code php entier en return, le problème semble résolu... Bon, c'était peut être tout simplement mon hébergement le fautif car ça m'a l'air de toujours bien ramer vers 6h du mat', allez savoir pourquoi je suis éveillé à cette heure là xD Mais oui, ça mets les nerfs à vif ces choses là, quand on tente de développer le bousin !

Enfin, le désespoir s'est installé car, entre tpl-cache:false; dans mon _public.php ou dans l'admin Dotclear, et mon return $p uniquement (pour sortir que le cookie) ou le return de tout le code (pour éviter la mise en cache selon le tuto Dotclear), il n'y absolument aucun changement. Si on teste avec un timestamp php, on constate avec désarroi que, dès qu'on revient sur des articles déjà consultés, ma fonction tpl n'est plus réinterprétée, seul le résultat semble avoir été mis en cache. Parcontre, en vidant le cache du navigateur, la page est réinterprétée, mais une seule fois, ensuite rebelote.

Pour info, mon tpl se trouve dans le dossier plugin, et je l'appelle ensuite dans post.html. J'ai également essayé user_head.html, mais à part appeler ma fonction à l'extérieur des articles, ça n'a servi à rien.

Quand j'ai développé mon petit compteur de stats Piwik, j'ai constaté dans Clearbrick (ou Dotclear) qu'à partir du moment où un template est mis à jour (date de modification du php), il modifie le header pour prévenir le navigateur de la nécessité de ré-actualiser la page... Et bien oui, effectivement, ça, ça marche très bien, car j'utilise une tâche cron et la commande php touch(_public.php) pour forcer la mise à jour une fois par jour pour mon module de stats. Donc, la seule solution que j'ai trouvé pour l'instant, ce serait de lancer une tâche cron externe à dotclear qui exécute la commande touch(_public.php) de mon template toutes les secondes, mais j'ai juste l'impression de violenter Dotclear. Il existe sûrement une meilleure solution pour exécuter des fonctions de template de manière "dynamique" à chaque chargement de page, non ?...

Si quelqu'un est intéressé, je balance mon code, mais y a pas grande différence à part qu'il select, insert et update avec la base de données, en passant par _ctx, opencursor et $cur... via les articles tutos de gniark, qui datent maintenant de quelques années déjà, mais je n'ai trouvé de réponse que là... Triste de constater que beaucoup de devs dotclear se sont tournés vers Wordpress au final... mais finalement, le cache est mon seul soucis.

Tant qu'il n'y a pas de soluce en tout cas fix, tu peux te faire plaisir avec touch() en php et faire des attouchements périodiques à ton Dotclear. ;-)

Dernière modification par Floxit (2012-10-08 17:29:15)

Hors ligne

Vous n'êtes pas identifié(e).

Pied de page des forums

Sites map