Problem/Motivation

If you load a file entity through entity manager $file->status is of "FieldItemList" type.
The condition in "_editor_record_file_usage" function is :

     if ($file->status !== FILE_STATUS_PERMANENT) 

As type of FILE_STATUS_PERMANENT is "int" we have a wrong assumption that file is not permanent.
Field values should be accessed as $entity->field_name->value

Proposed resolution

Use available API instead of status property(e.g. $file->isPermanent()).

Remaining tasks

User interface changes

N/A

API changes

Data model changes

N/A

Release notes snippet

TBC(?)

Comments

undertext created an issue. See original summary.

undertext’s picture

Version: 8.3.x-dev » 8.4.x-dev
Issue summary: View changes
undertext’s picture

Status: Active » Needs review
StatusFileSize
new642 bytes
undertext’s picture

Issue summary: View changes
berdir’s picture

Issue tags: +Needs tests

Surprised there is no existing issue about this, did you check?

As simple as the fix might be, the fact that it exists means that we need test coverage for this.

undertext’s picture

I went through issues filtered by "editor.module" component and didn't find similar issue.

Maybe this issue is unnoticed just because "file" entity is not revisionable.
In my case I use "multiversion" module which forces "file" entity to be revisionable, so i get a new file revision after each node save.
Will try to add tests shortly.

undertext’s picture

Adding test-only patch.

Status: Needs review » Needs work

The last submitted patch, 7: wrong_check_for_file_status-2923428-7-test-only.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

undertext’s picture

Updating test-only patch.

undertext’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 9: wrong_check_for_file_status-2923428-8-test-only.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

undertext’s picture

Status: Needs work » Needs review
StatusFileSize
new4.46 KB

And now the real patch with test included, this one should be success.

douggreen’s picture

The solution looks good. I also confirmed that we have no other usages of == FILE_STATUS_ or != FILE_STATUS_ in core.

douggreen’s picture

Version: 8.4.x-dev » 8.5.x-dev

bump version

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

manuel garcia’s picture

Issue tags: -Needs tests
manuel garcia’s picture

Queued #12 to be tested against 8.6.x

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andypost’s picture

StatusFileSize
new811 bytes
new4.65 KB

Fixed inline with changes in #3021833-12: Move FILE_STATUS_PERMANENT to \Drupal\file\FileInterface

Looks test should be extended to make sure that status really set

Status: Needs review » Needs work

The last submitted patch, 19: 2923428-19.patch, failed testing. View results

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

badjava’s picture

StatusFileSize
new4.65 KB

Rerolled the patch for 8.7.x.

manuel garcia’s picture

Status: Needs work » Needs review
manuel garcia’s picture

StatusFileSize
new2.19 KB
new4.7 KB

Addressing my own review here, mainly cleaning up.

+++ b/core/modules/editor/tests/src/Kernel/EditorFileUsageTest.php
@@ -60,6 +60,43 @@ protected function setUp() {
+    $file_entity_type = $this->entityManager->getDefinition('file');
...
+    $this->entityManager->clearCachedDefinitions();
...
+    $test_file_storage = $this->entityManager->getStorage('file');

Deprecated, lets use $this->entityTypeManager instead.


<code>
+++ b/core/modules/editor/tests/src/Kernel/EditorFileUsageTest.php
@@ -60,6 +60,43 @@ protected function setUp() {
+    $node = $node = Node::create([

This should be just $node = Node::create([

+++ b/core/modules/editor/tests/modules/src/TestFileStorage.php
@@ -0,0 +1,47 @@
+    return $this->saveCount[$entity->id()];

If I'm reading this class correctly, the save count for the given entity is only available if it's been saved before, so we should default to returning 0 if $this->saveCount[$entity->id()] isn't set.

The last submitted patch, 22: 2923428-20.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

manuel garcia’s picture

StatusFileSize
new927 bytes
new5.06 KB

Re #19:

Looks test should be extended to make sure that status really set

Good point @andypost, adding coverage for that here.

amateescu’s picture

Status: Needs review » Needs work
+++ b/core/modules/editor/tests/modules/editor_test.module
@@ -44,3 +44,14 @@ function editor_test_editor_info_alter(&$items) {
+function editor_test_entity_type_alter(array &$entity_types) {

I think it would be better if we would record the number of saves with a hook_ENTITY_TYPE_presave() implementation rather than using a special entity storage handler.

manuel garcia’s picture

Status: Needs work » Needs review
StatusFileSize
new4.17 KB
new3.72 KB

Good idea @amateescu - that way this implementation is a lot simpler - thanks!

Using state to keep track of the number of times a file is saved here.

Note that I went for using the file name as the array key of the state value because the file id is not yet available when it's a new file. Opened to using something else if anyone has a better idea :)

vijaycs85’s picture

Issue summary: View changes

Updating issue summary to reflect the solution proposed in the latest patch.

amateescu’s picture

Status: Needs review » Reviewed & tested by the community

This looks much better now!

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed aeefe0664b to 8.8.x and f3d837af83 to 8.7.x. Thanks!

Credited @amateescu and @douggreen for reviews.

alexpott’s picture

Version: 8.8.x-dev » 8.7.x-dev

  • alexpott committed aeefe06 on 8.8.x
    Issue #2923428 by undertext, Manuel Garcia, andypost, badjava, amateescu...

  • alexpott committed f3d837a on 8.7.x
    Issue #2923428 by undertext, Manuel Garcia, andypost, badjava, amateescu...

Status: Fixed » Closed (fixed)

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