Index page versus Start page: How to canonicalize

selkirk

Currently, the main index page of my wiki ("/") and the start page ("/start") show the same content. The links that the wiki generates, for example in "You are here" section or in "Recent Changes" will point the the "/start" page. What is the best way to get them to point to the index page as the canonical location for this content?

Setting $conf['start'] to '' causes the correct links to be generated, but I'm not sure how to tell it which file it should locate for that index page.

I'm also not sure about the impact of this on namespace index pages.

My goal is simply to make the traditional html index page the start page for the main wiki and each namespace.

Any advise on this issue?

selkirk

Ok, I'm starting on my journey to see if I can (hopefully quickly and easily) resolve this question myself.

From a PHP perspective '' is a very different value than 'start'. empty() returns TRUE for '' and FALSE for 'start' and (boolean) ($x) is FALSE for '' and TRUE for 'start'.

Looking at the code, I'm guessing that '' is at best a brittle value for a page id. So it looks like setting $conf['start'] to '' may not be a good approach.

Looking for another approach...

selkirk

By tracing back the configuration options dealing with building URLS ('useslash, 'userewrite', and 'deaccent') it looks like all the paths where a page id is converted into an url pass through the idfilter() function.

Perhaps I can patch this function to look for an id ending in $conf['start'] and remove that to generate an "index url."

It seems that no current code is performing tests on the return value of idfilter(), so this would seem to be safer than setting $conf['start'] to ''.

I'm going to look now for cases where idfilter() is not called.

selkirk

There appears to be an inconsistency in mapping URLs to page ids when 'useslash' and 'userewrite' are on.

The following links:

[[foo]] [[foo/bar]] [[foo/]] [[foo/start]]

Show the following titles:

foo bar start start

But map to the following urls:

/foo /foo/bar /foo /foo/start

Notice that the title for the third link does not match the url.

On the other hand the following links:

[[foo]] [[foo:bar]] [[foo:]] [[foo:start]]

Show the following titles:

foo bar foo start

And map to the following urls:

/foo /foo/bar foo/start foo/start

Notice that the title for the third link ALSO does not match the url, but in the opposite way from the first example.

I believe that [[foo:]] and [[foo/]] should both map to the url "/foo/start" and have the title "start".

selkirk

Moving right along with my monolog, I've reported the previous post as the following two bugs:

Links for namespaces incorrectly generated with useslash enabled
Links with a trailing colon or slash have an inconsistent title

I've also provided fixes.

I've think I've also start to stray from a simple configuration question.

selkirk

With that out of the way, I've added the following lines:

  if ($id == $conf['start']) {
    $id = '';
  } else if (preg_match('#^(.*[/:])'. preg_quote($conf['start'],'#') . '$#', $id, $matches)) {
    $id = $matches[1];
  }

To the end of the idfilter() function in common.php, just before the return $id statement.

This maps the start page to the index page in any generated links.

in other words, [[foo:]], [[foo:start]], [[foo/]] and [[foo/start]] all link to "/foo/".

Now, there is a problem. "/foo/" does not map back to the page id $conf['start']. instead it maps to the page 'foo'. This is discussed on the namespaceindex page. I'm off to explore solutions to this problem.

selkirk

The solution is easily available on the namespaceindex page:

in pageutils.php I added the following lines after $id = $_REQUEST[$param]; as instructed

     if((substr($_REQUEST['id'], -1) == "/") || (substr($_REQUEST['id'], -1) == ":")) {
         $id .= $conf['start'];
     }

and replaced $id = trim($id,’:._-’); with $id = trim($id,’._-’); also as instructed.

Now going to any url with a trailing slash shows the start page for that namespace. Combined with the ability to generate the correct urls in the correct locations and the two bug fixes, this is exactly what I wanted.

Now, I just need to do some double checking to make sure everything will work correctly.

selkirk

I found an error. removing the : from the $id = trim($id,’:._-’); as described on the namespaceindex page seems to cause the backlinks, index, and recent changes pages to break with the wrong urls. I've restored this line and everything seems to work fine without it so far.

billpowellisalive

Hi Selkirk!

Just wanted to thank you for post #6 above, the quick mod to common.php. Saved me hours!

I'm not sure if this is the same as what you wanted, but I wanted to map directories/namespaces to a default page.

e.g. http://localhost/about/ -> http://localhost/about/start

_without_ showing that "start", because it's much easier to keep an address like "about/" canonical.

The first step was to follow the DokuWiki steps for using an alternate URI scheme; in this case, Option 1, for Apache.

http://wiki.splitbrain.org/wiki:rewrite?s=uri%20rewrite

Then, after uncommenting the suggested lines in .htaccess, I added these 2 lines BEFORE the first RewriteRule (but after RewriteEngine on, of course):

RewriteCond %{REQUEST_URI} /$
RewriteRule (.*) doku.php?id=$1start [L]

This seems to work; any address ending in a slash gets "start" added to it, then gets passed directly to doku.php. This has the advantage of keeping DokuWiki code tweaks to a minimum.

This was great except, as you found above, DokuWiki would munge the final slash in wiki links. [[about/]] would become [[about]], which made everything useless. That's where your tweak to common.php in #6 above was so helpful.

So thanks.

anjiro

Regarding post #9: This was awesome - exactly what I needed - but you need to add QSA to change:

RewriteCond %{REQUEST_URI}              /$
RewriteRule (.*)                        doku.php?id=$1start [L]

RewriteCond %{REQUEST_URI}              /$
RewriteRule (.*)                        doku.php?id=$1start [QSA,L]

Otherwise logging in and such won't work right.

dan

Global DokuWiki Links