Okay this subject comes up ALOT.. <br /> <br />First of all what it is.. <br /> <br /> [] Search Engine-Friendly URLs <br />By Chris Beasley <br />August 10th 2001 <br />Reader Rating: 8.8 <br /> <br />On today’s Internet, database driven or dynamic sites are very popular. Unfortunately the easiest way to pass information between your pages is with a query string. In case you don’t know what a query string is, it's a string of information tacked onto the end of a URL after a question mark. <br /> <br />So, what’s the problem with that? Well, most search engines (with a few exceptions - namely Google) will not index any pages that have a question mark or other character (like an ampersand or equals sign) in the URL. So all of those popular dynamic sites out there aren’t being indexed - and what good is a site if no one can find it? <br /> <br />The solution? Search engine friendly URLs. There are a few popular ways to pass information to your pages without the use of a query string, so that search engines will still index those individual pages. I'll cover 3 of these techniques in this article. All 3 work in PHP with Apache on Linux (and while they may work in other scenarios, I cannot confirm that they do). <br /> <br />Method 1: PATH_INFO <br /> <br />Implementation: <br /> <br />If you look above this article on the address bar, you’ll see a URL like this: http://www.webmasterbase.com/article.php/999/12. SitePoint actually uses the PATH_INFO method to create their dynamic pages. <br />The PHP Anthology: Volume I & II <br /> <br /> * Save hours researching solutions to common problems <br /> * Explore real-world Object Oriented Programming with PHP <br /> * Develop secure, reliable PHP Applications <br /> * Cut down on wasted development time with enterprise practices <br /> <br /> * Download 4 Sample Chapters FREE <br /> <br />Apache has a "look back" feature that scans backwards down the URL if it doesn’t find what it's looking for. In this case there is no directory or file called "12", so it looks for "999". But it find that there's not a directory or file called "999" either, so Apache continues to look down the URL and sees "article.php". This file does exist, so Apache calls up that script. Apache also has a global variable called $PATH_INFO that is created on every HTTP request. What this variable contains is the script that's being called, and everything to the right of that information in the URL. So in the example we've been using, $PATH_INFO will contain article.php/999/12. <br /> <br />So, you wonder, how do I query my database using article.php/999/12? First you have to split this into variables you can use. And you can do that using PHP’s explode function: <br /> <br />$var_array = explode("/",$PATH_INFO); <br /> <br />Once you do that, you’ll have the following information: <br /> <br />$var_array[0] = "article.php" <br /> <br />$var_array[1] = 999 <br /> <br />$var_array[2] = 12 <br /> <br />So you can rename $var_array[1] as $article and $var_array[2] as $page_num and query your database. <br /> <br />Drawback: <br /> <br />There was previously one major drawback to this method. Google, and perhaps other search engines, would not index pages set up in this manner, as they interpreted the URL as being malformed. I contacted a Software Developer at Google and made them aware of the problem and I am happy to announce that it is now fixed. <br /> <br />There is the potential that other search engines may ignore pages set up in this manner. While I don't know of any, I can't be certain that none do. If you do decide to use this method, be sure to monitor your server logs for spiders to ensure that your site is being indexed as it should. <br /> <br /> <br />Method 2: .htaccess Error Pages <br /> <br />Implementation: <br /> <br />The second method involves using the .htaccess file. If you're new to it, .htaccess is a file used to administer Apache access options for whichever directory you place it in. The server administrator has a better method of doing this using his or her configuration files, but since most of us don't own our own server, we don't have control over what the server administrator does. Now, the server admin can configure what users can do with their .htaccess file so this approach may not work on your particular server, however in most cases it will. If it doesn't, you should contact your server administrator. <br /> <br />This method takes advantage of .htaccess’ ability to do error handling. In the .htaccess file in whichever directory you wish to apply this method to, simply insert the following line: <br /> <br />ErrorDocument 404 /processor.php <br /> <br />Now make a script called processor.php and put it in that same directory, and you're done! Lets say you have the following URL: http://www.domain.com/directory/999/12/. And again in this example "999" and "12" do not exist, however, as you don't specify a script anywhere in the directory path, Apache will create a 404 error. Instead of sending a generic 404 header back to the browser, Apache sees the ErrorDocument command in the .htaccess file and calls up processor.php. <br /> <br />Now, in the first example we used the $PATH_INFO variable, but that won’t work this time. Instead we need to use the $REQUEST_URI variable, which contains everything in the URL after the domain. So in this case, it contains: /directory/999/12/. <br /> <br />The first thing you need to do in processor.php is send a new HTTP header. Remember, Apache thought this was a 404 error, so it wants to tell the browser that it couldn’t find a page. <br /> <br />So, put the following line in your processor.php: <br /> <br />header("HTTP/1.1 200 OK"); <br /> <br />At this time I need to point out an important fact. In the first example you could specify what script processed your URL. In this example all URLs must be processed by the same script, processor.php, which makes things a little different. Instead of creating different URLs based on what you want to do, such as article.php/999/12 or printarticle.php/999/12 you only have 1 script that must do both. <br /> <br />So you must decide what to do based on the information processor.php receives - more specifically, by counting how many parameters are passed. For instance on my site, I use this method to generate my pages: I know that if there's just one parameter, such as <br /> <br />http://www.online-literature.com/shakespeare/, that I need to load an author information page; if there are 2 parameters, such as http://www.online-literature.com/shakespeare/hamlet/, I know that I need to load a book information page; and finally if there are 3 parameters, such as http://www.online-literature.com/shakespeare/hamlet/3/, I know I need to load a chapter viewing page. Alternatively, you can simply use the first parameter to indicate the type of page to display, and then process the remaining parameters based on that. <br /> <br />There are 2 ways you can accomplish this task of counting parameters. First you need to use PHP’s explode function to divide up the $REQUEST_URI variable. So if $REQUEST_URI = /shakespeare/hamlet/3/: <br /> <br />$var_array = explode("/",$REQUEST_URI); <br /> <br />Now note that, because of the positioning of the /’ there are actually 5 elements in this array. The first element, element 0, is blank, because it contains the information before the first /. The fifth element, element 4, is also blank, because it contains the information after the last /. <br /> <br />So now we need to count the elements in our $var_array. PHP has two functions that let us do this. We can use the sizeof() function as in this example: <br /> <br />$num = sizeof($var_array); // 5 <br /> <br />You’ll notice that the sizeof() function counts every item in the array regardless of whether it's empty. The other function is count(), which is an alias for the sizeof() function. <br /> <br />Some search engines, like AOL, will automatically remove the trailing / from your URL, and this can cause problems if you’re using these functions to count your array. For instance http://www.online-literature.com/shakespeare/hamlet/ becomes http://www.online-literature.com/shakespeare/hamlet, and as there are 3 total elements in that array our processor.php would load an author page instead of a book page. <br /> <br />The solution is to create a function that will count only the elements in an array that actually hold data. This will allow you to leave off the ending / or allow any links from AOL'’s search engine to point to the proper place. An example of such a function is: <br /> <br />function count_all($arg) <br />{ <br /> // skip if argument is empty <br /> if ($arg) { <br /> // not an array, return 1 (base case) <br /> if(!is_array($arg)) <br /> return 1; <br /> // else call recursively for all elements $arg <br /> foreach($arg as $key => $val) <br /> $count += count_all($val); <br /> return $count; <br /> } <br />} <br /> <br />To get your count, access the function like this: <br /> <br />$num = count_all($url_array); <br /> <br />Once you know how many parameters you need, you can define them like this: <br /> <br />$author=$var_array[1]; <br />$book=$var_array[2]; <br />$chapter=$var_array[3]; <br /> <br />Then you can use includes to call up the appropriate script, which will query your database and set up your page. Also if you get a result you’re not expecting, you can simply create your own error page for display to the browser. <br /> <br />Drawback: <br /> <br />The drawback of this method is that every page that's hit is seen by Apache as an error. Thus every hit creates another entry in your server error logs, which effectively destroys their usefulness. So if you use this method you sacrifice your error logs. <br /> <br />Method 3: The ForceType Directive <br /> <br />Implementation: <br /> <br />You'll recall that the thing that trips up Google, and maybe even other search engines, when using the PATH_INFO method is the period in the middle of the URL. So what if there was a way to use that method without the period? Guess what? There is! Its achieved using Apache'’s ForceType directive. <br /> <br />The ForceType directive allows you to override any default MIME types you have set up. Usually it may be used to parse an HTML page as PHP or something similar, but in this case we will use it to parse a file with no extension as PHP. <br /> <br />So instead of using article.php, as we did in method 1, rename that file to just "article". You will then be able to access it like this: http://www.domain.com/article/999/12/, utilizing Apache's look back feature and PATH_INFO variable as described in method 1. But now, Apache doesn’t know to that "article" needs to be parsed as php. To tell it that, you must add the following to your .htaccess file. <br /> <br /><Files article> <br /> ForceType application/x-httpd-php <br /></Files> <br /> <br />This is known as a "container". Instead of applying directives to all files, Apache allows you to limit them by filename, location, or directory. You need to create a container as above and place the directives inside it. In this case we use a file container, we identify “article” as the file we're concerned with, and then we list the directives we want applied to this file before closing off the container. <br /> <br />By placing the directive inside the container, we tell Apache to parse "article" as a PHP script even though it has no file extension. This allows us to get rid of the period in the URL that causes the problems, and yet still use the PATH_INFO method to manage our site. <br /> <br />Drawback: <br /> <br />The only drawback to this method as compared with method 2 is that your URLs will be slightly longer. For instance, if I were to use this method on my site, I'd have to use URLs like this: http://www.online-literature.com/ol/homer/odyssey/ instead of http://www.online-literature.com/homer/odyssey/. However if you had a site like SitePoint and used this method it wouldn't be such a problem, as the URL (http://www.SitePoint.com/article/755/12/) would make more sense. <br /> <br />Conclusion <br /> <br />I have outlined 3 methods of making search engine friendly URLs - along with their drawbacks. Obviously, you should evaluate these drawbacks before deciding which method to implement. And if you have any questions about the implementation of these techniques, they are oft-discussed topics on the SitePoint Forums so just stop in and make a post. <br /> <br /> [/] <br /> <br />Now then this only works in the Linux/Unix World using Apache. What about for IIS/Windows.. The above won;t work.. so we are left with what to do.. well one alternative is IIS_Rewrite <br /> <br /> <br /> []IIS Rewrite <br /> <br />Product Summary <br />IISRewrite is a rule-based rewriting engine that allows a webmaster to manipulate URLs on the fly in IIS. <br /> <br />URLs are rewritten before IIS has handed over the request to be processed, so requests for HTML files, graphics, program files, and even entire directory structures can be rewritten before they are passed to ASP scripts for processing. <br /> <br />IISRewrite was written to solve some practical problems that are nearly impossible to solve with IIS and ASP. It solves the compatibility issues when doing dynamic downloads with ASP, it allows portions of dynamic sites to be indexed by search engines as if they were static HTML files, and can provide a way to customize web sites based on the client's browser type without the use of Javascript. <br /> <br />IISRewrite is a stripped down implementation of Apache's mod_rewrite modules for IIS. Webmasters who have used Apache's mod_rewrite in the past will find that much of the configuration and functionality is the same. <br /> <br />IISRewrite is compatible with Microsoft's ISAPI specification and has been tested on Windows NT Server 4.0 running IIS 4 and Windows 2000 Server running IIS 5. <br /> <br />IISRewrite was featured in the February 2002 edition of Microsoft's MSDN Magazine. [/] <br /> <br />More Information can be found at IIS_Rewrite <br /> <br />Its costly.. and costs $199.00 per server <br /> <br />Another alternative is ISAPI_Rewrite <br /> <br /> [] <br /> <br />Product overview <br /> <br />ISAPI_Rewrite is a powerful URL manipulation engine based on regular expressions. It acts mostly like Apache's mod_Rewrite, but is designed specifically for Microsoft's Internet Information Server (IIS). ISAPI_Rewrite is an ISAPI filter written in pure C/C++ so it is extremely fast. ISAPI_Rewrite gives you the freedom to go beyond the standard URL schemes and develop your own scheme. <br /> <br />What you can do with ISAPI_Rewrite: <br /> <br /> * Optimize your dynamic content like forums or e-stores to be indexed by a popular search engines. <br /> * Block hot linking of your data files by other sites. <br /> * Develop a custom authorization scheme and manage access to the static files using custom scripts and database. <br /> * Proxy content of one site into directory on another site. <br /> * Make your Intranet servers to be accessible from the Internet by using only one Internet server with a very flexible permissions and security options. <br /> * Create dynamic host-header based sites using a single physical site. <br /> * Create virtual directory structure of the site hiding physical files and extensions. This also helps moving from one technology to another. <br /> * Return a browser-dependent content even for static files. <br /> <br />And many other problems could be solved with the power of the regular expression engine built into the ISAPI_Rewrite. [/] <br /> <br />Drawback is that it costs per license.. <br /> <br />For 1 it is 69.00 <br />For 2-5 it is 58.65 per <br />For 6-10 it is $49.85 <br />and so on <br /> <br />you can find more info at <br /> <br /> ISAPI_Rewrite <br /> <br />Hope this helps to clear it ul for you <img src="http://www.ubbdev.com/forum/images/graemlins/grin.gif" alt="" />

