Toucan Web Design

There's a quick way of doing it, not the best, but try opening up classes/cubecart.class.php FIND: if (!isset($cheapest['value']) || $value['value'] < $cheapest['value']) { $cheapest = $value; } REPLACe with: if (!isset($cheapest['value']) || $value['value'] > $cheapest['value']) { $cheapest = $value; } That'll just switch it so it defaults to the most expensive option instead, which if you only have 2, will sort it out fine for you

Depends how you mean by options really. The standard email options themselves can usually be found in: classeshtmlMimeMailhtmlMimeMail.php Or one of the other files in that folder. The actual generated text and such are in: classescartorder.php

Not sure about the particular line there, can't find that one, but I've found one bit which might do the trick, have a look on includes/lib/smarty/Smarty.class.php Find: public $php_handling = self::PHP_PASSTHRU; And try changing it to: public $php_handling = self::PHP_ALLOW; Might do it, but I'm no smarty expert, so can't really say for sure. May also need to change the allow_php_templates one below too

Don't think there's any way to just do so straight out of smarty, no, we had to write a plugin to do so

I thought I was imagining things when I vaguely remembered something using the get config variable.. bit of an odd place to put it really, thanks though, will give that one a try. Sadly can't go the route of modifying the database as it somewhat ruins the idea of nice modular plugins, that's why was checking there wasn't some method I was missing somewhere

Could anyone tell me how you're supposed to properly write custom queries in CC5? There seems to be a lack of methods to actually support it, is the problem, which is starting to make working on them hard. The current problem we're having is with the database prefix. In the past we used $GLOBALS['db']->_prefix which allowed us to directly access the database prefix. This seemed to work in the past (though I'm not entirely sure why, as having checked some earlier versions, it was also marked as protected and so should have failed?) Have had limited success with putting {$this->_prefix} in the query itself, but that seems to still be throwing errors on some of the pages. Have looked everywhere for a proper way of just accessing basic functionality like that that's needed for custom queries that can't be handled by the build in select functions and such, so wondering if anyone else knows

Well, after having a read into it, it seems to be more related to the storage of non essential cookies, like for analytics, advertising and otherwise tracking customers. Essential cookies like for shopping carts are apparently being made exempt, so it would likely be fine for CubeCart

Ah, apologies, I'd missed a step handleMouseOut: function(e) { Just change that to: handleMouseOut: function(e) { magnifier.$sensor.css("z-index", "100");

Depending on what versions of IE you support on your site, you may also need to have a lot more z-indexes setup for it to calculate them properly. The other problem with setting the z-indexes in that way, is that the magnification window will then hide behind the menu. What we did is to set a z-index on the menu of say, 300, then opened up the js/styles/jquery.magnifier.css, changed the #dio-sensor to be z-index 100, then on the js/plugins/jquery.magnifier.js file, we found: handleMouseMove:function(e) { And changed it to: handleMouseMove:function(e) { magnifier.$sensor.css("z-index", "11000"); That did the trick and solved any of the overlaying issues

Once the SSL is installed (which is all through your hosting account generally), all you should need to do is go into admin, general settings, and set the SSL to on, and put in the right paths. Be very careful and make sure the SSL is definitely set up correctly first though, as setting it on when it isn't installed correctly can lock you out of your admin. Best bet is try manually changing the urls to https a few times in the admin and site, to confirm that they don't have any errors. Taking a backup of the database to revert to can help restore the site if you get locked out when setting it live

It's this bit: I.manufacturer IN (') Should be more something like.. I.manufacturer IN ('20','4','5') So guessing that variable has gotten cut off or overwritten accidentally at some point higher up. Hmm, the relevant section is this: // Manufacturer if (isset($search_data['manufacturer']) && is_array($search_data['manufacturer']) && count($search_data['manufacturer'])>0) { $where[] = 'I.manufacturer IN ('.implode(',', $search_data['manufacturer']).')'; } Which is fine really.. only thing I can think of that would cause that error would be if the manufacturer bit in the search was just sending a ' instead of a number.. and it shouldn't be doing it if the manufacturer isn't set either, bit odd

Couple of ways I could think of going about that.. first would be to mark the bears as free, entirely free orders should go through the checkout without requiring payment, but depending on shipping setup, that may not be plausible either, plus you don't have a proper record of the preorder with the price. The second way would be to make some custom coding to flag up that category so that orders from it will use the print order form instead of the standard gateway, for that you'd need custom modifications made, best bet would be to check on the Unofficial third party services forum Either way however, you'll get a bit of a problem if anyone orders a limited edition bear and a standard product in the same basket. Not entirely sure what you could do to get around that one, bit tricky

Not entirely sure what you're meaning, but if you're just after a pickup from store option, you can easily add those by just enabled the free shipping module and rebranding it to say Pickup instead Sorry if I've not understood what you meant

