Je suis en train d'écrire un petit plugin custom destiné à gérer un annuaire d'entreprises.
Jusque la, rien de transcendant: j'ai créé une nouvelle table, déclaré une boucle ad hoc etc.
Mon problème est que j'aimerais bénéficier des fonctions de réécriture d'url de spip pour ces objets entreprises.
J'ai eu beau fureter sur le net, je n'ai pas trouvé d'infos sur la manière dont on pouvait interragir avec le système de réécriture ...
A titre de test, j'ai inséré manuellement en base dans la table spip_urls une ligne correspondant à une entreprise, mais spip l'ignore purement et simplement...
Si l'un d'entre vous à quelques billes sur le sujet ( liens, plugins ayant réussi à faire cette manip ou autres) , je suis preneur car la, je sèche complètement !
Je vais aller potasser le tout: c'est toujours bon de voir le code des autres, on trouve souvent des choses à apprendre !
Si ça t'intéresse, je peux aussi mettre mon code à dispo. Ca te permettra de récupérer la partie création des tables si tu le souhaites.
C'est pas super abouti et j'ai quelques incohérences mais dans les grandes lignes, ça marche.
Je vais aller potasser le tout: c'est toujours bon de voir le code des autres, on trouve souvent des choses à apprendre !
Si ça t'intéresse, je peux aussi mettre mon code à dispo. Ca te permettra de récupérer la partie création des tables si tu le souhaites.
C'est pas super abouti et j'ai quelques incohérences mais dans les grandes lignes, ça marche.
Volontier, quand tu auras réussi, pour le côté pédagogique.
As tu vu aussi qu'il y a un squelette de gestion d'annuaire
sur spip-contrib ?
JLuc
J'ai pas mal potassé programmer.spip.org de même que le code de spip concernant la génération des URL mais je n'ai pas trouvé grand chose de probant jusqu'a présent. Dans le code générant les url propres par exemple, il n'est pas fait référence au type d'objets (sauf cas particuliers dus aux anciens jeux d'url ). Du coup il semblerait que spip soit nativement capable de gérer des objets "non spip".
Le fait que ma bidouille ne fonctionne pas peut indiquer la nécessité de les déclarer "quelque part".
J'avoue que le troisième point que tu as indiqué m'est par contre complètement inconnu. Je vais donc aller gratouiller de ce coté !
actus5.html sera transformé en spip.php?page=actualites&id_syndic=5
Puis dans actualites.html, une boucle sur la table de ton choix.
Si j'ai une table nommée suiv_etablissements avec les champs id_etablissement et etab_raison_sociale,
on peut écrire :
Héhé, oui pour le coup du htacces, mais non en fait
Mon but est justement de me débarrasser de la dépendance au champ "id_objet", et d'avoir une url parlante ( référencement oblige ).
Sinon, j'aurais adopté cette méthode et je ne me serais pas creusé la tête plus loin.
Mon but ici est que tout comme j'ai un article.html comme squelette par défaut pour les articles, j'aie un entreprise.html pour mes entreprises.
Pour cela il faut cependant que spip reconnaisse les url du type "entreprise" situées dans la table spip_url, ce qui n'est pour le moment pas le cas pour moi.
Actuellement, je n'ai ni champ titre, ni champ texte, qui semblent être utilisés pour générer les url à la volée.
Dans la mesure ou j'ai fait un test en insérant à la main mes url à réécrire, cela ne devrait pas avoir d'incidence, mais je vais tout de même tenter de modifier mes objets entreprise pour qu'ils en contiennent.
Héhé, oui pour le coup du htacces, mais non en fait
Mon but est justement de me débarrasser de la dépendance au champ "id_objet", et d'avoir une url parlante ( référencement oblige ).
Sinon, j'aurais adopté cette méthode et je ne me serais pas creusé la tête plus loin.
Pourquoi l'url parlante implique-t-elle (ou empêche-t-elle) la dépendance à l'id_objet.
titre-complet permet le référencement, art5 permet d'atteindre l'id_objet.
Un intérêt pour moi est que si je dois changer un peu le titre de l'article, je garde le référencement puisque toto-art5.html fonctionne aussi.
Mon but ici est que tout comme j'ai un article.html comme squelette par défaut pour les articles, j'aie un entreprise.html pour mes entreprises.
C'est ce que je fais pour les actualites et autres :
titre-de-l-actu-actu18.html
Pour cela il faut cependant que spip reconnaisse les url du type "entreprise" situées dans la table spip_url, ce qui n'est pour le moment pas le cas pour moi.
L'intérêt de mes urls est que je ne passe pas par la base de données pour retrouver l'id_objet : il est dans l'url, elle-même avec le titre en clair.
Et dans le squelette actualite.html, je choisis la table que je veux.
titre-complet permet le référencement, art5 permet d'atteindre l'id_objet.
Un intérêt pour moi est que si je dois changer un peu le titre de l'article, je garde le référencement puisque toto-art5.html fonctionne aussi.
Mon but ici est que tout comme j'ai un article.html comme squelette par défaut pour les articles, j'aie un entreprise.html pour mes entreprises.
C'est ce que je fais pour les actualites et autres :
titre-de-l-actu-actu18.html
Pour cela il faut cependant que spip reconnaisse les url du type "entreprise" situées dans la table spip_url, ce qui n'est pour le moment pas le cas pour moi.
L'intérêt de mes urls est que je ne passe pas par la base de données pour retrouver l'id_objet : il est dans l'url, elle-même avec le titre en clair.
Et dans le squelette actualite.html, je choisis la table que je veux.
En fait c'est un cas assez tordu qui m'occupe: j'ai un système d'import permettant de me synchroniser via l'upload d'un fichier CSV sur une autre base de données.
Le souci est que je n'ai aps d'id numérique dans cette base et que j'en ai un sur spip. Par conséquent, je purge la base spip à chaque fois, et je recréé mes objets.
Les id sont flottants du coup ...
Ceci dit, ce n'est qu'une partie du problème dans la mesure ou les url sont associées à un id d'objet, j'ai encore des soucis à résoudre avec mon usine à gaz ^^
Le fond du problème pour être honnête est que spip fait des réécritures à sa sauce, et que j'aimerais réellement arriver à les employer en natif pour pouvoir bénéficier
de manière transparente ( sans toucher au htaccess de base ) des différents jeux d'url. J'ai déja utilisé ponctuellement des modifications du hataccess pour faire remonter des objets particuliers dans d'autres bidouilles.
Là, mon idée est d'aller un cran plus loin ( si j'y arrive !! ). Sinon, il est probable que je me rabattrai sur cette méthode.
Pourquoi l'url parlante implique-t-elle (ou empêche-t-elle) la dépendance à l'id_objet.
En soi, elle ne l'empêche pas. Ceci dit, supprimer toute trace d'id numérique est toujours un plus.
Ah bon ? En quoi ?
En fait c'est un cas assez tordu qui m'occupe: j'ai un système d'import permettant de me synchroniser via l'upload d'un fichier CSV sur une autre base de données.
Le souci est que je n'ai aps d'id numérique dans cette base et que j'en ai un sur spip. Par conséquent, je purge la base spip à chaque fois, et je recréé mes objets.
Les id sont flottants du coup ...
Ah ben là, on découvre la vraie forme du cahier des charges.
Peut-être faudrait-il annoncer l'origine du CSV et l'on trouverait une solution globale moins tordue ?
Le fond du problème pour être honnête est que spip fait des réécritures à sa sauce, et que j'aimerais réellement arriver à les employer en natif pour pouvoir bénéficier
de manière transparente ( sans toucher au htaccess de base ) des différents jeux d'url. J'ai déja utilisé ponctuellement des modifications du hataccess pour faire remonter des objets particuliers dans d'autres bidouilles.
Là, mon idée est d'aller un cran plus loin ( si j'y arrive !! ). Sinon, il est probable que je me rabattrai sur cette méthode.
Humm... la modif du .htaccess est LE meilleur compromis facilté*performance.
En fait c'est un cas assez tordu qui m'occupe: j'ai un système d'import permettant de me synchroniser via l'upload d'un fichier CSV sur une autre base de données.
Le souci est que je n'ai aps d'id numérique dans cette base et que j'en ai un sur spip. Par conséquent, je purge la base spip à chaque fois, et je recréé mes objets.
Les id sont flottants du coup ...
Ah ben là, on découvre la vraie forme du cahier des charges.
Peut-être faudrait-il annoncer l'origine du CSV et l'on trouverait une solution globale moins tordue ?
Dans ce cas précis, il s'agit d'un export plan tiré d'une base access. Il y a probablement moyen de négocier aussi pour que cette base soit modifiée et contienne à l'avenie des id numériques uniques pouvant me servir de base lors des mises à jour. Ceci dit, comme je le sous-entendais, c'est aussi de la curiosité qui me pousse plus qu'une recherche d'efficience.
Le fond du problème pour être honnête est que spip fait des réécritures à sa sauce, et que j'aimerais réellement arriver à les employer en natif pour pouvoir bénéficier
de manière transparente ( sans toucher au htaccess de base ) des différents jeux d'url. J'ai déja utilisé ponctuellement des modifications du hataccess pour faire remonter des objets particuliers dans d'autres bidouilles.
Là, mon idée est d'aller un cran plus loin ( si j'y arrive !! ). Sinon, il est probable que je me rabattrai sur cette méthode.
Humm... la modif du .htaccess est LE meilleur compromis facilté*performance.
Dans la grande majorité des cas, je suis bien d'accord. Ceci dit, j'aimerais avoir les deux approches à ma disposition ... Mais ça n'a pas l'air gagné .
Dans la grande majorité des cas, je suis bien d'accord. Ceci dit, j'aimerais avoir les deux approches à ma disposition ... Mais ça n'a pas l'air gagné .
Pour faire simple, il te faut :
- ton propre systeme d'url propres pour générer tes urls, qui devront avoir un marqueur specifique (sinon, l'url passera pour une url article) et une fonction generer_url_xxx_dist
- modifier le .htaccess pour recupérer ton url propre et la passer en variable d'environnement (comme pour les autres objets en bas du .htaccess)
- modifier /urls/standard.php pour que ton squelette gere les urls propres (qui ne sont gérées que pour article, breve...)
et normalement ca devrait rouler...
@++
PS : maintenant, c'est quand meme beaucoup plus simple de faire des url du genre nom-de-mon-objet__12.html et ca ne perturbe en rien le referencement.
Tu peux aussi tres simplement (puisque tu as un champ url) passer url=$1 dans ton .htaccess et dans ton squelette t'appuyer la dessus plutot que sur l'id (<BOUCLE_xxx(XXX){url}> au lieu de <BOUCLE_xxx(XXX){id_xxx}> )
=> la, pas besoin de stocker l'url propre en base, le .htaccess et la fonction generer_url_xxx suffisent
Après avoir un peu bricolé, je me suis aperçu que le spip sur lequel je développais mon plugin avait un comportement bizarre au niveau de la gestion de la réécriture d'url.
En repartant sur une install fraiche, les choses se passent NETTEMENT mieux, et j'y perds un peu moins mon (absence de ) latin.
Bilan : spip, c'est magique ! Je n'en doutais pas à l'origine, mais je suis tout les jours un peu plus conquis/surpris.
Pour faire simple donc: avec une install qui ne part pas en vrille, spip prend directement en compte le contenu de la table spip_url.
Si pour un objet entreprises on envoie en base une ligne du type :
mysql> insert into spip_urls values(essai,entreprise,100,NOW());
la page "www.monsite.dom/essai" affichera bien la page entreprise.html avec comme paramètre id_entreprise=100.
En soi c'est déjà super ... Mais la ou je n'en peux réellement plus, c'est en regardant le comportement du fichier "ecrire/balise/url_.php".
C'est vraisemblablement un générique pour toutes les balises #URL_OBJET. Du coup, tant que les nouveaux objets comportent un titre,
la balise génèrera une belle url arbo . J'ai encore un souci sur les url libres, mais grosso modo, je suis sur la bonne voie
( je suspecte la recherche d'une date dans le select pour créer la requête ).
Un grand merci donc pour toutes les infos et réflexions: je suis enfin débloqué !
