Velveeta

i think it should also be mentioned that the cookie scope is a security measure to keep other domains from reading your customers' cookies and finding out any personal data in it (i would also suggest base64_encoding the data you store in them)... if you set the cookie domain with preceding dots like .allthingschildren.com, that means the cookie is valid for any domain with that in the name, meaning www.allthingschildren.com, mail.allthingschildren.com, etc... if you were to simply set the cookie domain to "allthingschildren.com", then theoretically, a person could go out and register ballthingschildren.com, wallthingschildren.com, etc... and have access to the customers' cookie contents (if they could crack the encryption on them, which is one more reason to encrypt the data :D)... just some things to keep in mind :) Richard Lindsey.

Would you mind posting that simple change? We've been trying to get headyntl's SIDs out of his urls for the past few days, and it's still not working unless the site sets a cookie... Richard Lindsey.

I had that same problem for some reason on my site when i enabled Force Cookies to get rid of the SID in the url... heady, yet again, i'm going to refer you to the other thread for Ultimate SEO URLs, in which, on page 36, halfway down, i print a solution for keeping SIDs out of the url, without having to force cookie usage... Richard Lindsey.

another thing i can suggest is checking the search engines' indexes of your pages in a few months and see if they've updated... i know that on google and msn this works, and i would imagine that the others may have something similar, but since a ton of minor engines pull their results from these 2, you won't have to worry about them... if you do a search for "site:<domain name>" it'll show you all of the pages it has in its index for that site (including those of less than 4 pagerank in the case of google, which doesn't display those in normal results), so in the case of my own site, a search for this: site:allthingschildren.com only shows me like 2 pages on google, and only about 25 on msn (hey, we're only a week old :D), and if you check those in a few months you'll be able to see if the urls have the old-style format or if they've reindexed w/ the new one... now because this doesn't work on all engines probably, and like chemo said, it doesn't add any overhead, you may want to leave it in like he suggested, but if you keep feeling the itch to take it out, you can check some of the search engines w/ the method i showed above :) Richard Lindsey.

Heady, go check the other thread for this contribution, page 36, about halfway down the page, here's the url: http://www.oscommerce.com/forums/index.php?sho...c=130999&st=700 You'll see where i posted a solution that will most likely work for your problem... the SID being patched into the url isn't anything to do with this contribution, it's just the way that most web servers run by default... a quick little ini_set should correct the problem, and i've left the code to look for and what to replace it with in the other thread, enjoy :D Richard Lindsey.

Heya Chemo, any thoughts as to my problem with the apostrophes and quotation marks not stripping properly in my urls? It's still gnawing at me :D Richard Lindsey.

This is a tricky one, because of the way the searchbots work... one way you could do it would be to go into includes/application_top.php (approx. line 200) and find where the spider check is done and if passed, the session is started... at that point i would register $spider_flag... then, anywhere you don't want spiders to index options, such as sort options, check if $spider_flag is registered, and if it's not (most likely a spider) then don't print the href link for those options in the column headers, otherwise print them... that way a user can still sort, and a spider can still see the same page (default-sorted), but the clickable links to sort by various columns won't work for the spider to follow, and it can't index the page w/ those extra options... i don't think you can do it w/ .htaccess, even if you got a mod_rewrite snippet that would convert your arguments into directory appearance (like index.php/sort/2/page/1), because i believe .htaccess operates after mod_rewrite translates the url, so it would still be operating on the actual file (index.php or whatever) and wouldn't be able to deny access for spiders to say, index.php/* Hope that helps... Richard Lindsey.

i'm afraid i don't remember if that was the case, but all you'd have to do to find out is go grab a stock version of OSC and check the application_top file, because that's the version i installed it into, a plain old stock OSC MS2.2... but i can tell you that the case statements above that one (update_product, add_product) use HTTP_POST_VARS, and the ones below it (notify, notify_remove, cust_order) use HTTP_GET_VARS... if this looks similar to yours, then it's probably the same version... Richard Lindsey.

