"Nice URLs" - how to implement it in PHP?

How to apply nice URL-s into CMS?

1. Should we use nice urls for every page?

2. Do we need to put a FULL path into <a href="">?

3. What is faster and better?

a) 10 rules in .htaccess which redirect you to normal URLs with GET
parameters

b) one rule in .htaccess and parsing "nice url" in PHP (strpos,
explode...).

4. Do search engines still deal with "nice urls" better than with
normal URLs in 2008?

5. When we must put more parameters into GET and only some of them
occurs in one request - should we place them in "nice url" or should
we better do something like: index.php/nice/url?param=value?

Why are "nice urls" better than normal? How to implement them in CMS?
Example path:

- example.com/pathtosite/index.php/art/50
- example.com/pathtosite/art/50

Are they correct? So...

$_URL = explode(...); - good solution?

Or maybe some rules for the most important pages are enough and we
don't need to parse URLs in PHP?

On Thu, 06 Mar 2008 16:45:38 +0100, WebCM <webcm123@gmail.com> wrote:
> How to apply nice URL-s into CMS?

Apache mod_rewrite (ask in alt.apache.configuraion if you run into
troubles.

> 1. Should we use nice urls for every page?

Preferably, yes.

> 2. Do we need to put a FULL path into <a href="">?

Depends, if content can change location/hierarchy, yes, that is to say,
use <a href="/path/to/something/">, not <a href="../something/">. You
don't need the http and domain portion in it.

> 3. What is faster and better?
>
> a) 10 rules in .htaccess which redirect you to normal URLs with GET
> parameters
>
> b) one rule in .htaccess and parsing "nice url" in PHP (strpos,
> explode...).

b) is certainly more flexible (and is what I use), but has some overhead
as you delegate a lot ot 401's to PHP. Which one is faster depends highly
on the logic used, I'd say: try it out.

> 4. Do search engines still deal with "nice urls" better than with
> normal URLs in 2008?

They do a lot better with 'not nice urls' then they used to, however,
having the actual keyword(s) searched for in the URL is definitly a plus..
And you don't only change the URRLS's for the search engine, but also for
humans (guessable & rememberable URLS, certainly a plus when for instance
advertising in print, but in a browser context also a plus.)

> 5. When we must put more parameters into GET and only some of them
> occurs in one request - should we place them in "nice url" or should
> we better do something like: index.php/nice/url?param=value?

If you can change it to keywords searched for, having them in the path
portion has it's advantages. It they don't hold easily guessable
parameters interpretable by humans, just use the query string.

> Why are "nice urls" better than normal?

- Better scoring on keywords.
- Not related to the actual type of script or technology used (php, .NET,
Perl, Python), so it's easier to maintain the same URLs for all content,
even after a major refactoring ('nice urls don't change')
- Guessable by humans
- Easy to remember by humans

> How to implement them in CMS?
> Example path:
>
> - example.com/pathtosite/index.php/art/50
> - example.com/pathtosite/art/50
>
> Are they correct? So...
>
> $_URL = explode(...); - good solution?
>
> Or maybe some rules for the most important pages are enough and we
> don't need to parse URLs in PHP?

Depends on the actual goal, I just feed the path portion of
$_SERVER['REQUEST_URI'] directly into a query which gives me the page used
from a Nested Set Model table. Has some overhead, but most sites I workon
are complex enough to benefit from it.
--
Rik Wasmus

WebCM wrote:

> 1. Should we use nice urls for every page?

"Nice things are nicer than nasty ones."
-- _Lucky Jim_, Kingsley Amis.

> 2. Do we need to put a FULL path into <a href="">?

I tend to use a root-relative path (i.e. one starting with "/").

> 3. What is faster and better?
>
> a) 10 rules in .htaccess which redirect you to normal URLs with GET
> parameters
> b) one rule in .htaccess and parsing "nice url" in PHP (strpos,
> explode...).

Which is faster? Probably not much difference. mod_rewrite rules in
httpd.conf will beat both though.

I tend to just redirect all requests (except a few specific directories
for CSS files, images, downloads, etc) to "index.php/*" and then PHP logic
can deal with them.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 37 days, 18:16.]
[Now Playing: Ed Harcourt - The Trapdoor]

Bottled Water
http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/

Perhaps URLs like:
- example.com/index.php/art/50
- example.com/index.php/file/100
have no sense. You must parse URLs in PHP in this case. However, using
mod_rewrite is much better:
- example.com/art/50
- example.com/file/100

And better:
- example.com/art/article-title

What do you think about it? Maybe even index.php/art/article-title is
better? However, using only mod_rewrite, you don't need to parse all
URLs.

And another problem: Google deals with ? and & but it doesn't like
duplications. For example the same page can be accessed by:
- example.com/?art=50
- example.com/art/article-title,50

IMPORTANT: URLs like index.php/something/after may not work. It
depends on server configuration. If admin disable PATH_INFO, URLs like
this will cause 404 error.