Comme j'utilise le même système d'URLs, je m'intéresse à la solution !
Mais je pense que les URLs de spip.net n'ont pas été mis avec le squelette dans trac ?
Je confirme. Et il y a un bug supplémentaire sur spip.net, une fois
qu'on clique sur "Prévisualisation" :
<BOUCLE_archives_rub>()
Erreur SQL
L1.id_rubrique FROM spip_mots_rubriques AS `L1` WHERE (L1.id_mot = 9)
AND (id_secteur NOT IN (324))
Unknown column 'id_secteur' in 'where clause'
</BOUCLE_archives_rub>
Ce n’est pas un bug du compilateur, c’est dans le mes_fonctions spécifique de spipnet qu’on fait ce truc faux:
// hack pour ne jamais afficher les secteurs d’aide en ligne
// sauf evidemment dans le cas de l’aide en ligne, ou dans l’espace prive
define(‘secteurs_aide’, ‘324’);
if (!defined(‘aide_en_ligne’)
AND !_DIR_RACINE) {
function boucle_ARTICLES($id_boucle, &$boucles) {
$boucles[$id_boucle]->where[] = array("‘NOT IN’", “‘id_secteur’”, ‘"(’.secteurs_aide.’)"’);
return boucle_ARTICLES_dist($id_boucle, $boucles);
}
idem pour RUBRIQUES etc.
Le pb est que l’optimiseur voit passer “FROM spip_rubriques LEFT JOIN spip_mots_rubrique” et regarde si spip_rubriques est vraiment utile.
Dans le mode non preview, la réponse est oui car il y a “rubriques.statut=‘publie’” dans la clause Where.
Dans le mode preview, statut n’est pas là, et id_secteur n’est pas préfixé par “rubriques.” d’où erreur.
<BOUCLE_article_principal>()
Erreur SQL
articles.id_trad, articles.id_article, articles.lang, articles.titre,
articles.texte, articles.chapo, articles.descriptif,
articles.id_rubrique, articles.id_secteur, articles.surtitre,
articles.soustitre, articles.date, articles.date_modif, articles.ps
FROM spip_articles AS `articles` WHERE (articles.statut IN
('publie','prop')) AND (articles.id_article = 3796) AND
(rubriques.id_secteur NOT IN (324))
Unknown table 'rubriques' in where clause
</BOUCLE_article_principal>