Url-rewriting et url type "//ajax.googleapis.com/ajax/libs/jquery/..."
Bonjour,
Dans la partie publique des sites et lorsque l'url-rewriting est activé, la page index.php fait appel à la fonction plxUtils::rel2abs(..).
Avec l'utilisation intense de grosses bibliothèques comme jQuery, on utilise les réseaux de serveurs en cache (CDN) pour télécharger ces bibliothèques le plus vite possible.
On utilise de plus en plus des url comme ci-dessus pour éviter d'utiliser un serveur précis, laissant le choix aux routeurs pour proposer le serveur le plus rapide.
Hélas, la fonction plxUtils::rel2abs(..) ne prend pas en compte cette nouvelle technologie en compte.
Il a lieu d'optimiser cette fonction. Quelques remarques d'abord :
- transformer les adresses href="#toppage" ne sert à rien vu que le lien concerne la page actuelle. Au contraire, cela peut-être contre-productif en rechargeant la page (à vérifier selon les navigateurs)
- pour les adresses href="./plugins/...", on perd le lien si on le dossier plUgINs sur le site (Ok, j'ai l'esprit tordu, mais pas que moi)
- les url href="http://tonsite.com/kivabien"; sont mal-menés. On remplace d'abord et on défait ensuite. (cela occupe le serveur pour rien)
Après recherche sur Google avec "php preg exclure word", il faut utiliser les "negative lookahead". Sur reg101.com, j'ai fait quelques essais avec les urls suivantes :
A noter le rôle particulier de la chaine "(?!" dans le masque qui fait le negative lookahead.
On ne précise pas le protocole. Donc, http, https, ftp, mailto, gopher, news passent.
Je n'ai pas étudié le code php pour finir. Il y a un petit problème c'est que le nombre de captures varie entre 3 et 4 si l'url commence par "./"
Au pire, scinder l'expression en deux.
Il faudrait vérifier avec d'autres urls
Dans la partie publique des sites et lorsque l'url-rewriting est activé, la page index.php fait appel à la fonction plxUtils::rel2abs(..).
Avec l'utilisation intense de grosses bibliothèques comme jQuery, on utilise les réseaux de serveurs en cache (CDN) pour télécharger ces bibliothèques le plus vite possible.
On utilise de plus en plus des url comme ci-dessus pour éviter d'utiliser un serveur précis, laissant le choix aux routeurs pour proposer le serveur le plus rapide.
Hélas, la fonction plxUtils::rel2abs(..) ne prend pas en compte cette nouvelle technologie en compte.
Il a lieu d'optimiser cette fonction. Quelques remarques d'abord :
- transformer les adresses href="#toppage" ne sert à rien vu que le lien concerne la page actuelle. Au contraire, cela peut-être contre-productif en rechargeant la page (à vérifier selon les navigateurs)
- pour les adresses href="./plugins/...", on perd le lien si on le dossier plUgINs sur le site (Ok, j'ai l'esprit tordu, mais pas que moi)
- les url href="http://tonsite.com/kivabien"; sont mal-menés. On remplace d'abord et on défait ensuite. (cela occupe le serveur pour rien)
Après recherche sur Google avec "php preg exclure word", il faut utiliser les "negative lookahead". Sur reg101.com, j'ai fait quelques essais avec les urls suivantes :
[== Indéfini ==]
<a href="https://www.google.fr>My Friend</a>
<img href="data/images/selfie.jpg" />
<a href="./pluGIns/colorBox.php">the best</a>
<a href="#toppage">the best</a>
<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
[== Indéfini ==]
<(\w[^>]*)\s(href|src)=(["\'])(?!(\w+:\/\/)|(\/\/)|#)(\.\/)?
A noter le rôle particulier de la chaine "(?!" dans le masque qui fait le negative lookahead.
On ne précise pas le protocole. Donc, http, https, ftp, mailto, gopher, news passent.
Je n'ai pas étudié le code php pour finir. Il y a un petit problème c'est que le nombre de captures varie entre 3 et 4 si l'url commence par "./"
Au pire, scinder l'expression en deux.
Il faudrait vérifier avec d'autres urls
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Comme signalé dans un autre post, c'est pris en compte ici et tout le travail de recherche que tu as fait va bien nous aider.
Merci beaucoup ça va nous être très utile
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)