THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

This document discusses the adoption of a centralized approach for Tiki's handling of URLs.

Please use the talk page for discussion.

Reasons

Summary of the reasons we need to do this rewrite, due to current implementation shortfalls:

• No centralized function to handle URLs (e.g. call output_url($internal_link) to return URL that works anywhere in the site)
• As a result of above, most issues we're having revolve around relative/absolute URLs
• URL rewriting is slow, queries the database (albeit uses caching), and matches too loosely

Purpose

Since this rewrite will require significant work, we should make sure our approach will be worth the effort. Here are some of the things we must accomplish:

• Centralize all URL handling/rewriting into one place
• Avoid having to prefix URLs in templates with {$tikiroot}
• Allow preexisting links to function as before (e.g. in templates, article and forum topics content)
• Allow a SUMO checkout to work both at root of the domain and otherwise
• Improve performance

Current implementation

The following files contain code relevant to manipulating URL output:

• webroot/lib/smarty_tiki/outputfilter.urlt.php
• webroot/lib/tikilib.php (see parse_data, autolinks, other places: search for "href")
• webroot/setup_smarty.php (loads the urlt outputfilter)
• webroot/lib/wiki-plugins/wikiplugin_alink.php

Proposed implementation

Our current URL formats:

• /<locale>/kb/Page+title?extra_parameters...
• /<locale>/forum/<forumid:[0-9]+>?extra_parameters...
• /<locale>/forum/<forumid:[0-9]+>/<threadid:[0-9]+>?extra_parameters...

Research summary of options:

Option 1

• For a non-rewritten URL, store an aliased "friendly"/"pretty" URL
• url() function looks up the alias (1-1 correspondence) and outputs the alias, if it exists, otherwise outputs the URL passed in
• Pros:
  • Fast on viewing
  • Easy to use
  • Easy to switch our templates to use this
• Cons:
  • May slow down with large number of entries in "aliases" table?
  • Difficult to implement (extra work to auto-generate aliases -- done on creating content)
  • (see item above for why) Slow down for saving content
  • Caching may require too much memory, need to cache each page->alias

Option 2

• Store URL patterns with placeholders
• url() function takes in a list of parameters and the pattern id to match against. It looks up the pattern and outputs the url with replaced placeholders based on variables passed in.
• Pros:
  • Easy to implement
  • Fast
  • Easily cache-able (low amount of data to cache)
• Cons
  • Harder to switch our templates to use this
  • Less easy to use (overhead of syntax)

Decision

Option 2 is better in the long run, and the temporary overhead is acceptable.

Bugs

• bug 522813

Issues/Concerns

• How do we make links to articles vary by locale? E.g. link to Ask+a+question page on search results.