Error: Call to a member function getDefaultValueLiteral() on null

Just tried downgrading to Smart Date 3.7.2 and the same thing... Can't override (reschedule) instances.

I tried to reproduce this using Smart Date 4.0.2 using both Drupal 9.5 and 10.1. It worked fine in both cases. More detailed steps to reproduce are needed.

My setup is pretty standard... It's an attached Smart date field to a node, attached are the settings.

Anyway, I placed var_dump($field_config); inside SmartDateOverrideForm.php just before $defaults = $field_config->getDefaultValueLiteral()[0]; and it returns NULL, probably that's why I'm getting the error.

Btw in your tests did you use php 8? I'm using php 8.1.18...

I also tested on simplytest.me, there's no error when trying to override a date but they are using php 7.

Thanks.

When commenting out $defaults = $field_config->getDefaultValueLiteral()[0]; everything works as expected, the instance can be overwritten / rescheduled (of course there's an warning Undefined variable $defaults). However probably there are some side effects when doing this...

Thank you for the additional information. I'm still not able to reproduce the error, however.

One simple fix you might try would be changing:
$defaults = $field_config->getDefaultValueLiteral()[0];

To be:
$defaults = $field_config?->getDefaultValueLiteral()[0];

That should resolve the fatal error, but there's something else going on with your site. It seems as though it isn't able to properly able to retrieve the field configuration from the $rrule data.

Anyway, if the change above is helpful I could commit that change, but I'd also be interested in digging deeper as to why the field configuration isn't being retrieved.

$defaults = $field_config?->getDefaultValueLiteral()[0]; fix the error but I'm also interested to see why $rrule data can't be retrieved. Where should we start?

Thank you~

Updating the metadata.

Marking the bug report as fixed based on your feedback on the small code change. I'm still happy to continue the conversation, or if you prefer you could open a new support request.

It sounds like the problem is actually with retrieving the field configuration, or at least that's what was causing the error. If the $rrule object was empty you would have gotten a fatal error on line 87:
$instances = $rrule->getRuleInstances();

I should probably open a separate issue to either refactor this function to still work if $rrule is null, or change the function definition to not allow NULL and type-hint it to a SmartDateRule object. I'm sort of inclined to go the latter route, though it does have the potential to break more things. Maybe the prudent thing would be to do some light refactoring for now, and make a todo for the next major release to change this parameter to type-hinted and required.

Anyway, for troubleshooting your specific site, can you inspect what's in the $rrule object that gets passed in? I'm particularly interested in whether the entity_type, bundle, and field_name properties all have valid values.

One other thing I thought I should point out, based on testing your specific settings: For Smart Date, the duration values are in minutes, and "all day" is considered to be 24h less a minute, so if the intent is to force all day values, the value you should use would be 1439, and not 86400.

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