Interesting, thank you <img src="http://www.ubbdev.com/forum/images/graemlins/smile.gif" alt="" /><br /><br />I've found for Win2K/IIS5 in the php.ini file there's a paragraph like so:<br /><br /><br />[]; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI. PHP's<br />; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok<br />; what PATH_INFO is. For more information on PATH_INFO, see the cgi specs. Setting<br />; this to 1 will cause PHP CGI to fix it's paths to conform to the spec. A setting<br />; of zero causes PHP to behave as before. Default is zero. You should fix your scripts<br />; to use SCRIPT_FILENAME rather than PATH_TRANSLATED.<br />; cgi.fix_pathinfo=0<br />[/]<br /><br />If you change the last line to:<br /><br />cgi.fix_pathinfo=1<br /><br />then SEF urls work. Images within threads are spotty tho, some work and some don't. The ones that don't will have url's like:<br /><br />http://www.website.com/ubbthreads/showflat.php/Cat/0/Number/98389/an/0/page/images/star.gif<br /><br />These images (and the other broken images) were given {$config['images']}/star.gif (etc) and so the full url for the page was enabled. They would need to be changed to $config['imageurl'] instead to fix the broken images links <img src="http://www.ubbdev.com/forum/images/graemlins/smile.gif" alt="" /> I haven't checked everything yet (prelim results are good tho) but that would be a simple fix to achieve SEF urls <img src="http://www.ubbdev.com/forum/images/graemlins/yay.gif" alt="" />

