Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Notice: Trying to get property of non-object in Drupal\Core\Entity\RevisionableContentEntityBase->getRevisionLogMessage() (line 104 of /vagrant/app/core/lib/Drupal/Core/Entity/RevisionLogEntityTrait.php)
Proposed resolution
Return an empty string for missing log messages as per the interface:
/**
* Returns the entity revision log message.
*
* @return string
* The revision log message.
*/
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#27 | 2827701-27.patch | 770 bytes | neclimdul |
#9 | revisionlogentitytrait_getrevisionlogmessage_displays_a_notice-2827701-9.patch | 613 bytes | Robin Monks |
Comments
Comment #2
Sam152 CreditAttribution: Sam152 commentedComment #3
Anonymous (not verified) CreditAttribution: Anonymous as a volunteer commentedComment #4
Anonymous (not verified) CreditAttribution: Anonymous as a volunteer commentedComment #6
Robin Monks CreditAttribution: Robin Monks at Appnovation commentedRe-roll & update for coding standards.
Comment #7
Robin Monks CreditAttribution: Robin Monks at Appnovation commentedComment #9
Robin Monks CreditAttribution: Robin Monks at Appnovation commentedComment #10
Chi CreditAttribution: Chi commentedIf the log message consists of just one character "0" this would replace it with an empty string.
Can we use isset here?
return isset($this->revision_log_message->value) ? $this->revision_log_message->value : NULL;
Comment #11
BerdirHow exactly do you get this? THis can't happen if the *message* is empty, only if there is no field named like that. Which would mean that it is explicitly unset from the trait, which might not be a supported thing to do?
See also #2248983: Define the revision metadata base fields in the entity annotation in order for the storage to create them only in the revision table
Comment #12
Sam152 CreditAttribution: Sam152 commentedMaybe possible with a programatically created node with no explicit log message? I seemed to remember triggering it on an entity that had the field.
Comment #13
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedI think we need some proper steps to reproduce before attempting any patches here :)
Comment #24
quietone CreditAttribution: quietone at PreviousNext commented@Sam152, Thank you for reporting this problem.
Is this issue still a problem?
There has been no activity here for 5 years.
Since we need more information to move forward with this issue, I am keeping the status at Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #26
neclimdulLooking at the report, probably not but I think its come back in a different way. Not matching the interface is still causing problems.
Technically another solution would be to update the interface but... I think this solution is probably right? Does getting a null for the revision log have a useful meaning?
NW because looking at the trait, it looks nothing like the code in the patch so this definitely needs a reroll.
Comment #27
neclimdulHere's a patch. Much easier with Null coalescing. Could have been a one line patch but made it a bit longer to document what was going on.
No interdiff because the patch conflict is so old its painful to make. Summary, converted to "new" metadata to get field name and used the null coalescing to condense the return logic.
Comment #29
ameymudras CreditAttribution: ameymudras at Salsa Digital commentedMay be we can reduce this to:
Comment #30
neclimdulBecause it makes the line very long and the documentation less clear.