upgrade from 2.3.3 to 2.3.3.4

[MarcellaE]

I upgraded from 2.3.3 to 2.3.3.4. I had an issue with garbage text on my Euro symbol but resolved that but for the life of me I don't know why my Order Dates on the Admin front page is showing the date 11/30/2036 for all my orders! What could be the problem? (see image)

[Shuen]

I have the same problem, It only shows 11/30/2036 in the first admin page,

The date works fine in orders.php

[MarcellaE]

Yes, Shuen, same here. The 11/30/2036 dates only shows on the first Admin page and dates are fine in the orders. I'm stumped.

[burt]

I have not experienced that problem on any of the upgrades I have performed...

 

Is there anything else that you guys have done that could have affected it - eg sometime in the past did you change the date structure from american format to european format ?

[MarcellaE]

Hi Burt,

No, I didn't change any date structure. I just did the upgrade and that was it. In fact, this started in 2.3.3.3 and I thought 2.3.3.4 would resolve it but it didn't.

[tgely]

This will be tep_date_short() problem which related with the sql date return. The orders use tep_datetime_short(). The date_last_modified field could be datetime or date.

 

What is the DATE_FORMAT and DATE_TIME_FORMAT in english.php language file?

[Shuen]

I didn't make any changes on DATE_FORMAT and DATE_TIME_FORMAT.

define('DATE_FORMAT', 'm/d/Y');
define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');

[MarcellaE]

I had to go back to 2.3.3.2 that's the last upgrade where 11/30/2036 doesn't display in Orders on the admin front page. Strange thing was that the database didn't show any such date. All the dates in the database were what they were suppose to be. So something is happening in transit to the Orders date on that front page. I don't know what tho!

[tgely]

Could you post here server os from admin/server_info.php?

[MarcellaE]

Sure. Here it is:

 

[oscommerce]

version = 2.3.3.2

 

[system]

date = 2013-10-14 15:03:39 -0400 EDT

os = Linux

kernel =

uptime =

http_server = Apache

 

[mysql]

version = 5.5.24

date = 2013-10-14 15:03:39

 

version = 5.3.27

zend = 2.3.0

sapi = apache2handler

int_size = 4

safe_mode = 0

open_basedir = 0

memory_limit = 128M

error_reporting = 30711

display_errors = 1

allow_url_fopen = 1

allow_url_include = 1

file_uploads = 1

upload_max_filesize = 250000000

post_max_size = 250000000

disable_functions = phpinfo

disable_classes =

enable_dl = 0

magic_quotes_gpc = 1

register_globals = 1

filter.default = unsafe_raw

zend.ze1_compatibility_mode = 0

unicode.semantics = 0

zend_thread_safty = 0

extensions = Core,date,ereg,libxml,openssl,pcre,sqlite3,zlib,calendar,ctype,curl,dba,dom,hash,fileinfo,filter,ftp,gd,gettext,SPL,iconv,session,json,mbstring,mcrypt,mssql,mysql,mysqli,standard,PDO,pdo_mysql,PDO_ODBC,pdo_sqlite,Phar,Reflection,imap,SimpleXML,siteguard,soap,sockets,SQLite,exif,tokenizer,wddx,xml,xmlreader,xmlwriter,xsl,zip,apache2handler

[MarcellaE]

So I set up a 2.3.3.4 test store. The strange thing is with 3 orders placed and showing on the front page Admin, the dates are fine. Once a 4th order is placed is when the all the dates turn to 12/31/2036. I can't find why placing the 4th order sets all the dates wrong. If 3 orders show the date properly, why not 4 orders and above?

[tgely]

@@MarcellaE

 

If you delete the fourth order before orders will be ok?

[MarcellaE]

Yes, if I understand you correctly, if I delete the 4th order then the dates are displayed properly again for the 3 previous orders.

[tgely]

Could you list here the orders dates from SQL dump?

[MarcellaE]

Is this what you mean?

 

-- phpMyAdmin SQL Dump

-- version 2.11.11.2

-- http://www.phpmyadmin.net

--

-- Host: sql5c24c.carrierzone.com

-- Generation Time: Oct 20, 2013 at 01:02 PM

-- Server version: 3.23.32

-- PHP Version: 5.2.17

 

 

--

-- Database: `test_database`

--

 

-- --------------------------------------------------------

 