Good question, I hadn't even noticed that when I installed it, I guess I was just caught up in the cutting and pasting (plus it was on a vanilla version of OSC so I wasn't too concerned :D)... I know this has worked fine for me, and you're right, if it were passing the variables via $_POST and he were referencing them with $_GET, I don't think it would work, but I know it does work fine for me... it may have something to do w/ the mod_rewrite rules, which pass everything to the code in the form of a $_GET url with all the options in the url, and it may be that I have it wrong also, and that $_GET will reference $_POST variables, perhaps depending on your version of PHP (I know they've locked it down quite a bit in version 5, and I'm pretty positive you can't reference one array by calling the other and hoping it checks both, but perhaps in older versions you could do this, I'm pretty new to the language)... my advice, as I'm sure anyone will tell you, especially if your code is already heavily modified, would be to simply perform a backup of your code and database prior to installation of this snippet... Richard Lindsey.

This may not work for you (i seem to remember reading that it doesn't work for everyone), but it worked fine for me :) to remove the oscSid being appended to the end of the url, and yet retain the session information (i'd originally tried just changing the variable to false in tep_href_link that controlled the sid being appended, but then it wouldn't retain shopping cart entries or anything), find (on approx. line 148 of *catalog*/includes/application_top.php) this code chunk: // set the session cookie parameters if (function_exists('session_set_cookie_params')) { session_set_cookie_params(0, $cookie_path, $cookie_domain); } elseif (function_exists('ini_set')) { ini_set('session.use_trans_sid', '0'); ini_set('session.cookie_lifetime', '0'); ini_set('session.cookie_path', $cookie_path); ini_set('session.cookie_domain', $cookie_domain); } and replace it with this (i'd comment out the original before pasting in the new one, in case it doesn't work for you, you can simply switch it back): // set the session cookie parameters if (function_exists('session_set_cookie_params')) { session_set_cookie_params(0, '/', (tep_not_null($current_domain) ? '.' . $current_domain : '')); ini_set('url_rewriter.tags', ''); } elseif (function_exists('ini_set')) { ini_set('session.cookie_lifetime', '0'); ini_set('session.cookie_path', '/'); ini_set('session.cookie_domain', (tep_not_null($current_domain) ? '.' . $current_domain : '')); ini_set('url_rewriter.tags', ''); } that should do it, it's apparently the php.ini file that controls when certain things happen like the sid getting appended, through the use of the url_rewrite.tags, this simply changes that setting :D Richard Lindsey.

I hope someone out there has an answer for this, because it's boggling the hell out of me at the moment :) I installed this contribution a while back, and it seemed to work flawlessly... then i tweaked it for my needs so that the urls are a little prettier, at least in my opinion, and i was going to reupload it as a modified contribution, but i couldn't remember where i'd made all the changes :D so anyway, mine rewrites now, instead of like the -c-<name and cpath>, like this: <basename>/category/<category>/<subcategory>/<subcategory>/index.html and i have regexes that return the entire category and subcategory string as cPath, which is then parsed and queried for to construct the real cPath and cPath_array... this works just fine, and has for quite some time, here's the problem... when i originally installed this, it was on an empty storefront, with a few test products just for checking that urls were being constructed and translated properly, now that i have a little over 300 products in the listings, i'm finding some quirks, here they are: i have 1 puzzle and 1 game that i noticed this from, the puzzle is a Baby "Rex" something-something-something, and the quotations are not being stripped when creating the url or the cached name definition (since this was installed w/ the cache class by chemo as well)... the game is called Uncle Milton's something-something, and the apostrophe isn't being stripped either... i tried manually adding those in to the strip function's array to be stripped altogether, but it didn't work (and i suspect that punctuation that obvious was a part of those codes already), so i took them out... i turned on a test mode where i echo'd the entire cache to the page upon refresh and noticed the definition was appearing w/ that punctuation in it, and then added a line into seo_cache to echo this test message: echo "Uncle Milton's Ant Farm Game stripped to ".strip("Uncle Milton's Ant Farm Game")."<br>"; and then inside the while loop that creates the definitions i had it echo this: echo $product['products_name']." stripped to ".strip($product['products_name'])."<br>"; i reset the cache and refreshed the page... when i refreshed the page, that line i manually typed in (which is cut and pasted from the product's info on the page, and so should be exactly what is being extracted from products_name) stripped perfectly to: Uncle Milton's Ant Farm Game stripped to uncle-miltons-ant-farm-game then further down the page when i saw the definition for it, it had this: Uncle Milton's Ant Farm Game stripped to uncle-milton's-ant-farm-game the majority of links on my site work just fine, but it seems to not be stripping some of them correctly, any ideas? My strip function is the stock one from the contribution, unmodified by me, i even redownloaded it and compared to the original... Richard Lindsey