Toucan Web Design

Those files take an array of data, and essentially just act as loaders for the files. So rather than having a direct link to a javascript file or css file, it calls in the script which then reads the file, and outputs the content to the browser. I imagine this is to solve issues of js or css files being cached and not showing up to date changes, which can sometimes be an issue. They should each only get called once per page though.. if you're getting 95 hits per visit, that's a little weird. I'd have a look in the files and make sure there's nothing untoward in them just in case, just have a compare of them to the ones in a clean download from cubecart. Either that or maybe you've got a lot of ajax content and each one is calling that script, possible, not sure. Do you have lots of plugins or mods? The more javascript and css files it has to read, the more load would be on those particular files, so it might be that they're trying to load in a lot more files than in a regular store Can't think of much else that might help without going into debugging or such

Hmm, that's weird.. my change should let it add a product despite the category being disabled, can't see any other error it would cause getting the product data. It's not something else, like it missing a required option and throwing an error due to that perhaps? That's one of the few other checks it makes while trying to add something to the basket. There's some code which checks if it's out of stock or such, but that should still add it, though it'll cause a redirect to the basket which will usually then remove it and give you a warning message (or allow it, if you've got your settings to allow out of stock purchases)

When calling the add method in cart, it called catalogue -> getProductData, which does return false if the category is disabled, so yeah, as it currently stands, you can't order products if the category is turned off. You could turn that off by editting classes/catalogue.class.php Finding: if (!$category_status) { return false; } And just changing to if (!$category_status) { # return false; } Not sure if that's makeable as a snippet, still require the standard hooks don't they? Don't see any suitable on those locations that would get round it

Is it only on certain sections, like the category nav? If so, I've seen something similar to that happening before also, I can't remember what was actually causing it unfortunately If you want to drop us a PM with the url in, I'll take a quick look and see if it looks familiar

Did they provide the fonts you're using Nik, or did you find those yourself? Just to check whether that's the same I'd been doing another plugin so had access to Nik's test site, so just went on and had a look into it, figured it was something due to the charset and just had an experiment around with it, utf8_encode just made it bring up 3 squares rather than the one, as it clearly couldn't read the format it'd gone into, £ just got rendered as such in the font, with no conversion to £, the only one it took in the end was £

It's a very good question really, but maybe it's some quirk of either the charset being different on the test site so that the symbols were getting sent differently, or maybe a minor php version change was allowing the imagettftext function to just accept the £ or £. The php spec itself just references utf8, there's no reason I could see that it should only work on html entity numbers rather than bog standard entities or such

Always been one of the big problems with caching anything, it's a rare customer who knows about clearing caches unfortunately I know a few colleagues who are fans of setting up htaccess rules that auto set the caching at 1 seconds for a variety of things like the images and ico files, but that always seems a bit sledgehammery for my liking

Hi Brian, Yeah, I've been through the database files a few times in the past, but this is the first one that I've seen that's this weird. Hmm, in theory, that code change wouldn't fix anything, as $this->_result is apparently being set to bool(true) regardless, so in either case it'd return true, and start breaking things again. Well, I tried setting up a run to see if I could get it to happen again for debugging, and it flat out won't happen anymore.. so that's weird.. just brings back the empty array like it always used to array(0) { } Maybe it was a database problem and I was jumping the gun? Lasted a good 20 min or so of debugging though, so odd

Just been looking into an issue for a client who recently upgraded his store, not sure what he was on before unfortunately, but he's now on 5.2.5 Anyhow, a previous script we'd wrote had broke, where it runs a simple query like so: SELECT product_id FROM CubeCart_image_index WHERE `product_id` = '1302' AND `file_id` = '6268' LIMIT 1 That file reference isn't found, so I'd expect it to return either an empty array or false, but it's actually returning bool(true) Anyone else seen any problems like that? Not too sure what's causing it. Max results is false, as is cache, and no page is set Here's the actual line in fact: $imageCheck = $GLOBALS['db']->query("SELECT product_id FROM ".$GLOBALS['config']->get("config", "dbprefix")."CubeCart_image_index WHERE `product_id` = '".$GLOBALS['db']->sqlSafe($productId)."' AND `file_id` = '".$GLOBALS['db']->sqlSafe($fileId)."' LIMIT 1", false, 0, false); Closest thing I can ever see to it returning that, is on the mysqli class: if (is_bool($result)) { $this->_result = $result; But that shouldn't be returning a bool on a select either, so a bit nonplussed as to what's going on with it really. I know early on there were some issues with the error logging overriding the result returned with its own results, but that was more of an issue on inserts and updates, plus, there isn't actually any error being thrown as the query is fine, just no results to return. Bit of a mystery really, anyone have any clue what that might be?

