Allow creation of temporary files when using file_save_data function by adding the $status parameter. Will default to FILE_STATUS_PERMANENT to preserve previous behaviour.
Use cases:
#327512-31: devel_themer leaves files in /tmp
#105436: file_save_data -- Could use to easily save temp files too

Also, defining constant FILE_STATUS_TEMPORARY.
I'm aware that it was removed in #353207: Remove FILE_STATUS_TEMPORARY.
However, bitwise operation was dropped later in #809600: Stop using bit-wise operators for {file_managed}.status so now it makes sense to define it, IMO.

CommentFileSizeAuthor
#77 1659116-nr-bot.txt134 bytesneeds-review-queue-bot
#65 interdiff-64-65.txt1.37 KBAnonymous (not verified)
#65 1659116-65.patch3.59 KBAnonymous (not verified)
#65 interdiff-64-65.txt1.37 KBAnonymous (not verified)
#65 1659116-65.patch3.59 KBAnonymous (not verified)
#64 1659116-64.patch4.43 KBAnonymous (not verified)
#64 1659116-64-test-only.patch2.14 KBAnonymous (not verified)
#59 1659116-59.patch3.87 KBManuel Garcia
#55 d7-1659116-55.patch1.27 KBdrikc
#51 drupal--1659116--define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data--51.patch4.61 KBamontero
#45 drupal--1659116--define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data--45.patch4.61 KBamontero
#43 drupal--1659116--define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data--tests--43.patch1.91 KBamontero
#36 drupal--1659116--define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data--36.patch4.6 KBamontero
#33 drupal--1659116--define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data--tests--33.patch1.9 KBamontero
#28 drupal--1659116--define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data--28.patch2.69 KBamontero
#26 drupal--1659116--define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data--26.patch3.59 KBamontero
#23 drupal--1659116--define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data--23.patch3.56 KBamontero
#21 drupal--1659116--define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data--21.patch3.55 KBamontero
#21 1659116--interdiff-14-21.txt1.71 KBamontero
#14 drupal--1659116--define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data--14.patch2.6 KBamontero
#10 drupal--1659116--define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data-10.patch2.65 KBamontero
#6 1659116-define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data-6.patch2.58 KBamontero
#3 1659116-define-FILE_STATUS_TEMPORARY-and-expose-status-in-file_save_data.patch2.42 KBamontero
#1 1659116-define-FILE_STATUS_PERMANENT-and-expose-status-in-file_save_data.patch2.41 KBamontero
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

amontero’s picture

amontero’s picture

Title: Define FILE_STATUS_PERMANENT and expose $status in file_save_data » Define FILE_STATUS_TEMPORARY and expose $status in file_save_data

Ops. Fixing title.

amontero’s picture

Rerrolling testbot verified patch with amended commit message and function doc fix.

amontero’s picture

Assigned: amontero » Unassigned

Unassigning to allow review.

amontero’s picture

amontero’s picture

Chasing HEAD. Reroll in case issue gets attention.

amontero’s picture

amontero’s picture

Status: Needs review » Needs work
Issue tags: +API change, +API clean-up, +Backwards compatible API change
amontero’s picture

Reroll.

slashrsm’s picture

I like the idea. Some people could complain that there are not so many use-cases that this does not make sense, but I believe it does no harm to include status as an argument.

I definitely support re-introduction of FILE_STATUS_TEMPORARY. Let's wait a little bit if any other arguments appear before we RTBC.

Berdir’s picture

Berdir’s picture