cool <img src="http://www.ubbdev.com/forum/images/graemlins/smile.gif" alt="" />

[]http://emeraldforestseattle.nuclearfallout.net/ubbthreads/images/graemlins/yeahthat.gif[/]

Isn't this kinda obsolete for UBBThreads 6.5 since they already have spider friendly urls?

No <img src="http://www.ubbdev.com/forum/images/graemlins/smile.gif" alt="" /> Since just cause ya have it turned on doesn't mean its working <img src="http://www.ubbdev.com/forum/images/graemlins/smile.gif" alt="" />

> Since just cause ya have it turned on doesn't mean its working<br /><br />It works on this site.(since when it wasn't included in the infopop package). <br />Why shouldn't it work now?

It works on this site prior to 6.5 because Josh built his own spider friendly modification... He also uses a Linux server and he has a good setup... Now in most windows environments unless ya know what ya doing and own the server it doesn't work out of the box. On some Linux setups it fails also because of the way their server is probably setup.. <img src="http://www.ubbdev.com/forum/images/graemlins/grin.gif" alt="" />

Yeah, my experience was that it only worked on 75% of the servers without playing with the server setup.

*sniff-sniff* im off to go open my, "save for spider friendly mods" account <img src="http://www.ubbdev.com/forum/images/graemlins/smile.gif" alt="" />

