Dirty Butter
-
Posts
6,634 -
Joined
-
Last visited
-
Days Won
139
Posts posted by Dirty Butter
-
-
6.2.0 has a way to temporarily stop ALL plugins and snippets from running - a Safe Mode. It means going to your global.inc, changing your permissions and changing the Safe Mode setting from false to true. Then run your site again. Once you've changed your settings appropriately - change Safe Mode back to false and the permissions back to strict.
Hopefully that will give you what you need.
BTW, if I remember correctly, the Safe Mode setting was Bsmither's suggestion in GitHub.
-
Well, I've replaced all the files with stock AGAIN and run setup AGAIN. I STILL can't get this to work with today's 6.2.1 commit - with or without reverting the js file. I am at a total loss how to proceed. The only thing that still has anything from previous versions is the database, which is basically a copy of our live store that I upgraded to the commit.
-
That is very puzzling indeed.
Add item to basket, click Checkout, add in all required info, billing the same as delivery is already checked by default, check T&C box, left shipping choice as shown, clicked checkout button. Then get a very long load of next page - /index.php?_a=addressbook&action=add&redir=confirm
See screenshot https://dirtybutter.com/billingdeliveryaddressissue.png
Using FF tools, the long wait is a 302 POST to index.php?_a=confirm that takes 3719 ms to complete.
-
On your commit as of today (except for the button color change) WITH the reverted js file - sorry to say it still did not work. But since it's a js change, I'm going to do some major manual Windows cache cleaning and cache cleaning of CC and try again.
-
Testing it now - will report. BTW - I do not allow guest checkouts, so that is normally a hidden line of code in my own edited version.
-
I think I've found my problem. I still had admin cache disabled, as I've been doing lots of editing. I DID have cache cleared out before testing purchasing on the front end, but with cache disabled the front end evidently can't "hold" the choice to use billing the same as delivery. Once I enabled cache within Admin, I was able to get a proper purchase sequence. I'll test some more, but I think this is resolved.
-
This works correctly on the 6.2.0 Demo store. But mine on current commit 6.2.1 on one test store does not. The other test store is on 6.2.0 and it works correcly.
The code is stock on content.checkout.confirm.php as far as having the delivery and billing addresses checked as being the same. So, just as I should, when I am on content.checkout.confirm I see the checked box saying billing and delivery are the same.
But incorrectly, my next step in checkout takes me to the page where I'm told I have to provide a billing address. I have no idea what file to look in to try to see what I have wrong as far as acting on that checkbox is concerned.
-
I've double checked my install and find that a customer who fills out the Addressbook gets the correct process. If the state does not have any states listed, the State box is blank. If there are states listed, required or not, it simply offers the available choices.
BUT a customer who fills out the addresses from the content.checkout.confirm page (when they choose a product and then fill out address information) gets a different look, with the State (Required) placeholder.
I tried to compare the way states were handled in the content.checkout.confirm vs content.addressbook.php files. I noticed this difference:
checkout.confirm has var county_list = {$STATE_JSON};
addressbook has
var county_list = {$VAL_JSON_STATE}
Could it be that checkout.confirm needs the same line as addressbook?Well I tried using the addressbook JSON line in checkout.confirm, and it no longer offered the drop down when it should. So THAT's not it. UGH -
I actually have this test site on yesterday's 6.2.1 commit. I did run the new upgrade queries. Evidently something is still not working properly?
-
If a country does not have any county/states listed in my database and is set as optional - the State box on filling in the Checkout Confirm country SHOULD be blank.
Instead it shows a placeholder of "State (Required)". It does allow checkout to proceed even without filling anything in the blank.
The Demo Store also shows an extremely faint placeholder of County (Required), even though it allows checkout to continue without filling anything in the box.
The Estimate Shipping box correctly shows an empty State box when it should. There may be other places where the (Required) shows, but doesn't make sense to me.
Is this a bug?
-
This might help you:
-
I'm double checking all my edits (mostly Bsmither tweaks) for 6.2.0. I know there is now a choice in 6.2.0 store settings Advanced tab for Use Customer's address in Reply-To:
Am I correct that this tweak will not be needed for 6.2.0?
-
I thought it did do that previously. I so seldom have to create an order. Since it has the drop down to choose the tax rate, it seems logical that it would calculate it and add it to appropriate field. Instead, it just turns the empty box red.
Yes, the value I add manually sticks.
-
I can't help, but I just tested mine and it worked. I tried from within Admin on an old order and also logged in as a customer for the Order History.
-
I can't get the create order section to use the one sales tax entry I use. Could someone please confirm that this is working properly for you or not?
-
Hey Claudia - you probably want to edit your post to get your actual admin_XXXX.php name out of public view.
As for the database warning you're getting, it's being discussed in GitHub.
-
1
-
-
If removing email information didn't work - maybe it's stored in cache. Try manually deleting all cache before giving up and going offline.
-
Would it work to temporarily put the wrong password on the email information in the Admin>Store Settings>Advanced tab?
-
The millennium bug never happened because people either bought new equipment or did something like what I did at school. I reset the server clock to 1972?? (I think - same calendar days as 2001) and removed all instances where the year showed to the users. We limped along for quite a few more years on that old system.
-
In all our years in business I had one customer ask that all data about them be scrubbed. I did it manually via the database. I agree that an easily available query would be nice to have.
-
I'm glad you worked out a way for your situation. We only occasionally find the large Jumbo Love animals, and they are the only ones we have to ship with Oversize. Because of what we sell people usually buy one item at a time.
No matter how we work around the issue, the USPS module should be coded to deal with it.
https://features.cubecart.com/topic/add-dimensional-capabilities-to-usps-module
-
This has been needed for some time in the USPS module. My way around it for XL toys for now is to set their package weight higher than it actually is. That way I don't lose money paying the oversize charge that my Dazzle stamp software automatically calculates when I input dimensions for the package in the shipping software. That's cumbersome to say the least.
As for multiple orders going in a big box - THAT looks like it would be a horror to deal with. SWFW's plugin would have to be used to create a volume for each item in the order and come up with a total to be sent to USPS.
-
This is strictly a work around for now, but I would suggest you create a gmail account for this purpose. It will be "real" so you won't get all the bounce messages. I have a gmail account I use fro time to time to reply to people whose email company ban us for behavior of some other domain on our server.
-
SemperFi has a $1.00 plugin that provides a way to add dimensions to a product - that's all it does, but it's a start toward getting dimensional shipping to work.
http://semperfiwebservices.com/product-dimensions-cc6-plugin.html
Cubecart 6.2.1?
in Technical Help
Posted
OH!!! Congratulations to both of you!! I was hoping you were offline because your baby had come!