Status: Needs review » Needs work
+++ b/core/modules/file/file.moduleundefined
@@ -525,8 +531,8 @@ function file_save_data($data, $destination = NULL, $replace = FILE_EXISTS_RENAM
-      'uid' => $user->id(),
-      'status' => FILE_STATUS_PERMANENT,
+      'uid' => $user->uid,

Re-roll incorrectly changes $user->id() back.

amontero’s picture

Addressing #13.

amontero’s picture

Test pass OK. Also, it looks like an easily backportable change.
If/when going RTBC, it would be great to have feedback about this.

slashrsm’s picture

+++ b/core/includes/file.incundefined
@@ -126,12 +126,18 @@
  */
+const FILE_STATUS_TEMPORARY = 0;
+
+/**
+ * Indicates that the file is permanent and should not be deleted.
+ */

Would it make sense to FILE_STATUS_TEMPORARY and FILE_STATUS_PERMANENT into File entity class as class constants?

+1 for back-port. This shouldn't brake any APIs.

Berdir’s picture

FileInterface actually. And yes, but that's a API change.

slashrsm’s picture

@Berdir: Are you talking about moving constants to an interface or backporting to D7?

Berdir’s picture

About the constants. Agreed that this can be backported, but it is a feature, so getting it in core and backporting it is going to take... a long time ;)

slashrsm’s picture

Should we leave this constants as they are then?

amontero’s picture

Reroll of #14 with constants moved to FileInterface as per #16 & #17.

Status: Needs review » Needs work
amontero’s picture

Lots of commits lately. Failed to rebase against HEAD. Rebase'n'roll.

Status: Needs review » Needs work
amontero’s picture

Status: Needs work » Active

@berdir , @slashrm: Moving constant definition triggers lots of 'undefined constant' notices. A quick grep on the constant FILE_STATUS_PERMANENT throws 28 occurences in 13 distinct files.
Such an added change would make patch bigger and harder to review. I'm afraid that this would slow even more the issue resolution and make it fail to be in before beta. Anyway, if such constant move is truly required, it can be dealt with in a followup (novice) issue.

Also, I'm not sure if this entire issue is a valid "Approved API" change. Would love to have some qualified feedback on this before proceeding any further.

amontero’s picture

Stale patch, reroll.

Anonymous’s picture

Issue summary: View changes

Adding use case

amontero’s picture

slashrsm’s picture

Status: Needs review » Reviewed & tested by the community

