With my method, you need to parse everything out within php, so you would need to do something like this to start with
// create a URL without any GET params and don't allow HTML or PHP in URI
$url = strip_tags(str_replace("?" . $_SERVER['QUERY_STRING'], "", $_SERVER['REQUEST_URI']));
// we don't want the server name part b/c we don't store that in our DB (portability)
$url = str_replace($_SERVER['SERVER_NAME'], '', $url);
now the $url should be the same as the one we store in our DB or lookup file.
Query the DB for the $url and get the content of the page or the filesystem path to the image or whatever it is that you do. So in your case, the $url part would be equal to 'test/somedata/'
$query = SELECT photo_title as title, photo_caption as caption, photo_src as src FROM photos WHERE photo_url='$url'";
and then, once you've fetched that data from the DB, on your template page you would have something like
This is sort of nice because the url is completely independent of the file system. In addition, you can still have URLs where the GET parameters look like get parameters if you want that, but can look like "friendly urls" if you want, which I sometimes find useful.
To be honest, I also sometimes find it wasteful, since a rewrite rule adds almost no server overhead, whereas this method adds a database request and additional scripting. If you can do what you want simply with a simple rewrite rule, that is undoubtedly the better solution. From what you describe, though, I think you might find you get some decent benefit from the more complex method. It depends a little on your traffic, server power and all that I guess.
The rule that causes a server error is probably doing so because you cut and pasted it. This forum software breaks pipes, so when you paste code wth pipes in it, you must retype the ¦ Sorry I forgot to mention that when I posted the original rule.