Teabag

I've successfully installed the Select Junior module found here: http://addons.oscommerce.com/info/5665 It works perfectly except for one thing. Gaps are now appearing between order numbers.... I've narrowed the causes down to what happens on the checkout_payment.php and checkout_confirmation.php pages. Upon visiting checkout_confirmation.php an order is being inserted into the DB (with the status of "Preparing [WorldPay]") prior to the customer pressing the confirm button to actually perform payment. This isn't a problem unless the customer chooses to not confirm at that moment in time and continues shopping, browses away or logs out. Upon returning to the checkout_confirmation.php (or passing through checkout_payment.php) the order that was previously created is sometimes removed from the DB and instead of reusing the ID it just cleaned up a new one is created instead (or so it seems) and this is what leads to the gaps appearing. I can supply a list of "lost" order numbers when it's time to do our accounts, but it looks suspect and I'd prefer a fix. My thoughts are that if the insert is only done when the customer presses the confirm button we don't need to tidy up old incomplete orders (because there won't be any to clear up), but I don't know how/which code to move between the various functions within the includes/modules/payment/worldpay_junior.php file to achieve this. I've tried comparing/learning with other less complex modules but am getting nowhere fast. Naturally I've asked worldpay for help as it only happens when using it, but they refuse on the basis that they didn't write the code and that it's happening prior to communicating with their services, so I'm a stuck unless I can fix it myself or decide to ditch them and use another gateway that's more cooperative. (like PayPal who couldn't do enough to help make PPEC work). Has anyone else who's used this module come across the same problem, if so how did you resolve it? Harold, if you're reading this, can I ask why you've made this module work in this way? Many thanks

If it were the rewrite rules for apache then turning SEO URLS off shouldn't cure the problem and it does (see my initial post on this 2 pages back). The moment seo.class.php gets its hands on the query string something goes wrong.

You have located the .htaccess file in /shop/? However that message reads like a script error to me and not a 404 error (although it mentions one as a secondary problem), so I'd be checking the edits you made to install this mod to be honest. Perhaps there's a spurious bracket or something lurking in one of your edits. What does your web server error log say (if anything)?

I found a fix for the item not being added to the cart from search results on the original contrib page: In includes/classes/seo.class.php around line 653: CHANGE: return htmlspecialchars (utf8_encode ($link)); TO: return htmlentities (utf8_encode ($link), ENT_QUOTES); I'm still trying to find out what's happening with the query string params so keep your fingers crossed :)

Other things that are now failing as a result of the loss of the query string.... 1. Add to cart button in search results takes you to the item page instead of adding the item 2. Unable access/read reviews via the reviews box 3. basically any link that relies on a query string'd parameter fails. :angry:

OK more on the above. If you turn SEO off and then use the 2nd URL you get to the page you requested and/or the sort order of the column that's been clicked on. ie it works as it should and is clearly getting through the mod_rewrite part of the process. This proves that the problem is to do with the SEO mod's interception of the query string :(

I installed this contrib today and on the surface it looks great. However, it would appear that the cost of Ultimate SEO URLs is the ability to sort search results or to get past the first page of results if there's more than 1 :o The following 2 URLs should be equivalent (they appear to have the same parameters in the query string, I appreciate they are reversed but that shouldn't make any difference), but the 2nd one (with the SEO turned on) doesn't work. Both are generated as previous, next and numbered page links for search results. http://www.......co.uk/index.php?cPath=47_...t=2a&page=2 - works with SEO off http://www.......co.uk/essential-oil-c-47_...e=2&sort=2a - doesn't work with SEO on :| I've also noticed that the column sort functions on search results do not work now either. It would appear from the rewrite logs that the query string parameters are being picked up correctly, so I can only conclude that there's something wrong in how they are being handled by this mod? xxx.xxx.xxx.xxx - - [08/Oct/2007:20:28:11 +0000] [www..........co.uk/sid#8204b7c][rid#81e42f4/initial] (2) [per-dir /vhost/www..........co.uk/html/] rewrite essential-oil-c-47_48.html -> index.php?cPath=47_48&page=2&sort=2a xxx.xxx.xxx.xxx - - [08/Oct/2007:20:28:11 +0000] [www..........co.uk/sid#8204b7c][rid#81e42f4/initial] (3) split uri=index.php?cPath=47_48&page=2&sort=2a -> uri=index.php, args=cPath=47_48&page=2&sort=2a Has anyone else had this problem or got any ideas what might be wrong here? Many thanks