Je ne sais pas si il faut repasser par un redirect comme auparavant ou si on peut vérifier qu'on ne met a jour que l'url de la page en cours ?
??? Ca n'a rien à voir avec le redirect d'avant, ça a toujours été comme ça.
Non nullement, le bouton 'voir en ligne' ne provoquait que la mise a jour de l'url de l'objet concerné qui ne pouvait se faire que lors de l'appel depuis l'action redirect : Connexion · GitLab
et un simple ?var_mode=calcul utilisé pour mettre a jour une page ne modifiait aucune url.
Le test dont tu parles ligne 67 et suivantes a été remplacé par
(_request('var_mode') == 'calcul')
je ne vois pas en quoi il ne serait pas équivalent à ce qu'il y avait avant.
- auparavant, le globals['preview'] n'était pris en compte que si on était dans l'action redirect, endroit ou on ne recalculait qu'une seule url : celle de l'objet a 'voir en ligne'
- maintenant on calcule l'url des que il y a var_mode=calcul dans l'url, donc directement sur la page de l'objet, qui elle meme peut comprendre N appels a #URL_XX qui seront toutes recalculees également.
Par ailleurs, si tu fais un test simple de changer le titre d'un article et faire 'Voir en ligne', tu verra que tu n'arrive pas sur la nouvelle url, mais sur l'ancienne car le lien pointait sur l'ancienne url.
C'est donc doublement trompeur : tu as l'impression de ne pas avoir mis a jour l'url de l'article, mais en fait tu as mis a jour toutes les url contenues dans la page. Si tu recharges la page dans le navigateur, tu es cette fois renvoyé vers la nouvelle url, qui a aussi été mise a jour.
Pour le premier point, ok, la disparition du redirect est trompeuse, mais pas plus chère qu'avant.
Pour le 2e, je me souviens avoir constaté il y a bien longtemps qu'un var_mode=calcul provoquait le recalcul de toutes les URLs, là non plus je ne crois pas qu'il y a plus de calculs qu'avant.
Mais c'est vrai qu'il faudrait éliminer l'aspect trompeur. Revoir le pipeline "bloc_info" devrait pouvoir suffire.
si tu fais un test simple de changer le titre d'un article et faire 'Voir en ligne', tu verra que tu n'arrive pas sur la nouvelle url, mais sur l'ancienne car le lien pointait sur l'ancienne url.
C'est donc doublement trompeur : tu as l'impression de ne pas avoir mis a jour l'url de l'article, mais en fait tu as mis a jour toutes les url contenues dans la page.
Pour le premier point, ok, la disparition du redirect est trompeuse, mais pas plus chère qu'avant.
Pour le 2e, je me souviens avoir constaté il y a bien longtemps qu'un var_mode=calcul
je crains que le 'bien longtemps' ne soit malheureusement deja une version bugguee de la svn car je peux t'assurer qu'aucune version stable n'a jamais fait cela, la mise a jour des url d'un objet ayant toujours été plutot laborieuse que simple.
provoquait le recalcul de toutes les URLs, là non plus je ne crois pas qu'il y a plus de calculs qu'avant.
Mais c'est vrai qu'il faudrait éliminer l'aspect trompeur. Revoir le pipeline "bloc_info" devrait pouvoir suffire.
La on considère qu'un changement de titre doit automatiquement se traduire en changement d'url, non ?
je peux t'assurer qu'aucune version stable n'a jamais fait cela, la mise a jour des url d'un objet ayant toujours été plutot laborieuse que simple.
je continue à pense l'inverse: un squelette avec <BOUCLE1(RUBRIQUES)><a href='#URL_RUBRIQUE'>clic</a></BOUCLE1> va chercher les URLs dans la table des URLs, et les calculent si elles n'y sont pas, par exemple quand on vient de changer de jeu d'URL.
provoquait le recalcul de toutes les URLs, là non plus je ne crois pas qu'il y a plus de calculs qu'avant.
Mais c'est vrai qu'il faudrait éliminer l'aspect trompeur. Revoir le pipeline "bloc_info" devrait pouvoir suffire.
La on considère qu'un changement de titre doit automatiquement se traduire en changement d'url, non ?
Quand on modifie un article, on sait que la mise en cache de la version précédente induit un délai, qu'on ramène à 0 en cliquant sur "voir en ligne".
Je viens d'envoyer qqch qui suit la meme logique: "voir en ligne" force la prise en compte du nouveau titre si on clique dessus, sinon rien de se passe.
Si on trouve un meilleur titre qq secondes après (typiquement correction de fautes de frappe) on n'aura pas encombre la table pour rien.
Quand on modifie un article, on sait que la mise en cache de
la version précédente induit un délai, qu'on ramène à 0 en
cliquant sur "voir en ligne".
Je viens d'envoyer qqch qui suit la meme logique: "voir en ligne"
force la prise en compte du nouveau titre si on clique
dessus, sinon rien de se passe.
Si on trouve un meilleur titre qq secondes après (typiquement
correction de fautes de frappe) on n'aura pas encombre la
table pour rien.
Attention, au bout d'un certain délai (quelques heures ?), il faudra soit
figer l'URL, soit conserver la mémoire de l'URL précédente, pour ne pas
géner les utilisateurs qui auraient pu mettre l'URL en signet, ou faire un
lien vers cette page...