Xepher.Net Forums

Content => Web Design => Topic started by: yny-u on December 09, 2007, 11:30:17 pm

Title: Cleaning up PHP $_GET URLs
Post by: yny-u on December 09, 2007, 11:30:17 pm
I am building a site with PHP/MySQL, and I was wondering.. Is there a good way to get URLs like

/gallery/index.php?section=illustration&id=27

to appear as, and and be accessible from something like

/gallery/illustration/tree-27

where "tree-27" is the name of the picture and its id. (Having the id number in the URL along with the name prevents to images with identical names from causing problems..)
Title: Re: Cleaning up PHP $_GET URLs
Post by: Desh on December 10, 2007, 04:28:54 am
The way I know of is pretty easy, and I actually learned it here from Databits in this topic (http://xepher.net/forum/index.php?topic=303.0) :D

Basically, you take your php script that reads your values and chop off the .php.  Then, using .htaccess, you force the webserver to run it as a php script.  After that, you make your script read its URL, breaking it up by the slashes, and you have your variables.

In actual code, for the .htaccess

Code: [Select]
<Files ScriptName>
  ForceType application/x-httpd-php
</Files>
(Where ScriptName is the name of the php script you cut off)

Then, to get your variables, in the ScriptName script

Code: [Select]
$request=str_replace($_SERVER['SCRIPT_NAME'],'',$_SERVER['REQUEST_URI']);
$variables=explode('/',$request);

That first line will get rid of the ScriptName, and leave only your variables.  Then, your variables are broken up by slashes into an array.

Keep in mind, the way your script gets is variables is now different.  In your original method, variables are named and part of the $_GET group.  In this method, they're numbered starting at 0 and part of the $variables array. 

If you name your variables right away, such as $id=$_GET['id'];, just replace the $_GET with the right $variables[ #].  If you use $_GET throughout your script, you'll have to go through and change them.

Be sure to avoid naming a folder the same as ScriptName.  If you do, when you access ScriptName/Variable/Variable, the server will look for Variable/Variable in the folder and ignore your script.
Title: Re: Cleaning up PHP $_GET URLs
Post by: Xepher on December 10, 2007, 01:09:17 pm
Another option is to use ModRewrite (http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html) to silently redirect the requests within apache itself.

This goes inside a .htaccess file placed at the base of your website (/home/username/public_html/.htaccess)

RewriteRule ^/gallery/(.*)/(.*)-(.*) /gallery/index.php?section=$1&id=$3


You may have to tweak the exact paths (the path it sees depends on where you put the .htacvess file, and I'm typing this from memory) but that's generally how it works. The $1 and $2 bits in the second part are replaced by the first and second parenthetical matches in the first part. The ".*" is a regular expression term meaning match-any-character (.) any-number-of-times (*). You can fine tune that using more specific regular expressions... you may also need to tweak the first part to be  "^/gallery/(.*)/(.*)-(.*)(/?)" in order to catch cases where people (or their browsers) end the URL with a final slash (/).

The advantage to doing it this way is you don't have to tweak your script in anyway, so it's easy to use with pre-made scripts. The only downside is you have to figure out regular expressions to do it. :-) Hopefully I've done the hard bit for you though.
Title: Re: Cleaning up PHP $_GET URLs
Post by: Databits on December 11, 2007, 02:24:12 am
Or you can do a third option where you direct ALL of the requests for your site through a single script which internally outputs what it needs to after parsing the information out.
Title: Re: Cleaning up PHP $_GET URLs
Post by: yny-u on December 11, 2007, 04:28:29 am
Ahh, thank you all very much for your help. I shall mess around with this..

Thanks again.
Title: Re: Cleaning up PHP $_GET URLs
Post by: Databits on December 15, 2007, 08:04:27 am
Basically, it's called a content dispatcher. Which is incorrectly called at times, a model view controller (most claimed "MVC's" aren't really MVC's).

It's actually a rather useful method because it allows you to custom process everything, including images, videos, music, and the like. In addition, when combining this method with customizing your webserver config (either in the direct server config or the .htaccess override), you can do things like only running through your processing script if the real file doesn't actually exist/
Title: Re: Cleaning up PHP $_GET URLs
Post by: yny-u on December 20, 2007, 10:26:41 pm
OK... I have poked at this a bit, and I am having trouble getting it to work.. To simplify matters, I have started by trying to rewrite gallery/index.php?section=all to gallery/all

Below is a copy of the code I have in the .htaccess file in my web root directory:

Code: [Select]
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^gallery/([a-zA-Z]+)(/)?$ gallery/index.php?section=$1
RewriteRule ^gallery/([a-zA-Z]+)/([0-9]+)(/)?$ gallery/index2.php?section=$1&id=$2

First rewrite rule:
The URLs http://yny-u.xepher.net/gallery/all (http://yny-u.xepher.net/gallery/all) and http://yny-u.xepher.net/gallery/all/ (http://yny-u.xepher.net/gallery/all/) both forward... But using the second (with the trailing slash) breaks the CSS and images..
The second rule forwards, but breaks the CSS and images either way (with or without the trailing slash).

I am guessing that the problems are being caused by the rewrite adding faux directory levels that are messing up the relative file paths, because the nav links (which are relative) on the broken pages point to the wrong directory level, while the rewrite that works (gallery/all) points to the level that the the pages are actually on..

Does anyone know how to fix or get around this? (other than going through and changing all the relative links to to absolute ones, that is.. -_- )

Thanks for all the help.
Title: Re: Cleaning up PHP $_GET URLs
Post by: Xepher on December 21, 2007, 01:37:42 am
The only thing that comes to mind is making another rewrite rule for images/css files that points back to the right location. Something like

^gallery/(.*)/(.*)(\.css|\.jpg|\.png)     gallery/$2$3

That's just a quick "sketch" of code there... I'm sure it needs adjustment, but I hope it at least shows what I'm talking about. The key would just be figuring out how gallery organizes its files, and creating enough rules to match it, and basically just stripping the fake directories from the middle of the URL.
Title: Re: Cleaning up PHP $_GET URLs
Post by: yny-u on February 12, 2008, 11:20:54 pm
Thank you all for your help (sorry it took me so long to reply). I think I have gotten everything working now. Posted below is most of my .htaccess file - hopefully it will be helpful to someone interested in doing something similar.

Code: [Select]
#turn on the rewrite engine so all this stuff actually works..
Options +FollowSymlinks
RewriteEngine on
RewriteBase /

#redirect http://www.yny-u.com/ to http://yny-u.com/
RewriteCond %{HTTP_HOST} !^yny-u\.com [NC]
RewriteRule ^(.*) http://yny-u.com/$1 [L,R=301]

#clean up gallery URLs 
#make gallery sections accessible via /gallery/section/
RewriteRule ^gallery/([a-zA-Z]+)(/)?$ gallery/index.php?section=$1
#make gallery pages accessible via /gallery/section/id/ or /gallery/id/
RewriteRule ^gallery/([0-9]+)(/)?$ gallery/index2.php?section=all&id=$1
RewriteRule ^gallery/([a-zA-Z]+)/([0-9]+)(/)?$ gallery/index2.php?section=$1&id=$2
#make gallery full-view pages accessible via /gallery/section/id/full-view/ or /gallery/id/full-view/
RewriteRule ^gallery/([a-zA-Z]+)/([0-9]+)/full-view(/)?$ gallery/full-view.php?section=$1&id=$2
RewriteRule ^gallery/([0-9]+)/full-view(/)?$ gallery/full-view.php?section=all&id=$1
#exception for links to image files so that relative image source paths will still work
RewriteRule ^gallery/(.*)/images/(.*)/(.*)(|\.jpg|\.png)$ gallery/images/$2/$3

#clean up top URLs - make top.php accessible via /top/
RewriteRule ^top(/)?$ top.php
#rewrite links like /top/something/something/else/ to /something/something/else/
RewriteRule ^top/(.*)$ $1

#custom 404 page
RewriteRule ^404(/)?$ 404.php
ErrorDocument 404 http://yny-u.com/404/

#prevent people from viewing contents of directories without an index.php/html/etc file
IndexIgnore */*

Title: Re: Cleaning up PHP $_GET URLs
Post by: Miluette on March 04, 2009, 01:24:07 pm
Fah realz necrobumping this thread.

I'm wondering if this stuff can also apply to redoing the urls for my news scripts. Right now they look like this:

http://millennium.senshuu.com/mil/index.php?subaction=showcomments&id=1235775579&archive=&start_from=&ucat=1&

Yeah D: No idea what I'd redo it to but something much shorter and simpler. And, as usual, my brain is fried.

It's bad enough that the subdirectories also appear after I've used mod rewrite to create those subdomains, but it's because of how the news script is set up (I'm using one installation on three sites).
Title: Re: Cleaning up PHP $_GET URLs
Post by: yny-u on March 05, 2009, 08:09:02 pm
This can get complicated, but you probably could get something like:

http://milenium.senshuu.com/mil/1/1235775579/showcomments/
With:
RewriteRule ^mil/([0-9]+)/([0-9]+)/([0-9a-zA-Z)(/)?$ mil/index.php?ucat=$1&id=$2&subaction=$3

(That is just off the top of my head, so it probably has some mistakes...)

The $# things in the second half of the RewriteRule (after the first "$") refer to the thing matched by the regular expression subsection in the #th set of parenthesis counting from left to right. You can add more variables (like your start_from and archive variables) quite easily. The trick is to remain consistent about what order you put the variables in, otherwise you will end up with ucat getting id's value or the like.

Hope that helps.

Title: Re: Cleaning up PHP $_GET URLs
Post by: Miluette on May 12, 2009, 06:28:37 am
Slow response time! That is very helpful. <3

Before I try that, I kind of wonder if I can do that in a way so that anywhere past this part in my messy URLs can be rewritten without being relative to a certain subdirectory:

Quote
?subaction=showcomments&id=1235775579&archive=&start_from=&ucat=1&

But actually I think I know what to do relative to paths too. It's slightly confusing, because I'm using one copy of CuteNews in three different subdirectories, hehe.

EDIT: Oh gawd, I tried adding both your thing and my idea to my root .htaccess and I got a 500 error. I wonder if having so many rewrite rules already makes it worse?
Title: Re: Cleaning up PHP $_GET URLs
Post by: yny-u on May 18, 2009, 10:37:59 pm
Heheh, well it certainly is easy to get 500 errors when messing about the your .htaccess file... But having a lot of rules does not inherently generate an error. As long as all your rules are correct and don't conflict with each other there should be no problem (obviously).

Anyway, if you structure your URLs in such a way that each piece of data can be distinguished by some sort of regexp, you can probably set it up so that the order of the URL doesn't matter, ex. http://milenium.senshuu.com/mil/1/1235775579/showcomments/ and http://milenium.senshuu.com/1235775579/showcomments/mil/1 could both be fine... It makes writing your rewrite rules a little more complicated, but it should be doable. Is that what you mean by not being relative to a certain subdirectory? Or you can choose to only rewrite certain pieces of data and just pass everything else, ex. http://millennium.senshuu.com/mil/1/1235775579/?subaction=showcomments&start_from=1234

Does that help? Sorry, I am not quite sure what your question was..
Title: Re: Cleaning up PHP $_GET URLs
Post by: Miluette on May 19, 2009, 06:30:32 am
Well, hmm, let's see if I can explain it... I'm bad at explaining what I mean sometimes lol.

All of my actual news files are in /news/
But they're being inserted on /lf/, /mil/, and /ai/
(Those are all from the root directory)

I want to do a rewrite rule that doesn't involve including or relying on /mil/ /lf/ or /ai/ in the news-generated URLs at all, if possible (but I don't think it is)

And I wanna be able to try that suggestion of yours without having to create multiple .htaccess files in different directories (before I just tried your suggestion in the root one, and it didn't work aaaa)

Actually I'm not sure which .htaccess file I should be editing where ()
Title: Re: Cleaning up PHP $_GET URLs
Post by: Databits on May 19, 2009, 02:02:11 pm
Blend them.

Never, ever, split your variables up to look like a directory structure. Things like Google rank your pages lower the more it looks like they are nested in deep directories.

Generally, when you're doing something like this, it's generally nice to do a blend of the two methods. There is nothing wrong with having some get variables. Also, you could add in a url mapping that auto-assigns get variables on the back-end. That way you can have things like, say, "/page-1-1.html" translate to ?chapter=1&page=1 to your scripts. However, if you want to do something like sort by X as well, keep that as a GET param, there's no need to mask things like that as it's nothing more than needless and extra headaches.

Generally in something like a CMS (which is what I'm familiar with), you'd have some sort of URL mapping that translates particular special urls or patterns into the explicit variables you need. Say, for instance, you are using a CMS and therefore need to define a controller and view for viewing a comic page vs a news article. The comic page could be something like, say, the "viewIndex" method on the "ControllerComic" controller, where the news article page could be the "viewIndex" method on the "ControllerNews" controller:

Code: [Select]
class ControllerComic {
  public function viewIndex() {
  }
}

class ControllerNews {
  public function viewIndex() {
  }
}

Yet to define this to your system you pass something like, say a "view" variable

Now, what you could do is make something like "/comic-1-1.html" translate to "?view=comic.index&chapter=1&page=1" to your primary script, then loading/appending things to get the appropriate controllers and views:

Code: [Select]
if (preg_match(';/comic-([0-9]+)-([0-9]+)[.]html;', $_SERVER['REQUEST_URI'], $match)) {
  $_GET['controller'] = 'comic';
  $_GET['view'] = 'index';
  $_GET['chapter'] = $match[1];
  $_GET['page'] = $match[2];
}

Of course this is a VERY rough example, and I'd generally advise against explicitly setting GET/POST vars in this fashion. Instead it would be better to explicitly define a global custom environment variable for your application and read that in conjunction to the passed GET/POST vars.
Title: Re: Cleaning up PHP $_GET URLs
Post by: Miluette on May 19, 2009, 10:17:39 pm
I hope you know I have no idea what you just said. :V

(Also, this part of my site isn't running on a real formal CMS - just CuteNews. The actual Wordpress install is in my archives, and if I were using WP to power my entire site(s) I wouldn't even be using CN.)

I'm getting a real "leave ugly URLs as is" vibe here. If I wanted to change it I'd have to get into how CN is written, and, well, I don't want to, lol.
Title: Re: Cleaning up PHP $_GET URLs
Post by: Miluette on May 27, 2009, 10:58:52 pm
Ah! For the record, I found out there's a hack for this already. Didn't think there would be, but there you go.

By rights I shouldn't be using CuteNews at all, but it's just so dang convenient. I mean, you command so much control over it... (when you've nabbed a few people who can hack code)

Interestingly, however, as nice as those cleaned-up URLs are, I just realized that this hack (http://democute.de.funpic.de/cute/example2.php?subaction=showfull&id=1145819972&archive=&start_from=&ucat=6) causes all my CSS'd images and links to be horribly broken, since all the links are relative paths and the news listings are set to paths like /postpage/. Whoopsie.

I hadn't thought of that before. I wonder what I can do about that?

Well, there are too many things wrong with that hack that I hadn't considered, so until I can fix it myself I'm not using it lol...
Title: Re: Cleaning up PHP $_GET URLs
Post by: Databits on May 28, 2009, 03:41:53 am
Sorry about that. I do this stuff for a living so writing CMS's and stuff is like second nature to me. I sometimes forget that when trying to explain it to other people who may not have the experience I've got.

A fatal flaw, I'm afraid, that many programmers share.