Problem/Motivation
There are several existing issues related to this error during installation:
PHP Fatal error: Call to a member function hasTranslation() on null in .../docroot/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/ChangedItem.php on line 47
but I believe I have a straight forward way of reproducing it. These are the steps I took:
- Fresh site install (I was on 8.2.2) only extra module I enabled was admin_toolbar
- Edit Basic Page content type and add a File field (I added pdf to allowed extensions)
- Create a new Basic Page with a file attached and Save and publish (I chose a small pdf, but I don't believe filetype matters)
- Edit the page that was just created, then click Save and keep published. This creates a new revision which also increases the file use count to 2
- Enable multiversion
Proposed resolution
Drupal core has had file usage problems for years (ex. https://www.drupal.org/node/1239558) so I don't know if this is even a bug in multiversion, or a residual effect of existing core issues. This is a workaround I tried that is far from a good solution, but helped me feel confident that the problem was related to file fields with usage counts greater than 1:
// Get all fids of published files
$query = \Drupal::entityQuery('file')->condition('status', 1);
$result = $query->execute();
// Load all the files
$files = \Drupal::entityTypeManager()->getStorage('file')->loadMultiple(array_keys($result));
$file_usage = \Drupal::service('file.usage');
// Delete all file usages greater than 1
foreach ($files as $file) {
$list = $file_usage->listUsage($file);
if (!empty($list)) {
foreach ($list as $modname => $objtypes) {
foreach ($objtypes as $objtype => $objids) {
foreach ($objids as $objid => $count) {
if ($count > 1) {
$file_usage->delete($file, $modname, $objtype, $objid, $count - 1);
}
}
}
}
}
}
This just goes through all files and deletes any file usages with use count > 1. After running that code on my site with a lot of files (and even file_entity installed as well), I was able to get past the error. This would most likely break being able to go back to old revisions, and cause who knows what other problems, but again, was just to see if it could act as a workaround.
Remaining tasks
Would someone please verify they are able to reproduce the problem in the way that I described? Any thoughts on what the core issue may be? Better workaround or fix?
Thanks,
Mustafa
Comments
Comment #2
mabdullah2010 CreditAttribution: mabdullah2010 at Debug Academy commentedComment #3
jeqq@mabdullah2010 I think this issue is related to #2825477: ContentEntityStorageTrait uses current entity as original, which breaks things and the problem is in
$entity->original
, not file usage. At least for me, deleting file usages for revisions doesn't look like a solution.Comment #4
mabdullah2010 CreditAttribution: mabdullah2010 at Debug Academy commented@jeqq You're correct about the problem ultimately being due to
$entity->original
being null. In my specific situation, deleting the file usage count avoids this problem from occurring, but yes, it is definitely not a solution. I was just stating that in case it helped to track down the exact cause. I think, like you said, that it is another version of the issue you posted. Thanks.Comment #5
weynhamzSpent couple of hours on this issue, clearly it is in core, as can be seen from the call stack.
@jeqq, I have tried and tested you patches on the multiversion's override store class, but the problem facing is no-relevant to that part of code.
Comment #6
jeqqComment #7
vdenis CreditAttribution: vdenis at Agiledrop - Your Trusted Drupal Teammates commentedReopened this issue because I get a similar problem.