On revisioned panelized pages, we're seeing the following error when attempting to create a new draft revision for a published page:

Error: Call to a member function hasTranslation() on boolean in Drupal\conflict\Entity\ContentEntityConflictHandler->entityFormEntityBuilder() (line 201 of modules/contrib/conflict/src/Entity/ContentEntityConflictHandler.php).

It appears that it is possible for some entities to not have a concept of an original entity.

The attached patch "fixes" the issue, but may not be the correct resolution to the problem.

CommentFileSizeAuthor
#2 3013694-2-original-entity-false.patch952 bytesjeremylichtman

Issue fork conflict-3013694

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

jeremylichtman created an issue. See original summary.

jeremylichtman’s picture

jeremylichtman commented
StatusFileSize
new 3013694-2-original-entity-false.patch952 bytes
hchonov’s picture

hchonov
Primary language Bulgarian
Location Burgas
commented

The original entity should be always there, as it is appended in conflict_entity_load(). You should check why it is being removed.

However there is something strange in your error. If for some reason the property has been removed, then the message would be stating, that you are trying to access a method on "null", but in your case it is "boolean".

Example for accessing a method on non existing property:

>>> entity_load("node", 1)->non_existent_property->hasTranslationChanges();
PHP Error:  Call to a member function hasTranslationChanges() on null
hchonov’s picture

hchonov
Primary language Bulgarian
Location Burgas
commented
Status: Active » Postponed (maintainer needs more info)

Martijn Houtman made their first commit to this issue’s fork.

joel_osc’s picture

joel_osc commented

If anyone else runs into this, I have a bit more information from our occurrence:

  1. It happened when editing and saving a user, panelization was not a factor;
  2. A dpm at the very top of conflict_entity_load never displayed on user//edit, which means the hook was not being fired
  3. Clearing caches made the hook fire again, the dpm showed whenever you hit user//edit and we could once again save users.

Likely not a bug with conflict, but I am thinking there is a bug in the calling code somewhere. With the problem no longer occurring I cannot investigate any further.