The solution for Short (SEO Friendly) URL's

[Ruud]

Try adding this to your .htaccess

Code Select Expand

RewriteCond %{REQUEST_URI} pages
RewriteRule ^pages/(.*).php$ /$1/ [R=301,L]


It shoud replace /pages/something/more.php into /something/more/

See it in action on: http://short.allwww.nl/pages/howto/mod_rewrite.php )

[Sokhim Sim]

Good Job, I have test and use this module. But my question with this plugin why we still have old link work after we change to short URL.

Ex 1: http://www.mywebsite.com/pages/accommodations.php

Ex 2: http://www.mywebsite.com/accommodations/

It work the same link but i want to remove Ex 1. How?

Best Regards, 

[NorHei]

Good Work !

[dbs]

Now all seems to be allright 
Good script, thx ruud.

[Ruud]

I just put a new version (v2.1) on http://short.allwww.nl

This should fix both reported problems.

For redirected pages (the shortened url's) the SCRIPT_NAME variable is now changed with the value of REQUEST_URI. This was already done for the PHP_SELF variable in previous versions, because it would report the wrong url. REQUEST_URI is believed safe to use.
No modifications to the Form modules are needed by this fix.

The news module in 282 is not using defines anymore, so this is changed in the short.php script and is now working in WB282 as well as previous versions.

[Ruud]

The good solution would be to modify the form module (view.php) and modify all 'SCRIPT_NAME' into 'PHP_SELF'.

Not a good idea:

The form module (since WB2.7) sanitises the PHP_SELF variable so it will not be affected.

Code Select Expand

htmlspecialchars(strip_tags($_SERVER['PHP_SELF']))

The better solution would be that the module would generate the current url out of the WB database. Not using any $_SERVER[] method. 

[dbs]

oh my god. i must ruuds "good solution" rechange in my form-module?

[NorHei]

The good solution would be to modify the form module (view.php) and modify all 'SCRIPT_NAME' into 'PHP_SELF'.

Not a good idea:
http://blog.oncode.info/2008/05/07/php_self-ist-boese-potentielles-cross-site-scripting-xss/

Sorry only german, but the code examples should be understandable.

OK, here are some english articles about the problem:
http://seancoates.com/blogs/xss-woes
http://www.mc2design.com/blog/php_self-safe-alternatives

[Bug]

I guess the next step is a version where /posts will also be rewritten to' nieuws' (or whatever the name of the rootparent is)?

[Ruud]

now i see a problem with the news module. "read more" makes nothing.

I must confess I only tested on 2.8.1, there it is working fine  (example www.dev4me.nl/nieuws/ )
I will have a look on a 2.8.2. installation later.

[dbs]

have taked the good solution and it works 

now i see a problem with the news module. "read more" makes nothing.

[Ruud]

Can you share the link where this is happening? (PM if you do not want to make it public)

Never mind, I found the problem.

The form module, since WB2.8.2, suddenly uses the $_SERVER['SCRIPT_NAME'] variable as the url to post the data.
The script_name is the script that is used after rewrites. This means it will use the /short.php for posting the data.
Previous versions of the form module were using $_SERVER['PHP_SELF']. That will show the original request before any rewriting.

The good solution would be to modify the form module (view.php) and modify all 'SCRIPT_NAME' into 'PHP_SELF'.

The dirty solution is to modify /short.php and add before line 40  (  require.... ) a line that says:
$_SERVER['SCRIPT_NAME'] = $_SERVER['PHP_SELF'];
This will fake the correct value in the SCRIPT_NAME variable..
Note: This could break (or fix as well) other modules that make use of that variable!

[Ruud]

Can you share the link where this is happening? (PM if you do not want to make it public)

[dbs]

hi, i have a problem with standard form in wb2.8.2 Rev1518.
after click submit-button the site will redirected to start-page.
what could be the problem?

dbs

[Ruud]

You get a redirect without one, to add the trailing slash.

That wil only happen when the server needs to send out a default document (i.e. index.php)
In this case all calls are rerouted to a single script. So no differences in redirect with or without the trailing slash.

This url rewrite is purely cosmetic. It has no advantage on indexing by searchengines.
The standard WebsiteBaker way of serving pages is just as good.
It just is meant to create nicer readable url's.

[PurpleEdge]

Do a search for "URL trailing slash"

You get a redirect without one, to add the trailing slash.

No idea what effect Ruud's mod has though?

[Bug]

Websites work faster WITH the trailing URL.

Any documentation on that matter?

[PurpleEdge]

Websites work faster WITH the trailing URL.

[Ruud]

Sure, it was added "on purpose" to simulate WP type of links
It is added in the droplet code. Just remove it and it will work without.

Code (droplet) Select Expand

    $wb_page_data = str_replace($linkstart.$link.$linkend, $newvalue.'/', $wb_page_data);
into

Code Select Expand

    $wb_page_data = str_replace($linkstart.$link.$linkend, $newvalue, $wb_page_data);

[Bug]

Would it be easy to also get rid of the trailing slash?

[Stefek]

Thank you!

[Ruud]

Nope, this will work in any WB (2.7 and up)

[Stefek]

Thank you Ruud.

Do I need a new version of WB and News Module to use it?

Regards,
Stefek

[Ruud]

A new version (v2.0) is made available for download today.
http://short.allwww.nl/

The links will be rewritten diferently from the first version.
A page like
  http://www.mydomain.com/pages/products/myproduct.php
is now rewritten as
  http://www.mydomain.com/products/myproduct/

The nice extra is, also news posts will be used in this format form now on.

Downloadlink: http://short.allwww.nl/download/

[Ruud]

What form are you using? I guess it's not the standard WB form..

Anyway, without looking at the form and/or action url I cannot say why this is happening.