Toucan Web Design
-
Posts
148 -
Joined
-
Last visited
-
Days Won
4
Posts posted by Toucan Web Design
-
-
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
-
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
-
Sorry for not jumping in on this, been off ill for a week
The image uploader was trying to run some jquery that I could tell, which the skin was somehow setting to only ever load after the rest of the page content, meaning no other plugins could access jquery, was a bit odd
Did you get any javascript errors when you tried that Nik? If you didn't check, could you try setting it again and just have a look in the console using web developer tools on the browser, then paste them here? Will likely help debug
-
Try clearing your cache, categories often get stored in that
-
I'd go as far as to say that it's not unreasonable to expect a skin to not rewrite the javascript calls so that it, and it exclusively has access to jquery... that I think it what it seems to be doing anyhow.. not seen the particular script before, but essentially it seems to be making jquery and all the files the skin uses load only when the document has loaded, by storing them in an object which has a ready function of its own, presumably for more optimal page loads.
Loses out on a fair bit of flexibility doing that though, and sortof breaks our one completely. In an attempt to make the code changes as minimal as possible I went for a purely plugin based route where the js was loaded via the skin
Have a try of this Nik:
On the vector skin, there's a file in /js/ called application.js, at the bottom there's this bit:
{jquery: '//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js'},
You can try commenting that out:
// {jquery: '//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js'},
Then just grab the same jquery call from one of the standard skin files (main.php), and try just bunging it in the vector header?
I'm not 100% if the fix will work unfortunately.. it's plausible that whatever is going on in the header object, it might try and reference the js by the jquery parameter it's sending with the filename, in which case it'll just break everything no doubt. Won't hurt to try though, you can always set it back how it was
-
Do you have access to the database via the hosting control panel? Have a check for a table called CubeCart_admin_users, you should be able to see if there are any users set up in there If it's empty, or the table does not exist (which for some reason I've seen happen occasionally), then that will need restoring from a backup again ideally. Either that, or you can just add in a new user yourself via the control panel, super user should be 1 and for the password, you would need to click on the options section for that field and select MD5, as it's an encrypted field
-
Still getting a google attack site warning here
-
The only changes I made where in modules/external/lettering/genimage.php, so that should narrow it down. You should see mention of this variable:
$HTML401NamedToNumeric
Which has an array of entities to convert
-
That's a weird one.. falsely triggering some kind of anti cross site scripting perhaps?
Have a try of plain javascript maybe, give this a go?
document.getElementById(formname).submit();
Used that before on custom POS sites set up on localhost via xampp, so if that gets blocked as well, sounds like something weird's going on
I'm assuming that code is in a document ready section yeah? If not, then that might be why, depending on page load times sometimes the dom for the form or image might be getting found, others not
-
Some kind of bad formatted code on one of the return pages forcing it into whatever passes for a quirks mode these days maybe? Sounds a bit weird if they're all changing user agents on return from paypal.
Hmm, or what if it's on the paypal side of things that it forces the agent into a lower version that it happens to remain on when you return to the site?
-
I read somewhere on the PHP docs site that such-n-such a function already encodes ampersands, so having your application do it would be a mistake. I don't remember what that function was. I'll try to find it.
htmlentities does that one, might be converting it to &
-
There are a few changes to the way fundamental bits are stored, mostly images and such that cause the problem I think.. otherwise, the data in the tables isn't too dissimilar
Do you still have a backup of the cc4 and the database file? If so, I'd probably recommend just reinstalling that in a subfolder you can work on, then try and just port over any live, changed data.
In general, the only tables that are super important for that are:
documents, customers, inventory, category, cats_idx, order summary, order inventory
Anything else is mostly either statistics or config, which might not be applicable or particularly important
You might find it easiest to take a copy of the database tables from 5, rename them so they don't conflict and import them onto the 4, then just try renaming columns to get them to match the cc4 versions, see how close you can get them. That won't be too hard if you have a nice interface like phpmyadmin to work with
Either way, it's likely going to take a bit of work to get running again though, might be better off paying someone to write some php scripts which can just generate all the conversion queries.
Is the max_input_vars issue resolved in V6?
in Install & Upgrade Support
Posted
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