I must have done something wrong <img src="http://www.ubbdev.com/forum/images/graemlins/crazy.gif" alt="" /><br /><br />I edited my .htaccess file using method 2. 15 mins after I uploaded I had a visit from a bot and it killed my site. It would not load any pictures or my stylesheet. Even the infopop graphic at the bottom of the page would not load.<br /><br />Any ideas whats wrong?

[]<br />Drawback:<br /><br />The drawback of this method is that every page that's hit is seen by Apache as an error. Thus every hit creates another entry in your server error logs, which effectively destroys their usefulness. So if you use this method you sacrifice your error logs.[/]<br /><br /><br />it could be the way your apache config handles errors, Not every method will work on every configuration. As far as I have seen it there is actually no right way and is server dependent.

[]scroungr said:it could be the way your apache config handles errors, Not every method will work on every configuration. As far as I have seen it there is actually no right way and is server dependent. [/]<br /><br />I see now, oh well, nothing gained, nothing lost

I want to try "Method 1: PATH_INFO" to make my php/mysql based site to get SEO friendly URL's I am not very good in coding. Can some one help me with the codes that I need to add to my php scripts that will enable this method?<br /><br />My URL require about 3 var_array. Example :<br />http://www.domain.com/user/details.php?VehicleId=303&currency_id=1&userid=2543<br /><br />Should look like:<br />http://www.domain.com/user/details/VehicleId/303/currency_id/1/userid/2543.html<br /><br />Thank you,

