Toucan Web Design

Think what he means is, that if you have the eu cookies bit disabled (ie, you're not in the EU and don't have to bother with such laws), then the store should function as it did before they added it, ie, everything like analytics and such working as normal

You can set all those up via the by weight option, it offers several bands for you to seperate them out by destination, and shouldn't be too hard to just rebrand it as a royal mail module, a colleague has done that on his own store

Funny thing is, there originally was some code to handle things like that (it needed a little adapting to handle the manufacturers still mind), but they commented it out in a later version with a note that said something like // Can't see why this would ever be needed I found that a little bizarre when I had to re-fix a manufacturer search mod I'd done for a friend

Hmm, unfortunately, I'm not sure PayPal Express Checkout or Direct Payment work on any of the remaining versions of CC3, it's not been supported for a while, and there were some changes on PayPal a few months back that just flat out stopped it working I believe. That would be my guess anyhow. I did have a look into fixing it for a client, and tried updating the SOAP files, but didn't have much luck with it. It's possible you could pay someone to rewrite those gateways, or just fix whatever changed. The other option is to just use another gateway, as far as I know, all the others should be fine. Though I think you'll want the 3.0.20 files if you're using Protx/Sagepay

Could be adding shipping on at PayPal's end as well maybe, try going through your account settings and look for any shipping details set that might be getting added. That would be the most likely cause, they can override on PayPal's side.

Not sure either, that does sound a bit worrying.. I know that depending on the payment method, cvv codes aren't actually needed, so it's possible PayPal didn't actually need it.. but that doesn't explain why it's throwing the error or marking it processed after it.. I'd have a word with cubecart maybe

Might also be worth just clearing the cache from maintenance, it's possible that file got corrupted somehow, they'll just get regenerated if it finds them empty anyhow

The sample I gave would need a new language variable setting up yes (for {$LANG.catalogue.condition_broken}), but if it's hooked up to the other columns on the panel, yes, might be best to just rename one of the other ones if you don't need it, most likely the least intrusive way to change it

