Problem/Motivation

The view /admin/content/files shows me an incorrect file count.

- Drupal core 8.3.3
- It also exists in Drupal core 11.0.0

The issue is being addressed by preparing translations for each language, changing the translation from 1 to @count.
However, it appears more appropriate to change the original string from a fixed 1 to @count as well.

Steps to reproduce

  • Install Drupal. Specify a language with plurals determined by 1 or more [plural=(n>1)].
    • Ensure the language is specified in the po file description with plural=(n>1).
  • After installation, attach and save an image in the article content.
  • Remove the image from the previously created article content and delete any revisions where the image existed.
  • When viewing /admin/content/files, the translation text equivalent to the singular "1 place" is displayed for "Used in".
    • In languages treating 0 as singular, "1 place" is displayed instead of 0, which is unintended.

Proposed resolution

Change the view settings for the file list that is optionally created during installation.

To display the correct number of files in the file list, change the value of the singular form field from "1 place" to "@count place".

This change is useful in languages where the singular form is not limited to 1.

Remaining tasks

NA

User interface changes

NA

API changes

NA

Data model changes

NA

Release notes snippet

NA

CommentFileSizeAuthor
#13 sc.jpg15.99 KBThithi32
#11 plural_format.png10.75 KBhandkerchief
#8 installed_modules_2887988.txt11.17 KBgeorob
file_managed_db.png67.15 KBhandkerchief
file_usage_db.png39.35 KBhandkerchief
file_usage.png15.43 KBhandkerchief
file_overview.png33 KBhandkerchief

Issue fork drupal-2887988

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

handkerchief created an issue. See original summary.

cilefen’s picture

cilefen commented
Related issues: +#2821423: Dealing with unexpected file deletion due to incorrect file usage
handkerchief’s picture

handkerchief
Primary language German
Location Chur, Switzerland
commented
Priority: Normal » Major
cilefen’s picture

cilefen commented

Is this issue is unique among the issue family I linked above it needs a new title.

georob’s picture

georob commented
Issue tags: +TCDrupal 2017

Doing major issue triage w/ others at TCDrupal Camp Sprint. Aiming to reproduce this issue.

cilefen’s picture

cilefen commented

Please check if this is duplicating the linked issue or one of the linked issue's child issues. Thanks!

georob’s picture

georob commented

I went down a different path trying to reproduce. Looking now at potential duplicates of subsequent issues I found.

georob’s picture

georob commented
Issue tags: +Needs steps to reproduce
StatusFileSize
new installed_modules_2887988.txt11.17 KB

I tried to reproduce this issue on 8.3.4.
After @cliefen's suggestion in #6, I went and perused the issue queues and did not find any duplicates in the related issue. Looking further, to rule out a contrib module issue, I found this issue on Entity embed. They are using a core editor function to control file usage tracking. So, my steps to reproduce what should be 2 separate and or related issues.

Environment:

Acquia Dev Desktop version: 2
PHP: 5.5.38
Core: 8.3.4
OS: Mac 10.11.5
Modules: see installed_modules_2887988.txt (created with Drush pm-list > installed_modules_2887988.txt)

Steps taken to (not) reproduce:

  1. Install Drupal 8.3.4 core.
  2. Install File Browser and dependencies, and recommended module (for embedding in text editor) CTools
  3. Add image file embed button to Basic HTML format (this does not render the file)
  4. Create new article node, upload image file using file browser embed button on the body.
  5. Switch to source, html data embed is present.
  6. Save node. Image was not rendered, but subsequent edit and source view shows html generated by embed tool set is still present.
  7. View /admin/content/files, file is tracked here (claims in 2 places due to a revision.)
  8. View /admin/content/files/usage/{fid}, image is used by node.
  9. Edit the node with the file, delete the embed code from the source.
  10. Save the node.
  11. Clear cache.
  12. View /admin/content/files, file is tracked here (claims in 2 places.)
  13. View /admin/content/files/usage/{fid}, image is used by node.

This is 1 path of "deletion" aka erasing the embed code. A subsequent step series of more direct action:

  1. Delete the node from the last set of steps.
  2. View /admin/content/files, file is still tracked here (claims in 2 places.)
  3. View /admin/content/files/usage/{fid}, image is recorded as used by node.
  4. Node title is not present in the step above.

I was not able to exactly reproduce the issue, but following what I believe to be a similar path, this was my result. Marking this as Need steps to reproduce.

handkerchief’s picture

handkerchief
Primary language German
Location Chur, Switzerland
commented

Ok I have also tested it with a brandnew drupal core instance (8.3.4) with the help of simpytest and I had install Media Entity (8.x-1.6) and Media Entity Image (8.x-1.2) and it works as designed. So I do not mention all the details now.

So i tested it with my real project drupal instance (also 8.3.4) from my first post in this issue. My new files changes correctly the file status after creating/deleting the entity. BUT what's not working is the fact, that the Files Overview (/admin/content/files) shows the wrong number in the column USED IN. Although the media entity was deleted and the files status was changed correcty to temporary, the USED IN column shows me always minimum "1 place". But if i click on the "1 place" link (/admin/content/files/usage/{fid}) the view is empty and that's correct.

So the problem is now, a wrong USED IN number on /admin/content/files. What can that be?
I have imported a fresh files view (from the working simplytest instance) but nothing changed.

handkerchief’s picture

