Forum Moderators: coopster
Would it make sence to make the url in the form "find/2/4"? The problem I have with that is how would I be able to identify which of the values correspond to which variable.
Another option with this would be to use Sessions instead of passing variables through the url. Would that make it Search Engine Friendly? Also would it make a difference if I store SID within the url or within cookies?
And if I do store the SID withing the url, should I somehow mod the url to make the SID appear as a folder?
Thanks
I use different checkbox groups to set the criteria. For example var1 could equal *string1*string2*string3*... var2 could equal *string1*string2*string3*... so if you combine it all it would look something like this:
find.php?var1=*string1*string2*string3*&var2=*string1*string2*string3*
So as you can see the url becomes very bulky. I'm looking for suggestions on how to handle this. Any help would be appreciated.
Thanks.
Would it make sence to make the url in the form "find/2/4"?
If the architecture is stable and you can be sure that the various parameters will always be in those spots, then yes, you can do this. You would either use some sort of URL rewriting or you would parse the information based on the $_SERVER['REQUEST_URI'] variable.
Another option with this would be to use Sessions instead of passing variables through the url.
I don't follow. How will session vars know which page your user wants to go to?
as for using the var1/var2/var3 scheme all you have to do is say that if one var is missing it will pass a 0 in its place
$var1 = hi; $var3=hello
www.example.com/folder/hi/0/hello
then use a .htaccess file to parse the url
RewriteEngine On
RewriteCond ^(.*)/(.*)/(.*)$
RewriteRule (.*)/(.*)/(.*) file.php?var1=$1&var2=$2&var3=$3
would that be search engine friendly or would I have to remove the '*' and replace them with -, or _?
Also is there any point in making these search engine friendly since there will be no direct links to them from anywhere on the site. (they will be generated via forms).
Personally, I don't think short query strings are a major factor for search engines. Search engines handle URLs of this form just fine:
[example.com...]
These are "human unfriendly" not SE unfriendly. There was a time when SEs did not follow query strings, but that was years ago now. It is *probably* better than
The big issue is: how far is it from your home page *or* a page that ranks highly with the SEs. That overrides the actual naming scheme. If the only path to get there requires 12 clicks from your homepage and there are no pages along that click path that are highly rated and have inbound links, it doesn't matter whether your URL is
[example.com...]
you won't likely be in the SEs. On the other hand, if the last parameter in this URL correctly describes the content, as ugly as it is,
[example.com...]
&d=21&catid=31&subcatid=12&articleid=543&photoid=3504
&photosubject=only_pic_on_web_of_Britney_with_new_baby
it will be #1 in Google for when people want to see Britney's baby.
One other thing to keep in mind - what SEs like and don't like changes and adapts based on what's on the web. I'm not saying to ignore SEs in terms of your URLs, but that if you pitch your URL scheme so that it makes sense to users, that will be best in the long term because, the long term goal of SEs is to approximate the opinion of visiting users, and our mental capacity evolves far more slowly than SE technology. So any system that is pitched to SEs may or may not work for the long haul. Any system pitched to making readable URLs for users, should by virtue of that, be SE friendly now and forever.
So IMO the reason for use "clean" or "readable" URLs (which are terms I prefer to "SE Friendly") is that *ideally* (so I'm not saying I always do this, just that I would if I weren't so darn lazy):
- URLs should not be architecture dependent, so they should not have file extensions or be wedded to a given directory structure or means of querying for data
- they should be built to last, not have to change when you change from php to Ruby9
- they should be understandable in conversation as much as possible
- they should be robust. So if you use "string1_string2_string3", you should think about what happens when string1 is "a_string_with_underscores".
I think of these as usability optimizations, rather than SE optimizations.
On the specific question of * in URL, that will be a problem. You will need to URL-encode your URLs (in other words use %xx in place of *) because that is a reserved character.
Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde.
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Anything else needs to be percent-encoded. This is covered in the Characters section of RFC3986 [gbiv.com]
[edited by: ergophobe at 5:33 pm (utc) on May 21, 2005]
Also is there any point in making these search engine friendly since there will be no direct links to them from anywhere on the site. (they will be generated via forms).
Again, I would use usability not SEs as a test for what URL schema you should apply, but if they require a form submission, SEs can't get there in any case, so the point is moot as are some of the comments I made in the previous post.
I wonder, is your long query string because you are sending data from the form using the "get" method?
I don't know what your exact situation is, but I would say that the following would work pretty well.
1. submit the form using method="post"
2. fields that need to get passed on to the next page are maintained as hidden fields using <input type="hidden">
3. subsequent pages beyond the doorway page check for something and if not present, redirect to the doorway page as in
if (!isset($_POST['var1']))
{
header("Location: [example.com...]
}
So far I couldn't get it to work properly, and I have no idea why. I tried changing the php settings on my xampp server before i tested it , but it didn't work. I was wondering if there is any way to change the php.ini values without actually accessing it (I don't have access to it on my server), maybe through .htaccess file or through the actual code. Any help would be appreciated, thanks. :)
