'''How to Install Tiki URLt'''

(Back to TikiURLt)

Tiki URLt is provided as a tar.gz file, which can be extracted into your Tiki directory (ie. the one with tiki-*.php files in it). It extracts the following files:


 ./lib/smarty_tiki/outputfilter.urlt.php<br />
 ./lib/urlt/urltlib.php<br />
 ./lib/urlt/index.php<br />
 ./templates/tiki-urlt_admin.tpl<br />
 ./templates/tiki-urlt_edit_in.tpl<br />
 ./templates/tiki-urlt_edit_out.tpl<br />
 ./tiki-urlt_admin.php<br />
 ./tiki-urlt_edit_in.php<br />
 ./tiki-urlt_edit_out.php<br />

The first job is to add three tables to the database. Do this by running the tiki-urlt-regex.sql file, as follows:

mysql -u (user) -p (database) &lt; db/tiki-urlt-regex.sql

(where (user) is the database username and (database) is the database name)

Next, visit http://yourserver/tiki-urlt-admin.php in your browser. You should see a page that has three tables on it - one for Incoming URLt, one for Outgoing and one for Non-PHP Mime Types. If the database has been installed sucessfully, you should see a few MIME types configured.

Before URLt can be used it should be enabled. Tick the two &quot;enable&quot; boxes and save the changes.

Now install URLt into the Tiki application. This is a two stage process:

1) Outgoing URLt
This is implemented as a Smarty output filter. These are configured in PHP code, so edit setup_smarty.php (in the Tiki directory). You should find some lines like these at the bottom:

$smarty = new Smarty_TikiWiki($tikidomain);

 $smarty-&gt;load_filter('pre', 'tr');<br />
 // $smarty-&gt;load_filter('output','trimwhitespace');23

Add an extra line below the last one (before any ?&gt; though!):


Now try fetching a Tiki page, just to make sure there are no big problems. Since no outgoing URL translation has been configured, the page you see will be exactly as it always was. We're just making sure that there are no installation problems.

2) Incoming URLt
This is web server specific. Any web server will do. At a minimum you need to configure the file tiki-urlt.php to be the Error Document for any pages that arn't found. For Apache, you'd do something like the following:

))ErrorDocument 404 /tiki/tiki-urlt.php33 34For more Apache ideas, see ((TikiURLt. If you use a different web server, take a look at the manual and see what needs doing. By all means, drop me a line with instructions if you have a moment.

Try fetching a page that doesn't exist - you should see a sparse error message from URLt saying the page could not be found.

Lastly, you need to configure some URL translations. This is a very complicated subject, requiring lots of Regular Expression skills. However, here's a simple example to get you going.

On the &quot;Edit Incoming URLt&quot; screen, add a line that has the following in it:

10|^\/banana|/tiki/tiki-index.php| |Stop on Match||

(make sure Incoming URLt is enabled and that you save your changes).

Now visit http://yoursite/banana - you should see your Home Page! That's because URLt has translated the /banana part of the request into /tiki/tiki-index.php which is your home page. Easy huh? (well okay, not really ;-)

Now try editing an outgoing URLt. This is far more complex, but it's easy to get a few things working quickly. Add a line like this to the &quot;Edit Outgoing URLt&quot; screen:

10|tiki-index.php\?page=(.*)|/$1| |Stop on Match||

Again, save your changes. As soon as you do, try hovering your mouse over a Wiki page link. You should find that it looks a little different (if you click one, you'll probably get a Page Not Found error.

If all is well, the above example should change a link to the Wiki page &quot;HomePage&quot; to &quot;/HomePage&quot; (that is, &quot;tiki-index.php?page=HomePage&quot; is translated to &quot;/HomePage&quot;). Clearly, for this to be useful, you'd have to setup a corresponding Incoming URLt to be able to handle &quot;/HomePage&quot;.

This quick and trivial example just scratches the surface. It's possible to do some really complex translations by using the &quot;Stop on Match&quot; and &quot;Continue&quot; rule modes carefully. Also, if you're migrating an old site to a URLt site, you can use the incoming ULRt &quot;Redirect on Match&quot; mode to send browser redirects to other locations (which helps users realise they're using the old URL scheme).

This is a complex subject, far more so that I can really write about. If you've got some neat examples, let me know and I'll include them.


Doesnt work on vserver

on my Linux at home it was running

but online on a vserver this shit happens to me

Warning: mkdir(): open_basedir restriction in effect. File(/tmp/71) is not within the allowed path(s): (/srv/nww/web7/:/srv/nww/htdocs/phpMyAdmin/:/srv/nww/htdocs/confixx/html/gesperrt/) in /srv/nww/web7/html/wiki/lib/adodb/adodb.inc.php on line 1551

Warning: fopen(): open_basedir restriction in effect. File(/tmp/71/adodb_716f2422695ca15b221f4ce6f146321c.cache) is not within the allowed path(s): (/srv/nww/web7/:/srv/nww/htdocs/phpMyAdmin/:/srv/nww/htdocs/confixx/html/gesperrt/) in /srv/nww/web7/html/wiki/lib/adodb/adodb-csvlib.inc.php on line 298

did you know what's going on

Submitted by Anonymous (not verified) on Thu, 2006-05-18 02:08.
Re: Doesnt work on vserver

That looks like the DB caching (part of ADODB) mechanism isn't allowed to write to /tmp. I'm not sure exactly how to fix it, but there must be a way to tell ADODB to use another directory (which you could place in your home directory). I'm guessing the ADODB web site might be a good place to start. It may also be possible to set the PHP temporary directory somewhere else (if that's what ADODB is using?), again,not sure exactly how to do it, but php.net can probably help.

Failing that, change all occurrences of $dbTiki->CacheExecute to $dbTiki->Execute in the code, but that'll get a big gnarly.

Submitted by coofercat on Thu, 2006-05-18 10:04.

The incoming links work fine, but for t=outgoin I get the same ERROR message about adodb. CAN SOMEONE PLEASE HELP!!!!(:cry:)

Submitted by Anonymous (not verified) on Fri, 2006-06-16 21:23.