Move DateObject class to an separate file

If you look at the docs for drupal_load() it only loads the main file for that item - it doesn't load the full module's dependencies, include files or anything else. So this is by design. It might be cleaner to move the manual require_once() to after the drupal_load() and to document the issue there, so others will know why it's written this way.

Ultimately yes I'd like to include this change, a reroll would be appreciated. Thank you.

Rerolled for 3.x. Please review and test.

Fix tests.

require_once './' . drupal_get_path('module', 'date_api') . '/includes/DateObject.php';

I don't know why it can't open the file... anybody know what's wrong?

Your patches are missing the new file.

D'oh. I added the file.

Thanks!

I forgot about this quirk, but after updating I get

Error: Class 'DateObject' not found in date_views_filter_handler_simple->op_simple() (line 219 of /var/www/dcc-staging/sites/all/modules/contrib/date/date_views/includes/date_views_filter_handler_simple.inc).

A cache clear (in an update hook) is required to fix the issue.

Did you not clear the caches after updating the site to alpha2? I can just update the release notes and leave it at that, it's just an alpha release so that's sufficient for now imho.

Mmk.

Thanks for being through, I do appreciate it.

I have no idea what caused it, but when I merged alpha2 into my project, I received this error:

Error: Call to undefined function date_make_iso_valid() in DateObject->__construct() (line 130 of /var/www/html/sites/all/modules/contrib/date/date_api/includes/DateObject.

However, clearing cache and registry rebuild had already been performed. The error also only happened for me in a non-private browsing window on my current device. I had to clear my browser's cache to fix it.

I doubt there's anything that needs to be done in code. I just wanted to post this here in case someone else has the same issue. I only had it for one branch, too. I had tested it successfully in dev/staging, so there's no way I can reproduce it.

Thanks for the extra details. That is weird. I've ran into occasional problems with what appears to be the nfs connection in ddev not quite working correctly and an old file getting "stuck", it didn't fix itself until I restarted ddev.

I found a way to reproduce the error reliably. Once I view a certain page, the entire site becomes unviewable (for only me) until I clear my browser's cache.

I'm going to reopen this issue and begin posting debug information I discover.

Note that this error is different than the other one I shared above, but this is the one that is showing and reproduceable.

Fatal error: Uncaught Error: Call to undefined function date_limit_format() in /var/www/html/sites/all/modules/contrib/date/date_api/includes/DateObject.php on line 271

1	31.3130	3267656	_drupal_shutdown_function( )	.../bootstrap.inc:0
2	31.3131	3267576	session_write_close( )	.../bootstrap.inc:3856
3	31.3131	3267896	DateObject->__sleep( )	.../bootstrap.inc:3856
4	32.8765	3267896	DateObject->format( $format = 'c', $force = ??? )  # $force is FALSE here

I also get this (This is due to a bootstrap error, I realized):

Error: Call to undefined function menu_get_object() in /var/www/html/includes/theme.inc on line 2619

Basically, I get ONE view of the page in question, and after I view it once, viewing any page on the site will throw the above fatal errors. The page in question is a view. My guess is that something gets saved to the session, (I saw stuff about views filters, I think, perhaps remembering which ones are selected?), and once that happens, it cannot be unserialized when loading the session?

Is it possible that the DateObject class is not properly (un)serializable?

Relevant code:

  /**
   * Prepares the object during serialization.
   *
   * We are extending a core class and core classes cannot be serialized.
   *
   * @return array
   *   Returns an array with the names of the variables that were serialized.
   *
   * @see http://bugs.php.net/41334
   * @see http://bugs.php.net/39821
   */
  public function __sleep() {
    $this->serializedTime = $this->format('c');
    $this->serializedTimezone = $this->getTimezone()->getName();
    return array('serializedTime', 'serializedTimezone');
  }

...

  #[\ReturnTypeWillChange]
  public function format($format, $force = FALSE) {
    return parent::format($force ? $format : date_limit_format($format, $this->granularity));
  }

I placed a breakpoint earlier, and I confirmed my suspicions, as the root exception being thrown is:

"Invalid serialization data for DateTime object"

I tried removing the serialization code from DateObject, and I no longer experience the problem. The code itself says this:

   * We are extending a core class and core classes cannot be serialized.
   ...
   * @see http://bugs.php.net/41334
   * @see http://bugs.php.net/39821

But looking at the linked PHP bugs, built-in PHP objects are serializable as of PHP 5.3. Since we don't need to support < PHP 5.3, I'm going to recommend that we remove this code and use the native serialization. I'll create a separate issue and link it here.

#3309290: Invalid serialization data for DateTime object; Remove support for PHP < 5.3