Looks like those options are just hardcoded into the admin product template, yes, which means you wouldn't be able to change them on the database. Should be able to just add more on the template you found, it stores the text directly by the looks of it. That will give you the extra options on there without any bother What I'd do, is try adding one and see if that works on wherever it gets pulled out (may only be on product feeds, can't see it on the product template) If it comes through as blank, what you'll need to do is set up a new language variable to match it So if you added say.. broken <option value="broken" {if $PRODUCT.condition == 'broken'}selected="selected"{/if}>{$LANG.catalogue.condition_broken}</option> With condition_broken just saying Broken or whatever you wanted.

Try: {if !empty($order.state_d)}{$order.state_d}, {/if}{$order.postcode_d}<br />

Assuming that you don't have product pricing groups (which would need further modifications), all you need to do is open up. /classes/gui.class.php Find: if (isset($sale_sql_standard_select) && ($standard_pricing = $GLOBALS['db']->query('SELECT `product_id`,`description`,`name`, '.$sale_sql_standard_select.' AS `saving` FROM `'.$GLOBALS['config']->get('config', 'dbprefix').'CubeCart_inventory` WHERE '.$sale_sql_standard_where.' AND `status` = '1' '.$not_on_sale.' LIMIT '.$GLOBALS['config']->get('config', 'catalogue_sale_items'))) !== false && is_array($standard_pricing)) { And change to: if (isset($sale_sql_standard_select) && ($standard_pricing = $GLOBALS['db']->query('SELECT `product_id`,`description`,`name`, '.$sale_sql_standard_select.' AS `saving` FROM `'.$GLOBALS['config']->get('config', 'dbprefix').'CubeCart_inventory` WHERE '.$sale_sql_standard_where.' AND `status` = '1' '.$not_on_sale.' ORDER BY RAND() ASC LIMIT '.$GLOBALS['config']->get('config', 'catalogue_sale_items'))) !== false && is_array($standard_pricing)) { Should just switch it so that the products are drawn out randomly out of all your sale items. You could change the order to something else if need be, you may be able to order by the saving DESC if you wanted the biggest to always show and so forth. Hope that helps

The email field has to be unique on the database, means it won't accept duplicates no. It sounds like there's actually a problem with the registration script, it should either update the database when it finds a matching email (if they were just on a mailing list), or throw an error normally. Had a look on the file and it looks ok though.. so hmm.. ah.. no, that'd be the problem, I thought the type field was for mailing lists.. but that's actually checking if they want to be registered..so definitely a bug there. Ok, in that case, you'll need to edit your database so that the email field no longer has to be unique. In phpmyadmin this is relatively straightforward, just go to the table, hit structure, then at the bottom there'll be an indexes section with something like: email BTREE Yes No email 4 A You should be ok to just delete that particular line, but I'd take a backup first just in case. If not in phpmyadmin, it gets a little trickier, so would have to know what you were using

Is the editconf file inside whatever folder the cubecart is it? If you've got it in a subfolder like /store/, it'll need moving and running from there. Either that, or the ini.inc.php file is missing for some reason, but that would mean the store wouldn't work at all.. so.. either something is amiss, or maybe you're on CC3?

Just to check, do you have any mods installed? Either that, or it sounds more like you're on version 4 of cubecart

If you already have the column with those settings, then nothing to be concerned about, no. Is a bug though by the looks of it, shouldn't be trying to run that on the upgrade from a store that has it. Hmm, that said, that's different from the one on my copy of 5.0.7 That one defaults to 0000-00-00, the old one defaults to current timestamp. That field should get updated whenever the product is though, so it's still likely nothing to worry about. If you wanted to confirm, try just adding a new test product and have a look on the database whether it's got the correct timestamp on it or not

Ah, that may well be the problem then, I didn't notice that one, still used to the old style ones. It's trying to compare it to a non existent value then, did changing it to total sort the issue out? Had best find out who else asked me and let them know

Hmm, next step then is just to try debugging it really.. try changing: $transData['notes'][] = "Amount paid didn't match amount on invoice."; To $transData['notes'][] = "Amount paid didn't match amount on invoice. ".$_POST['mc_gross']." vs ".$order_summary['prod_total']; Should print out the values for both on the transaction log then, maybe will give a clue as to what's going on and why they're not tallying up

Assuming it's due to 5.3 being installled, I prefer error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED); That way you can still see the serious errors at least. I suspect php 6 isn't going to be out for a while anyhow, so should hopefully last a while

A client had a similar problem, try taking a backup of: modulesgatewayPayPalgateway.class.php then make the following change, see if it fixes FIND: if (isset($_POST['mc_gross']) && trim($_POST['mc_gross']) !== $order_summary['prod_total']) { $transData['notes'][] = "Amount paid didn't match amount on invoice."; } And try changing to: if(isset($_POST['mc_gross'])){ $_POST['mc_gross'] == trim($_POST['mc_gross']); if((float)$_POST['mc_gross'] !== (float)$order_summary['prod_total']){ $transData['notes'][] = "Amount paid didn't match amount on invoice."; } } Don't think they ever got back to say whether or not it had actually worked though, but I was suspecting that it might be trying to compare a string variable to a double or something along those lines. Let us know if that helps

The deprecated warnings are relatively easy to get rid of, as they're just warnings rather than actual errors, if you have a google for it, you should be able to find a simple fix on the includes/ini.inc.php file that will solve the vast majority of them

Hmm, unfortunately, that doesn't seem to be the way the per category shipping is set to run, if it's enabled, it will always show up as an option, and the shipping price will be calculated by the prices set on each category. So if the others are blank, they'll likely go through as free as well. Depending on the shipping you normally use, yours options are to either set the correct shipping on all the other categories, switch to some sneaky per weight option, with the free products set at 0.000kg, or have some custom modifications done to let you set valid free shipping categories. You'd need to ask on the unofficial forums for that

Safest bet would be to hide it rather than remove it, in case it breaks any functionality. You can either set display: none in the stylesheet if it has a specific class or id, or you can just find the button on the template and add: style="display: none;" to it to hide it. However, unless it's changed from earlier versions, the cart used to have a tendency to reuse that button, so it may well be the same as the continue button on earlier pages, and so not simple to remove

Could potentially be a lot of things I think, is the only problem. I'd check the following: That your zend encoder is definitely working, on a new host, maybe it isn't set up right That the website hasn't run out of either webspace or bandwidth. Doubtful if the host has checked as well, but I've seen similar errors pop up with this as the cause Try reuploading that particular file, making sure it's done in binary on the file transfer, may well be the culprit Those are all I can think of to try offhand

Can do yes, there are two options, either put a form on the landing page, so that the data can be sent by post as cubecart normally expects. The other option would be to modify the shopping cart and get it to check for a variable like the one you put in the url above

Should just be accessible with {$OVERVIEW_SUMMARY.title} and {$OVERVIEW_SUMMARY.title_d}