Looks good. Maybe we can open a follow-up to move constants to the interface?

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests
+++ b/core/modules/file/file.module
@@ -509,13 +509,19 @@ function file_validate_image_resolution(File $file, $maximum_dimensions = 0, $mi
+function file_save_data($data, $destination = NULL, $replace = FILE_EXISTS_RENAME, $status = FILE_STATUS_PERMANENT) {

Missing test coverage of calling this with FILE_STATUS _TEMPORARY

amontero’s picture

Status: Needs review » Needs work
amontero’s picture

First stab at tests.
Patch with just tests, should fail.

amontero’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
amontero’s picture

And now, patch and test.

Status: Needs review » Needs work

Status: Needs review » Needs work

Status: Needs review » Needs work
willzyx’s picture

+++ b/core/modules/file/src/Tests/SaveDataTest.php
@@ -67,6 +67,29 @@ function testWithFilename() {
+  function testWithFilenameTemporary() {
+    $contents = $this->randomName(8);

@amontero the test fails because $this->randomName(8) not exists. Probably you should use $this->randomMachineName(8)

amontero’s picture

@willzyx: Thanks! Didn't spotted that... maybe my branch was too old and became obsolete (?) I was also tracking old '8.x' branch.
Tests only attached, should fail.

Status: Needs review » Needs work
amontero’s picture

And now the full patch.

amontero’s picture

Issue tags: -Needs tests
amontero’s picture

As soon as tests are deemed good enough, as per #29 this will be RTBC. I'll open a followup as requested and tag this as 'needs backport to D7', since it's a backwards compatible change.

Status: Needs review » Needs work
amontero’s picture

Status: Needs review » Reviewed & tested by the community

Setting to RTBC as per #29. Steps after getting commited:
- Open followup issue to move constant as needed (seeding novice-tagged issue).
- Backport to 7.x.

alexpott’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Reviewed & tested by the community » Postponed

Hi @amontero thanks for work on this. Unfortunately we're in beta phase for Drupal 8 which means we're not accepting any new features. See https://www.drupal.org/core/beta-changes.

Looking at the patch two thoughts spring to mind firstly contrib can create temporary file entities by just creating a temporary and a file entity directly and it'd be possible to add support for this in a non bc breaking manner so I'm going to postpone to 8.1

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

drikc’s picture

FileSize
1.27 KB

Need this for D7.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

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

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

Chi’s picture

Status: Postponed » Needs work
Issue tags: +Needs reroll

Reopening this since 8.1 was release a long time ago.

Manuel Garcia’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
3.87 KB

Reroll of #51

amontero’s picture

Looks good to me.

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

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

Anonymous’s picture

+1 to RTBC.

FILE_STATUS_TEMPORARY looks nice and it will be useful in other places too. As a possible follow-up can be created issue about replace magic value 1 / 0 to FILE_STATUS_PERMANENT / FILE_STATUS_TEMPORARY.

Personally, I'm not a fan of the emergence of new opportunities to make files temporary 😜, but the flexibility in this behavior seems fair.

Also it would also be great to remove ossified behavior in file_save_upload, where we have the opposite situation:

/**
 * Saves file uploads to a new location.
 *
 * The files will be added to the {file_managed} table as temporary files.
...
    // Begin building file entity.
    $values = [
      'uid' => $user->id(),
      'status' => 0,

But it is separate issue, of course.

dawehner’s picture

+++ b/core/modules/file/tests/src/Kernel/SaveDataTest.php
@@ -58,6 +58,29 @@ public function testWithFilename() {
+    $this->assertEqual($result->getMimeType(), 'text/plain', 'A MIME type was set.');

Please use assertEquals here. Please also keep in mind that on the left side of the equation you want to have the expected value.

Anonymous’s picture

Indeed! Thank you, @dawehner! The test is hopelessly outdated. I overlooked this moment (the desire to get FILE_STATUS_TEMPORARY distracted me). Here's another:

  1. +++ b/core/modules/file/tests/src/Kernel/SaveDataTest.php
    @@ -58,6 +58,29 @@ public function testWithFilename() {
    +    $this->assertTrue($result, 'Unnamed file saved correctly.');
    

    Unnamed - not actual info, because we have name file to this test.

  2. +++ b/core/modules/file/tests/src/Kernel/SaveDataTest.php
    @@ -58,6 +58,29 @@ public function testWithFilename() {
    +    $this->assertEqual('public', file_uri_scheme($result->getFileUri()), "File was placed in Drupal's files directory.");
    +    $this->assertEqual($filename, drupal_basename($result->getFileUri()), 'File was named correctly.');
    ...
    +    $this->assertFileUnchanged($result, file_load($result->id(), TRUE));
    

    file_uri_scheme, drupal_basename, file_load also deprecated.

  3. +++ b/core/modules/file/tests/src/Kernel/SaveDataTest.php
    @@ -58,6 +58,29 @@ public function testWithFilename() {
    +    $this->assertFalse($result->isPermanent(), "The file's status was set to temporary.");
    

    We need to check other options too, because we add a new parameter.

This patch fixed all of them. Only this test is interdiff with #59 (see test-only.patch).

In the next post will be offered another version of the test.

Anonymous’s picture

This version based on question: Why do we do so many unrelated checks while checking the status?) Perhaps for historical reasons. Then we can do a general test, in which we check the basic behavior, and in-depth tests, in which there will be specific tests. Like this test.

Additional review:

+++ b/core/modules/file/tests/src/Kernel/SaveDataTest.php
@@ -131,4 +131,31 @@ public function testExistingError() {
+      'permanent status' => [1, TRUE, 'Permanent status was set correctly.'],
+      'temporary status' => [0, FALSE, 'Temporary status was set correctly.'],

Why in the dataProvider are used 1/0 instead of FILE_STATUS_PERMANENT/FILE_STATUS_TEMPORARY? I dont know. They are available inside the tests, but not available in dataProvider, so I replaced them with magic values.

The last submitted patch, 64: 1659116-64-test-only.patch, failed testing. View results

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.

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.

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.

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

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.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.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.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.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.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
FileSize
134 bytes

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

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.