🇦🇷Argentina @ibonelli

We discussed this in #bugsmash and we feel the problem is no longer there for 10.x & 11.x. We can not reproduce and it seems the usage count discrepancy is not related to the language system, but to the use of two different entities.

If we put this together with the new core initiative #3364744 reliable entity-usage system to core 🌱 Add a reliable entity-usage system to core Active (thanks @Lendude for sharing this with me!) we should probably close this issue in favor of the new initiative. As described the issue is no longer there.

Today I followed a hunch I had. Instead of doing the code deep dive, I tried something new. Still using Unami I added a new field_image to the content type. Reasoning being, the field in Unami is a field_media_image entity and maybe the file it is being used 2 times: One by the node entity, and one by the media entity. I did try to debug that, but I will need to go a bit deeper to get to the bottom of that.

In any case the testing was "successful". I do get 1 use for the file as a field_image and 2 uses for the field_media_image:

My impression is that this is not a bug, but a working as design. And that the increase of use with the different languages is not the problem, but the increase of use with the field_media_image. But this is probably not a problem, but the result of the description above (1 use by the node entity and 1 use by the media entity). As I described before, adding languages doesn't change the usage. I couldn't reproduce on a fresh install with a field_image. I can only see the problem with Unami, which uses the field_media_image.

I run the test in Unami, this time with debugging.

First thing I noticed is the use of field_media_image in Unami, instead of the use of field_image in the basic install. So even though in both situations we are adding an image, in one case is a field and in the other an entity. I get the impression this is at least part of the reason why the issue doesn't express on a clean installation.

And when adding an article I got the aforementioned issue: I get 2 uses for the image. But, this time I realized that I do not need to add a translation. As soon as I add the article (and without even saving it) I already see the file in the system being used twice. This happens because before saving the article node, I save the field_media_image. As soon as it gets saved, it already says it is used 2 times. And when I saved the article node, the usage remains the same (2 times).

While debugging the add of the image to the field_media_image entity, I realized that the code mentioned on my last post gets called twice. Even though it has a for() statement within it, that only does one iteration each time. But the method postSave() gets called two times.

I my head next step is to debug why it gets called twice. As soon as I'm able I'll get on with that and report what I find.

There is definitely something strange on this one. I tried one more time with a fresh install (no Unami SI). Tried all I could think of to reproduce, checked before adding the languages, nothing. I could not reproduce on a fresh install.

Even though I came empty handed, this time I took the opportunity of debugging the internals. As far as I can tell the code resposible of this is core/modules/file/src/Plugin/Field/FieldType/FileFieldItemList.php. The two parts I could identified as involved are:

from line 21:

public function postSave($update) {
  $entity = $this->getEntity();

  if (!$update) {
    // Add a new usage for newly uploaded files.
    foreach ($this->referencedEntities() as $file) {
      \Drupal::service('file.usage')->add($file, 'file', $entity->getEntityTypeId(), $entity->id());
    }
  }

And then at line 40:

// On new revisions, all files are considered to be a new usage and no
// deletion of previous file usages are necessary.
if (!empty($entity->original) && $entity->getRevisionId() != $entity->original->getRevisionId()) {
  foreach ($files as $file) {
    \Drupal::service('file.usage')->add($file, 'file', $entity->getEntityTypeId(), $entity->id());
  }
  return;
}

To me next step would be to test this again with Unami and debug it as I did it this time. There is something else going on in Unami which triggers the bug.

I've been working on this today and I can confirm the problem. Even though I was able to run the test, they have an strange error which doesn't seem related to the particular problem.

I thought of an experiment to see if the amount of languages had anything to do with the problem, but that does not seem to be the case. With 3 languages in the system (EN+ES+IT) I got a 2 usage instead of one for my article, and with 4 (EN+ES+IT+PT) I got the same (new article). So the 2 doesn't seem to be related to the amount of languages. Deleted and got back to 2 languages (EN+ES) and I still got a 2 usage count. The odd thing is that removing spanish and leaving only 1 language (EN) did not change the behavior, I still get a 2 usage count when I create a new article and add a picture to it.

I guess the next step is some debugging to find where it is being added. But it is quite straight forward to test/debug in a local Unami install. Maybe even trying disabling the language and the translation modules (which doesn't seem that straight forward for Unami as it is a site install).

Working on this during DrupalCon 2023 Pittsburgh.

Just to be sure I tried to reproduce the problem, instructions on comment #10 were very helpful. I created a local environment with Docksal running PHP 8.1.8 and Drupal 9.5.9.

I wasn't able to get the error myself. Tried a bit more than just changing the theme to seven, but couldn't either. Even made sure I was going through the code/function sort() by adding some logging. I see the logged message, but not the error mentioned.

My take would be similar to what I see in comment #13, I get the impression the problem is more being empty than anything else. In any case the patch seems to be harmful, small and to the point. Even follows a similar tactic which is used for weight. But I'm not sure if it is really needed and for what I know from the community we don't like to push stuff if it is 100% needed (which doesn't seem the case).

I will be working on this during DrupalCon 2023 Pittsburgh.

I'm working on this during DrupalCon.