Realurl
Un article de Typo3 CMS / Documentation Typo3 / Support Typo3.
EXT : Real URL
Clé d'extension : realurl
Copyright 2003 - 2004, martin@beryllium.net, <martin@beryllium.net> & Kasper Skårhøj <kasper@typo3.com>
Ce document est publié sous licence Open Content disponible sur http://www.opencontent.org/opl.shtml
Le contenu de ce document est relatif à TYPO3 -Gnu/GPL CMS/Framework disponible sur www.typo3.com
Sommaire |
[modifier] Introduction
[modifier] A quoi ça sert ?
L'extension procure une transformation automatique des URLs avec des paramètre GET dans le frontend (comme “index.php?id=123&type=0&L=1”) dans un chemin virtuel, une bien nommée 'URL parlante' (comme “dutch/contact/company-info/page.html”) et ainsi de suite. L'objectif est que les URLs devraient être aussi humainement lisible que possible.
L'extension est très flexible et peut fournir de simples traduction d'IDs de page au codage de presque toute combinaison possible de paramètres GET.
Exemples
| URL Entrée | Id TYPO3 et type |
| http://www.domain.com/ | id=0, type=0 |
| http://www.domain.com/products/product1/features/ | id=123, type=0 |
| http://www.domain.com/products/product1/features/leftframe.html | id=123, type=2 |
[modifier] Arrière-plan
Typo3 travaille avec des Ids de pages. Cela marche très bien, mais les URLs sont très moches (“...index.php?id=123&type=0&L=1....” etc.). Il y a des contournements (simulateStaticDocuments), mais c'est juste un fake : l'ID doit toujours être fournie dans l'URL, ce qui n'est pas souhaitable. De plus, seul le titre de la page est affiché, pas le 'chemin' complet (ou 'rootline') de la page.
Normallement vous écrivez le chemin et nom de fichier d'un document, mais typo3 travaille exclusivement avec les Ids de pages. L'extension RealURL procure un moyen de traduire entre les Ids de pages et les (virtuel) URLs qui sont facile à lire et se souvenir.
L'extension requiert le module Apache 'mod_rewrite' pour récrire les URLs virtuels du site au moteur frontend Typo3.
Généralement cela marchera en dehors de la boite mais vous aurez à aborder la question que tout les média référencent dans la page HTML d'avoir soit des URLs absolue ou la configuration d'onglet de 'base'. Les deux méthodes ont des avantages et des inconvénients mais la ligne directrice est que vous pouvez avoir à réparer vos templates/codages à plusieurs endroit pour que ce soit compatbile.
Photo d'écran (typo3.org extensions encoding)
[modifier] Caractéristiques
- Supporte divers arrangements pour coder le chemin de page, y compris des arrangements définis par utilisateur.
- Les titres de pages peuvent contenir des espaces et des caractères comme /.,&@ etc., l'URL sera toujours bonne.
- Les URLs sont générés en jolis petits chemins.
- Si une page est renommée, l'ancienne URL peux toujours être utilisée (voir plus bas dans le Manuel de l'utilisateur), donc si la page est indéxée, par exemple par Google, elle peut toujours être trouvée.
- Offre des traductions avancées de presque tout ensemble de paramètres GET en/d' URL virtuel.
- Une traduction entre une requête de string GET (“...&tx_myext[blabla]=123&type=2...”) et une URL virtuel (“.../123/2/”) est transparente pour Typo3 et toutes les extensions ; La seule nécessitée est que les fonctions de générateur de lien interne de Typo3 soient utilisés (“tslib_cObj::typolink”, “t3lib_tstemplate::linkData”)
- Les URLs sont misent en cache, ainsi la traduction entre URLs et IDs est très rapide.
- Il peut supporter différentes armatures, ou d'autres types de pages.
- Les URLs sont multi-langues : si vous surfez en Hollandais, vous verrez les URLs Hollandaises.
- Une fois configuré le système travaille entièrement automatiquement, créant de nouvelles et mettant à jour les URLs existantes.
- Vous pouvez aisément voir ou pointent les raccourcis, vu que l'URL 'Cible' est généré, au lieu de l'URL au raccourci lui même.
- Il manipule automatiquement de multiple domaines dans la base de données.
- Il manipule automatiquement les installations de Typo3 dans les dossiers autres que la racine du site web aussi.
Le codage cru des URL de paramètres GET restants obtiennent des noms vars. - Désactive “simulateStaticDocuments”!! ....
[modifier] Configuration
[modifier] Installation
Pour installer cette extension, quatre étapes doivent être effectuées :
1.L'installer dans le manager d'extension
2.Configurer Apache
3.Modifier vos templates pour Real URLs
4.Configurer l'extension dans typo3conf/localconf.php
[modifier] Installer l'extension
C'est très bien documenté dans les docs Typo3 usuelles : Cliquez simplement la petite sphère grise avec le signe plus et lorsqu'il demande pour effectuer tout changement , laissez le faire. Cependant il ne fait rien pour le moment.
[modifier] Configurer Apache
RealURLs travaille en fournissant des 'chemins virtuels' à des 'fichiers virtuels'. Actuellement cela n'existe pas sur les fichier systèmes, donc vous devez dire à Apache de laisser le script PHP manier les requêtes s'il ne peut pas trouver le fichier. De cette façon, toutes les URLs vers les pages (comme www.server.com/products/product1/left.html) seront 're-dirigées' vers /index.php, qui maniera la traduction de l'URL en paramètres GET. Les vrais fichiers (comme les images, le backend de typo3, les fichiers html statiques, etc.) seront toujours maniés par Apache lui même.
Vous devriez mettre l'échantillon .htaccess fournit (appelé _.htaccess) à la racine de votre installation Typo3.
Alternativement, vous pouvez inclure les lignes suivantes dans votre httpd.conf, probablement dans la section VirtualHost. Voici un exemple :
<VirtualHost 127.0.0.1>
DocumentRoot /var/www/typo3/dev/testsite-3/
ServerName www.test1.intra
RewriteEngine On
RewriteRule ^/typo3$ - [L]
RewriteRule ^/typo3/.*$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* /index.php
</VirtualHost>
Si vous le mettez dans un fichier .htaccess il devra être légérement différent, en dépouillant de base les principaux slash (“/”) :
RewriteEngine On
RewriteRule ^typo3$ - [L]
RewriteRule ^typo3/.*$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* index.php
Ceci dira à Apache que je devrais récrire chaque URL n'étant pas un nom de fichier, dossier ou liensym. Il laisse aussi tout démarrer avec /typo3/ seul.
Notification : pour ce travail vous avez besoin du module Apache “mod_rewrite”!
[modifier] Configuration TypoScript
Comme avec “simulateStaticDocuments” vous devez activer la génération des noms de fichiers/chemins dans l'enregistrement TypoScript – Ou alors votre site web n'utilisera pas la nouvelle méthode d'encodage d'URL.
C'est cependant insignifiant ; placez simplement quatre lignes dans l'enregistrement template TypoScript principal de votre site web :
0: config.simulateStaticDocuments = 0
1: config.baseURL = 1
2: config.tx_realurl_enable = 1
La ligne 0 désactive simplement “simulateStaticDocuments” - “realurl” est incompatible avec simulateStaticDocuments et ne marchera tout simplement pas s'il est désactivé. Cette ligne devrait vous rappelez ce fait.
La ligne 1 fait du produit de frontend un onglet '<base>' dans l'en-tête des pages. C'est necessaire à cause des references relatives aux images, feuilles de styles etc. qi casseront quand les chemins virtuels sont utilisés à moins que cela ne soit configuré. Veuillez voir ci-dessous pour une discussion détaillée du pourquoi c'est nécessaire.
La ligne 2 active l'encodage des URLs comme chemins virtuels, les 'URL's parlantes'.
[modifier] Configurer l'extension
Finalement, vous voulez probablement configurer la façon dontt sont encodées les URLs. Pour des besoins simples c'est plutôt facile et plus vous voudrez encoder des URLs avancées plus vous aurez besoin de configuration – simple n'est ce pas.
La configuration est effectuée dans “localconf.php” avec les variables $TYPO3_CONF_VARS['EXTCONF']['realurl']
Veuillez voir la section traitant des options de configurations. Elle offre aussi beaucoup d'exemples.
[modifier] Arrière plan d'en/décodage d'URL
Cette section fournit un peu d'informations d'arrière plan concernant comment les URLs sont encodées et décodées dans le système. Le principe général est que l'encodage et décodage doit être totalement transparent pour le système. Cela veut dire que n'importe quelle extension marchera avec 'realurl' tant qu'elles utiliseront le lien général de fonctions de générations dans Typo3 comme elle devrait déjà. Vus pouvez aussi utiliser “simulateStaticDocuments” comme test – si ca marche avec ça, ca marchera (plus probablement) aussi avec l'extension 'realurl'. L'implémentation de cette transparence est faite en encodant l'URL virtuelle strictement avec les bases de paramètres GET données dans la méthode d'encodeur. Et quand une requête HTTP est faite à une URL virtuelle elle est décodée en un ensemble de paramètres GET qui est récrite au variables globales HTTP_GET_VARS / _GET – ainsi toutes applications dans le système verra les paramètres come si elles étaient passés comme de véritables paramètres GET.
[modifier] Encodage :
L'URL avec des paramètres GET -> URL parlante -> Page HTML L'encodage des URLs arrivent en utilisant un hameçon dans la méthode t3lib_tstemplate::linkData(). C'est configuré dans “realurl/ext_localconf.php”:
$TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tstemplate.php']['linkData-PostProc'][] = 'EXT:realurl/class.tx_realurl.php:&tx_realurl->encodeSpURL';
[modifier] Décodage :
Les requêtes HTTP avec une URL parlante -> l'URL est décodée, surpasse les valeurs dans HTTP_GET_VARS -> la page est rendue comme toujours. Le décodage des URLs arrivent en utilisant un hameçon dans tslib_fe::checkAlternativeIdMethods(). C'est configuré comme ceci :
$TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_fe.php']['checkAlternativeIdMethods- PostProc'][] = 'EXT:realurl/class.tx_realurl.php:&tx_realurl->decodeSpURL';
[modifier] La syntaxe d'une 'URL parlante'
Avant que nous n'allions dans la section configuration il est important de comprendre comment est décodé le chemin virtuel (URL parlante) par le système. Etablissons un exemple et cassons le en morceaux. :
index.php?id=123&type=1&L=1&tx_mininews[mode]=1&tx_mininews[showUid]=456
La configuration de 'realurl' avait besoin de faire ce magic comme suivant :
1: $TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'] = array( 2: 'preVars' => array( 3: array( 4: 'GETvar' => 'L', 5: 'valueMap' => array( 6: 'dk' => '1', 7: ), 8: 'noMatch' => 'bypass', 9: ), 10: ), 11: 'fileName' => array ( 12: 'index' => array( 13: 'page.html' => array( 14: 'keyValues' => array ( 15: 'type' => 1, 16: ) 17: ), 18: '_DEFAULT' => array( 19: 'keyValues' => array( 20: ) 21: ), 22: ), 23: ), 24: 'postVarSets' => array( 25: '_DEFAULT' => array ( 26: 'news' => array( 27: array( 28: 'GETvar' => 'tx_mininews[mode]', 29: 'valueMap' => array( 30: 'list' => 1, 31: 'details' => 2, 32: ) 33: ), 34: array( 35: 'GETvar' => 'tx_mininews[showUid]', 36: ), 37: ), 38: ), 39: ), 40: );
Pour comprendre comment cette configuration peux traduire une URL parlante de retour en paramètres GET nous devons d'abord voir comment les URLs parlantes sont divisées en sections. Voici la syntaxe générale :
[TYPO3_SITE_URL] [preVars] [pagePath] [fixedPostVars] [postVarSets] [fileName]
Chacune de ces sections (excepté [filename]) peut consister en un segments ou plus divisé par '/'. Ainsi 'news/list/456/' est une séquence de trois ségments, nommés 'news', 'list' et '456' En prenant l'URL parlante ci-dessus (http://www.my-domain.dk/frontend/dk/123/news/list/456/page.html) comme exemple nous pouvons maintenant la casser en ces sections :
| Section | Partie de l'URL exemple | Description Générale | Commentaire de config accord. |
| [TYPO3_SITE_URL] | http://www.my-domain.dk/frontend/ | Cette partie de l'URL – L'URL de base du site et fondamentalement ou le script “index.php” du frontend est localisé – est dépouillé et n'est d'aucun intérêt pour la résolution des paramètres. | |
| [preVars] | dk/ | Cette section peut contenir de zéro à tout nombre de segments divisés par '/'. Chaque segment est lié à un var GET par la configuration dans la clé “preVars” (voir l'exemple ci-dessus).
Le nombre de segment dans la section pre-vars est déterminé exactement par les rangées dans la configuration 'prevars'. Un usage typique serait de lier un pre-Var au paramètre GET 'L' ainsi le langage du site est représenté par le premier segment du chemin virtuel. |
Dans la configuration ci-dessus il n'y a qu'un pre-var configuré et qui est attaché à la var GET 'L'. De plus une page de traçage dis que la valeur 'dk' devrait être traduite en un '1' pour la valeur de var GET quand encodée. Aussi, si le segment ne correspond pas à 'dk/' c'est juste ignoré. Cela veut dire que la version de langage par défaut de la page Danoise “.../dk/123/” devrait être simplement “.../123/” |
| [pagePath] | 123/ | Le chemin de page déterminant l'ID de page de la page. La méthode par défaut est juste de montrer l'ID de page, mais par la configuration vous pouvez traduire disons 'info de contact/compagnie) en une ID de page. Le nombre de segments du chemin utilisé pour résoudre l'ID de page dépend de la méthode utilisé. | Dans cet exemple la méthode par défaut est utilisée (pas configuré du tout) et cela veut dire l'id de page cru (ou alias s'il y en a) est affiché ; 123. Ce n'est pas un comportement 'd'URL parlante', désolée pour cet exemple faible ... |
| [fixedPostVars] | Les postes fixe de vars sont une séquence d'attaches fixe entre les vars-GET et ls segments de chemins, comme le sont les pre-vars. Ce n'est normalement pas utile de configurer pour un site entier étant donné que les paramètres généraux devant passer seront probablement configurés comme des pre-vars, mais vous pouvez configurer les postes vars fixes pour une page simple ou quelques application fonctionnent et dans ce cas peuvent être utiles. | Non utilisé dans cet exemple. | |
| [postVarSets] | news/list/456/ | postVarSets sont des séquences d'attaches var GET (dans le style pre-var) initiées par le premier segment du chemin étant un mot clé d'identification pour la séquence. Décoder le postVarSets continuera jusqu'à ce que tout les segments restants du chemin virtuel soit traduis. Cette méthode peut être utilisée pour encoder efficacement les groupes de vars GET (sets), typiquement pour des plugins variables utilisés sur le site web. L'usage typique est de configurer le postVarSets pour chaque plugin sur le site web. | Dans cet exemple il y a un varset de simple post (“news/list/456/”) ou le mot clé 'new/' (premier segment) identifie la séquence suivante (“list/456/”) pour être tracé vers les vars GET tx_mininews[mode] et tx_mininews[showUid] respectivement. |
| [fileName] | page.html | Le nom de fichier est toujours identifié comme segment du chemin virtuel après le slash '/'. Dans la configuration 'Nom de fichier' un nom de fichier peut être tracé en un nombre de vars GET qui seront configurés si le nom de fichier correspond à la clé de l'index dans la rangée. L'usage typique est d'utiliser le nom de fichier pour encoder le 'type' ou 'print' vars GET d'un site. | Dans cet exemple la valeur 'type' '1' est tracée au nom de fichier virtuel “page.html”. Dans tout autres cas la valeur type aurait été configuré vide. |
[modifier] Directives de configuration
La configuration de 'realurl' est effectuée dans la zone $TYPO3_CONF_VARS['EXTCONF']['realurl'] qui contient de nouveau des zones. Les directives de configuration sont décomposées dans ces tables décrivant les options comme elles sont regroupées en zones dans la zone de configuration.
Pour soutenir votre compréhension des options veuillez lire les informations d'arrière-plan présentées précédemment dans ce document et regardez les exemples disponibles.
$TYPO3_CONF_VARS['EXTCONF']['realurl']
| Clé | Type | Description |
| [host-name] | ->siteCfg ou pointeur vers une autre clé avec ->siteCfg dans la même zone | La configuration de codage des URL parlantes basé sur le nom d'hôte actuel pour le site web. Vous offres la possibilité de configuration individuel pour des domaines multiples dans la même base de données.
Si la valeur d'une entrée est un string, alors le système s'attendra a ce qu'il dirige vers une autre clé dans le même niveau et cherche après ->siteCfg la. Le nom d'hôte est trouvé par t3lib_div::getIndpEnv('TYPO3_HOST_ONLY') et toujours en minuscule. |
| _DEFAULT | ->siteCfg ou pointeur vers une autres clé avec ->siteCfg dans la même zone | Configuration du codage par défaut des URL parlantes si aucune similitude n'est trouvé pour le nom d'hôte spécifique. |
Exemple
1: $TYPO3_CONF_VARS['EXTCONF']['realurl'] = array( 2: '_DEFAULT' => array( 3: ... 4: ), 5: 'www.typo3.org' => array ( 6: ... 7: ), 8: 'www.typo3.com' => 'www.typo3.org', 9: 'typo3.com' => 'www.typo3.org', 10: '192.168.1.123' => '_DEFAULT', 11: 'localhost' => '_DEFAULT', 12: );
Dans cet exemple les clés “_DEFAULT” et “www.typo3.org” est assumé contenir sa propre configuration de 'realurl'. Si le nom d'hôte s'avère être “www.typo3.com” ou “typo3.com” la configuration de “www.typo3.org” est utilisée. Si le nom d'hôte “192.168.1.123” ou “localhost” alors la configuration “_DEFAULT” est utilisée (ce qui est redondant étant donné qu'elle serait utilisée de toute manière !).
->Configuration du site (siteCfg)
| Clé | Type | Description |
| init | -init | Configuration générale de l'extension |
| redirects [path] | Redirect URL | Ici vous pouvez spécifier les chemins virtuels qui ne devraient pas être transformés en vars GET mais plutôt déclencher un HTTP re-dirigeant l'en-tête directement à l'URL entrée comme valeur. Si une telle possibilité arrive le script publie un en-tête de localisation et des sorties. |
| preVars [0..x] | ->partDef | Configuration des pre-variables ; une configuration fixe de variables liés aux segments initiaux du chemin virtuel. Voir la description dans la section précédente de ce document. |
| pagePath | ->pagePath | Configuration de la méthode de transformation de l'id-en-chemin. Voir la description dans la section précédente de ce document. |
| fixedPostVars [pageIndex] [0..x] | ->partDef | Configuration de post-variable fixe ne nécessitant pas de mot de passe pour activer l'interpretation. Fondamentalement comme les pre-vars, configuré juste après le Chemin de page.
Voir la description dans la section précédente de ce document. Notification : 'PageIndex' permet de spécifier ceci pour des pages individuelles ou clavier utilisant '_DEFAULT'. Voir la notification sous ce tableau. |
| postVarSets [pageIndex] [keyword] | ->postVarSet | Configuration de post-variables ; configuration de post-variables sont activés par un mot clé dans le chemin virtuel.
Voir la description dans la section précédente de ce document. Notification : 'PageIndex' permet de spécifier ceci pour des pages individuelles ou clavier utilisant '_DEFAULT'. Voir la notification sous ce tableau. Important: L'ordre dans lequel les postVarSets arrivent est d'une grande importance étant donné que la définition du premier mot clé qui contient une définition pour un simple GET-var disponible sera choisi. Vous devriez arranger le postVarSets strategiquement. |
| fileName | ->fileName | Configuration de la signification du nom de fichier ; les noms de fichier peuvent être liés à des valeurs spécifiques de paramètres GET. Voir la description dans la section précédente de ce document. |
Notification : Dans le tableau ci-dessus est désigné une clé de zone, 'pageindex', pour fixedPostVars et postVarSets. Cela fonctionne de la même façon que le pointeur de nom d'hôte fait pour le niveau externe. La clé peut être
1.Soit une id de page, par exemple '123'
2.ou le mot clé '_DEFAULT'.
La valeur de la clé peux être une zone (suivant la définition ci-dessus) mais s'il s'agit d'un string, il est considéré comme une autre clé au même niveau.
Un pointer ne peut pas être configuré pour '_DEFAULT'. De plus, seuls les ids de page peuvent être utilisées (Alias de pages interne données comme paramètres seront résolues en premier !).
Exemple de structure
1: array( 2: 'init' => array( 3: ... 4: ), 5: 'redirects' => array( 6: => 'cms/', // If default URL, redirect to subdir "cms/" 7: 'test/' => 'http://www.test.test/', // If subdir is "test/" then redirect to URL 8: 'myFolder/mySubfolder/myFile.html' => 'test/index.php', 9: ), 10: 'preVars' => array( 11: array( 12: ... 13: ), 14: array( 15: ... 16: ), 17: ), 18: 'pagePath' => array( 19: ... 20: ), 21: 'fixedPostVars' => array( 22: '1383' => array ( 23: array( 24: ... 25: ), 26: array( 27: ... 28: ), 29: ), 30: '123' => '1383' 31: ), 32: 'postVarSets' => array( 33: '_DEFAULT' => array ( 34: 'consultancy' => array( 35: ... 36: ), 37: 'admin' => array( 38: ... 39: ) 40: ), 41: ), 42: 'fileName' => array( 43: ... 44: ) 45: );
Ce squelette vous aidera à comprendre la structure définie dans le tableau ci-dessus pour le niveau “->siteCfg” dans la configuration. Notez les exemples pour les redirections.
->init Configuration générale de l'extension 'realurl'
| Clé | Type | description |
| doNotRawUrlEncodeParameterNames | boolean | Désactive rawurlencoding des paramètres DET non traduit durant l'encodage.
Arrière plan : Durant l'encodage des URLs parlantes des paramètres GET tout paramètres GET ne pouvant être traduit en URL parlante sera configuré de nouveau en tant que paramètre GET. Durant ce processus le nom de paramètre sera rawurlencoded tel qu'il devrait être suivant les RDFs concernant ce sujet. Cela veux dire qu'un paramètre comme “tx_myext[hello]=world” deviendrait à la place “tx_myext%5Bhello%5D=world“ - ce qui n'est pas aussi beau visuellement mais plus correct techniquement. |
| enableCHashCache | boolean | Si configuré, les paramètres GET “cHash” sont stockés dans une table de cache s'ils sont les seuls paramètres restant en tant que vars GET. Cela vous permet d'être débarrassés de ces paramètres restant que quelques plugins pourraient utiliser pour permettre la mise en cache de ces contenu à base de paramètres . |
| respectSimulateStaticURLs | boolean | Si configuré, toutes les requêtes ou les chemin d'URL parlante ne sont qu'un simple document sans préfixe de chemin (par exemple “123.1.html”) sont ignorés en tant qu'URLs parmantes. Ce flag peut activer d'anciennes compatibilités avec de vieilles URLs utilisant simulateStaticDocuments sur le site. |
| appendMissingSlash | boolean / string | Si configuré, le slash de remorquage sera ajouté de façon interne au chemin s'il n'était pas configuré par l'utilisateur. Par exemple quelqu'un écrit "http://the.site.url/contact" sans slash à la fin. "contact" sera interprété comme le nom de fichier par realurl – et l'utilisateur veux qu'il soit le directory. Donc cette option fixe le problème.
Mot clé : "ifNotFile" Vous pouvez spécifier l'option comme étant le mot clé "ifNotFile". Si vous utiliser ce string comme valeur le slash est ajouté seulement si la dernière partie du chemin ne ressemble pas à un nom de fichier (basé sur l'existence du caractère point "." ). |
| adminJumpToBackend | boolean | Si configuré, alors le mode 'admin' n'affichera pas les icônes d'édition dans le frontend mais dirigera plutôt l'utilisateur vers le backend, allant directement au module de page pour éditer l'id de page actuel. |
| postVarSet_failureMode | string (mot clé) | Mot clé : "redirect_goodUpperDir". Composera une URL à partit des parties tracées avec succès et re-dirigées vers cela.
Mot clé : "ignore": Une acceptation silencieuse des parties restantes. Defaut (valeur vide) est une page 404 non trouvée à partir du frontend TYPO3 API. |
| enableUrlDecodeCache | boolean | Si vrai, mise en cache du décodage de l'URL activée. La table cache est transporté quand 'tout le cache' est transporté dans TYPO3. |
| enableUrlEncodeCache | boolean | Si vrai, mise en cache du décodage de l'URL activée. La table cache est transporté quand 'tout le cache' est transporté dans TYPO3. |
| emptyUrlReturnValue | string | Si l'URL est vide cela veut habituellement dire qu'elle doit être liée au frontpage.
Si vous configurez cette valeur en un string, cela sera l'URL retourné si l'URL est de toute façon vide. Si vous configurez cette valeur en vrai (PHP boolean, “TRUE”), alors cela retournera le baseURL configuré en TSFE. Configurez le en “./” devrait marcher comme référence à la racine aussi. Mais ce n'est pas très joli. |
->partDef La définition du traçage entre un segment du chemin virtuel et une variable GET ou autre.
| Clé | Type | Description |
| type | string mot clé | Par défaut la zone défini le traçage de Getvar mais il y a des alternatives qui sont configurées en configurant le type de clé : “action” : Si configuré, le segment peut définir des actions variées, comme configurer l'édition frontend ou re-diriger vers une certaine URL, en configurant quelques paramètres. |
| type = “action” | ||
| index[segment] index[“_DEFAULT”] | ->actionConfig (ou valeur vide qui n'acceptera que le segment mais ne fait aucune action dessus) | La zone d'index définies des actions variées et le premier segment de ce chemin est utilisé comme clé pour voir quelle action prendre dans la zone. Voir -> actionConfig pour plus de détails et exemples. |
| Type par Défaut | ||
| GETvar | Le nom de var GET pour lequel ce processus est accompli.
Nécessite La valeur de GETvar passera par une transformation définie par les autres oprions de configuration ici. Fondamentalement voici le processus : Premièrement, vérifier si “condPrevValue” permet le processus et si non, retourner en accord. La valeur est traduite par le “valueMap” si les entrées correspondent. Si aucune entrée dans “valueMap” ne correspond, “noMatch” est consulté pour une action concernant cette situation. Si noMatch ne s'active pas, nous chercherons après une table lookup et si définie nous ferons une translation look up (“lookUpTable”). Si aucune table lookup n'est définie pour traduire la valeur, nous chercherons la “valueDefault” et si configuré, appliquerons cette valeur. Si aucune de ces actions ne capture la valeur nous passons juste à côté dans sa forme d'ensemble. | |
| cond['prevValueInList'] | list of values | Si cette clé est configuré, le segment ne sera traité que si la valeur précédente est trouvée dans la liste de virgule de cette valeur! Autrement il sera contourné. |
| valueMap | array of “segment” => “Get var value” (table de traduction) | La cart de valeur est une table de traduction statique ou chaque clé représente un segment de l'URL parlante et la valeur de la clé est une valeur vrai de ce paramètre. Quand les URLs sont encodés cette table est inversée et s'il y a des valeurs dupliquées la dernière entrée est utilisée en tant que valeur d'URL parlante. |
| noMatch | string mot clé | Les mots clés définissant l'action si la valeur ne correspond à aucune entrée dans la zone de carte de valeur.
“bypass” : Veux dire que si le segment de chemin ne correspond PAS à aucune entrée dans “valueMap” le segment sera re-appliqué à la pile et nous retournons/cassons (et ainsi préservons le paramètre pour le prochain segment) “null” : Veux dire que si la valeur n'est PAS trouvé dans la valuemap le getParameter n'est pas configuré du tout. |
| lookUpTable | ->lookUpTable | Configuration de la table de base de données par laquelle effectuer les traductions de id en string alias. |
| valueDefault | string | Valeur par défaut à configurer si le segment de chemin ne correspond à aucune entrées dans “valueMap” ou a été autrement capturé pour la traduction. Notification : Les valeurs par défaut sont appliquées APRES que toute configuration “noMatch” soient traitées (et les autres, voir la description du flux pour la clé “GETvar”) |
Exemple:
1: 'preVars' => array( 2: array( 3: 'GETvar' => 'no_cache', 4: 'valueMap' => array( 5: 'no_cache' => 1, 6: ), 7: 'noMatch' => 'bypass', 8: ), 9: array( 10: 'GETvar' => 'L', 11: 'valueMap' => array( 12: 'dk' => '1', 13: 'danish' => '1', 14: 'uk' => '2', 15: 'english' => '2', 16: ), 17: 'noMatch' => 'bypass', 18: ), 19: ),
L'exemple ci-dessus montre la configuration qui permet deux prevars dans un chemin MAIS ils sont tout deux optionnels (à cause de la configuration 'noMatch'=>'bypass'). Normalement une URL dans le langage par défaut ressemblerait à ça :
123/page.html
Ensuite, si le GETvar L=1 est configuré, l'URL serait comme ceci :
danish/123/print.html
Enfin, si le premier segment correspond au “no_cache” la var GET “no_cache=1” est configuré et l'interprétation du langage GETvar est déplacé au segment 2 :
no_cache/danish/123/print.html
Le concept d'outrepasser les valeurs ne correspondant pas ouvre la possibilité d'erreur si deux valeurs venant de configurations voisines correspondent. Par exemple des erreurs pourrait résulter du fait d'avoir un langage marqué “no_cache” étant donné que c'est un mot clé dans la configuration du premier segment ! Retirer la configuration “noMatch” apportera ces URLs à la place :
//123/page.html /danish/123/page.html no_cache/danish/123/print.html
Une meilleur solution serait de configurer la valeur par défaut pour le langage :
1: 'preVars' => array( 2: array( 3: 'GETvar' => 'no_cache', 4: 'valueMap' => array( 5: 'no_cache' => 1, 6: ), 7: 'noMatch' => 'bypass', 8: ), 9: array( 10: 'GETvar' => 'L', 11: 'valueMap' => array( 12: 'dk' => '1', 13: 'danish' => '1', 14: 'uk' => '2', 15: 'english' => '2', 16: ), 17: 'valueDefault' => 'uk', 18: ), 19: ),
Cela donnerait ce résultat : uk/123/page.html danish/123/page.html no_cache/danish/123/print.html
Cela maintient toujours la configuration de de bypass pour le paramètre “no_cache” mais cela pourrait plutôt bien s'insérer dedans. Exemple: “fixedPostVars”
1: 'fixedPostVars' => array( 2: 'testPlaceHolder' => array ( 3: array( 4: 'GETvar' => 'tx_extrepmgm_pi1[mode]', 5: 'valueMap' => array ( 6: 'new' => 1, 7: 'categories' => 2, 8: 'popular' => 3, 9: 'reviewed' => 4, 10: 'state' => 7, 11: 'list' => 5, 12: ) 13: ), 14: array( 15: 'condPrevValue' => '2', 16: 'GETvar' => 'tx_extrepmgm_pi1[display_cat]', 17: 'valueMap' => array ( 18: 'docs' => 10, 19: ), 20: ), 21: array( 22: 'GETvar' => 'tx_extrepmgm_pi1[showUid]', 23: 'lookUpTable' => array( 24: 'table' => 'tx_extrep_keytable', 25: 'id_field' => 'uid', 26: 'alias_field' => 'extension_key', 27: 'addWhereClause' => ' AND NOT deleted' 28: ) 29: ), 30: array( 31: 'GETvar' => 'tx_extrepmgm_pi1[cmd]', 32: ) 33: ), 34: '1383' => 'testPlaceHolder', 35: ),
Cette configuration montre comment “fixedPostVars” peut être utilisé comme “preVars” mais après le chemin de page. Typiquement il sera utilisé sur une page seule ou un plugin connu fonctionne. C'est le cas dans l'exemple ci-dessus ; l'id de page “1383” pointe vers la configuration “alias” nommée “testPlaceHolder”. L'exemple est prévu pour l'Extension Repository de typo3.org. La configuration à installé une séquence de 3-4 segments dans le chemin virtuel. Le premier est le menu principal, ou les valeurs intégrées définissent le mode, est tracé pour de beaux strings alias. Le second segment est la catégorie id à afficher mais notez comment est configuré le “condPrevValue” en “2” - cela veut dire que seulement si la variable précédente est '2' alors le segment sera interprété, autrement outrepassée ! Finalement il y a l'extension uid, ici configurée pour la traduction vers/de la clé d'extension. C'est un processus sans danger comme les clés d'extension sont uniques. Finalement la 'commande' qui définie le niveau de menu quand on affiche les extensions seules. Cette configuration permet pour une URL comme celle-ci (4 segments dans la séquence “fixedPostVars”): http://typo3.org/1383/categories/docs/doc_core_cgl/details/
Ou (seulement 3 segments dans la séquence “fixedPostVars”, comme le premier segment n'était pas de 'catégorie' / 2) http://typo3.org/1383/popular/skin1/details/ ->Table de recherche (lookUpTable) Définie une table à utiliser pour rechercher dans les traductions d'id pour les strings alias pour GETvars.
| Clé | Type | Description |
| table | string | Nom de la table |
| id_field | string | Nom du champ supportant l'id, typiquement un nombre entier, par exemple 'uid' |
| alias_field | string | Nom du champ supportant le string alias correspondant à l'id. Devrait être unique. |
| addWhereClause | string | Supplément ou la clause pour ajouter la requête de recherche. Doit être configuré automatiquement, même pour les champs 'effacer' comme la recherche peux prendre place avant que la configuration de toute table ne soit accessible ! Valeur d'exemple : “AND NOT effacer” |
| maxLength | integer | Définie la taille maximum acceptée de la valeur alias. Si la valeur alias est plus longue que la valeur original intégrée, la valeur original sera remise à la place. Valeur par défaut : '100' |
| useUniqueCache | boolean | Si configuré , la traduction de l'id en alias est automatiquement stockée dans la table de recherche ou l'unicité de l'alias est assuré ; Lors du stockage il est simplement vérifié si l'alias est déjà associé avec une autre ID (dans la même combinaison table/champs) et si oui un alias unique est créé, typiquement l'alias demandé avec des nombres apposés. |
| useUniqueCache_conf['strtolower'] | boolean | Si configuré, les alias sont convertis strtolower() |
| useUniqueCache_conf['spaceCharacter'] | string | Normalement, ce sont par défaut un souligné (_), qui est utilisé pour remplacer les espaces et autres dans une URL. Vous pouvez configurer ceci par exemple un trait d'union (-) si vous voulez. |
Exemple
'lookUpTable' => array(
'table' => 'user_3dsplmxml_bfsbrand',
'id_field' => 'xml_id',
'alias_field' => 'xml_title',
'maxLength' => 10,
'addWhereClause' => ' AND NOT deleted'
)
->Configuration d'action (actionConfig)
| Clé | Type | Description |
| type | Mot clé string | L'action est identifiée par l'un de ces mots clé :
“admin” : Active les dispositifs d'Edition Frontend (dispositif similaire à ->postVarSet, type = “admin”. “redirect” : Vous rediriges vers une autre URL avec des marqueurs optionnels remplis avec la valeur de segment de chemin et le chemin restant. Utile pour les raccourcis de site. “notfound” : Lance une erreur 404 “bypass” : Outrepasse ET ajoute de nouveau la clé dans la pile ! default: Traverse (Sans ajouter la clé à la pile). Notification concernant la clé “_DEFAULT” : Si le type “_DEFAULT” n'est pas “bypass” (voulant dire que l'action _DEFAULT est de faire quelque chose) la méthode d'encodage URL cherchera pour la première occurrence d'une action d'aucun type (traverse sans ajouter la clé à la pile) et utilise cela comme valeur de segment. |
| url | string | L'URL vers laquelle se rediriger. Il y a deux marqueurs que vous pouvez utiliser dans l'URL :
|
Exemple: Prefixes redirects et required
1: 'redirects' => array( 2: => 'cms/', 3: 'mailinglist/' => 'http://lists.netfielders.de', 4: ), 5: 'preVars' => array ( 6: array( 7: 'type' => 'action', // "type" action 8: 'index' => array( 9: 'cms' => , // Just bypass 10: 'admin' => array( 11: 'type' => 'admin' // Jump BE login OR setting frontend edit flags... 12: ), 13: 'search' => array( 14: 'type' => 'redirect', // Redirect... 15: 'url' => 'index.php?id=1344&tx_indexedsearch[sword]=###REMAIN_PATH###', 16: ), 17: 'ext' => array( 18: 'type' => 'redirect', // Redirect... 19: 'url' => 'cms/1383/list/###REMAIN_PATH###/index.html', 20: ), 21: '_DEFAULT' => array( 22: 'type' => 'notfound' // If key was not found in index, throw "404" not found. 23: ), 24: ), 25: ), 26: ),
Dans cet exemple le premier segment de l'URL est configuré pour être une action. Le segment est requis depuis que le “type” de l'index “_DEFAULT” est configuré en“notfound” voulant dire que si aucune autres clés ne correspond vous verres une erreur “Page not found”. Quoi qu'il en soit, les exemples sont excentrées dans le website de typo3.org et ce sont les conséquences de la configuration ci-dessus:
| URL | Ce qui arrive |
| http://typo3.org/ | Cette URL résultera en une erreur 404 si la configuration n'est pas redirigé en ligne 1-4 da la configuration. Ici le système à pour ordre de rediriger vers “cms/” au cas ou il n'y aurait pas de chemin virtuel trouvé. |
| http://typo3.org/cms/1420/ | Cela affichera l'ID de page 1420. La clé d'action “cms” ne fait rien – elle outrepasse juste le processus au niveau suivant qui est l'ID résolu de page. En configurant un tel prefix vous définissez, fondamentalement, tout votre site pour fonctionner à partir du dossier virtuel “cms/”. La configuration est en ligne 9 |
| http://typo3.org/admin/1420/ | Cela affichera aussi l'ID de page 1420 mais active les icônes d'édition frontend dans l'interface – et si l'utilisateur n'est pas actuellement connecté en tant qu'utilisateur backend, une redirection au formulaire de connexion backend se produira. La configuration de ce dispositif est en ligne 10-12 Lors de l'utilisation du déclenchement de l'édition frontend (“admin”) dans “realurl” le segment “admin/” du chemin sera transporté à côté dans les liens sur le site donc vous restez en mode admin jusqu'à ce que vous le retirer de nouveau. Mais cela veux aussi dire que la mise en cache est annulé pour toutes les pages donc les liens de page ne sont jamais stockés avec l'action “admin/” enclenché ! |
| http://typo3.org/search/system+requirements | Redirigera vers http://typo3.org/index.php?id=1344&tx_indexedsearch[sword]=system%2Brequirement qui est la page le plugin indexed_search est actif et met en marche automatiquement une recherche pour les mots après “search/”. C'est configuré en ligne 13-16; Notez comment la recherche de mot (le chemin restant) est automatiquement insérée dans l'URL par le string marqueur “###REMAIN_PATH###” |
| http://typo3.org/ext/lang | Redirigera vers http://typo3.org/cms/1383/list/lang/index.html ou “lang” est inséré par le marqueur “###REMAIN_PATH###” simplement comme l'action “search” précédente. Les principes sont les mêmes. Configuration en ligne 17-20 |
| http://typo3.org/mailinglist/ | Redirigera vers http://lists.netfielders.de en accord avec la ligne dans la configuration |
Exemple: Prefixe de Langage et action “admin”
1: 'preVars' => array ( 2: array( 3: 'type' => 'action', // "type" action 4: 'index' => array( 5: 'admin' => array( 6: 'type' => 'admin' // Jump BE login OR setting frontend edit flags... 7: ), 8: 'search' => array( 9: 'type' => 'redirect', // Redirect... 10: 'url' => 'index.php?id=1344&tx_indexedsearch[sword]=###REMAIN_PATH###', 11: ), 12: 'ext' => array( 13: 'type' => 'redirect', // Redirect... 14: 'url' => 'cms/1383/list/###REMAIN_PATH###/index.html', 15: ), 16: '_DEFAULT' => array( 17: 'type' => 'bypass' // If key was not found in index, throw "404" not found. 18: ), 19: ), 20: ), 21: array( 22: 'GETvar' => 'L', 23: 'valueMap' => array( 24: 'dk' => '1', 25: ), 26: 'noMatch' => 'bypass', 27: ), 28: ),
Dans cet exemple deux preVars sont configurés, le premier est une action contenant presque les même actions que l'exemple précédent excepté la configuration de “_DEFAULT” de type “bypass” ce qui veux dire que si aucune des clés ne correspond au premier segment l'interprète bougera simplement vers la configuration preVar suivante pour ce segment (outrepassant et ajoutant la valeur du segment à nouveau sur la pile). En supplément il y a un prefix de langage aussi. Le résultat de cette configuration devrait être clair en regardant les exemples dans le tableau suivant :
| URL | Ce qui arrive |
| http://typo3.org/1420/ | Affiche la page 1420 |
| http://typo3.org/admin/1420/ | Affiche la page 1420 avec les icônes d'édition Frontend |
| http://typo3.org/dk/1420/ | Affiche la page 1420 en danois (&L=1) |
| http://typo3.org/admin/dk/1420/ | Affiche la page 1420 en danois (&L=1) avec les icônes d'édition Frontend |
->Chemin de page (pagePath)
Configuration de le méthode qui encode/décode l'id vers/du 'chemin de page'
| Clé | Type | Description |
| type | string | Configure la méthode utilisée pour encoder/décoder l'ID.
Le défaut est de simplement configurer l'id/alias de page en tant que simple entrée dans le chemin virtuel. “user” : Appelle une classe externe pour la génération. |
| userFunc | Fonction de reference | Fonction de référence pour manipuler l'encodage de l'id.
Des exemples peuvent être trouvés dans class.tx_realurl_dummy.php Une implémentation complète est trouvable dans “class.tx_realurl_advanced.php”. Voir plus de détails plus loin dans la documentation concernant cela. Valeur d'exemple : EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main |
Exemple de traduction d'id de page en chemin :
'pagePath' => array(
'type' => 'user',
'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced- >main',
'spaceCharacter' => '-',
'languageGetVar' => 'L',
'expireDays' => 3
),
Appelle une fonction utilisateur qui rendra une URL parlante véritable des pages de titres et non pas simplement un rendu des nombres d'id de page. Voir la description complète de cette classe plus tard dans ce document, chapitre “class.tx_realurl_advanced.php”
Par la configuration ci-dessus des URLs ressembleront à ceci (avant/après):
1420/index.html extensions/index.html 1420/repository/popular/skin1/details/index.html extensions/repository/popular/skin1/details/index.html 1440/index.html documentation/glossary/index.html 1409/index.html about/license/gpl-for-developers/index.html 1342/showreference/52/ about/yet-another-typo3-site/showreference/52/
Exemple de configuration de dummy :
'pagePath' => array(
'type' => 'user',
'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_dummy- >main',
),
Appelle une classe factice qui fait exactement ce que fait la classe principale : Produit la page id/alias et rien de plus. Mais si vous voulez mettre en application vos propres arrangements cette classe est un excentrage utile pour vous! ->Configuration postVar (postVarSet)
| Clé | Type | Description |
| type | string de mot clé | Par défaut un postVarSet consiste en
Un exemple (de précédemment) est “news/list/456/” ou le mot clé “news/” (premier segment) identifie la séquence suivante (“list/456/”) pour être tracé pour le GET-vars tx_mininews[mode] et tx_mininews[showUid] respectivement (suivant la configuration). La configuration de la séquence est effectuée par une zone numérique de ->partDef. Autres modes: Il y a d'autres modes que le mode par défaut et ils peuvent êtres activés en configurant la clé “type” à la d'un mot clé suivant. Dans ce cas alternatif il ne peux y avoir de sequence de segments après le mot clé, mais mais le mot-clé déclenche toujours le mode alternatif de sorte qu'il soit toujours autour. “single” : Utiliser ce mot clé le lie pour représenter un montant exact de GETvars avec des valeurs exactes. Cela fonctionne précisément comme des noms de fichiers lié au GETvars (voir ->Nom de fichier) “admin” : Utiliser ce mot clé fait que le backend activera le mode d'édition frontend pour l'utilisateur, montrant les icônes d'édition de contexte sensible. Si l'utilisateur n'est pas connecté en tant qu'utilisateur backend alors il sera redirigé au formulaire de connection backend d'ou l'utilisateur pourra se connecter et après s'être connecté avec succès l'utilisateur sera redirigé à la page précédente. |
| [0..x] | ->partDef | La configuration de la sequence associée au 'mot clé' qui définie ce postVarSet. |
| keyValues | Zone de [GETvar] => [valeur string] | La zone 'Valeur de clé' définie une ou plus variable GET avec des valeurs spécifiques. Le mot clé du postVarSet correspond si tout les GET-vars configurés dans [“keyValues”] se trouvent dans le pool restant de GET vars qui ont besoins d'une traduction et si les valeurs correspondent exactement ! |
Exemple: Edition Frontend
1: 'postVarSets' => array ( 2: '_DEFAULT' => array( 3: .... 4: 'edit_now' => array( 5: 'type' => 'admin' 6: ) 7: ), 8: )
Ajouter les lignes 4-6 dans le codesnippet ci-dessus à une configuration postVarSets activera le mode d'édition frontend si les utilisateurs apposent “.../edit_now/” au chemin virtuel. Bien sur vous pouvez choisir tout “admin-directory” que vous voulez. Un avertissement ici ; Si le mot clé est apposé à l'URL ou une séquence postVarSet précédente n'est pas encore terminée alors le mot clé sera bien sur vu comme un paramètre de ce postVarSet et non comme le mot clé activant le mode édition frontend comme vous le souhaitiez. Par conséquent vous pourriez vouloir employer le même dispositif mais pour des pre-vars à la place. Exemple: PostVarSets
1: 'postVarSets' => array( 2: '_DEFAULT' => array ( 3: 'plaintext' => array( 4: 'type' => 'single', // Special feature of postVars 5: 'keyValues' => array ( 6: 'type' => 99 7: ) 8: ), 9: 'ext' => array( 10: array( 11: 'GETvar' => 'tx_myExt[p1]', 12: ), 13: array( 14: 'GETvar' => 'tx_myExt[p2]', 15: ), 16: array( 17: 'GETvar' => 'tx_myExt[p3]', 18: ), 19: ), 20: 'news' => array( 21: array( 22: 'GETvar' => 'tx_mininews[mode]', 23: 'valueMap' => array( 24: 'list' => 1, 25: 'details' => 2, 26: ) 27: ), 28: array( 29: 'GETvar' => 'tx_mininews[showUid]', 30: ), 31: ), 32: ), 33: ),
Cet exemple montre comment trois ensembles de postVarSets ont été configurés, desquels deux d'entre eux sont de type defaut (mot clé + séquence de GETvars) pendant que le troisième est de type 'seul', tracé pour une valeur GETvar fixe. De façon à comprendre cette configuration et l'effet qu'il produit vous pourriez étudier ces exemples commentés basés sur la configuration ci-dessus. Chaque exemple consiste en deux lignes ou le premier est l'URL avec des paramètres GET et le second est la version URL parlante de la première.
index.php?id=123&tx_myExt[p3]=ccc&tx_myExt[p2]=bbb&tx_myExt[p1]=aaa 123/ext/aaa/bbb/ccc/
Ci-dessus, le postVarSet “ext”est utilisé pour encoder les paramètres GET. La séquence est initiée par le mot clé “ext” et les trois segments suivants du chemin virtuel est tracé pour les trois GET-vars configurés pour le mot clé et dans l'ordre de leur apparition dans la configuration ci-dessus (ligne 10-18)
index.php?id=123&tx_myExt[p1]=aaa 123/ext/aaa/
index.php?id=123&tx_myExt[p1]=aaa&tx_myExt[p2]=bbb 123/ext/aaa/bbb/
Les deux exemples ci-dessus montrent ce qui arrive si seulement un ou deux des paramètres sont utilisés – fondamentalement les valeurs vides sont dépouillées à la fin du chemin.Le premier exemple donnerait actuellement “123/ext/aaa///” et le second serait “123/ext/aaa/bbb//” mais depuis que les valeurs vides sont à la fin du chemin nous pouvons sans risque les dépouiller comme le montre l'exemple.
index.php?id=123&tx_myExt[p1]=aaa&tx_myExt[p3]=ccc 123/ext/aaa//ccc/
Dans cet exemple seul “tx_myExt[p1]” et “tx_myExt[p3]” sont utilisés et puisque la séquence demande “p2” pour être entre les deux nous devons accepter le segment vide du chemin virtuel.
index.php?id=123&tx_mininews[showUid]=123&tx_mininews[mode]=1 123/news/list/123/
Dans l'exemple ci-dessus les paramètres mininews sont encodées, utilisant le mot clé 'news'. Notez que le “tx_mininews[mode]” GETvar possède une table de traçage qui permet la traduction automatique entre les valeurs '1' et 'list' utilisés dans l'URL virtuelle. Ce dispositif (et les autres options similaires) permettent de créer vraiment des URLs parlantes même pour les paramètres qui sont des nombres ID.
index.php?id=123&tx_mininews[showUid]=123&tx_mininews[mode]=1&tx_myExt[p1]=aaa & tx_myExt[p2]=bbb&tx_myExt[p3]=ccc 123/ext/aaa/bbb/ccc/news/list/123/
Dans cet exemple nous avons deux postVarSets, nommés “ext” et “news”. Comme vous pouvez le voir ce n'est pas un problème du tout tant que les séquences contiennent le montant correct de segments ainsi le mot clé suivant est enregistré. Notez que le mot clé “ext” est listé en premier. C'est parce que l'“ext” postVarSet est le premier trouvé dans la configuration et donc est activé avant le postVarSet “news”.
index.php?id=123&tx_mininews[showUid]=123&tx_myExt[p1]=aaa&tx_myExt[p3]=ccc 123/ext/aaa//ccc/news//123/
Dans cet exemple nous avons laissés deux paramètres de l'URL précédente et cela veux dire qu'il y a deux segments vides dans le chemin virtuel. Il n'y a aucun moyen de contourner ceci comme la taille de la séquence doit être respectée et dans le cas de postVarSet “news” le “mode” était défini avant le paramètre “showUid” ce qui veux dire qu'il n'est pas possible de dépouiller la valeur vide.
index.php?id=123&type=99&tx_myExt[p1]=aaa&unknownGetVar=foo 123/plaintext/ext/aaa/?unknownGetVar=foo
Cet exemple est uniquement différent aux exemples ci-dessus par le fait de montrer ce qui arrive à un Get var inconnu quand une URL est encodée ; Plutôt simplement ce GET var arrive à l'URL finale – quoi d'autre ! ->Nom de fichier (fileName) Configuration de la signification du nom de fichier dans le chemin virtuel.
| Clé | Type | Description |
| index[filename][“keyValues”] | Zone de [GETvar] => [string value] | L'“index” est une zone de nom de fichiers virtuels (par ex. “page.html”) qui sont associés avec une ou plus variables GET avec des valeurs spécifiques.
Un nom de fichier est choisi durant l'encodage si tout les the GET-vars configurés dans index[filename][“keyValues”] est trouvé dans le pool restant de GET vars qui nécessitent des traductions et si la valeurs correspond exactement ! La valeur du nom de fichier “_DEFAULT” est utilisé si aucune correspondance n'est trouvé. Important: l'ordre dans lequel les noms de fichiers apparaissent est d'une grande importance étant donné que le premier nom de fichier correspondant sera choisi. Vous pouvez arrangez les noms de fichiers stratégiquement. Voir l'exemple ci-dessous. |
| defaultToHTMLsuffixOnPrev | boolean | Si configuré, alors la dernière partie du dossier du chemin virtuel étant fait sera modifié dans le suffix du nom de fichier “.html” Si la partie du nom de fichier est non-existante.
Par exemple, “workplace-learning-solutions/companion-solutions/” sera transformé en “workplace-learning-solutions/companion-solutions.html” et la basepart du nom de fichier (dépouillant l'extension“.html”) sera toujours perçue comme la dernière partie du chemin virtuel. Cette approche est utile si vous voulez simuler des documents HTML même si vous ne configurez pas le traçage de tout nom de fichier. |
Exemple: Nom de fichier multiples pour un frameset
1: 'fileName' => array ( 2: 'index' => array( 3: 'print.html' => array( 4: 'keyValues' => array ( 5: 'print' => 1, 6: 'type' => 1, 7: ) 8: ), 9: 'page.html' => array( 10: 'keyValues' => array ( 11: 'type' => 1, 12: ) 13: ), 14: 'top.html' => array( 15: 'keyValues' => array ( 16: 'type' => 2, 17: ) 18: ), 19: '_DEFAULT' => array( 20: 'keyValues' => array( 21: ) 22: ), 23: ), 24: ),
Cet exemple peux être la configuration d'un site web à base de frames. Quand il ne devrait pas y avoir de valeur “type” la clé par défaut est utilisée (ce qui ne rend aucun nom de fichier bien sur) mais si la valeur type est 1 ou 2 soit “page.html” ou “top.html” est utilisé ; ces noms de fichiers représentent alors le GET var “&type=1” et “&type=2” respectivement durant le décodage. Notez également comment le paramètre “&print=1” à été encodé en nom de fichier ! L'idée est que si un nom de fichier est “print.html” alors deux GET vars sont configurés ; “&type=1” et “&print=1”. Mais vous devez être très prudent pour comment vous arrangez les noms de fichiers ; si “print.html” était entré sous “page.html” alors il n'aurait jamais été utilisé vu que la première correspondance gagne et “page.html” aurait été trouvé comme correspondance exact avec “&type=1” et donc le “&print=1” GET var serait arrivé à l'URL (comme “page.html?print=1”) au lieu d'être encodé en nom de fichier (“print.html”). Exemple: Nom de fichier par defaut
'fileName' => array (
'index' => array(
'index.html' => array(
'keyValues' => array(
)
),
),
),
Cette exemple montre une configuration qui prefix le nom de fichier “index.html” par défaut quoi qu'il en soit.
[modifier] Manipulation de liens relatifs avec des URLs parlantes
Par défaut, TYPO3 génère tout les liens vers d'autres pages comme www.server.com/index.php?id=123&type=0, donc toutes les pages semblent être dans un dossier (filesystem-) : la racne du site web. Le problème est que, autant d'extensions (et le coeur du code de TYPO3 ) comptent sur les images, javascripts, etc. pour être dans un dossier relatif à la racine de TYPO3, comme “typo3/ext/indexed_search/pi/res/pages.gif”. Cette approche ne marche pas quand le chemin change constamment.
Par exemple, un fichier “fileadmin/my_image.jpg” référencé à partir de “index.php?id=123” sera trouvé car “index.php” est dans la racine du site web ou se trouve aussi le dossier “fileadmin/”. Mais dès que l'URL “index.php?id=123” est encodée en URL parlante , disons “contact/company_address/”, alors votre navigateur essaiera de trouver l'image dans “contact/company_address/fileadmin/my_image.jpg” ou il n'est de toute évidence pas localisé.
Donc pour résoudre ce problème vous
1.soit devrez mettre un prefix à toutes références relative avec un chemin absolu à la racine du site.
2.Ou configurer le tag <base> dans les en-têtes de fichiers HTML dans la racine du site.
config.absRefPrefix
Il y a une directive TypoScript-setup pour configurer un prefix absolu à tout les liens et images (config.absRefPrefix), mais malheureusement suffisamment ne sont pas implémenté partout (la recherche indexé et l'édition frontend par exemple), donc cela ne marche pas très bien. Veuillez ne pas utiliser config.absRefPrefix. Il possède de vilaines propriétés qui rendent les RealURLs complétement inutilisable parfois. Le seul problème est que la page 404 de TYPO3 ne possède pas le tag <base> donc il n'affiche pas le logo TYPO3 :) On pourrait permettre le soutien de ceci quand les bugs seront réparés mais généralement il exigera toutes les références de génération de code pour employer cette méthode et cela ne peut pas être garanti pour toutes les extensions naturellement.
<base> tag
Il y a cependant une solution très simple dans l'HTML : fournissez simplement le tag <base> dans le <head> de vos pages, comme : <base href="http://your.domain.com/"> Pour faire que vos templates TypoScript soient activés pour RealURL, vous devriez inclure auparavant cet état dans vos templates HTML, ou utiliser le snippet TypoScript suivant :
config.baseURL = 1
Cela lira automatiquement ce qu'est la base URL actuelle sur votre site web (en utilisant t3lib_div::getIndpEnv('TYPO3_SITE_URL')) et en créant un tag <base> dans l'en-tête du rendement HTML dans le frontend. Si pour quelque raison vous souhaitez configurer une autre URL à la place de cele créé automatiquement vous pouvez le configurer comme cela :
config.baseURL = http://your.domain.com/
La méthode de tag <base> semble fonctionner impeccablement dans TYPO3 excepté en deux cas ou vous avez un lien comme <a href=”#anchor_point”....> - cela ne marche pas parce que il réfère à la racine du site mais il semble que ce soit une référence 'interne' dans le document actuel. Cependant vous pouvez résoudre cette situation d'une manière simple:
config.prefixLocalAnchors = all
Cela configurera le préfixe nécessaire pour tout événement de type '<a href=”#....”....' dans la page ; fondamentalement partout ou une ancre est générée. Cette substitution se produit par un ereg_replace sur le contenu de page général après rendement. Voir Tsref pour les détails. L'autre situation est spécifique pour MSIE ; quand vous configurez le "document.location" via JavaScript, MSIE comprendra des URLs relatives à l'URL actuelle, pas l'URL de <base>. Donc vous devrez mettre préfixer l'URL de base. Vous pouvez trouver cette valeur dans $GLOBALS['TSFE']->baseUrl (ou utiliser t3lib_div::getIndpEnv("TYPO3_SITE_URL")). Attention: Il peut être dangereux d'activer “config.baseURL = 1” (la création automatique de l'URL de base) si vous êtes capable d'accéder au site web à partir d'une adresse IP ou d'un network interne. Dans un tel cas l'URL de base peut être “http://192.168.1.123/my_site/” qui a) ne marchera pas, pour qui que ce soit visitant votre site de l'extérieur et b) révèle des informations sur le dossier structurel du serveur (sécurité). Ce problème n'apparaîtra pas si les pages ne sont pas misent en cache lorsqu'elle sont visitées du network interne mais si les pages sont mises en cache durant des visites internes du site l'URL de base interne sera sur les pages que les gens de l'extérieur voient, d'ou le problème! En fait c'est vrai aussi si les pages sont générées et mises en caches par “index.php?id=123” et alors ensuite requises par une URL parlante – puis une page générée à partir d'une 'fausse' localisation afichera le contenu mis en cache de la mauvaise localisation.
[modifier] Créer des extensions compatibles avec “config.baseURL”
Si vous configurez “config.baseURL” et plus tard “config.prefixLocalAnchors = all” alors les extensions pourrait toujours produire de mauvaises ancres locals. Si les extensions incluent un contenu de page non mise en cache par USER_INT or USER_EXT cObjects ce contenu n'est pas traité ! (à moins que “config.prefixLocalAnchors” soit configuré en “output”). Pour de telles extensions il peut y avoir un support inhérent pour “realurl” et cela peut être fait (avec pleine retro compatibilité) en préfixant toutes les ancres locales faites par le résultat de ceci :
substr(t3lib_div::getIndpEnv('TYPO3_REQUEST_URL'),strlen(t3lib_div::getIndpEnv( 'TYPO3_SITE_URL')));
ou dans les versions récentes de TYPO3 :
$GLOBALS['TSFE']->anchorPrefix
Généralement Soyez sur d'avoir inclus soit la configuration dans tous les types de page qui sont générées !
[modifier] class.tx_realurl_advanced.php
[modifier] Introduction
La classe tx_realurl_advanced offre l'encodage d'IDs de page avancé en chemins incluant l'encodage en titre localisés et management de cache... [martin, finissez cette section concernant votre script ... J'ai déjà importé un peu de votre documentation mais vous DEVRIEZ le relire et le faire plus significatif dans le nouveau contexte. Je n'ai rien coupé car c'est mal, donc ajoutez tout contenu plus ancien s'y intégrant toujours...]
[modifier] Méthode de résolution de page, comment ça marche ?
Jetons d'abord un oeil sur un cas simple, ou tout marche bien et rien ne tourne mal : Lorsque vous tappez une URL (u cliquez dessus), elle est recherché dans le bien nommé cache URL. Assumant qu'elle soit trouvé, nous connaissons alors l'ID de page (à partir du chemin) pour générer une page correct. Et c'est fini. Maintenant, quelque chose peux tourner mal ici : Premièrement, les chemins générés par RealURL ne contiennent uniquement que a.z, 0..9 et soulignés ('_'), donc c'est une bonne idée de dépouiller l'URL de tout caractères non voulus avant que nous l'examinions. Donc nous le faisons :) En outre, si l'URL n'est pas trouvée dans le cahce de l'Url (par exemple quand le cache est vidé), nous devons la rechercher dans la base de données. Ceci est fait en examinant d'abord la partie domaine, et en recherchant ensuite chaque 'dossier' dans l'URL jusqu'à ce que nous atteignions la page de destination. La partie langage (si présente) est également traduite en ID de langage. Ce résultat est mis en cache, ainsi nous pouvons l'employer plus tard. Si la langue n'était pas donnée dans l'URL, une fonction est appellé pour figurer quelle langue sera la plus appropriée. J'ai créé un certain code qui ressemble à une adresse IP haut dans l'IP2Country-database (une table), que j'ai importé dans la base de donnée TYPO3. Je pourrais créer une extension séparée pour ceci, mais pour le moment vous pouvez retirez les commentaires du code si vous voulez l'employer. Recherchez après getDefaultLangID(). Quand l'ID de page est trouvée, un autre contrôle est fait (après que TYPO3 ai chargé toutes sortes d'informations sur la page): il vérifie pour voir si l'URL demandé correspond a la 'vrai' URL de la page. Ceci pourrait être différent dû aux changements du titre de page de la page, ou un de ses parents. Ou, on pourrait avoir écrit l'URL d'une page qui serait un raccourci vers la vraie page. Dans ces cas, l'utilisateur est réorienté vers la vrai/officielle/nouvelle URL de la page et en cas de titre de page changé, la vieille URL est marqué comme 'expirant'. Ceci permet de changer le titre de page d'une page (et ainsi l'URL), mais que l'on puisse toujours accéder cette page par la vieille URL, qui sera encore employé par exemple par Google. Un problème surgit quand vous créez une autre page, avec le même titre qu'une page ayant déjà existée, parce que cette URL dirige toujours vers l'autre page. Par conséquent, si RealURL remarque que vous avez écrit une URL expirant, il recherche la base de données comme si l'URL n'était pas trouvé dans le cache. Si une page est trouvée de cette façon, cette nouvelle URL + ID de page est mise en cache à la place. Si aucune page n'est trouvée, le résultat mis en cache sera employé. L'autre manière est beaucoup plus simple : quand une URL doit être produit pour une certaine page, elle est recherché dans le même cache URL. S'il n'est pas déjà là, l'URL sera créé en construisant le prétendu RootLine pour la page, en filtrant chaque titre de page de sorte qu'il contienne seulement a..z, 0,,9 et soulignages et en le mettant en cache finalement. Ce processus tient compte des langues, ainsi si vous utilisez le navigateur en version hollandaise d'une page, vous obtiendrez une URL hollandaise (en utilisant les titres de pages hollandais).
[modifier] Configuration
Vous devriez créer des enregistrements de Domaine aux pages où les domaines commencent. Même si vous avez seulement un domaine, c'est une bonne idée de créer un enregistrelent de Domaine pour lui. Il y a une chose que vous devriez noter: Si vous avez installé TYPO3 dans la racine du document d'un hôte, vous devriez créer un nom d'enregistrement de domaine comme 'www.server.com '. Si, d'autre part, votre installation TYPO3 est dans un dossier différent, vous devriez créer un nom d'enregistrement de domaine comme 'www.server.com/the_path_to_your_typo'. Les slashs aux extrémités importes peu. Configurer “realurl” pour fonctionner avec l'encodage ID “tx_realurl_advanced”
Placez simplement cette configuration pour la clé "pagePath" dans la zone de configuration :
'pagePath' => array(
'type' => 'user',
'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main',
'spaceCharacter' => '-',
'languageGetVar' => 'L',
'expireDays' => 3
),
Les directives spécifiques pour "tx_realurl_advanced" sont celles-ci :
| Directive: | Type de données : | Description: |
| languageGetVar | string | Définit quelles variables GET dans l'URL qui définit l'id de langue; si réglé le chemin tiendra compte de cette valeur de langue et essayera de produire le chemin dans la version localisée. |
| expireDays | integer | Le temps des vieilles URL d'une page dont le titre de page changé sera toujours rappelé (en jours) (temporairement neutralisés) |
| spaceCharacter | Normalement, ceci est par défaut un soulignage (_), qui est employé pour remplacer les espaces et tels dans une URL. vous pouvez placer par exemple un trait d'union (-) si vous voulez. | |
| segTitleFieldList | list de noms de champs | L'ordre prioritaire de noms de champs à partir des table de pages (ligne racine !) utilisés lors de la construction d'URL parlante.
Par défaut “tx_realurl_pathsegment,alias,nav_title,title” (pour des enregistrements alternatif de langage de page c'est simplement “nav_title, title”). Notification: Si vous spécifiez des champs d'utilisateur défini n'étant pas encore dans la ligne de racine vous devrez les mettres à la ligne racine via “$GLOBALS['TYPO3_CONF_VARS']['FE']['addRootLineFields']” |
| disablePathCache | boolean | Désactivera l'utsage de cache de page. Le système se fondera seulement sur des vus précédentes des champs dans "segTitleFieldList". |
| firstHitPathCache | boolean | Si configuré, alors la vue de cache de chemin est acceptée seulement s'il revient un résultat au premier coup. Cela sera fait seulement quand aucun postVarSets ne sera utilisé pour l'URL. |
| rootpage_id | integer | Définie l'uid de page racine du site pour laquelle la configuration est faite. Cet arrangement est nécessaire si vous faites fonctionner de multiples sites dans la même base de données en utilisant de vrais urls pour plus d'un des sites. La configuration rend possible aux algorithmes "chemin-vers-ID" pour distinguer les sites. Par exemple deux sites pourraient avoir le même titre de page au premier niveau qui produira le même chemin d'URL parlante. En ce cas deux IDs différentes sont associées au même chemin de page et quelque chose est nécessaire pour distinguer la vue. Il est également nécessaire de placer ceci si le site "défaut" n'est pas la première page sous la racine d'arbre de page! Afin de configurer différents sites vous employez simplement la possibilité de faire différente configuration pour différents domaines. Voyez la section principale au sujet de la configuration. Il est important que vous employiez l'uid de la racine de page dans les sites. Autrement le résultat de vue de page ne fonctionnera pas correctement. Voir l'exemple ci-dessous |
| encodeTitle_userProc | function utilisateur | Utilisateur additionnel traitant dans l'"encodeTitle()" |
| dontResolveShortcuts | boolean | Si réglés, des raccourcis de page ne sont pas résolus à leur page de destination. |
| excludePageIds | string | La liste de virgule d'IDs de page à exclure d'être rendus en tant que realurl. La liste ne doit PAS contenir d'espaces entre les numéros d'id de page! |
Exemple: Configuration de realurl pour une utilisation sur plus d'un domaine dans la même base de données
1: $TYPO3_CONF_VARS['EXTCONF']['realurl'] = array( 2: '_DEFAULT' => array( 3: 'pagePath' => array( 4: 'type' => 'user', 5: 'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main', 6: 'rootpage_id' => 437 7: ), 8: ), 9: 'www.test1.intra' => array( 10: 'pagePath' => array( 11: 'type' => 'user', 12: 'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main', 13: 'rootpage_id' => 111 14: ), 15: ) 16: );
Notez comment “rootpage_id” est placé différemment pour ces deux cas!
[modifier] Problèmes connus (class: tx_realurl_advanced)
Liens vers les pages de type 'URL' seront générées comme si elles étaient des pages normal. Le lien vers ou elles pointent devrait être pris normalement. Pages ayant des sous pages avec le même titre de page (actuellement : se résout à la même URL) ne marche pas pour le moment. Voir les choses à faire.
[modifier] Liste de choses à faire (class: tx_realurl_advanced)
L'essai étendu doit toujours être fait, particulièrement avec des titres de pages changeants, suppression de page, créant alors une autre page avec le même nom, le multiple-domain-stuff, etc. Il y a une fonction pour trouver la langue désirée quand elle n'est pas explicitement donnée dans l'URL. Il a besoin de plus de travail pour être généralement utilisable cependant. (jetez un coup d'oeil à la source, le code à figurer hors de la langue avec la base de données d'IP2Country...) La table devrait être automatiquement nettoyée de temps à autre, pour enlever les URLs expirées. N'avons pas regardé dans ceci encore. Une possibilité est de créer un cron-job pour elle, une autre manière est de laissé un nombre aléatoire décider qu'il est temps de supprimer toutes vieilles URLs dans l'updateURLCache() de fonction Je pourrais créer une option pour imposer l'utilisation du https-protocole tout à fait facilement. Rendre la détection de pathPrefix (le path/to/typo/) plus élégante. Fixez les bugs et le reste d'articles à faire dans la source (dénotée par//!! TODO!! Bladiebla)
[modifier] Liste à faire
pour la liste technique de choes à faire voir le "doc/TODO.txt" dans l'extension Inclure l'information sur la façon d'établir ceci avec IIS, si possible. Est-ce que quelqu'un peut essayer ceci svp ? Quelques pages 404 intelligentes pouvant être créées, en utilisant le builtin recherche d'index par exemple. La langue demandée (/nl/...) pourrait aider à fournir la page dans la langue demandée. Rien n'est fait pour ceci pourtant cependant.
[modifier] Liste des modifications
- 0.0.1: Premier upload
- 0.0.4: Première version fonctionnant
- 0.0.5: une icône à été ajoutée, merci à Netcreaters pour l'avoir créée !
- 0.0.6: Ajout de documentation dans le format StarOffice
- 0.0.7: Réécriture/révision presque complètes du code, implémenté '/path_to_typo'-feature, implémentation de support de domaines multiples, changé le code de sorte que la majeure partie de la configuration soit maintenant automatiquement, documentation mise à jour
- 0.1.0: Première version disponible publiquement
- 0.1.1: pathPrefix ne marche pas correctement, donc un hack fut ajouté pour lui permettre de fonctionner maintenant
- 0.1.2: les URLs dans les pages n'étaient pas rendues correctement sur les sites uni-langage
- 0.1.3: Possibilité supplémentaire pour choisir un autre caractère pour remplacer un espace (au lieu d'un soulignage), fixé un autre bug stupide concernant le rendu de certaines URLs
- TOTAL re-organisation par Kasper Skårhøj mars 2004
