Call to a member function isPublishedState() on a non-object

Odd. I've not seen that in a very long time.

Theory: Does it matter if the node in question existed before WBM was enabled for its content type?

We are are migrating content in to the site after WBM has been enabled.

That said, if we create a new node -> save as draft it works fine. Then, If I edit that draft again, save as draft, it also works.

I suspect WBM is expecting something from our imported nodes that is not there. Such as explicitly setting the WBM state.

If that is the case, seems like we should have a default set up if WBM is turned on and no state is selected. (Probably just published, like a standard node).

Ugh. Yeah, we've run into a couple of situations where pre-WBM nodes fail in various and sundry ways. Unfortunately, I'm not sure how to globally solve that problem, and simply tossing ever-more if statements around is not a solution either.

We need to get someone from Entity API who knows how to handle this situation. The root issue, I think, is that the moderation_state field is only added to an entity after it's been saved once post-WBM. That means if an entity exists pre-WBM, it will be missing that field and therefore break in odd ways whenever we try to access that field (as is the case here). We need some way to add a default moderation_state field to entities on load if they're missing, I think, but I don't know if Entity API has a mechanism for that.

I'll see if I can get some backup.

OK, after some discussion in IRC, this is what I came up with. (It's also in a branch by the same name.)

I'm not 100% on the selected default, but it's the only default value that I can reliably access. It may not always be appropriate, but it seems to avoid fatals for me.

Feedback/testing welcome.

I tested this patch out and I am getting the same issue with our migrate of nodes.

Fatal error: Call to a member function isPublishedState() on a non-object in /modules/contrib/workbench_moderation/src/EntityOperations.php on line 193

Well that's frustrating... Why is it happening in Migration, but not elsewhere? Bcwald, can you post a full backtrace from the the error message?

@Crell,

I may not be having that issue now, I went to turn on xdebug on to get trace and It seems to not be happening. I am doing more testing to confirm.

Is this how you are testing?

1) Start with basic page with no WBM.
2) Create a basic page
3) go to basic page content type and turn on WBM
4) go to edit that node you created before turning it on and try to save.

Essentially, yes. (I was using Article, same diff.) That's also what's encoded into the test changes in the patch above.

It doesn't imply anything for Migrate; in theory it should cover any time an entity is loaded, but...

Crell -- I must have had something cached somehow, I just redid the test and I no longer get those errors.

Hook cache, perhaps. The fix adds a new hook implementation, so that requires a hard cache-clear.

I'll leave this for another day or two in case someone wants to review the code before I commit it. :-)

No, that feels related since it's a case of $entity->moderation_state->entity still being null, which shouldn't be possible anymore with this patch. Damn. I will keep investigating.

Brant, can you provide a beefed up test with multi-lingual to replicate the issue? Or instructions for how I can do so manually?

I am able to replicate this issue as well. The easiest way to test this:

Basically same process as before but with translated node:

1) Start with basic page with no WBM.
2) Create a basic page
3) Translate the basic page
3) go to basic page content type and turn on WBM
4) go to edit the translated node and save.

@Crell, It seems like that field is unique for each node variant so the other translated versions are still not set.

Somewhat unrelated, but what happens if you want different states for each language? I.E. English is in needs review but Spanish is still in draft?

Since each translation is, I think, stored as its own revision id, each translation has its own independent workflow logic. I think. :-) (Translations are turning out to be much more annoying to develop around than was previously promised...)

After much wailing and gnashing of teeth against Entity API, let's try this. (HT to dawhener for helping me figure out the magic incantations for Entity API.)

The error log for that test looks highly spurious to me, as it's complaining about the PDO interface. Ignore that for now. Test the rest of it. :-)

This doesn't seem to break anything new and I THINK solves the issues here, so I went ahead and merged it in preparation for beta2. If more problems of this type come up, please file a new issue. Thanks all!

(I also gave some commit love to dawhener for helping me figure out what to actually, um, do here.)