Dotclear

Ticket #1365 (closed defect: fixed)

Opened 11 years ago

Last modified 11 years ago

L'utilisation de behaviors liés aux catégories provoque des problèmes d'ordre

Reported by: zeiram Owned by: sogox
Priority: normal Milestone: 2.5.2
Component: module:core Version: 2.4
Severity: normal Keywords: catégorie, behavior
Cc:

Description

L'utilisation des behaviors adminAfterCategoryCreate et adminAfterCategoryUpdate perturbe l'ordonnancement des catégories.

Cas test :

  • soit un plugin qui utilise le behavior adminAfterCategoryCreate et qui ne fait que resauvegarder la catégorie :
$core->addBehavior('adminAfterCategoryCreate',array('testBugCatOrderAdminBehaviours','coreAfterCategorySave'));

class testBugCatOrderAdminBehaviours
{
	public static function coreAfterCategorySave ($cur,$id=null)
	{
		global $core;
		$core->blog->updCategory($id, $cur);
	}
}
  • soit un blog ayant deux catégories "imbriquées" : "b" est l'enfant de "a" (a / b).
  • l'utilisateur veut ajouter une nouvelle catégorie "c" comme enfant de "a".

Résultat attendu : les catégories "b" et "c" sont sœurs : a / b et a / c. (Note : et c'est bien ce qui se produit sans l'existence du plugin décrit ci-dessus. Le bug n'apparaît que lorsqu'on essaie d'utiliser ces behaviors pour modifier la catégorie qui vient d'être créée.)

Résultat obtenu : "c" devient enfant de "b" : a / b / c.

Le souci est également présent à l'appel du behavior adminAfterCategoryUpdate et si on essaie de réordonner les catégories depuis leur écran propre. Il n'y a plus que deux solution pour réparer la situation : désactiver le plugin et refaire tout l'ordonnancement des catégories ou intervenir directement en base de données.

(Évidemment, le plugin qui m'a fait découvrir ce problème a un but plus intéressant que simplement resauvegarder la catégorie. ;-) )

Change History

comment:1 Changed 11 years ago by franck

J'ai du mal à comprendre pourquoi le bug persiste dans le cas de la modification, par contre pour la création, je pense que ça vient du fait que les champs cat_lft et cat_rgt ne sont pas mis à jour dans le curseur, une fois le nœud créé.

Un contournement possible :

$core->addBehavior('adminAfterCategoryCreate',array('debug','adminAfterCategoryCreate'));

class debug
{
	public static function adminAfterCategoryCreate ($cur,$id=null)
	{
		global $core;

		$cur_local = $core->blog->getCategory($id);
		$cur->cat_lft = $cur_local->cat_lft;
		$cur->cat_rgt = $cur_local->cat_rgt;
		$core->blog->updCategory($id, $cur);
	}
}

Où j'applique la mise à jour des champs idoines après lecture dans la base.

comment:2 Changed 11 years ago by franck

Par contre j'ai du mal à voir où mettre en place un correctif qui permettrait de se passer du contournement.

Si quelqu'un veut regarder…

comment:3 Changed 11 years ago by franck

  • Milestone changed from A definir to 2.5.2

comment:4 Changed 11 years ago by sogox

comment:5 Changed 11 years ago by Evelf

  • Owner changed from xave to Team

comment:6 Changed 11 years ago by franck

  • Owner changed from Team to sogox

comment:7 Changed 11 years ago by franck <carnet.franck.paul@…>

  • Status changed from new to closed
  • Resolution set to fixed

(In [797b03c6a9ef]) Fix category cursor before corresponding behaviour, fixes #1365, thanks sogos/sogox for patch and tests

Note: See TracTickets for help on using tickets.

Sites map