Help test a possible future change.

[Zegnåt]

Today I submitted a new pretty URL .htaccess up for review to see if we can make GetSimple just a tiny bit better again. But before we want to put a change like this into the core we want to make sure we aren’t breaking anything.

Don’t you mind testing a new piece of code to help make GetSimple better? Great! I’ll tell you how to plug this into your installation and you’ll tell us if anything breaks.

Open up your .htaccess file, you’ll find it in the root. In it you look for this line:

Code:

RewriteRule /?([A-Za-z0-9_-]+)/?$ index.php?id=$1 [QSA,L]

Now replace it with this:

Code:

RewriteRule ^((.+/)?(.+?)/?)$ index.php?path=$1&id=$3 [QSA,L]

What has changed for you? Nothing visible.

The only change you should notice is faulty URLs like http://example.ms/example== now show the GetSimple 404 page. (Try it without the above change, you’ll see your server’s default 404 page.)

What has changed for developers? Everything!

We now have access to the full URL that has been requested. This means plugins like I18N no longer need to ask you to change the .htaccess. It also means we can start to slowly work on supporting Unicode support (finally slugs in your own language!) or things like URL shorteners (screenshots of URL shortener, only when you’re logged in).

So how do I use this in my upcoming plugin?

Here’s a very simple example. This would be how I18N can check what language is requested:

Code:

$path = explode('/', rtrim($_GET['path'],'/'));
if ( count($path) > 0 ) {
   $language = $path[0];
}

After this $language contains a string of the first directory in the URL, which would be “en” on the English page http://example.ms/en/home.

Please leave a comment here or on the issue in the bug tracker with your thoughts and error reports.

› Edit: now includes a working (or not, depending how you look at it) example of getting the server’s default 404 page. Updated RewriteRule inspired by comments, read more a little down.

[hameau]

No problems were introduced for me, with GSv3.1 under various configurations : in the server root; in a subdirectory; with/without Fancy URLs; with/without custom URLs. Do you need any server information ?

The only change you should notice is faulty URLs like http://example.ms/==example now show the GetSimple 404 page. (Try it without the above change, you’ll see your server’s default 404 page.)

I have never had a server 404 page, with GS v3.x, no matter how I try to break it, neither with the default GS error page nor with a custom page (slug==404). Am I missing out ? ;-)

[Carlos]

@Zegnåt

Tested, no problems so far, seems to work as expected.

PS Great idea!

[mvlcek]

Today I submitted a new pretty URL .htaccess up for review to see if we can make GetSimple just a tiny bit better again.
...

I think it would be better to use only one parameter, let's say path. That way it would look better on installations with fancy URLs turned off.
In index.php you would put $_GET['path'] into $path and extract the last component and put it into $_GET['id'] and the global $id/$url. So everything would still work as before, but there is an additional $path variable, which can be used instead of (or together with) $id, if needed.

P.S.: if there is no path parameter, index.php would work as before.

[Zegnåt]

I have never had a server 404 page, with GS v3.x, no matter how I try to break it, neither with the default GS error page nor with a custom page (slug==404). Am I missing out ? ;-)

It seems my example was wrong. Sorry.

The default GetSimple .htaccess file only sends you to GetSimple if the last character of the URL (not counting the trailing /) is a letter (A–Z), number (0–9), a -, or a _. Try going to /example== on your server with the original .htaccess, that should show you the server’s 404 page.

(Another funny thing about this way of parsing is that GetSimple will open your frontpage when you go to /=€!=index, it just skips characters it does not understand as long as it understands the end of the URL.)

I think it would be better to use only one parameter, let’s say path. That way it would look better on installations with fancy URLs turned off.

Mike came with the same comment. I’ll post my reaction from the issue tracker here for you all to read without leaving the forum:

I agree, as I said at the end of the original issue:

Something to think about [is] w[h]ether we might want to opt for a more WordPress like system and just pass everything along to the PHP.

I just tried to support the ‘old way’ in the .htaccess as well, this way we’ll be catering for plugin authors already, even before we would have had a need to rewrite the whole URL parsing. It will also keep old plugins working that might depend on the $_GET['id'] variable.

Code:

RewriteRule ^((.+/)?(.+?)/?)$ index.php?path=$1&id=$3 [QSA,L]

Would put the complete path, including the possible trailing slash and the value of $_GET['id'] into $_GET['path'] while still supporting putting the last part of the request in $_GET['id'] as well. (Untested, I’m at school.) Would that be better?

[Carlos]

https://github.com/GetSimpleCMS/GetSimpl...t-25299323

[Oleg06]

https://github.com/GetSimpleCMS/GetSimpl...t-25299323

I replaced this line

Code:

RewriteRule /?([A-Za-z0-9_-]+)/?$ index.php?id=$1 [QSA,L]

this line

Code:

RewriteRule ^((.+/)?(.+?)/?)$ index.php?path=$1&id=$3 [QSA,L]

and nothing has changed, everything works as before

[Ellahays]

Let me see how do I use these in my plugin?

[shawn_a]

necroposting ?