PHP Fatal error: Call to a member function getTransitionsBySidTargetSid() on boolean in /workflow/includes/Entity/WorkflowTransition.php on line 207"

Is this with a scheduled transition?
Do you use Workflow_node or Workflow_field?

Hmm, would you be able to try it again with latest dev-version and workflow_field?

If not, please close the issue. I cannot reproduce it.

I'm using workflow field and I got this error when attempting to make a change to content with a non-scheduled workflow field. I don't see anything related to cron with this error, though.

I have experienced this error as well when doing a programmatic update of a node with a workflow field. In our situation it is caused by a a scheduled unpublication of the node using Scheduler.

Here workflowfield_field_update() is called with an empty $items argument. As there is no sid present to transition to Workflow tries to determine the first state. If this happens during cron there is no user present and consequently no permissions to access the creation state and 0 is returned.

This value is passed through the code until the WorkflowTransition class tries to get the workflow based on the new sid. null is returned and the fatal error occurs.

There seems to be multiple ways to go about fixing this. Here is one approach:

When getting a transition to a non-existing sate, 0 is used as the new state id. This causes a fatal error when the transition attempts to retrieve the corresponding workflow as sid 0 does not correspond to a workflow.

Use the old state id to retrieve the workflow instead. That should ensure that the workflow exists. Performing the transition will fail more elegantly later on.

Also log the state to watchdog instead of setting a message. That makes cron fail.

I tested this in 7.x-2.x and the problem is fixed there.

Here are two patches:

• An updated patch which applies the same solution as in 7.x-2.x to 7.x-2.5. This solution still yields two error messages: One standard Drupal message and one in watchdog.
• A patch to 7.x-2.x which prevents the situation from occurring entirely by ignoring field updates without $items. According to the API this should unset the field but I do not think this makes sense for workflows. It does not seem to be supported in the code anyhow.

@kasperg, since the problem is solved, in the other issue, I am going to close this issue.
Your patch would be helpful for people who experience the problem, and do not want to dus the dev version.

Normally, you'd use dev version, or wait for 2.6.

Thanks.