The first one I mentioned, would auto link up to the cart, you'd essentially set it up as a custom text option and just stick the url to the image in there. It's not the safest however, as allowing people to upload images and then potentially showing them a link to it is a bit risky. It's possible to inject all manner of stuff in an image potentially. You'd want to at minimum obfuscate the location, so ideally it will upload the product into a hidden folder and just return the filename, and you can piece it together yourself on the admin end. Making changes to core files is just another quick and easy method really, it depends on what your budget for the work would be. Doing it as a plugin would be the nicest option, they don't get broken by upgrades (generally) and won't affect your normal files at all. They do however usually cost a bit more, at least from us, as it takes us extra time to write them that way. But yes, I'd have a look for a jquery file uploader, that preferably just uploads and sends the file off to some provided location via ajax. You'd then want a script like I mentioned before, which would upload it to a hidden location and return a filename

How would you want that to work? Is it just going to be a straight image upload, or would you want the image/text to display on the mug/product in some kind of preview sense? A straight image uploader in theory wouldn't be too hard, The easy way out would be to just upload and then store a link to the image in a hidden text option, which wouldn't be too hard, but you'd need a jquery uploader to be hooked onto that, might want to have a google for a few options and find one that looks best. That's probably going to be the least intrusive version anyway, anything else would likely require modifications to the core files or setting up as a full plugin

Could always do both, have the number and a fallback string for if it can't find the reference. I can think of a few reasons to potentiall ywant a foreign key for it. One would be if you were deepening the language support and wanted to be able to provide country/county selections tailored to the customers selected language, which wouldn't be too bad an idea, though certainly not in any way integral to anything Also if you've linked to an order via the country, you might need to get a list of relevant states/counties, which you wouldn't be able to do with surety if the country was text (and had been changed since), also not exactly the most common of occurences really, short of editing orders via the admin Finally, you'll be able to actually reference orders properly by country for the purposes of sales statistics and queries, which if they end up having potentially changed country names ever so often, wouldn't be plausible

Not too sure then unfortunately, that's another success message, if ACK=Success then the payment has gone through ok. Hmm, it could be failing another part of the validation though, have a check to see if the amount being returned by paypal is matching up with the amount on the store, if those don't match it also throws an error in case people are trying to scam orders. Either that or if you're getting logged out, that might be the issue, not sure offhand what might be logging you out though, that was only an issue I recall seeing on v3 of cubecart

That seems to be a success message actually, no error in there that I can see. One quick question though, you mention it doesn't happen to new customers. Did you by any chance update from a previous version? I'm wondering if it's the old logins that have the states recorded as numbers, in which case they'd just need a script running to update them on the database

Brian's right, that's the cause of it. Ugh, if you saw the previous bad advice, ignore it.. shouldn't answer things in a morning it seems. Hmm, I'm not too sure what's wrong with it either actually, normally those issues are caused by certain elements being floated and not display block, which sometimes seems to set off that glitch, but that doesn't appear to be the case in this one. Ok, it's because the container it's in isn't floated but the gallery on the left is. What you need to do is on the css, edit the styling for: #productDetail, line 423 on common.css Take out the margin-left, and replace it with: float: left; width: 340px; Some of the elements within, like the label are a still a little odd though, that has a width of 600 and is bigger than the box it's in, but it's not a direct issue

You head into the table you're editting, hit the structure tab, then just underneath the table, there's either directly visible the option to add an index, or there'll be a link called Add Index or some such, click that and it'll open up the form below. From there, it's just a case of selecting the column required and that it's a primary key