No built in way in CC4 that I'm aware of. However there is a mod that will do what you want straight out the box, though you'll need to modify whatever means of importing into SagePay you were planning on most likely. Try a google search for 'Stock Levels for Product Options CC4'

Not seen any configurable modules about, no. We did convert someones cc4 version to 5, but that was just a standalone file that generated it, not sure whether they were manually uploading it to getprice or not really, so think that's different from what you're after They were somewhat similar to the googlebase feeds if I recall, so there is a possibility they can read those, yes

Can be a variety of things, but often it's caused by & symbols in the urls getting converted to safe ones which it doesn't like.. could be other things though. Best bet would be to post the url which causes the error, then we can just have a look what part of it is causing the issue

Hmm, the code for that section is a little odd, it's not actually confirming it's created the coupon properly, but I think I know why it's not working, it's always converting the coupon_id to 1 as it's being cast as a bool In classes/order.class.php FIND: private function _createCertificate($value, $blocks = 5, $bsize = 4, $glue = '-') { // Create Certificate Code $length = ($blocks*$bsize)+($blocks-1); $seed = hash('whirlpool', time().rand().microtime()); $code = ''; for ($i = 1; $i <= $length; ++$i) { $code .= ($i%($bsize+1)) ? substr($seed, rand(0, strlen($seed)-1), 1) : trim($glue); } $gc = $GLOBALS['config']->get('gift_certs'); ## Insert the Certificate Record $record = array( 'cart_order_id' => $this->_order_id, 'discount_price' => $value, 'code' => strtoupper($code), ); if (isset($gc['expires']) && (int)$gc['expires'] > 0) { $record['expires'] = date('Y-m-d', strtotime((int)$gc['expires'].' months')); } return (bool)$GLOBALS['db']->insert('CubeCart_coupons', $record); } And try just getting rid of the (bool) in the return, so: return $GLOBALS['db']->insert('CubeCart_coupons', $record); That should hopefully have it be returning and storing the id properly

In the mean time, could try the following: In modules/gateways/BarclayCard/gateway.class.php Find: if ($hidden['bcountry'] == 'US') { $hidden['bstate'] = $this->_basket['billing_address']['state']; } else { $hidden['bcountyprovince'] = $this->_basket['billing_address']['state']; } if ($hidden['scountry'] == 'US') { $hidden['sstate'] = $this->_basket['delivery_address']['state']; } else { $hidden['scountyprovince'] = $this->_basket['delivery_address']['state']; } Replace with: if ($hidden['bcountry'] == 'US') { $hidden['bstate'] = getStateFormat($this->_basket['billing_address']['state_abbrev'], 'name', 'abbrev'); } else { $hidden['bcountyprovince'] = $this->_basket['billing_address']['state']; } if ($hidden['scountry'] == 'US') { $hidden['sstate'] = getStateFormat($this->_basket['delivery_address']['state_abbrev'], 'name', 'abbrev'); } else { $hidden['scountyprovince'] = $this->_basket['delivery_address']['state']; } Might do the trick for you, took the code from the SagePay gateway, as that also requires abbreviated states on USA orders, haven't tested though, so make sure to take a copy of the file first and just pop some orders through after to make sure it's working ok

We get it sometimes, yes.. wide variety of potential causes sadly, as it's a session bug and sessions get used all over the place. Usually we find it best to clear our cookies and active sessions from the browser when we encounter it, as sometimes that can cause it, especially if the tabs were left over from previous sessions. Other possible causes can be due to the switch from http to https on secure checkouts, a corruption in the session database table (which can be fixed by running a repair on the CubeCart_sessions table in the database administration), and logging into admin in a directory, causing it to store a seperate session cookie in a different path (More a CC3 error that one, I believe CC4 has pretty much solved that one) There are likely even more causes of the bug, but those ones seem to be the most common

Just to check, when it sends you back to the store, are you actually clicking the Complete Payment button? We looked into a similar issue a while back on I think.. 5.0.3, and what PayPal express and other such nonstandard gateways seem to do is complete the payment on the paypal side, then send you back to the store cart page, where you need to hit the complete payment button for it to finalise the order, mark as processed on the status and otherwise let the customer know it's been done. As the cart page it sends you back to looks like the ones before, it's easy to think it hasn't worked. I'm not entirely sure why it doesn't automate that particular process like before, didn't manage to figure that bit out unfortunately, but having tracked the order all through the code, that seemed to be the way it was set up. If that does the trick, might be worth putting a message somewhere to explain it, it's not entirely intuitive

Just seems to throw that error whenever it finds a customer who doesn't have a valid IP, which it apparently requires to set up their session. As long as it's not happening to you yourself, I don't think it's something to be worried about, may just be a bot or some such masking it's IP. Not entirely sure why it's kicking an error for it though.

Yes one of our clients is having the same problem, i am trying to find the problem but no luck so far. We just get a blank page with the url as: Paul