PHP Fatal error when adding an action and address is installed

Can you provide some more info on how to reproduce this bug? Do you use any particular action?

I'm getting the same problem:

2016/04/12 07:35:12 [error] 7099#0: *16796 FastCGI sent in stderr: "PHP message: PHP Fatal error: Call to a member function getDataType() on a non-object in /var/aegir/platforms/drupal-8.1.0-rc1/sites/mysite.com/modules/rules/src/Plugin/RulesAction/EntityCreateDeriver.php on line 99" while reading response header from upstream, client: xx.xx.xxx.xx, server: mysite.com, request: "GET /admin/config/workflow/rules/reactions/edit/test/add/rules_action HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "mysite.com", referrer: "http://mysite.com/admin/config/workflow/rules/reactions/edit/test"

I'm using nginx 1.4.6 and PHP 5.5.9. The only other Drupal modules I have installed so far are commerce and its dependencies.
I can't add any actions to my rules.

Thanks,

It seems to work if I change 'continue' to 'continue 2' at line 88:

      foreach ($base_field_definitions as $field_name => $definition) {
        if ($field_name != $bundle_key && !$definition->isRequired()) {
          continue 2;
        }

Thanks for catching this!

Could you provide a pull request? Instructions on our contribution workflow can be found here:
https://github.com/fago/rules#contributing

Hi!

https://github.com/fago/rules/pull/462

Patch attached for quickfix on active projects

The original continue statement jumps to the next foreach ($base_field_definitions as $field_name => $definition) {
All base_field_definitions will be parsed this way.
The new continue 2 statement jumps to the next foreach ($this->entityTypeManager->getDefinitions() as $entity_type_id => $entity_type) {
Now it is possible that not all base_field_definitions are parsed.
I don't know the code good enough to judge this is ok or not.

#3 line 99 has this function that throws the error.
$type = $type_definition->getDataType();
Can we add a check on $type_definition instead of continue 2?

// prevent fatal error
if (!$type_definition) {
  continue;
}
$type = $type_definition->getDataType();

A stack-trace of the error can help a lot to find out why this error occurs.

Ref: continue (php manual)

I don't think this is the right fix and failing tests prove that. There's probably some incompatibility with some commerce entities - best just debug the code when commerce is enabled to see what the real issue is.

Is this patch safe to use? I am receiving the same error in the logs.

I have the same problem. I can't action to my rules.
This is the error that I got:
PHP Fatal error: Call to a member function getDataType() on a non-object in /var/www/html/drup8t/web/modules/contrib/rules/src/Plugin/RulesAction/EntityCreateDeriver.php on line 99

@fehlin:

Commerce is also still quite developing. A check as in #13 will probably get you there, but YMMV.

Here's a patch that implements the concept mentioned in #13 against the current 8.x-3.x-dev release, for anyone who needs a quick fix now.

I'm not sure if #10 is inferior to this in any way, but it seemed like a slightly more reliable method so I wanted to give a way for people to patch it rather than having to hack the code to accomplish it.

I've started investigating this a little more to figure out what the actual problem is. So far, it seems that the $item_definition->getMainPropertyName() call for an "address" field returns value even though there is no value property listed when I call $item_definition->getPropertyDefinition.

So this seems to actually be a bug in address in which it's defining the wrong property for its main property name. Or perhaps it's supposed to have a "value" property and doesn't.

However, null is a documented possible return value for item_definition->getPropertyDefinition() and thus I think the approach in my previous patch is actually a pretty sane default to account for a possible null value.

Rather than introspecting the class, however, here's a new patch that simply checks for a null value and continues, since I think that's the only possible case that the object won't have the getDataType method we need.

Referencing https://www.drupal.org/node/2823536 which I just created in the address module's issue queue.

Here's a patch which I believe solves the problem in Rules in more of the "right" way, although it also requires the patch in the referenced Address issue above to work.

With the Address patch, address fields properly return NULL for getMainPropertyName(). That's a perfectly valid return value for a field item type. However, that return value causes an error with Rules it seems, because Rules expects there to always be a main property name.

This patch simply continues to the next loop iteration if there is no main property name, since the data type cannot reliably be determined AFAIK.

If you don't want to patch Address, then my patch in #19 is still a viable solution. However, I think this new patch is the right one to commit to Rules to support fields that don't have a main property.

The related patch in the address module has been committed, so with the dev version of address installed and my latest patch in this issue applied I think everything should be resolved.

Thank you for the patches @bmcclure

I applied the patch in #22 and the one in the address module but I'm still getting the same message
PHP Fatal error: Call to a member function getDataType() on a non-object in /modules/contrib/rules/src/Plugin/RulesAction/EntityCreateDeriver.php on line 105

@fehin: I haven't yet seen this error return with both issues patched. The latest dev version of "address" should already be patched, as well, so really only this patch is needed now as far as I know. I'm curious if anyone else is still experiencing an issue with this patch applied and the latest dev version of "address"?

@bmcclure : running latest drupal commerce install + latest dev of "address". Patched with #22, receiving same error as #25

Interesting, I still do not have this issue, but don't currently have time to investigate what might be different in my case. Perhaps in certain cases there is something more going on than what the separate Address issue fixes that I just haven't hit yet.

I'll try and get back to this ASAP if it's still an issue to see if I can update the patch.

it seems $item_definition->getMainPropertyName() fails for type commerce_price on my install.
is this an issue for the commerce module? patch #18 solved the issue.

@argogi: I bet that's the new issue here. I created an issue in the Address module to get that fixed and they merged the patch right away. I bet they'd do the same in the Commerce module.

Try this, it's just like #22 but also adds a check in for items which don't properly define their main property.

I am not currently running into this issue anymore, so I'd appreciate if anyone who still is could verify if this fixes it.

@almare It seems likely that issue is related to something in the typed_data module (I'm not too familiar with that to be honest) and the way that Rules is inspecting one or more of your fields. However, it's hard to say exactly. Do you have a full stack trace for that error message by chance?

I *think* it might be a separate issue to this one, so it might get more attention if created separately. At this point it's hard to say if it's related to Rules or to Typed Data, or an interaction between one of those modules and a particular misbehaving field type.

I ran into the error from the OP again, and the patch from #30 still worked for me to fix it.

Hi, im using the actual Commerce 2.x install with Composer and some additinal Modules.
To day i work on a Bootstrap Commerce Theme and i still work on a Commerce Distribution.
...i need help in the future...

When i ad an action to "shipment is viewing" or others i become this "Fatal Error" and my site hangs up.
Error: Call to a member function getDataType() on null in Drupal\rules\Plugin\RulesAction\EntityCreateDeriver->getDerivativeDefinitions() (line 99 of modules/rules/src/Plugin/RulesAction/EntityCreateDeriver.php).

Any idea to fix this?

@Frank - patch in #30 fixes that issue for me.

Hi skitten, thanks for your reply.

Is the patch already integrated into the current dev version?
Is the installation patch already in the current dev version?

I try to avoid the original files.

#30 is still Needs Review, but if it's working for other people, perhaps it can be marked RTBC to encourage merging it into the dev branch. For me it solves the issue and I don't believe introduces any new problems.

What is the status on this for the dev version? Is it still under review? When should we expect roll out? Thanks!

AFAIK this is good to go, but not merged into dev yet. I think ideally if a couple others test it and it works, we could mark it RTBC instead of Needs Review.

Retesting the patch in #30 as there have been significant changes to the testing set-up since that last test run in Dec 2016.

+ // Get around types which don't properly define their main property (or lack of one)
+ if (is_null($type_definition)) {
+ continue;
+ }

This hunk should not be necessary. If the main property is there, there must be a type definition. Let's drop that hunk.

Also, we should add an issue and a @todo in code referencing the issue to add support for multi-property fields for entity creation.

That workaround was added because some things don't have a main property, but still use the default main property name of "value". Address was one such module, though it's been fixed there since. I do think this is an issue with any other code which is like that, and not an issue specifically with Rules, but it's hard to know what code will have that issue, and it breaks things pretty badly when it's found.

The "right" fix is probably still #22, since I believe the only change I added in #30 was that workaround that you'd like to have removed. However #22 didn't work by itself for some users, I believe due to the above mentioned issue. That probably means those users need to figure out which modules they're using that have types with bad definitions, and report them in the appropriate queue.

Thanks to bmcclure
I was getting this error with Address and Commerce2.x installed.
#30 fixed it in my case

#30 seems to be working fine. Thanks a lot :)

Added TODO to patch from #30. Didn't modify anything else as the remark by @bmcclure in #42 made sense.

Hi shabana.navas,
The failure in your test is unrelated to the patch - it seems that the text of 'publishing status' has changed between Drupal 8.4 and 8.5. I have raised #2903101: AutocompleteTest fails at D8.4 due to changed "publishing" text, OK at D8.3 to fix this.

By the way, the todo and see comments should be lower-case and have @ in front of them, so that they are identified during scanning for documentation mark-up.

Jonathan

Fixed for smaller case @todo and @see.

Thanks Shabana.

I have now added a patch on #2903101: AutocompleteTest fails at D8.4 due to changed "publishing" text, OK at D8.3 which fixes the Rules autocomplete tests, and it runs green on 8.2, 8.3, 8.4 and 8.5. I have also created a github pull request for the change, as per the developer process. When that change gets committed then d.o. tests should pass again, and your patch can be re-tested and should pass too.

Jonathan

#30 worked for me too.

Thanks @superlolo95 - it is good to hear that the patch is working. Just to confirm, the actual fix in #30 is the same as in patch #48.

@Shabana, your patch in #48 included an unintended and unrelated change to EntityIsOfBundle.php (probably your debug) so I have removed it and uploaded a clean patch. This fix actually needs a pull request on github (as per the Rules development guide). We had a pull request https://github.com/fago/rules/pull/462 (see #5-#8) but I don't know if Facine wants to update that one, or if you would like to make a new pull request? I can make one if you do not want to.

the patch works for me. I hope it will be quickly applied on the dev version.

Is the patch included in dev now? Thanks, running Commerce.

Hi mygumbo, no this has not been committed yet. Generally, if the commit message has been formatted as per Drupal best practice then the issue thread will get an automatic comment linking to the commit. As an alternative you can look at the "view commits" link from the project front page.
Jonathan

#52 is working fine. Thanks.

Running Address 8.x-1.3, Rules 8.x-3.0-alpha3,

applied patch #52, error gone.

Confirming #52 works. Any active maintainer who will add this patch? Shell we create a pull request on GitHub? That would be simple.

#52

#52 also works for me. I hope it will be quickly applied to the dev version, because this problem makes Rules unusable with drupal commerce

#52 ok... i was about to cry

#52 it worked for me

The #52 patch worked for for this error. https://www.drupal.org/project/rules/issues/2866133#comment-12606529 and I think it is the same error.

Any plans for a new release containing this major patch?

This makes sense to add, so less stuff breaks here. Thx, committed.

Thanks that worked for me.

The patch was "authored" by me, but I just did some re-rolls and sorting things out, the real coding was done by bmcclure

Thanks for the commit. Good to see this done.