Fatal error: Call to a member function getGranularity() on boolean in /Users/serenity/Sites/d8.local/modules/calendar/src/CalendarHelper.php on line 850

Steps to reproduce

  1. Create a view using the calendar_config_field.yml template
  2. Add a new content type
  3. Add a new field (any field)

The issue is resolved after doing a cache rebuild.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kerby70 created an issue. See original summary.

kerby70’s picture

Status: Active » Needs review
FileSize
579 bytes
kerby70’s picture

After running into another error related to the related object not existing, here is another patch to consider.

esteinborn’s picture

I was getting an error whenever I added or removed a new content type, and could only clear the error after a cache clear.

my error was this:

[Mon Aug 29 10:53:20.786644 2016] [:error] [pid 22454] [client 172.20.6.62:62045] PHP Fatal error: Call to a member function getGranularity() on boolean in /var/www/html/modules/calendar/src/CalendarHelper.php on line 853

The patch in #3 fixed this issue for me.

Thanks for the patch.

natanaugusto’s picture

Status: Needs review » Reviewed & tested by the community
paddy.doyle’s picture

The patch in #3 fixed this issue for me too. Thanks!

Anonymous’s picture

So it seems like you are missing an argument plugin, but I'm not able to reproduce this with the usage of the suggested views template.

Could you specify what the exact steps to reproduce this are?

paddy.doyle’s picture

For what it's worth, the latest 8.x-1.x-dev (2016-11-26) exhibits the bug again (the patch in #3 above wasn't applied I guess).

The bug is intermittent; as a guess it might occur after creating an instance of a new content type, but am not sure. Without applying the patch, doing a drush cache-rebuild fixes the problem temporarily; but it does eventually occur again.

bobemoe’s picture

Confirming this issue with the latest 8.x-dev as of today. I haven't applied any patches.

It seems quite repeatable to me, its appears to be after adding a new content type, however I think its actually after adding a new field to an existing content type; just adding a new empty content type (with default body field) doesn't trigger the bug, returning to the content type and adding an additional field then triggers the bug. Even non date related fields on unused content types seem to trigger it.

Clearing the cache always fixes the problem.

geertvd’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs review
FileSize
1.92 KB

So I was able to reproduce this issue after doing the steps to reproduce mentioned in #9.

The patch in #3 just masks the real issue though, that the argument is missing. Let's try to figure out why that happens.

After some debugging I noticed that the only argument handler which seems to be broken is the week argument handler (which is also the only one we are providing).
Looking at the hook_field_views_data_alter in calendar.views.inc we can actually see that is is incorrectly prefixed with calendar_datetime.
Fixing the hook prefix fixed the issue for me, I guess the incorrect hook was only being called after a cache rebuild and not after a field was added, which resulted in the missing argument handler.
Besides the prefix fix I did some minor changes in the custom views argument handers to improve readability and fix some coding standards.

bobemoe’s picture

I've applied the patch from #10 and done a quick test (added a field) and it appears to have fixed the issue.

I will report back if I find the error occurs again. Thanks.

AlejandroSalinas9294’s picture

Can confirm #10 fix the issue for me.

  • pjonckiere committed 533e6cc on 8.x-1.x authored by geertvd
    Issue #2785771 by kerby70, geertvd, paddy.doyle, bobemoe, esteinborn,...
Anonymous’s picture

Status: Needs review » Fixed

Looks good to me. Great catch.

Pushed to 8.x-1.x. Thanks all!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.