|Mod_Rewrite & getting shorter url's|
My programmer has used mod_rewrite to get static urls from dynamic in an osCommerce cart. The current structure for product pages is this:
I'm interested in shortening the url. I have a vague recollection of a thread that discussed removing parts of the url with mod_rewrite but my 2 hours of searching can't find it.
Is there a way to rewrite the product url's to something shorter like:
[domain.com...] or whatever?
Is there a benefit of having a file extension at the end? Won't that effectively move it one directory higher?
BTW, I've been using some info from this thread [webmasterworld.com] and others as we've been doing the hacking.
I think that this might be relevant
osCommerce has a very active message board. Have you posted there? In fact, don't post there, SEARCH there, because this question comes up constantly on their board.
The most obvious thing you can do to shorten the URL is put the catalog in your root directory (either physically on the hard drive or virtually with mod_rewrite). That will get rid of the /catalog part.
as for the rest, I haven't used osC in a while (so take this with a grain of salt), but did some fairly major hacking on PR2.3 (which is still current) once upon a time.
The problem with the url you propose (where you drop product_id and cPath) is that it will only work if you are sure which parameters are being sent and in which order. As I recall, there are so many options and so on in osC, that you simply can't count on this. Also, you can't change product_id to pID without serious forethought because both are used in osC and the former is often used specifically to avoid confusion with the latter. Any solution like that will require extensive testing.
Is there a benefit of having a file extension at the end
I don't know about SEO effects, but aside from that, no, there is no benefit and there are several drawbacks.
1. it exposes your software (e.g if it's php or asp it tells hackers what you are using, which saves them those first seven seconds)
2. it is non-permanent. Someday your site will be running on other software. You will decide that all files should have *.wertsa extensions because that is the absolute best new software out there. Now every single one of your urls is obsolete
3. You wanted shorter urls didn't you?
You might want to check out the article by Tim Berners-Lee
Cool URIs don't change [w3.org] (and note that the url for his own article breaks at least ontwo of his rules).
Now to show my anal retentive side..
used mod_rewrite to get static urls from dynamic
The form of the url does not determine whether it is static or dynamic. In fact, all of these URLs are "temporarily static" (they stay what they are until you change them), though they point to dynamic pages.
Use mod_rewrite in .htaccess to redirect requests for
- to -
RewriteRule ^catalog/product_info.php/cPath/([0-9]+)/product_id/([0-9]+)$ /catalog/$1-$2 [L]
You may actually be wanting to go the other way. If so, the technique is the same, just the details
of the RewriteRule change:
Use mod_rewrite in .htaccess to redirect requests for
- to -
RewriteRule ^catalog/([0-9]+)\-([0-9]+)$ /catalog/product_info.php/cPath/$1/product_id/$2 [L]
See Apache mod_rewrite documentation [httpd.apache.org]
Check for typos, use at your own risk!
Hope this helps,
Jim's solution gets you the URL you want, but like I said, you have to be super careful if you're going to do this in osCommerce. I think you will probably break the app because it has not traditionally been very strict about the order in which GET params are listed and it uses several different ones.
The problem is not rewriting the URLs - as Jim showed, that's easy. The problem is that with that rewriting, you are losing data. You'll have just the values, but not the keys and since the keys are different for different pages and situations, it's going to be really hard to parse. I just grepped an old version for $HTTP_GET_VARS[' and got 1331 matches in 119 files. Just looking throught hte first twelve files returned, I found the following keys:
Once you eliminate the key information from your URL and have just the values, how on earth do you propose to parse this and make sense of it?
Be really careful and make sure whoever is doing is a solid coder who either has prior knowledge of osCommerce. I would say this will likely cost you a bundle and it will make it impossible for you to keep up with the CVS and apply patches.
I grepped again for tep_href, the URL wrapper they use. The first two URLs returned were
tep_href_link(FILENAME_CATEGORIES, 'cPath=' . $new_parent_id . '&cID=' . $categories_id);
tep_href_link(FILENAME_CATEGORIES, 'cPath=' . $new_parent_id . '&pID=' . $products_id);
This means you have
You can't parse this intelligently if you drop the keys from your URLs. It's going to require a lot of rewriting
Thanks for all the input. As I'm not a coder, my hope was to get a discussion that I could point my programmer to, so thanks again.
|osCommerce has a very active message board. Have you posted there? In fact, don't post there, SEARCH there, because this question comes up constantly on their board. |
I'd say I've read at least a thousand posts over there in the last 3 weeks. Plenty of big talkers over there that know just the right way to stuff the meta tags to rank #1 for every word in the dictionary. Unfortunately, I've studied about 100 osCommerce sites and exactly 1 has multiple pages indexed in Google. Not looking real optimistic, but I'm hoping to be the second indexed site.
The cart has so many nice features and a dang good initial cost, you can't help but want it to work. Sure wish someone could just give us a *definitive* answer on what Googlebot doesn't like about osCommerce and suggestions on how to make it GBot friendly ... Anyone, anyone?
Any more comments are Greatly appreciated.
Give me a couple months & I'll post an update.
I know something about osC and next to nothing about SEO, but for what it's worth...
I wonder if the problem isn't due to the fact that by default there's nothing of interest on an osCommerce front page. In other words, all you have is X new products with no descriptions. Once Google crawls to these products, it sort of dead ends. There are a couple of links to other products on the individual product pages, but I suspect that Google follows a few of these links, basically get "More of same" and stops.
How many products will you have? Could you generate a page that lists all products with brief descriptions and put this one link off the main page? Call it something like "Complete Printable Price List". I think any programmer should be able to pull something nice out of your osC database. This would allow your visitors to print out a full catalog and, if you had links there, it would actually get Google to *all* your products in three pages (home -> price list -> product).
Another potential problem is that there is a lot of code overhead on the pages (header, links, and so on) and the links in that code are mostly to things like a search page, a list of manufacturers and so on. Most of these, if crawled (some are drop-down lists or text boxes that won't get crawled), get you to a page of links. Like in the default setup you go
Front page -> computers -> hardware -> printers -> DING DING DING actual product 5 pages deep. There are product listings on some of the previous pages, but nothing that showcases a single product.
By the time you get to the product listing links (often a good ways down the page) that Google would need to follow (i.e. the "What's New" section), Google may have given up on the page.
Incidentally, I haven't looked at the code in a while, but it's miles for validation.
I realize that sounds a little negative RE osCommerce. Actually, I think that what they're doing is fantastic and the people involved are really doing hard work and tremendous work. That said, I don't think it will really come into it's own until they implement a templating system, which won't come until Preview Release 3.0/version 1 according to the old roadmap. They are also hampered by the desire to have something that works on as many systems as possible. Last I checked they were committed to creating something that would run under PHP3. Laudable, but it does complicate their lives a lot and slow down the app at least a little (when it checks to see if the PHP4 native function exists before it uses it).