Toucan Web Design
Member-
Posts
148 -
Joined
-
Last visited
-
Days Won
4
Toucan Web Design last won the day on January 23 2015
Toucan Web Design had the most liked content!
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
Toucan Web Design's Achievements
Newbie (1/14)
9
Reputation
-
Is the max_input_vars issue resolved in V6?
Toucan Web Design replied to techmistress's topic in Install & Upgrade Support
I'd imagine if a shared server is restricting the vars limit to the point where it's blocking that, there's also a pretty solid chance that it might be running a limit on the amount of get data sent size wise as well, so if you do go that route, I'd have a check to make sure you're not going to be hitting that. Looks like 512 characters is a limit for them on some suphp setups -
Bah, do apologise, I misread a bit of the original code and it's wonky due to that I'd managed to read where you were originally setting up the selectors variable, to be a selector string, not actually setting it to the elements. You probably want it to be var selectors = 'form.addForm label.return select'; To use it in the way we are doing Also, it'll need to be outside of document ready, otherwise it won't necessarily be in scope for the function Once you've got the triggers output, try doing: console.log(jQuery(selectors)); console.log is pretty swish, it'll happily output entire elements or arrays for you to look through and confirm they're getting picked up
-
The way I'd generally do it is like this: var selectors = jQuery('form.addForm label.return select'); function ccOptionAjax(){ var assignArr = new Array(); var arrCount = 0; var goAjax = true; jQuery(selectors).each(function(){ var oSelected = jQuery(this).find("option:selected"); if(oSelected.length > 0 && oSelected.val() > 0){ assignArr[arrCount++] = oSelected.val(); } else { goAjax = false; } }); if(goAjax){ } } jQuery(document).ready(function(e){ jQuery(selectors).each(function(){ jQuery(this).change(function(){ ccOptionAjax(); }); }); }); I generally use jQuery explicitly over $ as a matter of course, just for the rare occasions where a store ends up being smushed together with another system which is running prototype, otherwise they kinda hate each other. Running each before change (or blur or any other event) is more a personal preference/paranoia thing I think, I used to have a few scripts just refuse to run the other way round, but I suspect this was more due to very old versions of jQuery or other similar bugs, I don't think there's any especial advantage to doing so. Calling a function instead of putting the code inside the change is a much better thing though as far as I'm aware, as javascript ends up creating a full function for each event trigger. Ideally you want to minimise the size of those to reduce overhead, so having them just reference a single function can help with that. Similarly not sure if you still need to have the functions outside of the document.ready, but I also had problems with that in the past, so I put them out in the open as a matter of habit these days.. pretty much the same with running a find of option:selected.. I've found running val() on the select way too flakey over the years, so I end up just sticking with someone I know works on those situations I'd also suggest sending over the array in JSON via the ajax, it's just a little nicer as you can then just json_decode it on the php side and get an array, rather than fiddle with unsafeing data and exploding Seconding the use of console.log though, it's a much handier function than alert, and a lot better for when you're chucking out lots of debug data
-
New EU VAT rules from 1st January 2015
Toucan Web Design replied to Al Brookbanks's topic in Developer Forum
Just to clarify something which is confusing me, if they'll need to be charged tax at all kinds of different rates, why are you taking the prices at the inclusive value, instead of exclusive? -
First I've heard of this one.. had a check through the user class and everything appears to be in order.. register customer checks if they're existing and type = 1, which shouldn't be triggered on guest accounts.. similarly the create user function checks for an existing ghost account and updates rather than inserts.. everything in the code suggests it should be fine. Hmm, I've just spotted one difference between an earlier version and the current one though, on createUser on the user class, it used to set: $data['type'] = $type; As part of the global data set... now it only does that on insert... so it's possible that the register/update is working fine, but it's leaving them as guest users, which can't be logged in as, so useless.. I'd recommend changing that back just in case: $data['new_password'] = '0'; $data['ip_address'] = get_ip_address(); To: $data['new_password'] = '0'; $data['type'] = $type; $data['ip_address'] = get_ip_address();
-
Just to check, did you set up a sandbox account with different details? They use a different encryption password and id and whatnot usually.. by the looks of things they've simplified it since last time I touched it, you should be able to quickly clone your live details into the sandbox mode one But yes, if you've hooked that up, then a little worrying if it's failing on sandbox.. does it give a specific error, or is it generic?
-
You're going to need to turn on debug mode in your admin to track that down, or at least help to White page is usually a fatal php error, which could be caused by a number of things Also worth checking is if there's an error log on whatever hosting control panel you use, that can store important info on precisely what's failing
-
Functions as a form of banning as well, in that they can't re-register under the same email, and can't login to their existing one Of course, it's not like email addresses are hard to find, bans are getting more and more obsolete really
-
Something else to check up on, if you have access to the database, try going onto that and checking the table called CubeCart_order_sum, see if the order exists in there. If it is, then what has likely happened is the one of the joined table references has gone missing, which is stopping it from showing up in the query If it isn't, then it would sound like it was deleted in some fashion Should help narrow down which of them it actually is.
-
Looks relatively fine, that .htaccess.. I'd just try the following: First off, remove these lines at the bottom and see if that sorts it out RewriteCond %{HTTP_HOST} ^domain.com.au$ [OR] RewriteCond %{HTTP_HOST} ^www.domain.com.au$ RewriteRule ^/?$ "http://www.domain.com" [R=301,L] If that does fix it, then it's a problem with those.. those are the only non standard bits on there I can see, might just be from a newer version of 4 I'm not familiar with Anyhow, if they're causing the issue, try switching them for this: RewriteCond %{HTTP_HOST} ^yourdomain.com.au$ [OR] RewriteCond %{HTTP_HOST} ^www.yourdomain.com.au$ [OR] RewriteCond %{HTTP_HOST} ^yourdomain.com$ RewriteRule ^(.*)?$ http://www.yourdomain.com/$1 [R=301,L] The backslashes should only need to be in front of those .'s. .. plus I'm not too sure what it's even trying to do.. seems to want to rewrite www and non www .. which is a bit odd for that sort of code, you're generally just writing them to one or the other, so only needs to trigger on the one. Edit: Ah right, nevermind, I see now, it's redirecting a com.au to a .com, got it. Ok.. changed the code accordingly Obviously you'll want to switch out the domain for the one of your site
-
Perhaps even phpmyadmin refuses to back the whole lot up, though I'm surprised, I've exported databases that size before with no issue, thought there was only a limit on the importer. Could try exporting each table seperately and see whether that works, if so, then it might be an issue with the size of the database
-
Replacing this bit: #account a, #header a { color: #FFF; display: inline-block; font-weight: bold; height: 0px; padding-right: 1px; text-decoration: underline; } With the code provided should be the safest, the bit with the header links may be to fix issues with store logos that could affect you in the future
-
The stylesheet on common.css line 49 has the code setting them to display inline-block and with a height of 0. Bit unusual that, getting rid of both of those should fix the issue. However, it's also used for links in the header.. which might be needed, so what you might have to do is split those out into two seperate sections #account a, #header a { color: #fff; font-weight: bold; padding-right: 1px; text-decoration: underline; } #header a { display: inline-block; height: 0; }
-
Just to clarify something, are you taking the books sold online through the PoS system as well? Just wanting to check that you won't end up with any discrepancies if they're both keeping a seperate record of stock levels. Seeing as you've got a unique reference for each product, I wouldn't imagine it would be hard to whip up some basic stock updating code for an import. I'm a bit wary running it through the importer, due to a bunch of code that cto wipe out product category references and/or seo urls, ah, and it doesn't appear to have any update options that I can see, just runs inserts every time?
-
Did you say it was calling in all the various bits contained within the head.ready bit asynchronously Brian? What I'm wondering is if it's happening in certain browsers due to load optimisations and whatnot.. as it only tries to call in the javascript when the page is loaded I presume, might be happening earlier (or later) for safari/chrome/firefox, and could explain why it's being so random in the results. Could also be down to internet speed, which would explain why it broke on firefox via a different network Anyhow, just saw the reply Nik, that's indicating that jQuery isn't loaded when it gets to the point where tries to run the imageupload template yes, all of those files are packs within that template. I'd say getting it to run via head.ready is likely going to be the safest option, but I haven't a clue what might have been causing that bug you mentioned where it loaded up the button twice, unless it's somehow calling the ready function of the loader twice, which would cause a ton of other errors anyway, jquery does not like being loaded twice usually