--

-- Table structure for table `orders`

--

 

CREATE TABLE IF NOT EXISTS `orders` (

`orders_id` int(11) NOT NULL AUTO_INCREMENT,

`customers_id` int(11) NOT NULL,

`customers_name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`customers_company` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,

`customers_street_address` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`customers_suburb` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,

`customers_city` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`customers_postcode` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`customers_state` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,

`customers_country` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`customers_telephone` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`customers_email_address` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`customers_address_format_id` int(5) NOT NULL,

`delivery_name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`delivery_company` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,

`delivery_street_address` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`delivery_suburb` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,

`delivery_city` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`delivery_postcode` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`delivery_state` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,

`delivery_country` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`delivery_address_format_id` int(5) NOT NULL,

`billing_name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`billing_company` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,

`billing_street_address` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`billing_suburb` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,

`billing_city` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`billing_postcode` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`billing_state` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,

`billing_country` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`billing_address_format_id` int(5) NOT NULL,

`payment_method` varchar(255) COLLATE utf8_unicode_ci NOT NULL,

`cc_type` varchar(20) COLLATE utf8_unicode_ci DEFAULT NULL,

`cc_owner` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,

`cc_number` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,

`cc_expires` varchar(4) COLLATE utf8_unicode_ci DEFAULT NULL,

`last_modified` datetime DEFAULT NULL,

`date_purchased` datetime DEFAULT NULL,

`orders_status` int(5) NOT NULL,

`orders_date_finished` datetime DEFAULT NULL,

`currency` char(3) COLLATE utf8_unicode_ci DEFAULT NULL,

`currency_value` decimal(14,6) DEFAULT NULL,

PRIMARY KEY (`orders_id`),

KEY `idx_orders_customers_id` (`customers_id`)

) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=62 ;

 

--

-- Dumping data for table `orders`

--

 

INSERT INTO `orders` (`orders_id`, `customers_id`, `customers_name`, `customers_company`, `customers_street_address`, `customers_suburb`, `customers_city`, `customers_postcode`, `customers_state`, `customers_country`, `customers_telephone`, `customers_email_address`, `customers_address_format_id`, `delivery_name`, `delivery_company`, `delivery_street_address`, `delivery_suburb`, `delivery_city`, `delivery_postcode`, `delivery_state`, `delivery_country`, `delivery_address_format_id`, `billing_name`, `billing_company`, `billing_street_address`, `billing_suburb`, `billing_city`, `billing_postcode`, `billing_state`, `billing_country`, `billing_address_format_id`, `payment_method`, `cc_type`, `cc_owner`, `cc_number`, `cc_expires`, `last_modified`, `date_purchased`, `orders_status`, `orders_date_finished`, `currency`, `currency_value`) VALUES

(61, 1, 'test acct', '', '2222 test lane', '', 'Los Angeles', '90045', 'California', 'United States', '55555555555', '[email protected]', 2, 'test acct', '', '2222 test lane', '', 'Los Angeles', '90045', 'California', 'United States', 2, 'test acct', '', '2222 test lane', '', 'Los Angeles', '90045', 'California', 'United States', 2, 'Cash on Delivery', '', '', '', '', NULL, '2013-10-20 12:57:14', 1, NULL, 'USD', 1.000000),

(60, 1, 'test acct', '', '2222 test lane', '', 'Los Angeles', '90045', 'California', 'United States', '55555555555', '[email protected]', 2, 'test acct', '', '2222 test lane', '', 'Los Angeles', '90045', 'California', 'United States', 2, 'test acct', '', '2222 test lane', '', 'Los Angeles', '90045', 'California', 'United States', 2, 'Cash on Delivery', '', '', '', '', NULL, '2013-10-20 12:56:32', 1, NULL, 'USD', 1.000000),

(59, 1, 'test acct', '', '2222 test lane', '', 'Los Angeles', '90045', 'California', 'United States', '55555555555', '[email protected]', 2, 'test acct', '', '2222 test lane', '', 'Los Angeles', '90045', 'California', 'United States', 2, 'test acct', '', '2222 test lane', '', 'Los Angeles', '90045', 'California', 'United States', 2, 'Cash on Delivery', '', '', '', '', NULL, '2013-10-20 12:55:56', 1, NULL, 'USD', 1.000000),

(58, 1, 'test acct', '', '2222 test lane', '', 'Los Angeles', '90045', 'California', 'United States', '55555555555', '[email protected]', 2, 'test acct', '', '2222 test lane', '', 'Los Angeles', '90045', 'California', 'United States', 2, 'test acct', '', '2222 test lane', '', 'Los Angeles', '90045', 'California', 'United States', 2, 'Cash on Delivery', '', '', '', '', NULL, '2013-10-20 12:55:14', 1, NULL, 'USD', 1.000000);

[tgely]

Yes it is. The tables are good.

 

You say that every page or do you have problems with date only on dashboard?

 

 

Maybe the problem affected with setlocale

 

 

Try to change in admin/includes/languages/english.php

 

setlocale(LC_ALL, array('en_US.UTF-8', 'en_US.UTF8', 'enu_usa'));

 

to:

setlocale(LC_ALL, array('en_US.UTF-8', 'en_US.UTF8'));

[burt]

In the dashboard module, the date comes from this SQL call:

 

greatest(o.date_purchased, ifnull(o.last_modified, 0)) as date_last_modified

 

I wonder if, for some reason, this is failing on your version of MySQL. To test this, please change that part of the code to:

 

o.date_purchased as date_last_modified

 

save the file and upload. View the index page module and see if the dates are now OK.

 

 

 

[MarcellaE]

Thank you Gergley but I tried setlocale changes and it hasn't effected anything.

Burt, I will try your suggestion. I did dabble around in the d_orders.php file and couldn't resolve the issue.

[MarcellaE]

That was it, Burt! I sensed that piece of code was the culprit but didn't know what to do with it. Thanks so much! Hope it helps others too.

[tgely]

I examed some returns:

 

when '0' return string(10) "11/30/2036"

when 0 return bool(false)

when Null return bool(false)

when empty return bool(false)

when '2013-10-21 00:00:01' return string(10) "10/21/2013"

 

so this sql code should be better:

greatest(o.date_purchased, ifnull(o.last_modified, 0)) as date_last_modified

 

or need edit tep_date_short() function

 

change:

 function tep_date_short($raw_date) {
   if ( ($raw_date == '0000-00-00 00:00:00') || ($raw_date == '') ) return false;

 

to:

 function tep_date_short($raw_date) {
   if ( ($raw_date == '0000-00-00 00:00:00') || ($raw_date == '') || $raw_date == '0' ) return false;

 

 

or we should use the catalog tep_date_short function:

 

 function tep_date_short($raw_date) {
   if ( ($raw_date == '0000-00-00 00:00:00') || empty($raw_date) ) return false;

[burt]

I feel that

greatest(o.date_purchased, ifnull(o.last_modified, 0)) as date_last_modified

would be better as

coalesce(x, y) as date_last_modified

- dates can only be NULL or a date, it can't be a "0" or can it ?

[tgely]

I dont have any idea why happening this. As the test results and this forum show it can be "0". The coalesce test failed when date is "0".

[katayama]

I upgraded from 2.3.3 to 2.3.3.4 and now I receive this error when I try to log on:

 

"The webpage at http://howdoyoubrew.com/brewstore/admin/login.php?action=process has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.

 

 

Learn more about this problem.

Error code: ERR_TOO_MANY_REDIRECTS"

 

In an effort to fix this, I tried the following:

 

In the database tables "sessions" the default size of the field "sesskey" is set to varchar(32) so only the first 32 characters were being stored.

Changed it to varchar(255) to be able to store the cookie value.

Similarly in the "whos_online" table, the default size of the field "session_id" field is set to varchar(128). Also changed it to varchar(255).

 

I still have the same problem. Am I the only one with this problem?

 

 

-Teddy

[lennie_boy]

Hi guys,

I am still on vesion 2.3.3 and just added a new product. In the english language section there is no problem but in the french section I get the error -

The web page athttp://xnecobbc.cluster015.ovh.net/catalog/index.php/protections-intimes-lavable-%C3%83%C2%A9co-c-36?language=fr has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.

I have cleared the cookies but still the same error message.

Any ideas?

Thanks for any help/advice :-D

 

Kind regards

Len

[tgely]

@@lennie_boy

 

you can not use pseudo utf8 mulibyte characters in url. URLs should be on ascii standard or save encoding.