Toucan Web Design

The skin shouldn't really cause problems on the searches, which are typically in the php code, but never know, worth contacting him to see if he knows. Are all the keywords which work short? If so, they'll likely be using a different search method, as full text searches typically don't work unless the word is 4 or 5 letters long, it's a mysql security setting. Might help track it down if so Yeah, seems to be working ok on 3 letters or lower, which is likely using a standard search. So whoever you get to look into it, tell them to check for errors on the fulltext search

Hi Debby, I have looked at your website and to align the menu in the centre you will need to do the following, NOTE: the details below are based off of your code not the default crosshatch skin. Making the header larger can be done by increasing the height of #nav and #nav .navContainer, just add a larger background image or replace with a solid colour. Add text-align: center; to .navContainer on common.css line 223 #nav .navContainer { height: 66px; margin: 0 auto; width: 100%; text-align: center; } Remove float: left and add display: inline-block to ul.dropdown li on dropdown.css line 13 ul.dropdown li { zoom: 1; display: inline-block; } Then you'll maybe want to set a fixed width and perhaps display: block; on the sub categories to ensure they display correctly. Kind Regards, David.

It's because the first url it goes too is login.html perhaps. It worked fine for me the second time if you try login again once you've been redirected to _a=login Not sure why that might be the case, but it could be an issue with redirects

Ah, gotcha

Last I recall they said they weren't providing the files themselves, but it was ok for third party developers to still distribute them, has something changed?

Code snippets work more or less similar to the existing plugins, they can insert lines of code into a preset 'hook' within CubeCart. Unfortunately the issue of being unable to do anything if there's not a hook in the place you need it is still there, but it's starting to take steps forward I think. Anyhow, basically they work the same as plugins, but if it's just a small fix or code insert, it saves you from writing out an entire plugin, so it's just a little easier to apply quick little jobs and such really. You can also send them as xml files for people to install directly into the snippets, which means that in the future, potentially when bsmither posts a fix to someones issue, he could just link a file, they upload it.. bam, fixed. Depending on your knowledge of cubecart however, they're not very useful directly as an end user, as you'd need to know how to write the code to insert into them, and also know where the code needs to be hooked in, so mostly it'll be for developers .. any of that make sense? I'm a little bad at explaining things sometimes, but that was what I got from it when I had a look into it on the beta

That databases are considerably different between 3 and 5. You'd need to run the upgrade scripts, possibly taking a step on 4 in between, not sure, never done a direct upgrade like that yet. Usually we just run some conversions of the inventory and such.

Thanks Brian

There was no delineation on the code I checked, no, just straight var[option].var[value]. I did a test of some of some md5 hashes and checked against the database just to confirm, so at the moment it's just a ton of bugs waiting to happen Yeah, you'd need to get a significant amount of product options for it to be longer than the md5 hash, which was why I couldn't figure out why they'd prefer that over the unhashed string.. at least with an unhashed one, we can do simple searches to enable future mod work

So I've been looking into the new product options matrix.. .. I'm somewhat wondering what the thinking is behind that, it looks like it's going to cause a lot of trouble down the line as it currently stands. The main thing I can't figure out, is why unique identifier that links together the matrix of assigned options, is being converted into an md5 hash, making it both unusable from a searching perspective, in most cases longer than the original string, and also adding in the factor of duplication errors. For example, if you have a product with option 1, value 111, and option 11, value 11. Those are completely identical and so you can't reliably track the stock for them or do a search Is there any reason that you couldn't just leave the options_identifier as a simple imploded array of assign ids? So just :5:4:110: (or an alternate one with both option and value ids similar to the product key generation) Then it would be nice and easy to search for combinations by matching :5: :4: and :110:, and not risk any of the duplication bugs. For the vast majority of stores I imagine it's going to be less filesize on the database as well.

