I am experiencing an issue with date when sending order emails to customers.
I am posting it here because this OC has OE installed so it can't qualify for the official "1.5.6 bugs" thread and because the language and other PHP files are indeed modified by OE.
Basically what happens is this: in the order email we have the order date.
Expected value:
(other text, logo etc.)
...
Date Added: 02/05/2014
This is what I get using "clean" OC and also when I use my Unit Tests Linux shell command line test file.
Instead, the website sends this:
Date Added: 02am31UTC_f2014Fri, 02 May 2014 07:58:38 +000005am31_38072014Fri, 02 May 2014 07:58:38 +000031
that is a completely garbled mess.
I have investigated by adding some debug stuff in the relevant PHP file:
catalog/model/checkout/order.php
under
Code: Select all
$template->data['date_added'] = date($language->get('date_format_short'), strtotime($order_info['date_added']));
I have vQMod added:
Code: Select all
$template->data['debug01'] = $order_info['date_added'];
$template->data['debug02'] = strtotime($order_info['date_added']);
$template->data['debug03'] = $language->get('date_format_short');
$template->data['debug04'] = date($language->get('date_format_short'), strtotime($order_info['date_added']));
At the bottom of the corresponding template file:
catalog/view/theme/default/template/mail/order.tpl
I have added these simple lines:
Code: Select all
<p style="margin-top: 0px; margin-bottom: 20px;"><?php echo 'Debug01: ' . $debug01; ?></p>
<p style="margin-top: 0px; margin-bottom: 20px;"><?php echo 'Debug02: ' . $debug02; ?></p>
<p style="margin-top: 0px; margin-bottom: 20px;"><?php echo 'Debug03: ' . $debug03; ?></p>
<p style="margin-top: 0px; margin-bottom: 20px;"><?php echo 'Debug04: ' . $debug04; ?></p>
Output:
Code: Select all
Debug01: 2014-05-02 07:58:38
Debug02: 1399017518
Debug03: date_format_short
Debug04: 02am31UTC_f2014Fri, 02 May 2014 07:58:38 +000005am31_38072014Fri, 02 May 2014 07:58:38 +000031
It's evident that the culprit is Debug03, that is the language does not load the 'd/m/Y' alike format mask so it just returns the verbatim 'date_format_short' string, which in turn is used by date() and the latter interprets it as mask with the resulting garbled results.
Now, this happens with English (too), so no, it's not due to a missing translation entry. I have actually looked at the language PHP files and the entry is there indeed:
Code: Select all
// Locale
$_['code'] = 'en';
$_['direction'] = 'ltr';
$_['date_format_short'] = 'd/m/Y';
too bad for some reason that stuff does not get loaded.
In Order.php line 271:
Code: Select all
// Send out order confirmation mail
$language = $this->factory->newLanguage($order_info['language_directory']);
$language->load($order_info['language_filename']);
$language->load('mail/order');
it should indeed load the base translation file (second line in the snippet) but it does not happen.
Reading the code more in detail it looks like $order_info comes from getOrder($order_id).
That function has an "else" statement:
Code: Select all
$this->load->model('localisation/language');
$language_info = $this->model_localisation_language->getLanguage($order_query->row['language_id']);
if ($language_info) {
$language_code = $language_info['code'];
$language_filename = $language_info['filename'];
$language_directory = $language_info['directory'];
} else {
$language_code = '';
$language_filename = '';
$language_directory = '';
}
For some reason it could pick the "else" branch and return an empty set of values.
Now, to get why this happens, it's a mystery. Expecially since it happens for English as well.