[Done v1.3.6] bug with state selection check on registration

JeffD:

That's great Dr. Byte, I will refrain from doing any further work for now then!

Is the official bug fix going to hide the state field when it is not required?

Thanks,
Jeff

Yes .

DrByte - this code has been in testing for some time now - since the 6th I believe - as of the 18th, do you have an ETA for this fix? Many businesses are reporting sharply reduced sales and are thus quite significantly impacted - so any ETA you could provide would be welcome news.

Thanks.

Can't you just roll back to your previous version?

I can't figure out people who rely on internet sales so much and yet take a huge risk in going live with an upgrade before they (you) have fully tested it.

What I did was this: installed all security patches to existing shops, installed 1.35 on a testing server (but could also be your service prodiders server, another directory), spend time looking at everything, every calculation, rounding, tax, etc, etc.

anyway, end of rant.

Look - innocent store owners upgrade because they receive a Security Advisory to do so. They upgrade - all appears to look and test ok - and then code problems emerge.

Store owners can't know that there are rather arcane bugs as this one is - the question I raised was - as there is a code-fix in testing - could DrByte or Ajeh just indicate when that fix might be released.

Any ETA on fix?

I have seen no complaints since I added these lines to this popup error message:

Until a fix is available:

includes/languages/[your custom template directory]/english.php (or your preferred language define)

define('ENTRY_STATE_ERROR', 'Your State must contain a minimum of ' . ENTRY_STATE_MIN_LENGTH . ' characters.\n\n **If you cannot complete your edit or selection of your state, this is a software error. Please close your browser window, reopen, restart your registration and select state before hitting Submit.\n\n We regret the error. Thank you for your patience.');

This at least will tell customers what is going wrong and what to do about it. For a workaround, all they have to do is close the browser window and reopen it. This is slightly aggravating but at least does not result in lost sales. The problem is in how to instruct customers what to do until you have a fix.

---Diana

Unfortunantely, that doesnt really help if you have an international store where customers CANNOT choose any country. Has "some" impact on sales...

jetx:

Can't you just roll back to your previous version? You can. But that's almost twice the work. And moving on is always preferable to moving back. More to the point, what do you roll back to? The new version included a fix for what was an even bigger bug in the previous version. So fixing it would mean rolling back two versions, not just one :cry: > jetx:

What I did was this: installed all security patches to existing shops, installed 1.35 on a testing server ... spend time looking at everything, every calculation, rounding, tax, etc, etc. So did I. Over several days in fact. But you can't cover all the bases all the time. I only discovered this bug myself by accident 2 days after we'd gone live. If the good Doctor himself needs 2 weeks to test it then how can mere mortals be expected to do it in less? > ben_golant:

• the question I raised was - as there is a code-fix in testing - could DrByte or Ajeh just indicate when that fix might be released. Personally I find that coding is painstaking work, best done at your own pace, without deadlines or anxious bystanders breathing down your neck. And I also happen to think that things would be much better (in the rest of the world, outside Zen Cart that is) if more people stopped promising things they never intended to deliver.

On the other hand, we are talking about ecommerce. With my store-owners hat on for a moment, it has to be said that rocking and rolling back and forward over the same-old ground does entail some kind of cost - of opportunity if nothing else... When you're doing that you're not getting on with something else. So, if the fix is weeks away it may well be worth patching or rolling back. But if it arrives five minutes after you've spent half a day carefully undoing what you've already spent several days doing, then you'd probably be kicking yourself. So, on balance, I'd have to say that some kind of loose - hassle free - no sweat - laid-back - ball-park kind of feedback on the sort of timescale we might be looking at - could have its attractions :blush:

I feel certain that the development team is working very hard to get an update out to correct the problem as soon as humanly possible. There are many different store configurations to test, many different browsers to test against as well as three different UI's in the store which require this fix be applied. The result is it takes time to test all of the permutations. I can tell you from testing that the proposed solution as of a few days ago works perfect under our configuration(s) and I would expect that a publically available solution will be released very soon.

Jeff

Badabing:

Unfortunantely, that doesnt really help if you have an international store where customers CANNOT choose any country. Has "some" impact on sales...

actually, once I installed the workaround snippet, I've not had any problems. We also work with an international customer base, so it's not causing a problem there.

:cheers:

imac:

You can. But that's almost twice the work. And moving on is always preferable to moving back. More to the point, what do you roll back to?

Going back and replacing files is a laborious task and I agree that is not really a realistic approach. However, by rolling back I mean restoring the files completely.

Before any upgrade or any store changes including templates I just download the entire store, maintaining every change in a specific directory, backed up to DVD. A bit of work but allows me to restore whatever backup I want so if an error is found I can check through previous versions of the site. Same thing with the database, all backed up in the same way.

A site can be completely replaced by a previous version in less than 30 minutes, depending upon connection speeds; hardly any work.