I thought I'd post this here for reference.<br /><br />I ran against a server which was running PHP as a CGI and wouldn't accept .php/Cat/0 etc... (the slash after the .php caused an error). I think you can recompile PHP with different options, but I didn't have that ability. So essentially the PATH_INFO method, which Threads 6.5 uses was ruled out. I was able to make some quick modifications to the stock 6.5 code and use REQUEST_URI instead.<br /><br />Here's how:<br /><br />In ubbt.inc.php find this:<br /><br /><br />Change to this:<br /><br /><br />Then I changed this:<br /><br /><br />to this:<br /><br /><br /><br />This still puts the ? in the URL, but makes the request appear to have only one variable. Then we make it look like the path info method and threads can split the variables out and go from there. <br /><br />YMMV (Your mileage may vary) as all servers are different. <img src="http://www.ubbdev.com/forum/images/graemlins/smile.gif" alt="" />

Hi,<br /><br />I'm from the Netherlands and my English is not so well, but i'll try. Now i'm using the code above, because the PATH_INFO variable wasn't available. Everything works okay, but for example with the "view=expand" button...i get the old url: ?var=var&var=var etc. So soms options doesn't work with the method above?

spider-friendly url's are in threads 6.5+ - there's security exploits in the older stuff, you might want to upgrade <img src="/forum/images/graemlins/smile.gif" alt="" />

I'm running on version 6.5.2 ...

I see (sorry for not reading your whole post <img src="/forum/images/graemlins/blush.gif" alt="" /> ). Josh's mod probably wasn't designed to work with all possible links, looks like his example was just for searches, tho probably it can be adapted for the other urls. Which ones are you especially interested in?

Ah okay, if google doesn't need those links or it doesn't matter for how good google finds you, it's no problem.