File Field Path save only to Temporary Directory

There are people reporting issues that may be related to this issue, but this is the first official issue opened for this issue.

Can you do some things for me?
- Provide reproduction steps using a fresh install of Drupal.
- Test the reproductions steps on SimplyTest.me.
- Run the Simpletest test included with the File (Field) Paths module.
- Provide me with any information you can on your dev environment.

The fact that it does work on SimplyTest.me but not on your local environment is indicative of an issue with your local environment, although that doesn't say that your environment is to fault but rather File (Field) Paths may not be able to cater for a difference in the server environment.

Did you try running the tests? To do so, simple enough the Simpletest module (listed as 'Testing' in the modules page) and then run all the File (Field) Paths tests on the Testing page. Let me know if they pass or fail, and what fails.

What is your server stack? OS, PHP version, etc?

In the meantime, to get you back on track until this issue is resolve, you should simply be able to comment out a single link in filefield_paths_form_alter(), the one containing $form[$field_name][$language][$delta]['#upload_location'] = 'temporary://filefield_paths';.

I'll intentionally set my permissions incorrectly and see what happens, as I don't think it's acceptable that there is no error messages. Will do as soon as I can.

Thanks for following this up.

Hi! I have a similar problem, but it only occurs when using images on multi-value field.

I mean, I have 2 fields: photo and gallery. The first one is a Image field with just one image allowed; while the second one is a Image field with unlimited images.

When I upload an image on my "photo" field, I can see preview it. But when I upload the image in the "galley" field, I can't see the preview.

At the first case, the preview src is like:
http://mysite.com/sites/default/files/public/styles/thumb__144x81/public...

At the second case, the preview src is like:
http://mysite.com/system/temporary/styles/thumb__144x81/temporary/filefi...

Why is such difference?

If I go to the corresponding tmp folder, I can see the image uploaded for both cases, so the problem (I guess) is when applying the 'system/temporary' rewrite.

The environment which fails is:
Debian 8
Nginx
ISPConfig
Drupal 7.39

But if I run on WAMP it is working properly.

Just for checking, I assigned 777 permissions to the tmp folder, and even tested to move into /sites/default/files/tmp, with no luck.

Maybe I missed some configuration on nginx, but I can't find out what.

As I have given 777 permissions, I "discarded" permission settings as the first cause. I have chown file system to www-data user and the site user generated by ispconfig, with the same results.

From configuration, in both cases the final folder is the same, but in one case the temporal file is copied to the public folder and the failing one is copied to the tmp folder. When I save, the file is stored properly and on edit I can view it correctly on both fields.

So, I guess I have activated some module that is modifying tmp path for the first image.

I will continue investigating. Thank you!

Just to clarify, I expect the working field copies the images on tmp folder, like the failing one... so none will be working.

So here I have 2 problems:

1. Why is one field storing image on public://?

2. Why tmp is not being shown, even if the file is uploaded and can be found on temporary://filefield_paths?

If I get any answer, I will come back :)

The module is failing to save on tmp folder the file when it is inside a field collection. I have opened the corresponding issue #2592519.

@dtamajon,

Can you confirm that the Field Collection issue was the cause of all you reported in this issue? If so, that issue has been resolved. If not, can you test that latest development release and confirm whether you are still having issues and if so, how to reproduce said issues.

@Deciphered,

The problem about storing image on temporary:// for both cases looks good.

Still I can't get temporary:// working on linux environment, but looks like a contextual problem on my side. So, I'd say the dev is fine.

@dtamazon,

Can you give me some steps/detailed information on the issue you are having with the permissions? I'm using a Linux based Vagrant box as my primary development environment and am not encountering any issues, but I don't doubt that the issue exists and I don;t want to risk launching the 1.0 if there is still a quite large issue.

@Deciphered,

I have 2 environments where everything is working properly (including the last dev version):

1. • Linux Debian 7
   • ISPConfig3
   • nginx
   • PHP 5.4.36
   • 
     
2. • WAMP server
   • 
     

And one environment where it is not working:

1. Linux Debian 8 with:
   • ISPConfig3
   • nginx
   • PHP 5.6.12

I have downgraded PHP to 5.4.x version, with no success. All the Drupal and permission configurations on this last environment are identical to the ones working.