The other error bug you had with the previous version 1.3? was that a security issue?

Moebiusenterprises:

actually, once I installed the workaround snippet, I've not had any problems. We also work with an international customer base, so it's not causing a problem there.

The workaround snippet was posted by JeffD earlier in this thread.

jetx:

Before any upgrade or any store changes including templates I just download the entire store, maintaining every change in a specific directory, backed up to DVD. I keep a mirror of the online site running on a local server and test everything out there first before uploading. Before any upgrades I save a copy of the entire catalogue directory - so rolling back to any previous version of the files is simply a matter of renaming the directory. So, apart from the upload, that just takes seconds. > jetx:

Same thing with the database, all backed up in the same way. Now you've lost me. How do you restore a 3 month old database without losing all the orders, customers, products and the other stuff that was added since? > jetx:

The other error bug you had with the previous version 1.3? was that a security issue? Not security, but a bug with the state selection routine in 1.3.2 which affected tax calculations. You can find it at http://www.zen-cart.com/forum/showthread.php?t=40630 That one ran from July through to September. The eagerly awaited fix arrived with v1.3.5, so it was a bit of a nuisance to discover that we ain't quite out of the woods just yet :unsure:

Yes I see that bug can affect you with state taxes, so far I've had no problems from it, though I'm only dealing with a single sales tax so its just the out of region (not within my state drop down) deliveries which, if a customer happened to enter at checkout, I'd have to reject the order, advise correct freight component, etc.

Updating various data fields from one version to the other using phpMyAdmin seems to work without any problem, so far.

jetx:

Updating various data fields from one version to the other using phpMyAdmin seems to work without any problem, so far. Sure enough. But you're talking about quite a lot of fairly heavy database manipulation here. Not something to be undertaken lightly. And no longer a simple matter of just replacing a few files :no:

imac:

Sure enough. But you're talking about quite a lot of fairly heavy database manipulation here. Not something to be undertaken lightly. And no longer a simple matter of just replacing a few files :no:

It means exporting selected tables from your production database running on existing Zen Cart installation and then importing those same tables into your "test" shop database running on the new Zen Cart version installation. That is how I upgrade everytime. Of course you have to ensure the fields in the various tables match-up between versions... not difficult to figure out or act on after inspecting the sql patch file(s).

Personally - I would prefer a bug fix. And I would prefer it...yesterday.
:blush:

We will keep that in mind ... as so would we ... :cool:

Woodymon:

It means exporting selected tables from your production database... ...Of course you have to ensure the fields in the various tables match-up between versions... not difficult to figure out or act on after inspecting the sql patch file(s). Er... No... Not particularly difficult. But to be safe, after you've checked the sql patch files and after you've exported & imported the tables, you'd also want to double-check functioning of catalog and admin to make sure that nothing had been broken. All of which adds up to a little more than an easy half-an-hour's stroll in the park - which is where this particular line in the discussion began. > Badabing:

Personally - I would prefer a bug fix. And I would prefer it...yesterday.
:blush: Wouldn't we all! But out of quick, cheap and good, you can only have an 2 at the same time. I'm sure the Doc, Ajeh and the rest of the crew are doing everything they can. Me, I'd rather have it good than Tuesday. :yes:

imac:

Er... No... Not particularly difficult. But to be safe, after you've checked the sql patch files and after you've exported & imported the tables, you'd also want to double-check functioning of catalog and admin to make sure that nothing had been broken. All of which adds up to a little more than an easy half-an-hour's stroll in the park - which is where this particular line in the discussion began.

I do understand the frustation in not having a patch/bug fix in hand when you need it.

However the steps you describe above are the same steps one would have to do with ANY upgrade and/or bugfix, requiring a sql patch or not. It is well documented that one should THOROUGHLY test upgrades, db patches and bugfixes on a non-production server.

Regarding "you'd also want to 'double-check' functioning of catalog and admin to make sure that nothing had been broken", I do this following EACH and EVERY new installation, upgrade or patch (or rollback)? Doesn't everyone? Once you do it a couple of times you will understand how difficult it is not (but agreed it can be time consuming).

Analyzing the cost to upgrade or patch (or rollback) versus the risk of continuing to run older (or newer) software/code is just part of the cost of managing an ecomm shop (or when working with technolgy in general). So get used to budgeting that potential risk/time requirement into your performa statements, consulting estimates and support/maintenance contracts.

Linda has communicated that a release date announcement for v.1.36 will not happen. It will be out when it is out. And we have to respect that. So end of that discussion. ;-)

However if the bug fix code was indeed already fully tested and ready I would have thought it could have been made available separately, before v.1.36 release. My assumption is the patch testing for this far reaching issue is still not complete, thus the "delay" in v.1.36 and non-release of patch code. At least I have not heard anything to the contrary.