Utilité
Lorsque l’on crée les squelettes d’un site, il arrive que l’on ait des squelettes ne se rapportant à aucun objet éditorial : « galerie.html », « contact.html », « plan.html » etc.
SPIP permet nativement de définir des urls personnalisées pour les pages se rapportant aux objets éditoriaux (articles, rubriques etc.), ce qui exclut ces types de squelettes.
Pour accéder à ces page, on dispose d’une balise #URL_PAGE, qui produit par défaut une url du type monsite.com/spip.php?page=toto.
Voyons comment utiliser le plugin pour personnaliser ces urls.
Utilisation
Avant tout, le fichier fichier .htaccess doit être correctement installé à la racine du site.
Rendez-vous sur la page de configuration du plugin ?exec=configurer_urls_pages ou dans le menu de configuration « Configurez les URLs ».
1. Renseigner les urls personnalisées
Le plugin répertorie tous les squelettes « actifs » identifiés comme étant des pages. Sont donc exclus de la liste les squelettes des objets éditoriaux (article.html, article-10.html etc.), les noisettes (inc-xxx.html) et les squelettes « techniques » (404.html, sommaire.html etc.).
La recherche est effectuée à la racine des dossiers de squelettes et des plugins actifs de catégorie « squelette ».
Si Zpip ou Zcore est actif, c’est dans les sous-répertoires « content » et « contenu ».
Pour chaque page, vous pouvez donc définir une url personnalisée. Une vérification des doublons est effectuée, en revanche la validité de la chaîne rentrée est de votre ressort (attention aux caractères accentués et consorts).
Après enregistrement des paramètres, la balise #URL_PAGE pointera vers les nouvelles urls pour chaque page concernée.
2. Vérifier RewriteBase
Si nécessaire renseignez le champ « RewriteBase » tel qu’il est défini dans .htaccess. RewriteBase indique le chemin relatif du site sur le serveur si celui-ci est installé dans un sous-répertoire. Il est nécessaire pour le calcul des urls personnalisées par la balise #URL_PAGE.
3. Modifier le fichier .htaccess
Pour rendre effectives ces nouvelles urls, il ne reste plus qu’à mettre en place la redirection dans le fichier .htaccess : copiez-y le code indiqué en fin de formulaire (la section « réglages personnalisés » est toute indiquée).
Evolution
Toutes les contributions sont les bienvenues, il s’agit d’un premier jet et de nombreuses améliorations sont possibles.
Discussions par date d’activité
21 discussions
Bonjour,
J’utilise ce plugin depuis longtemps et je suis en train de migrer en spip 4.2 (php 8.1).
Aucun soucis pour activer le plugin (dernière version 1.1)
Mais, on perd les liens de prévisualisation : plus de var_mode=preview dans l’url générée suite à une redirection depuis
#VAL{redirect}|generer_url_action{Hello,
Pour SPIP 4+ une v2 est en développement, elle devrait sortir bientôt.
Elle devrait continuer à fonctionner tel quel, avec quelques améliorations mais non visibles.
Il y a aussi un chantier pour ce qui sera probablement une v3, qui aura des améliorations bien visibles, elle.
Répondre à ce message
Bonjour,
J’aimerais associer une url propre a un squelette en spip 4.
Est-ce que ce plugin pourrait encore marcher ? Ou y-a-t-il une nouvelle fonctionalité
de spip 4 qui permet celà ?
Merci !
Bonjour,
En théorie le plugin devrait toujours fonctionner tel quel en SPIP 4 en forçant son activation avec _DEV_VERSION_SPIP_COMPAT (je n’ai pas testé).
Mais le vrai portage en bonne et due forme pour SPIP 4 reste à faire.
C’est prévu dès que j’aurais du temps.
Ok, Tcharlss,
Je peux donc avancer.
Merci !
Répondre à ce message
Bonjour,
Le lien vers https://www.openstudio.fr/Pages-personnalisees-et-reecriture.html est brisé.
Répondre à ce message
Salut,
j’utilise un plugin boiler plate basé sur ZCore avec un dossier de squelettes qui est
mainau lieu ducontentpar défaut donc les fonds de pages ne sont pas détectés.J’ai tenté de surcharger la constante
_DIR_PLUGIN_ZCOREdansmes_options.phpqui semble être la solution mais sans succès :et
Je rate quelque chose ?
Sur suis en SPIP 4.0.5 GIT [4.0 : 4c6577cb]
Hello,
Ah tiens nous aussi on s’est mis à utiliser « main » comme dossier principal avec RastaPopoulos.
Donc là il y a en effet un manque dans le plugin, ça prend le dossier « content » en dur au lieu d’aller chercher le dossier déclaré via la globale (c’est du vieux code hein :p) : https://git.spip.net/spip-contrib-extensions/urls_pages/src/branch/master/inc/fonds_pages_to_array.php#L102-L103
Je vais corriger pour Spip 3.2.
Pour info dans la prochaine version pour Spip 4, je me tâte pour abandonner la détection automatique des fonds de page. C’est un besoin communs à plusieurs plugins donc ça devrait être déporté dans un sous-plugin idéalement.
Merci pour ton retour.
Pour info, ça bloque dans la détection auto mais aussi dans l’ajout manuel (cf capture jointe).
Par contre, en ajoutant
define('_DIR_PLUGIN_ZCORE','main');dansmes_options.php, j’ai une erreur de squelette :Mais c’est du côté de ZCore pour le coup, faut que je vois d’où ça provient...
PS : Je vous ai copié pour le main :) ça parait plus logique effectivement.
Ah mais le plugin n’est pas officiellement compatible spip 4 par contre, la borne a été changée trop vite dans paquet.xml (pas par moi #dénonciation).
Nonobstant le bug avec zcore, la détection des fonds de page ne fonctionne plus correctement car ça repose sur des informations qui ont été retirées de SVP en spip 4.
Et donc ça empêche d’enregistrer les urls, visiblement.
Pour info la roadmap pour une version vraiment compatible spip 4 : https://git.spip.net/spip-contrib-extensions/urls_pages/issues/3
Sinon je ne sais pas ce que tu essaies de faire avec
define('_DIR_PLUGIN_ZCORE','main'), il ne faut surtout pas changer cette constante !Les blocs se déclarent via globale
$GLOBALS['z_blocs'], avec le bloc principal en premier (cf. ce que fait Integraal par exemple).Je note pour la roadmap :)
Répondre à ce message
Bonjour à tous,
savez vous si une version pour Spip 4 est dans les tiroirs et sinon, quelle procédure à écrire, même page par page dans le Htaccess ?
c’est vraiment un plus et ce serait des grands merci, Cordialement, Alain
Hello,
En principe le plugin devrait fonctionner tel quel avec Spip 4, ou alors avec des ajustements mineurs.
Il faut juste que je teste bien tout ça avant d’incrémenter la compat.
Avec des guillemets à « juste » quand même.
J’en profiterai pour mettre à jour la doc pour la v1, l’UX ayant bien évolué.
Bonjour,
quelle bonne nouvelle, je ne savais pas si quelqu’un était encore derrière ce travail.
J’espère que ce ne sera pas trop long...
Bon courage et encore merci, Alain
Bonjour,
excellente nouvelle et merci pour le travail.
Un peu impatient mais c’est normal, j’ai quelques pages qui ne sont plus accessibles ...
Cordialement Alain
Bonjour
Effectivement, URLs Pages Personnalisées 1.0.12 fonctionne avec Spip 4.0.4.
Mais, ce qui est curieux, c’est que, sur un site en Spip 3.2.13, le paquet.xml de la version 1.0.12 affiche «
compatibilite="[3.1.0;3.2.*]"» sans signaler de version plus récente alors que dans le code actuel de la même version du plugin (https://git.spip.net/spip-contrib-extensions/urls_pages.git), c’est «compatibilite="[3.1.0;4.0.*]"».De fait, mon Spip 3.2.13 ne propose pas de mise à jour, et son passage à Spip 4.0.4 rendra le plugin incompatible.
@+
Luc
C’est parce que la pose du numéero v1.0.12 a été faite avant qu’on ait vérifié la compat spip 4.
La v1.0.13 sera prochaienement dispo.
Heu, alors moi j’avais pas du tout prévu de releaser une version spip 4, c’est pas encore prêt.
Depuis le dernier commentaire j’ai testé plus en profondeur, en l’état il reste quelques bugs, et d’autre part je voulais en profiter pour faire quelques évolutions / mise au propre : https://git.spip.net/spip-contrib-extensions/urls_pages/issues/3
Donc ça prend un peu de temps, c’est comme ça, mais c’est pas prêt à releaser pour l’instant, merci d’enlever le tag maieul.
edit : pour spip 4 ça sera une v2
Répondre à ce message
Bonjour,
Je déterre un peu ce plugin, du moins son fil ....
Est-t-il toujours maintenu ?
Dans tous les cas, un problème de dépendance est survenu depuis une mise à jour en SPIP 3.2.5
Dans url/propres.php : il manque
Répondre à ce message
Salut,
merci pour ce plugin que je viens de mettre en place, ça fonctionne nickel !
J’ai lu dans les commentaires que depuis la branche 1, plus besoin modifier le fichier .htaccess, les adresse propres sont directement accessibles depuis #URL_PAGE.
Du coup, j’ai une question : les url type ?page=toto restent accessibles malgré le plugin et, sans redirection htaccess, elles risquent d’être indexées et représenteraient un duplicate content dommageable pour ces pages.
N’est pas un problème ? Ne vaudrait-il pas mieux conserver la redirection htaccess ?
jean marie
Salut,
Je ne suis pas expert sur le sujet, mais les quelques articles que j’ai consultés indiquent qu’il suffit d’indiquer l’URL canonique, et les moteurs de recherche n’indexeront que cette URL en cas de pages identiques (et donc pas de pénalité) :
<link rel="canonical" href="#URL_PAGE{toto}" />Du coup inutile de conserver la redirection htaccess.
D’ailleurs c’est aussi le cas pour les objets éditoriaux : ceux ayant une URL personnalisée restent accessibles avec l’URL traditionnelle
spip.php?page=patate&id_patate=NEffectivement, avec ça, ça devrait rouler.
Merci encore pour tes retours...
Répondre à ce message
Salut,
petit retour d’expérience : les paramètres passés aux pages ayant des URLs personnalisées ne sont pas pris en compte chez moi.
Par ex : www.mondomaine.net/monurlperso.html fonctionne mais www.mondomaine.net/monurlperso.html?param=toto m’affiche la page d’accueil
Pour info, je suis en SPIP 3.1.4 avec la V1.0.9 du plugin.
merci
Salut,
J’ai testé avec la même URL et « chezmoiçamarche™©® » :
#ENV{param}→ toto.Alors par contre, que les query strings ne soient pas prises en compte, c’est une chose, mais que ça occasionne une redirection sur la page d’accueil ça c’est vraiment bizarre.
Une 404 à la rigueur je comprendrais, mais la page d’accueil je pige pas. Aurais-tu laissé les redirections htaccess ? Si oui, tu peux réessayer sans ?
Salut tcharlss,
merci pour ton retour.
Je viens de tester sur SPIP 3.2.0-beta3 [23599] avec fichier .htaccess neuf et j’ai le même comportement (?tutu=toto m’affiche l’accueil).
Ça dépend peut être de la config de l’hébergement ? Je suis sur un mutu OVH...
Quand tu dis
#ENV{param}, tu mets ça où ?jeanmarie
#ENV{param}je le mets dans le squelette qui correspond à l’URL personnalisée.On m’avait signalé le problème auparavant et ça avait été corrigé dans la v1.0.1 : https://zone.spip.org/trac/spip-zone/changeset/99810/_plugins_/urls_pages/trunk
Tu aurais la vraie URL où ça se produit pour voir ça d’un peu plus près ?
C’est un site de test : http://test.cousumain.info/testfest.html et http://test.cousumain.info/testfest.html?toto=titi
Alors que http://test.cousumain.info/?page=testfest&toto=titi est ok...
(le squelette testfest.html ne contient que les qqs caractères qui s’affichent)
OK, merci pour les URLs.
En fait il n’y a pas de redirection, c’est le mauvais fond de page qui est récupéré.
Je ne vois pas comment reproduire le souci chez moi, à la rigueur si tu pouvais m’ouvrir un accès FTP au dossier du plugin, je pourrais faire un rapide coup de debug. Tu peux me contacter par email, sinon en mp sur IRC / #spip
Je t’ai envoyé un mail :)
Hop c’est corrigé dans la v1.0.10 (et c’est bon sur ton site tout de suite, là du coup)
Super, ça fonctionne nickel...
Merci pour l’efficacité du SAD :)
Répondre à ce message
Je suis en SPIP 3.22 avec zspip et j’ai donc des squelettes dans /squelettes/contenu.
C’est étrange car certains squelettes sont bien listés sur la page de configuration du plugin (exemple page-resume-event) mais pas d’autres (exemple page-groupes_mots).
Et évidemment c’est cette dernière qui manque qui m’intéresse le plus.
dd
Hello,
Merci pour le retour, je subodore que comme c’est proche de « groupes_mot », la fonction de détection des pages la considère à tord comme une page d’un objet éditorial.
Je regarde ça de plus près.
À noter que dans les prochaines versions, on va enlever cette détection automatique au profit d’une saisie manuelle je pense, ce qui évitera ces désagréments.
Hello,
Il est indiqué que :
Si Zpip ou Zcore est actif, c’est dans les sous-répertoires « content » et « contenu ».
Mais pour moi cela ne fonctionne pour aucun des fonds de page listés dans ?exec=controler_urls_pages&onglet=fonds pour les squelettes du dossier contenu/
exemple : /squelettes/contenu/page-recherche_carto
"Attribuer une URL" retourne "erreur fond absent page"
et lorsque je veux l’ajouter manuellement j’ai "Aucun squelette ne correspond à cette page !"
Bref je dois mal m’y prendre ou bien il y a une incompatibilité quelque part.
Hello,
Ce n’est pas encore prêt pour zpip effectivement.
OK
Alors je reviendrai voir plus tard !
En principe, avec la version 1.0.3, ça devrait passer avec Zpip.
Je viens de m’y remettre.. ça fonctionne merci.
J’ai une p’tite question
J’ai transformé l’URL spip.php ?page=groupes_mots&id_groupe=12
en /activites
et donc cela me donne activites ?id_groupe=12 pour le groupe 12
Il n’est pas possible d’avoir une URL plus sympa comme /activites12
Ou bien alors il faut jouer avec l’URL rewriting dans le htaccess ?
dd
Répondre à ce message
Bonjour,
Merci pour ce plugin fort utile :-)
Il me semble avoir détecté une erreur dans la doc, la page de paramétrage est « exec=controler_urls_pages » et non pas « ?exec=configurer_urls_pages » et elle est accessible depuis « Publication -> Gestion des URLs » et non pas de puis « Configuration -> Configurer les URL » qui est la page d’activation générale de la ré-écriture. Et il n’est plus utile d’après ce que je lis de modifier le htaccess.
Mais ma question principale :
j’essaye de rendre jolies les urls de la recherche pour un site basé sur cet outil à tous les niveaux.
Le plugin fait bien le boulot pour remplacer /spip.php ?page=recherche&recherche=toto par /trouve ?recherche=toto mais je me demandais s’il y aurait une solution pour arriver à un truc du genre /trouve/toto (sachant que toto peut être aussi bien un mot-clé au sens spip qu’une recherche fulltext (mais ça je gère ailleurs) ?
Merci !
Bonjour,
Oui c’est vrai pour les 2 premières remarques, la branche 1 a changé pas mal de choses et un nouvel article doit être publié.
Par contre je confirme qu’il n’est pas possible d’utiliser des URLs au format « arborescent », mais uniquement au format « propre ».
Ps . bizarre, je n’avais pas reçu la notification pour ton message.
Ok merci pour la réponse !
Répondre à ce message
Hello,
sur un SPIP 3.1.3 [23214] et un plugin fraichement installé : « URLs Pages Personnalisées » (version : 1.0.7)
Si je clique sur le lien proposé par le plugin j’ai => Accès interdit
Vous n’avez pas le droit d’accéder à la page controler_urls_pages.
et si je me rends sur les onglets je ne vois pas celui de configuration.
Aucun bug à part que rien ne se passe :-p
Me demande si c’est pas un problème de droits ? ...
Amitié
Paulbe
Comme ça, je dirais que la « gestion avancée des URLs » n’est pas activée, dans « Configuration → Configurer les URLs ».
Si c’est bien ça le problème, il faudra que je le rajoute dans la phrase d’explication (et tant qu’à faire, écrire la doc pour cette nouvelle version du plugin.)
Oups en effet, désolé pour le bruit ... je continue ma découverte du plugin.
Merci pour le boulot en tout cas !
Amitié
Paulbe
Si j’ai bien compris cette version du plugin permet de ne pas devoir modifier le htaccess ?
Si oui je constate un truc... mes url de site sont configurées avec .html à la fin, si je mets le lien par exemple
|video|touteslesvideos|../squelettes/video.html|
J’ai maintenant une page avec touteslesvideos mais sans .html à la fin ce qui n’est pas logique avec mes autres URL, j’ai donc tenté avec touteslesvideos.html mais il me crée alors touteslesvideos-html mais toujours sans le .html à la fin...
Suis-je à l’ouest ?
Merci
Paulbe
Oui c’est exact, plus besoin de modifier le htaccess.
Alors je confirme que pour l’instant, on ne peut pas ajouter « .html » à la fin des ces URLs, mais c’est un choix arbitraire et techniquement ça pourrait fonctionner.
En fait je réutilise les vérifications du formulaire d’édition des URLs, qui n’accepte que le format « propre ». Mais pour les URLs des pages, il n’y a pas de raison d’interdire les extensions à la fin effectivement, je rajoute ça dans la todo list.
Merci pour les retours !
Voilà dans la version 1.0.9 c’est possible d’utiliser l’extension .html (version dispo dans la journée)
Répondre à ce message
Est-ce que cela ne vaudrait pas la peine de passer le plugin du statut « experimental » à « en test » ?
Tiens, on a eu la même idée au même moment, ça vient d’être fait.
Répondre à ce message
Hello,
Dans cet article ici http://contrib.spip.net/URLs-pages-personnalisees#s-Utilisation
Les liens ne fonctionnent pas pour moi :
/ ?exec=configurer_urls_pages renvoie Fichier configurer_urls_pages introuvable
et
?exec=configurer_urls ne montre pas la config de ce plugin
Il faut aller dans ?exec=controler_urls (publicaiion > gestion des urls)
sur un SPIP 3.1.3
Bonjour,
Oui la branche 1.x est une refonte complète du plugin, pas mal de choses on changé dont les menus. Il y aura un nouvel article quand j’aurais eu assez de retours.
En attendant, cet article ne concerne que la branche 0.x, je vais rajouter cette précision au début.
Répondre à ce message
Bonjour, sur free j’ai ce message d’erreur dans l’admin :
Bonjour,
quelle est la version de PHP ?
Bonjour,
Mais en fait ce ne serait pas intégré a spip ? Dans configuration > url > gestion avancée
on peut activer l’édition de l’url de chaque objets.
Répondre à ce message
Bonjour,
votre plugin m’intéresse fortement pour ne pas avoir « spip ?page= ».
je me sers des urls propres pour le reste.
Chez moi, le plugin « à l’air de fonctioner » :
« La nouvelle configuration a été enregistrée .
N’oubliez pas de copier le code présent en fin du formulaire dans le fichier .htaccess »
J’ai donc copier le code donné mais lorsque je vais sur mon site, j’ai toujours les pages « mon_site/spip.php ?page=plan » et non juste « mon_site/plan »
Re Bonjour,
maintenant la redirection fonctionne mais la nouvelle page montre ERREUR 404 au lieu de pointer sur ma page.
Je l’ai testé sur « plan » pour avoir mon_site/plan au lieu de mon_site/spip ?page=plan
Bonjour,
Désolé de ne pas avoir répondu à ton premier message.
En ce qui concerne l’erreur 404, dur de déterminer d’où vient l’erreur.
Est-ce que redirection est bien opérationnelle avec les urls persos traditionnelle ?
Peux-tu poster la section de ton .htaccess contenant le code ? (au mieux, toute la section « réglages personnalisés »).
Sinon, la prochaine version devrait éviter d’avoir à toucher au .htaccess, si tu as le courage d’attendre (car je ne sais pas quand ça sortira :p ).
Merci de me répondre,
j’ai collé en fin du .htaccess comme indiqué
La redirection se fait bien sur la barre d’adresse mais apparemment il pointe sur rien puisque j’ai l’erreur 404 (qui apparaît lorsque rubrique vide ou page inconnu)
Répondre à ce message
Hello sur un SPIP 3.0.16 j’ai ceci quand je clique sur les outils pour configurer le plugin
1 Erreur SQL 1052
Column ’actif’ in where clause is ambiguous
SELECT paquets.id_plugin, plugins.id_plugin, plugins.prefixe AS prefixe, plugins.categorie AS categorie, paquets.actif AS actif, paquets.src_archive AS dossier, paquets.constante FROM spip_paquets AS paquets, spip_plugins AS plugins WHERE paquets.id_plugin = plugins.id_plugin AND categorie = « squelette » AND actif = « oui »
2 Erreur SQL 1052
Column ’actif’ in where clause is ambiguous
SELECT paquets.id_plugin, plugins.id_plugin, plugins.prefixe AS prefixe, plugins.categorie AS categorie, paquets.actif AS actif, paquets.src_archive AS dossier, paquets.constante FROM spip_paquets AS paquets, spip_plugins AS plugins WHERE paquets.id_plugin = plugins.id_plugin AND categorie = « outil » AND actif = « oui »
Une idée de solution pour utiliser ce plugin ?
Merci
Paulbe
Bonjour,
merci d’avoir relevé le bug. Peux-tu tester la 0.1.10 qui sera dispo demain et me dire si ça corrige le problème ?
Ca a l’air de passer.
Merci
Répondre à ce message
Bonjour.
Je suis nouveau sous spip, alors je vais peut-être dire des bêtises, mais le plugin ne pourrait-il pas utiliser la table spip_urls pour éviter de devoir ajouter une règle de réécriture à la main dans le .htaccess ?
Je m’explique.
J’ai écrit le squelette ’tutoriel’.
A l’aide du plugin « Menus », j’ai ajouté une entrée vers cette page, qui pointe donc vers http://.../spip.php?page=tutoriel
J’ai activé les urls propres.
A l’aide de votre plugin, je remplace http://.../spip.php?page=tutoriel par http://.../tuto
En rechargeant le site, l’URL dans le menu est bien modifiée, mais pour qu’elle soit comprise par spip, il faut effectivement ajouter la règle de réécriture proposée. Sinon -> Erreur 404, normal.
Donc tout fonctionne pour l’instant.
J’ai ensuite inséré, à la main, une entrée dans la table spip_urls (url=’tuto’, type=’tutoriel’)
(et j’ai desactivé le test dans formulaires_configurer_urls_pages_verifier_dist()).
Du coup, j’ai maintenant l’URL propre qui est bien utilisée dans le menu, et cette URL est comprise par spip (puisqu’elle est définie dans la table spip_urls). Plus besoin de la règle de réécriture...
Est-il donc possible d’implémenter cette méthode (plutôt que l’utilisation d’une règle de réécriture) dans votre plugin ? Ou y a-t-il un effet de bord que je ne connais pas encore ?
En tout cas, merci pour votre travail !
Ah, j’ai oublié... Je suis en SPIP 3.0.16...
Bonjour,
Oui, enregistrer les urls des pages avec celles des objets dans la table
spip_urls, c’est une piste intéressante. Je vois plusieurs avantages :Après, les urls persos sont censées se référer à des objets éditoriaux. Donc là, on tordrait un peu le cou à ce mécanisme, il faut voir s’il n’y a pas d’effet secondaire.
J’avais entamé une version dev qui fonctionne selon le principe, si ça t’intéresse je pourrai te l’envoyer pour tester. S’il n’y a pas de dommage collatéral constaté, ça pourra être reporté sur le plugin.
Voilà, en tout cas merci pour la suggestion et bonne découverte de SPIP !
Ah oui, au moins en option svp !
Pas de soucis pour tester le plugin de dev, et vu le peu de choses que j’ai pour l’instant (je vérifie juste d’abord que j’ai bien à disposition toutes les fonctionnalités dont j’ai besoin) ça devrait pas créer de gros dommages.
Répondre à ce message
Bon j’ai essayé en SPIP 3.0.16 avec la page recherche.html qui présente les résultats de recherche du formulaire recherche mais sans succès. J’ai pourtant, je crois rien oublié.
Bonjour,
Vous voulez dire que la page « recherche » n’apparaît pas dans la liste des pages détectées, ou que la redirection pour cette page ne fonctionne pas ?
Et est-ce que la redirection fonctionne pour d’autres pages ?
Bonjour,
La page recherche est bien listée mais ça ne fonctionne pas.
Je n’ai pas testé sur d’autres page étant donné que je n’ai que la page recherche qui est détectée.
Répondre à ce message
Bonjour,
sous spip 3 impossible de faire marcher le plugin (voir pièce jointe), c’est ennuyant car ce plugin à l’air vraiment intéressant !
Bonjour,
C’est sans doute que vous n’avez pas le plugin « saisies » d’installé.
Et là c’est ma faute, parce que j’ai omis de le déclarer comme une dépendance nécessaire dans paquet.xml.
D’ailleurs cette dépendance est un peu superflue, je l’enlèverai dans la prochaine mise à jour.
Merci pour le retour !
Merci pour l’indication :) le plugin fonction mieux, cependant à la fin du formulaire je n’ai pas les rewriterules à renseigner dans le fichier htaccess...
Hop, c’est corrigé dans la v0.1.7 qui devrait être dispo demain
Pour les rewriterules, vous avez bien rempli les champs des pages et validé le formulaire ?
Normalement, elles s’affichent une fois les informations enregistrées correctement.
Ah oui ok, merci, les champs préremplis m’ont perturbés !
donc comme je suis une quiche, forcément, les rewrites rules ne sont pas prises en compte dans le htaccess j’ai tjrs mes url type
spip.php ?page=contact
pourtant j’ai bien nommé mon url #URL_PAGEcontact dans le squelette et indiqué
RewriteRule ^spip.php ?page=contact(\.html) ?$ spip.php ?page=contact [QSA,E=url_propre :$0,L]
je n’ai pas renseigné le premier champs car mon spip est à la racine de mon serveur
une solution ?
Bon, finalement, j’ai trouvé moi même d’où venait le problème (c’était moi)
j’ai renseigné tout comme il faut et patatra j’ai des 404 lorsque j’arrive sur mes pages...
Arf, j’avais mal compris le processus de création de l’url... un peu crevé ^^
Sinon bon, mes urls fonctionnent, cependant :
1. lorsque je rentre l’url personnalisée : toto sur un ?page=toto, le front n’agit pas comme je le veux : l’url se présente comme cela monsite.com/toto or je voudrais que ça finisse par .html type monsite.com/toto.html
2. mes urls modifiés je suis content cependant lorsque j’accède à l’url je tombe sur ma 404 page... c’est gênant...
monsite.com/toto.html, il suffit d’enregistrertoto.html(au lieu detototout court).Cela dit, je ne l’ai pas précisé dans la doc mais avec les rewriterules indiquées, une url
monsite.com/totofonctionne de facto aussi avecmonsite.com/toto.html.Je ne suis pas sûr que ce fonctionnement est forcément une bonne idée par contre, donc ça pourra changer par la suite.
Répondre à ce message
Bonjour,
j’ai un petit soucis que je n’arrive pas à comprendre. Suite au changement dans le htaccess pour parvenir à la page contact :
RewriteRule ^Contact(\.html) ?$ spip.php ?page=contact [QSA,E=url_propre :$0,L]
j’obtiens une erreur 404. Pourtant l’adresse spip.php ?page=contact est bonne. L’ensemble également correcte. Avez-vous une idée ?
Bonjour,
Il faut peut-être supprimer la majuscule :
RewriteRule ^contact...Ou mieux :
RewriteRule ^[Cc]ontactpour accepter « contact » avec et sans majuscule.Répondre à ce message
Bonjour et bravo pour avoir pensé à ce plugin,
mais j’ai trouvé une petite coquille qui doit se corriger facilement, visible sur l’image jointe...
ou expliquée en 2 mots :
le code du RewriteRule reprend en 2e argument la partie indiquée par l’administrateur et non la partie détectée automatiquement dans le dossier /squelettes/, soit pour moi :
page détectée : page-orr, Url perso souhaitée : organisation.html
code créé :
RewriteRule ^organisation.html(\.html)?$ spip.php?page=organisation.html [QSA,E=url_propre:$0,L]code qui fonctionne :
RewriteRule ^organisation.html(\.html)?$ spip.php?page=orr [QSA,E=url_propre:$0,L]Cordialement
Outch, une belle boulette !.
Merci de l’avoir signalée, c’est corrigé dans la v0.1.2
Il faudrait peut-être que je précise un truc dans l’article : en rentrant « toto » pour une page, les 2 adresses « lesite.com/toto » et « lesite.com/toto.html » fonctionneront.
Donc il n’est pas nécessaire de rajouter « .html » au niveau de la saisie.
Il reste à finaliser en supprimant « page- » dans « spip.php ?page=page-orr » pour avoir l’adresse correcte : « spip.php ?page=orr »
Et ok pour le .html, c’est plus simple
Si le squelette s’appelle "page-orr.html" (je me fie à la capture d’écran), c’est le comportement attendu. Il n’est pas nécessaire de préfixer les squelettes des pages par « page- ».
Et dans certains cas si !!!
je précise que j’utilise ZPIP et dans /squelettes/contenu/ il faut utiliser page-nomdepage.html pour avoir la configuration complète de la page avec l’utilisation du fichier body.html ...
Une solution :
2 zones de code « avec Zpip » en enlevant « page- » et « sans Zpip » avec le contexte complet
Ah ok, je n’avais pas pensé au cas de ZPIP. Je corrigerai ça dans le prochain commit. En ZPIP 2, j’ai un doute, il faut également préfixer les squelettes des pages ?
Pour Zpip 2, je ne sais pas !
Voilà c’est réparé dans la v0.1.3.
Donc effectivement, il faut préfixer pour Z1 mais pas en Z2, d’où ma confusion (j’utilise Z2).
Merci encore pour les retours
Merci,
Juste pour finir, j’ai, par hasard, configuré des majuscules dans mes pages du type :
page-MaPage.html, ceci a été transformé en spip.php ?page=mapage et bien sur cela me redirige vers la 404, à toi de voir si c’est à corriger ou à ma pomme de m’appliquer...
Encore bravo pour la réactivité
Une coquille à corriger !
Voilà, ça devrait rouler avec la v 0.1.4
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
