branchons la v2.0 qui est un portage simple pour SPIP 3.0, avant de lancer un chantier dev d'une v3.0

Aucune raison de limiter la recherche à rubriques et articles : on limite à tous les objets éditoriaux déclarés.

On continue l'adaptation à SPIP 3 et ses fonctions génériques d'objets : on affiche le "Également dans les rubriques..." pour tous les objets déclarés.

Obligé de faire une fonction "get_enfants" car l'API générique de SPIP objet_trouver_liens() ne peut pas marcher avec Polyhiérarchie à cause du champ "id_parent" au lieu de "id_rubrique".

On peut donc trouver tous les enfants indirects d'une rubrique, ça retourne des couples avec objet et id_objet.
Ou bien on peut demander un type d'objet précis, et dans ce cas ça ne retourne que la liste des identifiants.

array(
	'article' => array(1, 2, 3),
	'patate' => array(2, 4, 6),
)

Le deuxième argument permet de filtrer pour ne renvoyer qu'un ou plusieurs types d'objets.

On peut dès lors rechercher des rubriques liées comme pour les mots-clés en déclarant pour un objet :
'rubrique' => array('titre' => 5) par exemple

Retour sur r75991 : pour eviter un warning on utilise isset() car array_key_exists provoque un warning si son second argument n'est pas un tableau

bugfix : Le critère {branche} ne prenait pas en compte correctement les jointures décomposées id_objet,objet (code qui n'avait pas suivi celui du core) et échouait sur une boucle (MOTS) (même si c'est un peu tordu)

Utilisons les trucs fournis par SPIP 3, tant qu'à faire. Dans le formulaire générique (utilisé nulle part dans le plugin de base mais utilisé dans "Polyhiérarchie configurable", par exemple), on utilise le sélecteur générique.

find . -name '*' | grep '/lang/'  | xargs sed -i 's#http://www.spip-contrib.net/#http://contrib.spip.net#g'
find . -name '*.xml' | xargs sed -i 's#http://www.spip-contrib.net/#http://contrib.spip.net#g' 

Perf issue : contrintuitivement il est beaucoup plus rapide sur les grosses bases de passer par un sql_all_fetsel + array_map + sql_in que par une sous requete SQL,
meme si cela oblige a raptrier le resultat intermediaire en PHP et a le reinjecter dans la requete fille
+ ajout de 2 index id_objet et objet sur la table spip_rubriques_liens

* les sous requetes dans un IN sont lentes a cause d'un bug de mysql qui les interprete en correlated queries. Consequence, la sous requete est executee pour chaque ligne de la requete principale, ce qui fait exploser le temps de requete totale, de complexite m*n
Reference :
https://dev.mysql.com/doc/refman/5.5/en/correlated-subqueries.html
http://bugs.mysql.com/bug.php?id=9090
* On peut contourner le bug en emballant la sous-requete dans un (SELECT * FROM(...) AS subquery). Elle redevient uncorrelated, executee une seule fois, et on retrouve la perf mysql attendue, meilleure qu'en rapatriant les resultats dans PHP et en les reinjectant dans la requete principale
cf http://stackoverflow.com/questions/6135376/mysql-select-where-field-in-subquery-extremely-slow-why#6157797

Ameliorer le critere branche quand on l'utilise sur une boucle EVENEMENTS dont l'article est en polyhierarchie :
- si on a besoin d'une jointure pour id_rubrique, verifier qu'on en a pas une sous la main qui fait l'affaire
- si on utilise une jointure pour id_rubrique, alors c'est le type/id de l'objet joint qu'il faut checher dans spip_rubriques_liens (ie l'article et pas l'evenement)

Ajout d'un type d'urls arbopoly qui est capable de gerer les urls arborescentes polyhierarchique, c'est a dire plusieurs URLs pour un objet rattache a plusieurs rubriques
Cela ne prend en compte que les rattachements simples, et pas les chemins de rubrique complexes avec rubrique indirectes au milieu d'un chemin
Ajout d'une balise associee #URL_POLYHIER{#ENV{id_rubrique,#ID_RUBRIQUE},article,#ID_ARTICLE} qui fourni l'URL d'un objet contextualisee a une rubrique
Si la rubrique n'est pas une parente de l'objet elle est ignoree
Si on utilise un module d'URL non arbo le id_rubrique est ajoute en query-string de l'URL dans un argument id_rubrique (id_parent si c'est une url rubrique)
Il faut evidemment ensuite que les squelettes soient capable de prendre en compte ce id_rubrique fourni dans le ENV pour afficher le bon fil d'arianne et autres elements de navigation contextuelles)

amelioration de #URL_POLYHIER : on peut lui passer une rubrique de la hierarchie qu'on veut prendre comme contexte d'URL, pas uniquement le parent indirect de l'objet (ie on peut passer le parent du parent indirect, ou le grand parent du parent indirect...)

on extrait la seule reference a spip_rubriques_liens dans une fonction generique surchargeable url_verifier_parent_objet(), ce qui rend le module arbopoly generique, non dependant de la polyhierarchie et de son implementation

- trad.spip est en https maintenant, donc, j'ajoute le"s"

classe editer-groupe sur l'ul du formulaire_editer_licence + double quotes sur les attributs html

Backport de [107571] :  Revert d'une partie de [96181] : non on ne doit pas aller chercher les liens indirects sur une autre table que celle demandé. Cette modif casse complètement de nombreux squelettes qui marchaient bien avant (on vient seulement de le voir et comprendre pourquoi).

Le principe des tables de liens avec objet/id_objet c'est de pouvoir les utiliser sur les objets que l'on veut. Donc ensuite quand on demande les liens de rubrique pour les objets "patates", on VEUT les liens avec "patates", pas avec un autre objet calculé et remplacé en cachette comme ça. Quand on demande "les événements liés en polyhier aux rubriques de la branche 30" on veut bien les événements qui y sont liés, pas les événements des articles de cette branche ce qui n'a rien à voir.

Si des gens ont besoin d'une fonctionnalité différente en cherchant les articles parents liés, c'est autre chose, et il faudrait un autre critère ou bien un paramètre explicite supplémentaire à ce critère. Mais le fonctionnement normal, cohérent, toujours sur l'objet demandé, doit rester le même.

Backport de [107574] : Amélioration de [107572] : comme proposé par cerdic, quand on trouve une jointure ET qu'on détecte que l'objet peut être classé avec polyhier, alors on cherche les deux liaisons avec un OR. Sinon c'est que l'un ou que l'autre.

Juste un peu de nettoyage pour y voir plus clair et comparer avec le trunk + quand même un  qui n'était pas défini avant d'être rempli.

oups la coquille repérée par David, dans la branche 2, c'est pas comme en trunk avec un $in_rub calculé en avance dans le "hash", mais un $b gardé directement dans le sql_in() qui précède.

Grosse optimisation de la fonction generer_url_polyhier_entite qui parcourait les memes branches encore et encore a chaque appel, d'autant plus qu'un oubli dans r100658 avait fait sauter le test sur id_rubrique non nul, et du coup on parcourait les rubriques depuis la racine a n'en plus finir

Evite un warning PHP + permet de gerer correctement singulier/pluriel