Does the warehouse stock system already exist? If so, we'd need details of what it's running to be able to know if it's possible to bridge them. If it's not, then you're asking for a warehouse script that also hooks into the ecommerce store (and likely has offline storage for when internet availability is down), probably be somewhat expensive if done bespoke, but if you plan on using it for years, might be cheaper than the monthly plans yes. You'd need to lay out a proper brief and hire someone for that, as it's likely to be somewhat involved

The base software itself shouldn't be doing that, no.. it does sound like some kind of spambot has gotten inserted into your hosting account somehow, might not be anything to do with the cubecart. It is indeed odd that the hosting can't just track down what's sending it, usually that never seems too hard for any decent host If you want, feel free to PM us with an ftp login for the account and we'll have a quick look in the morning to see if we can spot anything out of the ordinary, a lot of these type of bots tend to hide in pretty similar folders, and usually you can spot them without too much bother

Think I've seen that before as well, and from the pattern, I think it might be similar to what I saw. if I recall, it was an odd situation where a loop either not closing off correctly, or somehow writing into itself more data to loop through.. didn't show up for single product purchases, but when they were buying more than one, it was looping through and displaying product A, then product B then A again, then C and B and A and so forth. That said, having looked at the files, I'm very sure it wasn't a CC5 this was happening on, so not much help there unfortunately

First thing I'd check is to go onto the database, find the CubeCart_order_sum table, and look for a field named product_options, or similar. See if there's anything in there essentially.. if so, then it's recording them correctly and just not displaying them. If it's not recording them, then the problem is either on the cart/checkout page, where it stores those options as an array, or on the gateway page where they get recorded on the database. The checkout is probably the most likely culprit, and may be due to a mod You're going to need to continue this on the 3rd party forum though, as that's definitely a CC4

It'd be pretty easy to use centimetres as the stock, Brian was correct in how I was meaning, yes. All you'd need to run it then would be a quick mod to display the quantity field as a drop down box with options from 1m to (max stock), going up in half metres. That said, if you're going up in half metres, I'd probably set that as what 1 stock means. Generally you always just want to use your lowest increment as the stock level and work back from there. But as they say, you'd have to ask for that on the 3rd party site

Would it not be possible to use the stock level as the amount of fabric, and just use centimetres for it instead of metres? That way you don't have to worry about the fractional issue. You'd still probably need a little modification to lock the quantity input into certain bands of length though

Dreamweaver is a relatively solid editor for working with cubecart, but you'll still need knowledge of php and html to work directly on it, so unless you know how to do that, might struggle still. It will also be all you need to upload to the hosting, you just need to set up the ftp details when creating a new site to work with, your hosting should provide those if you have access to them. Most of what you should need to do to manage the store itself should just all be available via the admin, on occasion you might need to alter the template files a little. Those are located in the skins folder of your store, and are .tpl files. For those you mostly just need a bit of knowledge of html and an idea of how the templating system works. Do you know what version of cubecart you're on? It should say on the home page of your admin. If it's been updated to 5, then it'll be using the smarty template system, there should be a few guides for that if you have a look around on the net. If it's 3 or 4, you'll want to switch your queries over to the other forum as this one is only for version 5 of CubeCart. Those ones use a different templating system that I'm not sure if there ok online guides

Hmm, can't see anything that might be causing it offhand. The only way I can see it happenings if is the order is created, then for whatever reason, updated while still on pending. There are checks to make sure it doesn't just add duplicate products however, so they'd have to be failing for some reason. I suspect you're not going to find out the issue without putting some debugging code in there to find out if the product hashes are different or something along those lines. If you hire a developer to look into it, I'd sugest they started investigating the _updateOrder function on the order class If it's only happened the once, personally I'd maybe just keep an eye on it for the time being, might be a rare one off. Maybe submit a bug report but I'm not sure I'd spend the support credits on something that may never come up again. If it does start happening regularly, then would be worth getting them to have a look into it

header.inc.php was the admin header template if I recall, if that's what you're after, you'll find it under: /admin/skins/default/templates/main.php