Yeah, it's because of the folder structure of the safe links, it's breaking the link to the css. What you could do is open up the global cart and index templates from within the skin, go through the references in the header at the top of the page (generally looking for things like these: <link rel="stylesheet" href="css/nivo-slider.css" type="text/css" media="screen" /> <script src="jq/jquery.nivo.slider.pack.js" type="text/javascript"></script> And try changing the links to one that always references from the base of the store, in this particular case, it would likely be adding /shop/ at the start, so: <link rel="stylesheet" href="/shop/css/nivo-slider.css" type="text/css" media="screen" /> <script src="/shop/jq/jquery.nivo.slider.pack.js" type="text/javascript"></script> Will provide a fix for the current issue, but the downside is that if you move the shop out of that /shop/ folder, they'll stop working again and need the links changing, may or may not be an issue for you

I'm guessing it just wasn't getting into that particular section of the pagination function for whatever reason, like if you only had a single page of things.. either that or your server spontaneously jumped back a version.. oh well, good to hear it fixed it anyhow

The earlier versions of CC4 look like they don't use php5 for that function.. so they -may- work.. not rightly sure. Here's a copy of the entire function, that's in includes/functions.inc.php Try taking a backup of the file then replacing the function, see if it works function paginate($numRows, $maxRows, $pageNum=0, $pageVar='page', $class='txtLink', $limit=5, $excluded = array()) { global $lang; $navigation = ''; // get total pages $totalPages = ceil($numRows/$maxRows); // develop query string minus page vars $queryString = ''; if (!empty($_SERVER['QUERY_STRING'])) { parse_str($_SERVER['QUERY_STRING'], $params); foreach ($params as $key => $value) { if (!array_key_exists($key, $excluded) && strtolower($key) !== strtolower($pageVar)) { # $newParams[$key] = $value; # PHP5 $newParams[] = $key.'='.$value; } } if (!empty($newParams)) { # $queryString = http_build_query($newParams); # PHP 5 $queryString = htmlentities(implode('&', $newParams)); } } ## Get current page # $currentPage = basename($_SERVER['PHP_SELF']); $currentPage = sanitizeVar($_SERVER['PHP_SELF']); ## Build page navigation if ($totalPages> 1) { if(!empty($lang['admin_common']['misc_pages'])) { $pageText = $lang['admin_common']['misc_pages']; } else { $pageText = $lang['front']['misc_pages']; } $navigation = $totalPages.$pageText; $upper_limit = $pageNum + $limit; $lower_limit = $pageNum - $limit; if ($pageNum > 0) { ## Sho, if not the first page if (($pageNum - 2)>0) { $first = sprintf('%s?%s&amp;%s=%d', $currentPage, $queryString, $pageVar, 0); $navigation .= "<a href='".$first."' class='".$class."'>&laquo;</a> "; } $prev = sprintf('%s?%s&amp;%s=%d', $currentPage, $queryString, $pageVar, max(0, $pageNum - 1)); $navigation .= "<a href='".$prev."' class='".$class."'>&lt;</a> "; } ## get in between pages for ($i = 0; $i < $totalPages; $i++) { $pageNo = $i+1; if ($i==$pageNum) { $navigation .= "&nbsp;<strong>[".$pageNo."]</strong>&nbsp;"; } else if ($i!==$pageNum && $i<$upper_limit && $i>$lower_limit) { $noLink = sprintf('%s?%s&amp;%s=%d', $currentPage, $queryString, $pageVar, $i); $navigation .= "&nbsp;<a href='".$noLink."' class='".$class."'>".$pageNo."</a>&nbsp;"; } else if (($i - $lower_limit)==0) { $navigation .= "&hellip;"; } } if (($pageNum+1) < $totalPages) { // Show if not last page $next = sprintf('%s?%s&amp;%s=%d', $currentPage, $queryString, $pageVar, min($totalPages, $pageNum + 1)); $navigation .= "<a href='".$next."' class='".$class."'>&gt;</a> "; if (($pageNum + 3)<$totalPages) { $last = sprintf('%s?%s&amp;%s=%d', $currentPage, $queryString, $pageVar, $totalPages-1); $navigation .= "<a href='".$last."' class='".$class."'>&raquo;</a>"; } } } return $navigation; }

That call is on the pagination function yes, so if it's not needed, it won't be getting run to that particular step. The function that's missing appears to be a standard one in php 5, I'd have a check to see if you're on an up to date version of php, you can usually find the php info in your admin

Try: {if $PRODUCT.use_stock_level == false || $PRODUCT.stock_level > 0} {if $PRODUCT.stock_level > 0} <p><strong><strong>{$LANG.catalogue.stock_level}:</strong></strong> {$PRODUCT.stock_level}</p> <p>&nbsp;</p> {/if} {else} <p><strong>Awaiting Stock</strong></p> {/if}

You'll want to open classes/cubecart.class.php Find this line: $mail->sendEmail($GLOBALS['config']->get('config', 'email_address'), $content); Change to: // $mail->sendEmail($GLOBALS['config']->get('config', 'email_address'), $content); Should do the trick. Also, if you find the reviews section on the content.product.php template file, you can wrap it in some tags to make it so that it only shows for logged in users. Just find <div id="review_write" style="display: none;"> Change to: {if $IS_USER} <div id="review_write" style="display: none;"> Then find: </form> </div> </div> Change to: </form> </div> {/if} </div>

That's quite odd, I've had a run through the 5.1.5 code and as far as I can tell, it should be printing out the discount correctly. The only thing I can find which might be a discrepancy is on cubecart.class.php, line 1330, where it grabs the basket $contents = $GLOBALS['cart']->get(); That function there recalculates the grand totals and discounts.. however, the discount actually being printed out references: $this->_basket['discount'], which has not been updated. I suspect that $this->_basket is getting populated somewhere higher up, with the correct initial values, then the cart->get function is being called multiple times, and it's further diluting the discount somehow.. the discounts also seem to get called cumulatively, which is also a bit confusing.. far as I can tell, the first time it runs it'll run off £100 subtotal. The next it will run off £100 - £10 discount and calculate the discount as £9, then add that onto the discount level (making it then £19) .. which is fine in theory, and explains why some of the values might be different from some of the others.. .. except I haven't got a clue how it's managed to end up at £4.17 .. if anything it should be going up, not down Edit: .. no it isn't, got myself confused didn't I.. if anything, if $this->_basket is being correctly calculated earlier, the discount should be correct also, if anything it's the subtotals and grand total that should be wrong.. sadly I've got no idea other than printing out a lot of debugging info and trying to track it down that way

What version are you on of CC4? Wondering if you have an old database file, if you open up the following file, should see these lines of code right at the bottom: File: classes/db/db.inc.php ## New for 4.1.x function getFields($table) { global $glob; $list = mysql_list_fields($glob['dbdatabase'], $table, $this->db); $cols = mysql_num_fields($list); for ($i = 0; $i < $cols; ++$i) { $array = (array) mysql_fetch_field($list, $i); $return[$array['name']] = $array['name']; } return $return; } If that's not there, just try adding it in right after: function close() { mysql_close($this->db); }

Three ways you can go about it really that I can see, if you want it to be foolproof.. the first would be to change the coding that handles registrations on the front end, get it to assign them a random password so they can't login when they've filled it in (which also necessitates removing any forgotten password functionality), then remove the code which auto logs them in after registration, instead perhaps redirecting to a success page hidden site doc. Probably relatively simple to do in theory, but not a very elegant solution Second way would be to modify it so that they not only have to be logged in to order/view prices, but also have to have a particular flag set on their account, where you can essentially mark them in admin whether they've been validated or not. I'm not really sure how many places, or indeed where, you would need to edit that into the code though, so not a clue whether or not that would be easier to do, but it would affect the actual running of the store less Both options I suspect however won't be workable with hooks, and so will need to be careful when upgrading the store not to lose it. The final way would be similar to what you suggested, just code it directly into the registration page that it just redirects them to your contact page, ideally with a little GET variable on the end so that it displays a message telling them why they can't just register. Probably the simplest solution, but would require you to do most of the legwork when it comes to adding the customer information, which may add up if you're going to have lots of them

They need to be declared as strings (wrapped in " or ' ), so you'll want: $mail->send(array($config['masterEmail'],"[email protected]"), $config['mailMethod']);

Not seen those particular characters, but I've seen similar garbage getting put at the end of images myself on some stores, couldn't track down the cause, but I think what I did find was that it only seemed to happen when the image field was being stored as binary or varbinary. If bsmither's tactic doesn't work, could try switching it over to varchar, seemed to fix it in that particular case for me

Kind of can blame excel, seeing as it's excel that's doing it. The same behaviour happens in xls or xlsx format as well, regardless of type casting. As I mentioned, if you have an export of data coming in that may either contain long numbers or leading 0s, excel flat out cannot handle it. You can put in bodge fixes for one, but then the other won't work That's the issue I'm talking about, the fact that as a data reader, excel is somewhat unreliable due to the fact that it changes things, and you can't turn off the changes it makes.

There's no way to turn off the automatic rewriting of numbers to various notations. You can usually get round them converting to scientific format if you explicitly set them as numbers, but then that ruins any product codes beginning with a 0, setting to text to allow those triggers the scientific notation You just can't stop excel reformating your data and it's a bit odd

I was tearing my hair out over this a few weeks back.. it's hard to believe there's no way to turn off them -changing- vital information in what is essentially a data storage software, but.. nope

If it's throwing out direct php code onto the page, it likely means php isn't installed or running correctly