This week I will check to move the failing environment to the Debian 7 environment, just to check... and will try to copy some working site to the Debian 8 environment to check too.

The problem that remains is with the /system/temporary/filefield_paths/* path. The image is correctly generated on the temporary path, but not displayed (the server is returning a 404 error).

I have checked the nginx directives and looks fine (like the working ones). Permissions are set correctly too... maybe I missed some Drupal config.

When I have done the test, I will be back with more info.

I am having the same issue, our sites are hosted on Acquia. The issue seems to only happen in production (based on limited testing). This document seems to outline a possible cause due to their setup. I'm going to try and modify the filefield_paths_temporary_upload_location function with some logic implementing their recommendations:

https://docs.acquia.com/articles/correcting-broken-uploads-acquia-cloud-...

Excerpt from the Article:

The Plupload integration module works by first creating a temporary file for each uploaded file. After the temporary file is on the server, it is then moved to its final destination. For customers running their sites on Acquia Cloud, this works without any errors. Customers running their sites on Acquia Cloud Enterprise, however, often experience errors when some of the uploaded files don't save properly.

Files added by Plupload to Acquia Cloud Enterprise sites are saved to a temporary location that is not shared between the redundant provisioned hardware. It's possible for the move process to take place on a server different from the one that the file is uploaded to, which causes that move to fail, and the upload to appear broken.

This is a common scenario for sites hosted on either redundant hardware or multiple servers. Because of this, the Plupload integration module allows you to overwrite the temporary file location to create the temporary files at a location shared between the hardware being used. The module does not provide a user interface to set the variable to do this, but the Drush utility allows you to easily set the required variable. To do this with Drush, use the following command:

drush @[docroot].[environment] vset plupload_temporary_uri '/mnt/gfs/[docroot].[environment]/tmp'
You can also set this in a more permanent fashion, by inserting this code into your website's settings.php file.

$conf['plupload_temporary_uri'] = "/mnt/gfs/{$_ENV['AH_SITE_GROUP']}.{$_ENV['AH_SITE_ENVIRONMENT']}/tmp";

---

It might be worth considering providing a configuration variable like the one above.

@sbubaron,

While I am contemplating making a the temporary location that File (Field) Paths uploads to, it seems like the issues you are having are present for any module that may access to the Temporary file system.

As such, I'd suggest changing the location of the temporary file system across the board:

/admin/config/media/file-system

or

$conf['file_temporary_path']

That should fix your issue with File (Field) Paths as well as any other module that uses the Temporary file system.

-

Hi,

I have the same issue, and I have checked my temporary folder, all is ok.

This problem is new since I updated File (Field) Paths from 7.x-1.0-rc1 to 7.x-1.0-rc2.

Thanks

@rroblik,

You need to provide more information, this issue was marked as fixed and stating you have the same issue is not helpful to me to determine if you have the issue or what I can do about it. Who is your hosting provider? Is your temporary file system writable? Anything else you can provide me with to reproduce this issue?

Hi,

Here is my configuration (local hosting, for dev) :

Debian Squeeze (Linux 2.6.32-5-686-bigmem i686)
PHP 5.3.3-7+squeeze19 with Suhosin-Patch (cli) (built: Feb 18 2014 13:59:15)
Drupal 7.41
$conf['file_temporary_path'] = "/tmp" (yes writable, Drupal (or FFP ?) now put uploaded images files here 

(joined config of my image field : (french, sorry))

To reproduce this issue hum ... simply update File (Field) Paths from 7.x-1.0-rc1 to 7.x-1.0-rc2 :)
I will try to downgrade to 7.x-1.0-rc1 to see if it's working.

Regards

Ok @Deciphered, my bad :)

The problem was my (final) destination folder was not writable by apache user (why did this happen ? I don't know ...)

So both 7.x-1.0-rc2 and 7.x-1.0-rc1 are working fine :)

NB :
Maybe at less a (watchdog) error if the test at line 105 of filefield_paths.inc fail can help people :)

if (file_prepare_directory($dirname, FILE_CREATE_DIRECTORY) && $new_file = file_move((object) $old_file, $file['uri'])) {
// ...
else{
 // message error / watchdog here ?
}

Regards

destination folder was not writable

I found the same problem on a customer project. I opened a related issue: #2612396: Missing explaining error message if target folder is not writeable