handkerchief
Primary language German
Location Chur, Switzerland
commented

anyone? It's a really strange effect, but what's the problem?

handkerchief’s picture

handkerchief
Primary language German
Location Chur, Switzerland
commented
StatusFileSize
new plural_format.png10.75 KB

Update: If I uncheck the format plural checkbox in the file usage field configuration (view), the count of the field "file usage" is displayed correctly in the file overview view.

Format Plural

So if this field is checked, the view use the singular form for 0 and also for 1 file usage.

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Closed (duplicate)

Thank you for reporting!

This is basically another duplicate of #2821423: Dealing with unexpected file deletion due to incorrect file usage

Thithi32’s picture

Thithi32 commented
StatusFileSize
new sc.jpg15.99 KB

As @handkerchief suggested, there's a small problem in default views. Just change the singular field from '1 place' to '@count place'

Singular field screenshot

brightbold’s picture

brightbold
she/her
Primary language English
Location Boston, MA
commented

Thanks @Thithi32. Your workaround in #13 does indeed solve this problem.

dunebl’s picture

dunebl
Primary language French
commented

I confirm #13 is the tip, patch needed

pbouchereau’s picture

pbouchereau commented
Title: File usage is incorrect » Translation of file count is incorrect
Priority: Major » Normal
Issue summary: View changes
Status: Closed (duplicate) » Active

This is not a duplicate of #2821423: Dealing with unexpected file deletion due to incorrect file usage

The file usage count itself is correct, it's just the number displayed that isn't.
As mentioned above, it could be fixed by using the "@count" token instead of "1" for singular in the "format plural" part of the "count" field's configuration in the "files" view.

This is due to the fact that unlike English, some languages (including French) don't consider 0 as plural.
So when viewing the files list in english, the plural version with the "@count" placeholder is applied to display the correct count for unused files ("0 places"). But when viewing the same list in french the singular version is applied and shows "1 place" for files that are actually not used.

This could confuse people and make them think that a "ghost" usage prevents a file to be deleted if they're not aware of the change in : Files that have no remaining usages are no longer deleted by default.
But this issue actually has no effect on the files deletion process.

pbouchereau’s picture

pbouchereau commented
Version: 8.3.x-dev » 9.4.x-dev

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

kazuko.murata made their first commit to this issue’s fork.

kazuko.murata opened merge request !6803

kazuko.murata’s picture

kazuko.murata commented
Status: Active » Needs review

Hello.

I agree with the comment in #16. I always modify the configuration of the 'count' field in Views settings after installing Drupal and use it.

I propose the fix through https://git.drupalcode.org/project/drupal/-/merge_requests/6803

I would appreciate it if someone could review it. Thank you.

smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work
Issue tags: +Needs issue summary update, +Needs Review Queue Initiative

Leaving needs step to reproduce as those should be in the issue summary.

But noticed issue summary isn't using standard issue template with the correct sections so tagging for that.

Thanks.

kazuko.murata’s picture

kazuko.murata commented
Issue summary: View changes
kazuko.murata’s picture

kazuko.murata commented
Status: Needs work » Needs review

I've revised the summary. If you come across any typos or unclear descriptions, I'd be grateful if you could make the necessary corrections. Thanks to anyone who takes the time to review it.

smustgrave’s picture

smustgrave commented
Issue summary: View changes
Status: Needs review » Needs work
Issue tags: -Needs steps to reproduce

Thanks, leaving the summary tag though for the missing sections. I added them to hopefully help.

Also ran the test-only job https://git.drupalcode.org/issue/drupal-2887988/-/jobs/920335 and it did fail to show coverage.

Issue summary mentions D8 but assume this is a D10 problem too.

Looks close.

kazuko.murata’s picture

kazuko.murata commented

@smustgrave Thank you for your review.

I understand that the job has failed.

This modification is a site configuration change, so ConfigTranslationUiTest.php and views.view.files.yml must be modified simultaneously.

I think it's natural for the test to fail as a result of Reverting non test changes.

What would be the best course of action? I would appreciate any guidance.

kazuko.murata’s picture

kazuko.murata commented
Status: Needs work » Needs review
smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work

Test only job on a bug should fail that’s fine.

But issue summary is still incomplete

kazuko.murata’s picture

kazuko.murata commented
Issue summary: View changes
Status: Needs work » Needs review

The summary has been updated to state that it also occurs in Drupal core 11.0.0.
I would be happy if anyone could review it again.

smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work

Summary still says proposed solution is TBD

kazuko.murata’s picture

kazuko.murata commented
Issue summary: View changes
kazuko.murata’s picture

kazuko.murata commented
Status: Needs work » Needs review

Summary has been updated.

smustgrave’s picture

smustgrave commented
Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs issue summary update

Thanks, believe this good to go.

  • catch committed 503b3972 on 10.4.x 
    Issue #2887988 by kazuko.murata, handkerchief, georob, Thithi32,...

  • catch committed 8a74cf61 on 11.x 
    Issue #2887988 by kazuko.murata, handkerchief, georob, Thithi32,...
catch’s picture

catch
he/him
Primary language English
commented
Version: 11.x-dev » 10.4.x-dev
Status: Reviewed & tested by the community » Fixed

Committed/pushed to 11.x and cherry-picked back to 10.4.x, thanks!

catch closed merge request !6803

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.