4

After some unreported changes made by our customer's store hosting company we are getting many errors around the magento date formatting and many admin screens breaks (sales order view, customers, index management, and others).

In the reports folder log, I get:

a:5:{i:0;s:44:"No date part in '2012-09-03 19:36:17' found.";i:1;s:6218:"#0 /public_html/sp/lib/Zend/Date.php(1078): Zend_Date->_calculate('set', '2012-09-03 19:3...', 'yyyy-MM-dd HH:m...', 'pt_BR')
#1 /public_html/sp/lib/Zend/Date.php(197): Zend_Date->set('2012-09-03 19:3...', 'yyyy-MM-dd HH:m...', 'pt_BR')
#2 /public_html/sp/app/code/core/Mage/Core/Model/Locale.php(478): Zend_Date->__construct('2012-09-03 19:3...', 'yyyy-MM-dd HH:m...', Object(Zend_Locale))
#3 /public_html/sp/app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Renderer/Datetime.php(81): Mage_Core_Model_Locale->date('2012-09-03 19:3...', 'yyyy-MM-dd HH:m...')
#4 /public_html/sp/app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column.php(128): Mage_Adminhtml_Block_Widget_Grid_Column_Renderer_Datetime->render(Object(Mage_Index_Model_Process))
#5 /public_html/sp/app/design/adminhtml/default/casadosaber/template/widget/grid.phtml(161): Mage_Adminhtml_Block_Widget_Grid_Column->getRowField(Object(Mage_Index_Model_Process))
#6 /public_html/sp/app/code/core/Mage/Core/Block/Template.php(235): include('/public_html/s...')
#7 /public_html/sp/app/code/core/Mage/Core/Block/Template.php(266): Mage_Core_Block_Template->fetchView('adminhtml/defau...')
#8 /public_html/sp/app/code/core/Mage/Core/Block/Template.php(280): Mage_Core_Block_Template->renderView()
#9 /public_html/sp/app/code/core/Mage/Adminhtml/Block/Template.php(81): Mage_Core_Block_Template->_toHtml()
#10 /public_html/sp/app/code/core/Mage/Core/Block/Abstract.php(758): Mage_Adminhtml_Block_Template->_toHtml()
#11 /public_html/sp/app/code/core/Mage/Core/Block/Abstract.php(525): Mage_Core_Block_Abstract->toHtml()
#12 /public_html/sp/app/code/core/Mage/Core/Block/Abstract.php(476): Mage_Core_Block_Abstract->_getChildHtml('grid', true)
#13 /public_html/sp/app/code/core/Mage/Adminhtml/Block/Widget/Grid/Container.php(70): Mage_Core_Block_Abstract->getChildHtml('grid')
#14 /public_html/sp/app/design/adminhtml/default/default/template/widget/grid/container.phtml(36): Mage_Adminhtml_Block_Widget_Grid_Container->getGridHtml()
#15 /public_html/sp/app/code/core/Mage/Core/Block/Template.php(235): include('/home/storage/5...')
#16 /public_html/sp/app/code/core/Mage/Core/Block/Template.php(266): Mage_Core_Block_Template->fetchView('adminhtml/defau...')
#17 /public_html/sp/app/code/core/Mage/Core/Block/Template.php(280): Mage_Core_Block_Template->renderView()
#18 /public_html/sp/app/code/core/Mage/Adminhtml/Block/Template.php(81): Mage_Core_Block_Template->_toHtml()
#19 /public_html/sp/app/code/core/Mage/Adminhtml/Block/Widget/Container.php(295): Mage_Adminhtml_Block_Template->_toHtml()
#20 /public_html/sp/app/code/core/Mage/Core/Block/Abstract.php(758): Mage_Adminhtml_Block_Widget_Container->_toHtml()
#21 /public_html/sp/app/code/core/Mage/Core/Block/Text/List.php(43): Mage_Core_Block_Abstract->toHtml()
#22 /public_html/sp/app/code/core/Mage/Core/Block/Abstract.php(758): Mage_Core_Block_Text_List->_toHtml()
#23 /public_html/sp/app/code/core/Mage/Core/Block/Abstract.php(525): Mage_Core_Block_Abstract->toHtml()
#24 /public_html/sp/app/code/core/Mage/Core/Block/Abstract.php(476): Mage_Core_Block_Abstract->_getChildHtml('content', true)
#25 /public_html/sp/app/design/adminhtml/default/default/template/page.phtml(74): Mage_Core_Block_Abstract->getChildHtml('content')
#26 /public_html/sp/app/code/core/Mage/Core/Block/Template.php(235): include('/home/storage/5...')
#27 /public_html/sp/app/code/core/Mage/Core/Block/Template.php(266): Mage_Core_Block_Template->fetchView('adminhtml/defau...')
#28 /public_html/sp/app/code/core/Mage/Core/Block/Template.php(280): Mage_Core_Block_Template->renderView()
#29 /public_html/sp/app/code/core/Mage/Adminhtml/Block/Template.php(81): Mage_Core_Block_Template->_toHtml()
#30 /public_html/sp/app/code/core/Mage/Core/Block/Abstract.php(758): Mage_Adminhtml_Block_Template->_toHtml()
#31 /public_html/sp/app/code/core/Mage/Core/Model/Layout.php(529): Mage_Core_Block_Abstract->toHtml()
#32 /public_html/sp/app/code/core/Mage/Core/Controller/Varien/Action.php(391): Mage_Core_Model_Layout->getOutput()
#33 /public_html/sp/app/code/core/Mage/Index/controllers/Adminhtml/ProcessController.php(55): Mage_Core_Controller_Varien_Action->renderLayout()
#34 /public_html/sp/app/code/core/Mage/Core/Controller/Varien/Action.php(420): Mage_Index_Adminhtml_ProcessController->listAction()
#35 /public_html/sp/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(253): Mage_Core_Controller_Varien_Action->dispatch('list')
#36 /public_html/sp/app/code/core/Mage/Core/Controller/Varien/Front.php(176): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#37 /public_html/sp/app/code/core/Mage/Core/Model/App.php(340): Mage_Core_Controller_Varien_Front->dispatch()
#38 /public_html/sp/app/Mage.php(630): Mage_Core_Model_App->run(Array)
#39 /public_html/sp/index.php(84): Mage::run('', 'store')
#40 {main}";s:3:"url";s:39:"/sp/index.php/cs_mg_admin/process/list/";s:11:"script_name";s:13:"/sp/index.php";s:4:"skin";s:5:"admin";}

In dev environment it works well, and before yesterday, when the hosting made many changes, it also works there.

We use America/Sao_Paulo as timezone, and there's no customer in customer_entity table with NULL values at created_at or updated_at, neither in sales_flat_order and sales_flat_order_grid tables.

I also tried to update the created_at attribute in eav_attribute table and other things I saw in this topic.

Can anyone help with this?

Community
  • 1
  • 1
Ricardo Martins
  • 5,702
  • 3
  • 40
  • 59
  • 1
    The server company that cannot explain what was done is a server company which should not longer be used. Are they unable to explain what happened? – benmarks Sep 03 '12 at 20:08
  • Yes. Its one of the worses hosting company in Brazil, but our customer doesn't want to change. This is the life. =] – Ricardo Martins Sep 03 '12 at 20:27

3 Answers3

7

Looking at the dump above, your exception message is

"No date part in"

If you search the Magento codebase, the only place this exception message shows up is in

#File: lib/Zend/Locale/Format.php 
$split = false;
preg_match_all('/\d+/u', $number, $splitted);

if (count($splitted[0]) == 0) {
    iconv_set_encoding('internal_encoding', $oenc);
    #require_once 'Zend/Locale/Exception.php';
    throw new Zend_Locale_Exception("No date part in '$date' found.");
}

Doing a bit of research in that function, I'm pretty sure what's happening on your server is the pcre_match_all function is failing to find any matches when it runs the following code (you can confirm this with debugging)

preg_match_all('/\d+/u', '2012-09-03 19:36:17', $splitted);

That seems illogical since there are numbers in there to be split, so what's probably happening is somehow, either via a PHP change or MySQL change, this function is receiving non-utf8 encoded text, and with the /u option the regular expression fails to parse the string correctly.

If I was consulting on this project I'd recomend confirm the above with some debugging code (try running the preg_match_all function with plain text, and then with text pulled from your database). Then I'd yell at the host and tell them to configure their applications so this didn't happen. Then, if that didn't work, I'd concentrate on how to convert all the date text in my database to a format understood by the current configuration. Good luck!

Alana Storm
  • 164,128
  • 91
  • 395
  • 599
  • Hi Alan Storm. I'm glad for receiving an answer from you (I admire you blog and some of your extensions). I guess my hosting company made a lot of modifications that I cant find where, or what config have changed. For example: I saw that if I delete the /u, I resolved the problem for this particular case. But I also saw that there are other places like truncate method on core/string helper that also uses preg_match with /u. Do you have any tip for find out what could be the configuration problem in my case? I also imported the mysql base from production and it works great here. Thanks again. – Ricardo Martins Sep 05 '12 at 17:37
  • By the way: I tried to do mb_detect_encoding with the values and both of them are in ASCII format, but in dev environment, it works. – Ricardo Martins Sep 05 '12 at 17:56
  • @RicardoMartins Sorry, no magic bullet, too many variables to debug remotely. If it were me I'd concentrate on converting the database data in production so it works with the current configuration OR play hardball with the host and make them fix it. Good luck! – Alana Storm Sep 05 '12 at 18:03
2

First at all, thanks to Alan Storm that helped to figure out the almost-real problem of it. I tried to remove the "/u" from that REG EXP, but I realized that Magento and Zend Framework uses regular expressions with /u in many places like core/string helper, and many others.

So, I made a PHP with the following code and tried to run it in both environments.

<?php
$number = '2012-08-23 22:15:48';

preg_match_all('/\d+/u', $number, $splitted);

echo "<pre>";
var_dump($splitted);
echo "</pre>";

So, at the problematic server I got a warning...

Warning: preg_match_all() [function.preg-match-all]: Compilation failed: unknown option bit(s) set at offset -1 in /.../public_html/test.php on line 4 NULL

And searching in the web, I found this (phpinfo is reporting incorrect pcre version) that in a nutshell tell us to verify the PCRE version (in phpinfo()).

SO... All of this problem is because the PCRE lib version... too old in my production environment.... that is using 6.6 06-Feb-2006 while others uses 8.xx.

Community
  • 1
  • 1
Ricardo Martins
  • 5,702
  • 3
  • 40
  • 59
0

thanks its becuase of that and its mostly when if some hosting is using secure php with suexec and I dont know that much but there is some conflict of PCRE