RealURL

< 1.2. Configuration

Table Of Content

1.2.2. URL en/decoding background

This section provides a bit of background information about how URLs are encoded and decoded in the system.

The general principle is that the encoding and decoding should be totally transparent to the system. This means that any extension will work with "realurl" as long as they use the general link generation functions inside TYPO3 as they should do already. You can also use "simulateStaticDocuments" as a test - if it worked with that, it will (most likely) work with the "realurl" extension as well.

The implementation of this transparency is done by encoding the virtual URL strictly on the basis of the GET parameters given to the encoder method. And when a HTTP request is made to a virtual URL it is decoded into a set of GET parameters which is written back to the global variables HTTP_GET_VARS / _GET - and thus any application in the system will see the parameters as it they were passed as true GET parameters.

Encoding:

URL with GET parameters -> Speaking URL -> HTML page

The encoding of the URLs happens by using a hook in the method t3lib_tstemplate::linkData(). This is configured in "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';

Decoding:

HTTP request with Speaking URL -> URL is decoded, overriding values in HTTP_GET_VARS -> page rendered as always

The decoding of the URLs happens by using a hook in tslib_fe::checkAlternativeIdMethods(). This is configured like this:

  $TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_fe.php']['checkAlternativeIdMethods-PostProc'][] = 'EXT:realurl/class.tx_realurl.php:&tx_realurl->decodeSpURL';

The syntax of a "Speaking URL"

Before we go on to the configuration section it's important to understand how the virtual path (Speaking URL) is decoded by the system. Lets settle an example and break it up into pieces:

  index.php?id=123&type=1&L=1&tx_mininews[mode]=1&tx_mininews[showUid]=456

This URL requests page id 123 with language "1" (danish) and type "1" (probably a content frame in a frameset) and on that page the display of a mininews item with id "456" is requested while the "mode" of the mininews menu is "1" (list). This parameter based URL could be translated into this Speaking URL:

  dk/123/news/list/456/page.html

The configuration of "realurl" needed to do this magic is as follows:

     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: );

In order to understand how this configuration can translate a speaking URL back to GET parameters we have to first look at how the Speaking URLs are divided into sections. This is the general syntax:

      [TYPO3_SITE_URL] [preVars] [pagePath] [fixedPostVars] [postVarSets] [fileName]

Each of these sections (except [fileName]) can consist of one or more segments divided by "/". Thus "news/list/456/" is a sequence of three segments, namely "news", "list" and "456"

Taking the speaking URL from above (http://www.my-domain.dk/frontend/dk/123/news/list/456/page.html) as an example we can now break it up into these sections:

Section	Part from Example URL	General description	Comment accord. to config
[TYPO3_SITE_URL]	http://www.my-domain.dk/frontend/	This part of the URL - the base URL of the site and basically where the "index.php" script of the frontend is located - is stripped of and is of no interest to the resolve of the parameters.
[preVars]	dk/	This section can contain from zero to any number of segments divided by "/". Each segment is bound to a GET-var by configuration in the key "preVars" (see example above) The number of segments in the pre-vars section is determined exactly by the arrays in "preVars" configuration. Typical usage would be to bind a pre-var to the "L" GET parameter so the language of the site is represented by the first segment of the virtual path.	In the configuration above there is only one pre-var configured and that is bound to the GET var "L". Further a mapping table tells that the value "dk" should be translated to a "1" for the GET var value when decoded. Also, if the segment does not match "dk/" it is just ignored. meaning that the default language version of the danish page ".../dk/123/" would be just ".../123/"
[pagePath]	123/	The page path determining the page ID of the page. The default method is to just show the page ID, but through configuration you can translate say "contact/company_info/" into a page ID. The number of segments of the path used to resolve the page ID depends on the method used.	In this example the default method is used (not configured at all) and that means the raw page id (or alias if there were any) is displayed; 123. This is not "Speaking URL" behaviour, sorry for this weak example...
[fixedPostVars]		Fixed post vars is a sequence of fixed bindings between GET-vars and path segments, just as the pre-vars are. This is normally not useful to configure for a whole site since general parameters to pass around should probably be set as pre-vars, but you can configure fixed post vars for a single page where some application runs and in that case may come in handy. Typical usage is to apply this for a single page ID running a specific application in the system.	Not used in this example.
[postVarSets]	news/list/456/	postVarSets are sequences of GET-var bindings (in pre-var style) initiated by the first segment of the path being an identification keyword for the sequence. Decoding of postVarSets will continue until all remaining segments of the virtual path has been translated. This method can be used to effectively encode groups of GET vars (sets), typically for various plugins used on the website. Typical usage is to configure postVarSets for each plugin on the website.	In this example there is a single post var set ("news/list/456/") where the keyword "news/" (first segment) identifies the following sequence ("list/456/") to be mapped to the GET vars tx_mininews[mode] and tx_mininews[showUid] respectively.
[fileName]	page.html	The filename is always identified as the segment of the virtual path after the last slash ("/"). In the "fileName" configuration a filename can be mapped to a number of GET vars that will be set if the filename matches the index key in the array. Typical usage is to use the filename to encode the "type" or "print" GET vars of a site.	In this example the "type" value "1" is mapped to the virtual filename "page.html". In any other case the type value will be set to blank.

To top