Ce petit plugin permet de suggérer les tags déjà utilisés en fonction de la saisie (adaptation de la bibliothèque jquery).
Version originale sur http:/
Version modifiée (avec les 2 patchs de l'auteur, plus le mien) ici même ;)
Sur la modif pour exclure les "subtypes" qui ne sont pas des tags :
à vrai dire, je me demande s'il ne vaudrait pas mieux une liste des subtypes autorisés.. la liste risque d'être rapidement assez longue, et il faut contrôler les nouveaux sous-types d' "object" pour chaque nouveau plugin.
Je viens de le mettre, c'est encore un grand désordre :) définitivement, il faut des subtypes autorisés ....
Fabrice Collette Il y a 491 jours
La nouvelle version fonctionne en sélectionnant les "bons" subtypes plutôt qu'en éliminant les "mauvais".
Après quelques essais, je n'ai gardé que $proper_subtypes = array('file', 'page-top', 'page', 'blog'); sur la liste complète : // Subtypes : file, plugin, widget, moddefaultwidgets, groupforumtopic, page_top, page, messages, poll, front, bookmarks, blog, pages_welcome, siteaccess_email, searchstats, event_calendar, thewire
Je n'ai pas trouvé le pb de site_guid..
..dans index.php le test utilisé est bien :
//If we have site_guid
if ($site_guid < 0) {
$site_guid = $CONFIG->site_id;
}
Dernier détail : les tags ne sont récupérés que sur les entités de type "object", mais cela peut être paramétré au besoin sur "user" et "site"
Facyla Il y a 491 jours
Je vais l'essayer
pour le site guid la bonne version serait
//If we have site_guid
if ($site_guid == 0) {
$site_guid = $CONFIG->site_id;
}
la logique "elgg etant :
site guid == 0 -> le site courant
site_guid == nn le site nn
site guid <0 -> tous les sites
C'est très précieux dans un contexte multisite de pouvoir s'appuyer sur cette logique "unifiée"
Fabrice
Fabrice Collette Il y a 491 jours
ok je saisis mieux la question ; en fait, dans ce script, le site_guid est défini manuellement comme paramètre au début, et non récupéré depuis la config. Donc, si j'ai bien compris, la variable étant définie à -1 initialement, on va systématiquement récupérer le guid du site courant (donc soit 0, soit +), qui est utilisé ensuite pour filtrer les résultats seulement pour ce site (l.98 de cette version).
On peut donc modifier site_guid pour récupérer les tags d'un site particulier, qui ne soit pas le site actuel, par ex. pour utiliser les mêmes tags qu'un site "principal" qui ne soit pas le site courant..
Pour résumer, si je ne m'abuse, dans un contexte multisite, ça devrait donner quelque chose comme :
Facyla Il y a 491 jours
pas tout a fait, la logique est :
Toutes les apis elgg sont basées sur ce principe
d'ou l'erreur dans le plugin qui prend la valeur de $config quand la variable est <0, alors qu'il devrait le faire uniquyement quand la variable = 0
Fabrice Collette Il y a 491 jours
Ok !! je crois que cette fois c'est bon ;)
Dans ce cas, il faudrait aussi modifier (l.98) :
if ($site_guid > 0) {
en
if ($site_guid > -1) {
pour que la valeur "0" permette un filtrage sur le site actuel (sinon 0 et -1 provoquent le même comportement) ...
Facyla Il y a 491 jours
pas obligé, parce que au moment de ce test le site_guid n'est jamais = 0. Si le site_guid était = 0 au depart, il a été transformé en site_guid du site courant en cours de route.
par le
//If we have site_guid
if ($site_guid == 0) {
$site_guid = $CONFIG->site_id;
}
Fabrice Collette Il y a 490 jours
Fabrice Collette
Profil
Contacts
Contacts de
Annonce
Pages
Fichiers
Blog
Poll
Discussions
Je vais l'installer ici, mais je suis d'accord avec toi, il vaudrait surement mieux une liste de subtype autorisés, en prenant les contenus "majeurs" : profil, blog, files, etc ...)
Un autre pb du plugin est ici
//If we have site_guid
if ($site_guid site_id;
}
La cohérence avec l'architecture générale de Elgg voudrait que l'on ait :
//If we have site_guid
if ($site_guid == 0) {
$site_guid = $CONFIG->site_id;
}
(d'ailleurs le get_tags a ce pb, je vais en faire un trac)
Je vais le modifier en ce sens, sinon il sera inutilisable dans un contexte de multisite
Fabrice Collette Il y a 491 jours