Date formatting crashing?

Omeka Classic Troubleshooting
1

I’m grasping at straws here, sorry… I have an Omeka 2.2 site. I relocated it to another hosting provider. We only use the admin side - no public access/items. It seems to run OK (searches work, etc.) but for some reason it is crashing (silently) whenever Omeka needs to format a date.

So, for example, if I get list of items, the first row is generated up until the date added td element, which just crashes in mid-air. Same with viewing an item. Everything works right up until the citation, which never shows.

No errors. No error logging that I can find. I have Omeka in develop mode.

It works dandy on the “old” system, just not on this new one. So far, I haven’t found any other aspect of the system that is misbehaving. I noted that the locale.name was set to null in the config.ini. I set it to “en_US” just to be sure.

Suggestions on how to get more error logging activated would be welcome! Strangest thing I’ve ever seen! New site is running PHP 5.6. (Not sure what the old was using, but can check.)

Thank you for any assistance.

  • dave
2

Can you share the information from your system profile page? (the link’s in the footer of every admin page, next to the version statement)

3

User
Browser Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36
Role super

System
Omeka 2.2
PHP 5.6.27 (cgi-fcgi)
OS Linux 3.10.0-427.18.2.lve1.4.24.el7.x86_64 x86_64
MySQL Server 5.6.33
MySQL Client mysqlnd 5.0.11-dev - 20120503 - $Id: 76b08b24596e12d4553bd41fc93cccd5bac2fe7a $

PHP Extensions
Regular bcmath, bz2, calendar, cgi-fcgi, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, hash, htscanner, iconv, imap, intl, ionCube Loader, json, libxml, mbstring, mcrypt, mhash, mysql, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, pspell, Reflection, session, SimpleXML, soap, sockets, SPL, sqlite3, standard, tidy, tokenizer, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib
Zend the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured)

Plugins
CsvImport 2.0.2
Dropbox 0.7.2
ExhibitBuilder 3.1 (inactive)
SimplePages 3.0

Themes
Berlin 2.2
Seasons 2.2 (current)
Thanks, Roy

4

Have you checked “View Source” to make sure that nothing at all is being emitted when the page dies in the middle like that? Depending on where the error occurs, it can be printed on the page but just not be visible due to the surrounding markup.

Additionally, have you checked the PHP log for errors (not the Omeka log, but where PHP itself logs errors)?

If you don’t get anything from either of those, that probably means this is a class of error that’s actually quite difficult to retrieve on older versions of Omeka (in fact even up to the current version, though Omeka 2.5 will make things much easier). The only way to get at them is to make changes to the bootstrap.php file.

5

I inspected the generated HTML for an item list and it literally has a

for the the date column and that’s the end of the HTTP response. I’ve looked for error.log files in various places and, so far, haven’t found any with new information.

I’ll look at the bootstrap.php file…

Thank you.

6

It is definitely the format_date function crashing. When I remove that function from the item list (and just show the date), it works fine.

Now to find where this format_date thing lives…

7

Zend_Date references seem to be toxic. Not sure why yet.
Changed format_date to just return the input date and it works. References to things like Zend_Date::DATE_MEDIUM cause it to crash. I assume it’s nestled in a try block or something that is catching/hiding the exception. Maybe I’ll add my own inside of format_date…

8

Since it’s killing the page, it pretty much has to be a PHP error or an uncaught exception, as a caught one would let execution continue.

If just referencing the class is causing the error, then I think this is the kind of error I alluded to above that’s hard to get at: it’s an error that occurs when the file is loaded, and those errors get hidden by the autoloader.

Here’s what you can try:

  1. Comment out the line $autoloader->suppressNotFoundWarnings(true); in bootstrap.php
  2. Under that line add a call to ob_start();

This will result in a fair amount of warnings and notices being printed, but if you just look for the last one, the one that kills the page, it should be there.

9

Found it! Somehow (I don’t think I’ve seen this in a long time) the FTP upload of the sources to the new site corrupted Zend/Date.php — I have no idea how it even loads without tossing a major error. I uploaded the file again and all is well.

Sorry for all the fuss. Looking forward to better debugging tools in the future… this one was very well masked.

Thank you again for all the help.

10

I found it using a fatal error hander:

function __fatalHandler()
{
    $error = error_get_last();
//check if it's a core/fatal error, otherwise it's a normal shutdown
    if ($error !== NULL && in_array($error['type'], array(E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING))) {
        echo "<pre>fatal error:\n";
        print_r($error);
        echo "</pre>";
        die;
    }
}

register_shutdown_function('__fatalHandler');

It said that the Zend_Date class was essentially undefined. From there I modified bootstrap.php to explicitly load it, and voila - an error message! Your solution would be more elegant.