NewsFeaturesDownloadsDevelopmentSupportAbout Us

Custom urls

From LifeType Wiki



Since version 1.0, LifeType comes with a new URL generator that can be used to generate custom URLs. Virtually any URL in LifeType is now customizable (with only a few exceptions, such as the trackback URLs) Support for this url is implemented in two parts: first part is the URL generator itself, that wil read the format that we defined for the URL and generate one accordingly. The other part is the URL matcher, that will receive incoming URLs and split them into its different parts according to the format that we previously defined. The pattern is a modified version of a regular expression (in the end, PHP's regular expression functions are used to process the URL and extract the information)

Support for custom urls is site-wide. This means that all blogs will share the same URL format, as opposed to each blog defining its own format.

Support for this kind of URLs is only available when using Apache. Support for the ForceType and ErrorDocument Apache directives is recommended to fully make the best of this feature. Support for mod_rewrite is not necessary.

URLs that can be customized

The following urls can be customized:

  • Permalinks
  • Links to categories
  • Links to blogs
  • Archive links (links to dates, categories, etc)
  • Links to albums
  • Links to resources
  • Links to resource previews (small preview and medium preview)
  • Links to resource download


For each one of the url that can be customized, there is a defined set of "tags" that can be used. Not all tags are available to all URLs because it would not make sense to have an {article} tag in the url generated for albums. The table below shows which parameters are available for each format.

Before generating a url, LifeType will see which format was defined for it. Every url is made up of these different tags that in fact, are telling LifeType where to insert which information. The tag names are pretty intuitive so it's easy to figure out what each one of them does.


  • {blogname}: Inserts the blog name. Spaces are converted to "_" and any other non-alphanumeric character is removed. Accented characters are replaced with their non-accented counterparts (i.e. "ä" becomes "a", "é" becomes "e", etc)
  • {blogid}: Inserts the blog numerical identifier.
  • {blogowner}: Inserts the username of the user who owns the blog. Please be careful when using this tag in case the same user owns more than one blog, because it is impossible to tell which one of them we are trying to access. LifeType will choose the first one that comes from the database.
  • {username}: Inserts the username of the user.
  • {userid}: Inserts the numerical identifier of this user
  • {postname}: Inserts the topic of the article. The text string is transformed in the same way as in the {blogname} tag
  • {postid}: Inserts the article numerical identifier.
  • {year}: Inserts the 4 digit year.
  • {month}: Inserts the 2 digit month.
  • {day}: Inserts the 2 digit day.
  • {hour}: Inserts the 2 digit hour.
  • {minute}: Inserst the 2 digit minutes.
  • {catid}: Inserts the article category name. As with any other string, it is transformed as in {blogname} and {articlename}
  • {catname}: Inserts the article category id.
  • {albumname}: Inserts the resource album name.
  • {albumid}: Inserts the resource album id.
  • {resourcename}: Inserts the resource file name.
  • {resourceid}: Inserts the resource numerical identifier.

Where each tag is used

{blogid}, {blogname} and {blogowner} are always available.

FormatAvailable tagsDescription
permalink_format{postname}, {postid}, {year}, {month}, {day}, {hour}, {minutes}, {catid}, {catname}, {userid}, {username}Defines how permalinks look like.
archive_link_format{year}, {month}, {day}, {hour}, {minutes}, {userid}, {username}Defines how links to the archive look like.
category_link_format{categoryid}, {categoryname}Defines how the link to a certain category looks like.
users_posts_link_format{username}, {user}Defines how the link to the posts of a certain user looks like.
blog_link_format_no additional parameters_Defines how the link to the main page of the blog loos like.
post_trackbacks_link_format{postname}, {postid}, {year}, {month}, {day}, {hour}, {minutes}, {catid}, {catname}, {userid}, {username} Defines how the link to the trackbacks received for a certain article looks like.
template_link_format{templatename}Defines how the link to "static" templates looks like.
album_link_format{albumid}, {albumname}Defines how the link to resource albums looks like.
resource_link_format{albumid}, {albumname}, {resourceid}, {resourcename}Defines how the link to the page showing the resource and information about it looks like.
resource_download_link_format{albumid}, {albumname}, {resourceid}, {resourcename}Defines how the link to download the "raw" resource looks like.
resource_preview_link_format{albumid}, {albumname}, {resourceid}, {resourcename}Defines how the link to the preview of a certain resource looks like.
resource_preview_link_format{albumid}, {albumname}, {resourceid}, {resourcename}Defines how the link to the medium-sized preview of a certain resource looks like.

Additional parameters

$Tells the URL parser that it should take the whole line into account. For example, let's suppose a URL like If we use a format such as /blog/{blogname}$, it would match. If we use a format such as /blog/{blogname} (without '$'), it would also match but so would match, because the URL parser will not take the whole request into account.
?Makes the character before it optional. This can be helpful to generate for example URLs to our archives: /blog/{blogname}/{year}/{month}/?{day}/? means that the '/' are optional. Additionally, if you only type in the year, or only the year and month, that will also work, so that and are URLs that would match according to this format.

Why removing /blog/ from the URLs is evil

It is very easy to change all the URL formats so that instead of


we have


After all, we already know that we're dealing with a blog so why have it in all URLs as well?

The answer is clear: if we use the second suggestion, each single hit to our blogs will count as an error instead of as a valid hit so our access statistics will become pretty much useless.

This is because in the first situation, Apache will use the script "blog" that can be found in the root folder of LifeType as the entry point to LifeType. Since it's a valid script that exists in disk, it will be counted as a valid hit. On the other hand by using the second solution, none of the components in the path exists as a valid script in our LifeType folder so Apache will resort to calling LifeType's error.php (via the ErrorDocument directive) which is an error handler.

Apache error handlers allow scripts to still show a friendlier message o do some other kind of processing instead of Apache showing a cold "404 error" message. In the case of LifeType, we will use the error handler to be able to direct users to the right URL and that is fine. However, Apache will count this accesses as errors even though we managed the correct page (in other words, all these hits will appear in error_log instead of access_log)

Some sites do care about statistics so it is important to make this issue clear.

If you still insist on removing /blog or /blog.php from your URLs, some mod_rewrite trickery will avoid the situation described above, and your links will not generate 40x errors anymore.

Just add this to your .htaccess file:

RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog.php

This approach is being currently successfully used at for example


Permalink exaples:

The following one would match against things like


The following one would match against URLs such as


(see section 4 why this is evil!)

If our web server does not have support for the ForceType directive (so that we can get rid of the .php extension in our scripts), we can still use this URL format:


The blog.php will be used as the main entry point to LifeType and it must exist in our web server tree. The best option is to rename the "blog" script to "blog.php" and configure the URLs as above.

How to customize URLs when we are the only user in the site

In case we are the only user in the whole installation, it might seem a bit redundant to have custom URLs include "/blog/my_blog_name" or "/blog/myusername" in every single URL. Therefore, it is possible to tweak these URLs not to include this parameter while still not using the error handler (so that all requests to our site count as a valid hit and not as an error)

Of course if we ever add a second blog to the site, it will not be possible to use this neat little trick because otherwise LifeType will have no way to tell whether we are trying to access one blog or the other.

This is also something that can be done when subdomains are enabled and the name of the blog or its owner can be obtained from the host name.

This is how the _link_format parameter should be set:


If you look at the root folder of LifeType, you will see a set of scripts called "static", "post", "resource", "album", etc. Even though they lack the .php extension, these are valid PHP scripts (thanks to some .htaccess trickery we can still get Apache to recognize them as PHP scripts) that will be used as access points to LifeType and therefore all URLs above will work just fine.

Working example for LifeType 1.2