Plugin Author
elfin
(@elfin)
Have never seen anyone else report this. Can you try some test purchases with all other plugins deactivated, and in the Twenty Eleven theme please. Does the issue still occur?
Have just tried with all other plugins deactivated and then in 2011 Theme (also with plugins deactivated). Still occurs with same date/time of 1999-11-30 01.
FYI. I have just read the FAQ about deactivating before updating. I did not do this.
Is there an easy way to roll back to version 6.2.11 that I have as ZIP file and was using prior to the update?
I need to be careful not to lose the database for previous shop orders and stock levels if possible (but do have a back up).
Cheers
Do you have any eShop sites on a different server? This does sound like a server timestamp issue.
No unfortunately this is the only eshop I’m running. It could very well be a server issue and will keep checking over the next 24 hours.
Is there an easy rollback process without deleting the database?
No – I’m afraid there isn’t.
Have just reverted to latest backups of wordpress and database. Date/Time was working again albeit time was 2 hours ahead of the timezone setting???
All updates performed again and date/time is working (but with 2 hour error as noted above). FYI update performed with eshop deactivated.
I guess it is a server issue??? Will keep an eye on it and update this post if anything changes.
I’m seeing the same problem in one of my 2 production eShop installs, and in my local/dev install.
I get 1999-11-29 20:00:00 (in prod) or 1999-11-30 00:00:00 (local) for all orders placed some time after 2012-06-22 22:02:00 (the date of my first order locally).
Currently using eShop version 6.2.15, WP 3.4.1.
Cheers,
Vinny
Nope, same server for both production sites.
mysql> select now();
+———————+
| now() |
+———————+
| 2012-08-28 08:11:28 |
+———————+
1 row in set (0.00 sec)
And…
usestrict@usestrict:~$ date
Tue Aug 28 08:12:16 EDT 2012
Plugin Author
elfin
(@elfin)
can you try it on a different server to rules things out then please.
I did some digging in the code and found that it’s not the server. I overrode function orderhandle() based on eShop version 6.2.13 (for eShop Shipping Extension) or 6.2.14 (don’t remember which now) and my version of the code does not set $custom_field to date() as is done in 6.2.15.
The result is eshop_orders.custom_field == NULL when saving the order, which then returns the bad date from eshop_real_date($myrow->custom_field);
I’ll check for other differences between 6.2.15 and my overridden code and merge them for the next release of eShop Shipping Extension.
