Image/File Upload Problems without Errors

[alanp]

I have a PW site where I had been successfully uploading png and jpeg files. Recently the file and image file fields don't save. The upload status bar completes (100%) without error but when the page with the file field is saved the uploaded file name is missing from the refreshed page.

This must be due to a site hosting change but I need more specific info like error details before I raise it with them.

The php v5.4 config has file uploads enabled and safe mode is off. 

I have tried the following to fix this without success:

1. I have read and tried the fixes to the similar posting from Soma:  can't upload image/files problem
2. Upgraded the PW site from 2.3 to 2.5.3. (no change)
3. Turned on debug in config.php with no obvious error messages showing.
4. Debugged core\WireUpload.php where I found that the recommended fixes from 1. wouldn't work because the file field is not using Ajax.

Have you got any other suggestions?

  

[Soma]

Memory? If Images are a little bigger it can require a great amount of memory real quick to create the thumb.

[alanp]

Don't believe its memory. The pdf files I have been testing with are less than 270KB and site hosting disk space allowance is 2GB with only 163MB used.

In the associated posting the following recommendation was provided:

Edit: just added a new $config->uploadTmpDir that you can set in your /site/config.php. This will override PHP's upload_tmp_dir for ajax uploads only (I don't think we can override that on non-ajax uploads).....

Given the above and that I found that the file field on the hosted site is currently not using Ajax based uploads does anyone know how I can configure the file field/site to use Ajax?

[Falk]

I have a similar problem with a website I just finished. 

Images appear in the correct directory (I see them with FTP), but they won’t get cropped or scaled and they won’t show up in frontend and backend.

I tried some of the tips I found in the forum but nothing worked…

Uploading PDF Files works fine, so I think it might be a problem with Scaling/Cropping images.

[alanp]

With further analysis I have found I was wrong about the use of Ajax. The client side script in InputfieldFile.js was using Ajax based file upload but it was just not working and not returning any errors. As soon as I commented out the following code block and replaced it with InitOldSchool() both image and file uploads worked fine not using Ajax.

*	if (window.File && window.FileList && window.FileReader && $("#PageIDIndicator").size() > 0) {  
*		InitHTML5();  
*	} else {
*		InitOldSchool();
*	}

So any guess as to why Ajax based file uploads have stopped working or how I can debug this?

I have tested this on both IE, Chrome and FF with no change. It must be a hosting config issue. 

[pwFoo]

Have you added an element with ID "PageIDIndicator"?

If you remove / rename it upload should work without modifications.

Take a look at the if condition.

[blast]

Same problem here, it only works if I launch InitOldSchool();

[blast]

I try to investigate but first I show you the errors.

The ajax return:

<br />
<b>Deprecated</b>:  Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in <b>Unknown</b> on line <b>0</b><br />
<br />
<b>Warning</b>:  Cannot modify header information - headers already sent in <b>Unknown</b> on line <b>0</b><br />
<br />
<b>Warning</b>:  Cannot modify header information - headers already sent in <b>/Users/andreamontaldo/Sites/siae-promo/web/wire/core/admin.php</b> on line <b>15</b><br />
[{"error":false,"message":"Added file: dsc00181.jpg","file":"\/siae-promo\/web\/site\/assets\/files\/1023\/dsc00181.jpg","size":98458,"markup":"\n\t<li id='file_3dbec45f3f9fb3712c4ac718c1f1ba9b' class='InputfieldFileItem InputfieldImage ui-widget'>\n\t\t<p class='InputfieldFileInfo InputfieldItemHeader ui-widget ui-widget-header'>\n\t\t\t<i class='fa fa-fw fa-sort HideIfSingle'><\/i>\n\t\t\t<i class='fa fa-fw fa-caret-right HideIfMultiple'><\/i> \n\t\t\t<a class='InputfieldFileName pw-modal pw-modal-large' title='dsc00181.jpg (1623x1080)' href='\/siae-promo\/web\/gestione\/page\/image\/edit\/?id=1023&file=1023,dsc00181.jpg&rte=0&field=cover' data-buttons='#non_rte_dialog_buttons button' data-autoclose='1' data-close='#non_rte_cancel'>dsc00181.jpg <i class='fa fa-pencil ui-priority-secondary'><\/i><\/a> \n\t\t\t<span class='InputfieldFileStats'>96 kB, 1623x1080  <\/span> \n\t\t\t<label class='InputfieldFileDelete'><input type='checkbox' name='delete_cover_3dbec45f3f9fb3712c4ac718c1f1ba9b' value='1' title='Delete' \/><i class='fa fa-fw fa-trash'><\/i><\/label>\n\t\t\t<a class='InputfieldFileMove InputfieldFileMoveBottom' href='#' title='Move to bottom'><i class='fa fa-fw fa-angle-double-down'><\/i><\/a> \n\t\t\t<a class='InputfieldFileMove InputfieldFileMoveTop' href='#' title='Move to top'><i class='fa fa-fw fa-angle-double-up'><\/i><\/a> \n\t\t<\/p>\n\t\t<div class='InputfieldFileData ui-widget ui-widget-content'>\n\t\t\t<div class='InputfieldImagePreview'>\n\t\t\t\t<a class='InputfieldFileLink' target='_blank' href='\/siae-promo\/web\/site\/assets\/files\/1023\/dsc00181.jpg?nc=1429127148'><img height=\"50\" src=\"\/siae-promo\/web\/site\/assets\/files\/1023\/dsc00181.0x100.jpg?nc=1429127149\" alt=\"\" data-gridsize=\"50\"  \/><\/a>\n\t\t\t\t<div class='InputfieldImageActions'>\n\t\t\t\t\t<a title='dsc00181.jpg (1623x1080)' href='\/siae-promo\/web\/gestione\/page\/image\/edit\/?id=1023&file=1023,dsc00181.jpg&rte=0&field=cover' class='pw-modal pw-modal-large' data-buttons='#non_rte_dialog_buttons button' data-autoclose='1' data-close='#non_rte_cancel'><i class='fa fa-fw fa-crop'><\/i><\/a>\n\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t<div class='InputfieldFileDescription'><label for='description_cover_3dbec45f3f9fb3712c4ac718c1f1ba9b' class='detail'>Description<\/label><input type='text' name='description_cover_3dbec45f3f9fb3712c4ac718c1f1ba9b' id='description_cover_3dbec45f3f9fb3712c4ac718c1f1ba9b' value='' \/><\/div>\n\t\t\t<input class='InputfieldFileSort' type='text' name='sort_cover_3dbec45f3f9fb3712c4ac718c1f1ba9b' value='0' \/>\n\t\t<\/div>\n\t\t\t<div class='ui-widget-content crops'><p class='description'>Thumbnails (hover to preview, click to crop)<\/p><a target='_blank' data-thumburl='\/siae-promo\/web\/site\/assets\/files\/1023\/thumbnail_dsc00181.jpg' class='crop' href='\/siae-promo\/web\/gestione\/page\/image-crop\/?filename=dsc00181.jpg&prefix=thumbnail&width=100&height=100&pages_id=1023&field=cover&modal=1'>thumbnail<\/a><\/div>\n\t<\/li>","replace":false,"overwrite":0}]

The PHP logs:

[15-Apr-2015 21:45:34 Europe/Rome] PHP Deprecated:  Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0
[15-Apr-2015 21:45:34 Europe/Rome] PHP Warning:  Cannot modify header information - headers already sent in Unknown on line 0
[15-Apr-2015 21:45:34 Europe/Rome] PHP Warning:  Cannot modify header information - headers already sent in /Users/andreamontaldo/Sites/siae-promo/web/wire/core/admin.php on line 15
[15-Apr-2015 21:46:41 Europe/Rome] PHP Notice:  Undefined index: id in /Users/andreamontaldo/Sites/siae-promo/web/wire/core/Process.php on line 313
[15-Apr-2015 21:46:41 Europe/Rome] PHP Notice:  Undefined index: id in /Users/andreamontaldo/Sites/siae-promo/web/wire/core/Process.php on line 313
[15-Apr-2015 21:46:41 Europe/Rome] PHP Notice:  Undefined index: id in /Users/andreamontaldo/Sites/siae-promo/web/wire/core/Process.php on line 313
[15-Apr-2015 21:46:41 Europe/Rome] PHP Notice:  Undefined index: id in /Users/andreamontaldo/Sites/siae-promo/web/wire/core/Process.php on line 313
[15-Apr-2015 21:46:41 Europe/Rome] PHP Notice:  Undefined index: id in /Users/andreamontaldo/Sites/siae-promo/web/wire/core/Process.php on line 313

[blast]

Roll back to php 5.5 and it works like a charm.

With PHP 5.6 I added this line to php.ini

always_populate_raw_post_data = -1 

and now the ajax upload works.

[Beate]

I have the same problems with PW 2.6.0 and php 5.3.9, I can't upload images (The upload status bar completes (100%) without error but when the page with the file field is saved the uploaded file name is missing from the refreshed page).

With console, I got a Javascript error, please see attached....

[LostKobrakai]

The listed script snippet is part of the jquery core library, which should be rather stable. Please refresh the modules in the backend and hardreload the browser to clear your cache. If the error persists, please report back.

[jvdbol]

Same problem with me. Everything with uploding images or files is working flawlessly on mij local xampp server. I could get it partly working on my live shared hosting provider (with by the way by years never have given me any problems when trying out lot of CMS/CMF applications) with version 2.5 after the solution mentioned above at Alanp. Since version 2.6 even that is no longer working. The strange thing is that i get, just like Beate, js errors, with is not happening on mij local site. All the Apache en PHP requirements are fulfilled on both servers. The only difference: local server PHP 5.63, hosted server PHP 5.3.29. 

I can't figure out why I get javascripterrors when something is different in the PHP version.

Very pity, because I love the clearness of the PW system, wich is now nut usable for me. 

[ryan]

If you see a JS error form file upload, there's an way to find out exactly what the source of the error is, at least in Chrome. 

1. Open the developer tools in Chrome: View > Developer > Developer Tools.
2. Click on the "Network" tab in these tools. You should see columns for "Name, Status, Type, Initiator, Size, Time, Timeline" (if you don't, drag your dev tools to be a little larger). 
3. Drag in a file to your file field that's not working, to attempt to upload. 
4. You'll see a new item appear at the bottom of your Network tab that looks like "?id=123", where 123 is the ID of the page you are uploading to.
5. Click that "id?=123" item. It'll open a new panel to the right with several new tabs. Click the "Response" tab. 
6. In this Response tab, you'll see some kind of error message, likely followed by some JSON code. 
7. You may be able to tell what the next step is from the error message. For instance, maybe it's some 3rd party module reporting an error directly to output, or maybe it's a 403 error from Apache, indicating that mod_security is interfering with your file uploads. It could be anything. If you can't tell what to do next from the error, paste it all in here so we can get a better look and we can suggest what to try. 

[jvdbol]

Thank you Ryan for your instruction. It deliverd me the solution for the problem.

It pointed out that there was an Apache error 406, due to my hosting providers settings. The mentioned Ajax errors were non visible in Chrome Developer Tools (all the way logical, because there are no real Jquery errors, although the console in IE shows them, but that should be incorrect).

I found the solution for the Apache error 406 here: https://www.tipsandtricks-hq.com/apache-mod-security-update-how-to-fix-error-406-or-not-acceptable-issue-259

Coding solution 1 in my .htaccess file resolved all problems with uploading files or images:

<IfModule mod_security.c>

SecFilterEngine Off

SecFilterScanPOST Off

</IfModule>

I am very very happy, and can go on with processwire.

[JoshoB]

I'm having the exact same problem. I'm using the CropImages modules (to get neat thumbnails). It's working on XAMPP offline, but doesn't work when the site is online on my server. I've tried the .htaccess trick, but it isn't working: the file gets uploaded (supposedly), reaches 100%, and then nothing happens.

I have debugging on and I get this message: "Pageimages: Removed 'images' temp file(s) for page /applications/h2so4-oleum/ - applications-h2so4.jpg, applications-h2so4-1.jpg".

I've added the temporary directory to config.php (it wasn't included there), and even manually added the directory under /assets, but no luck so far. I've changed permissions to be very lenient (for testing purposes), but that didn't seem to have any effect either.

In developer tools, I'm getting this error: "Warning: set_time_limit() has been disabled for security reasons" (and I have no idea why -- I didn't specify a time limit anywhere and don't have direct access to php.ini on my host). Any ideas on how to solve this?

Edit: something curious just happened -- I get the same error in Chrome, but unlike Firefox, the images do appear to get uploaded. (But only if you leave it on for a while, apparently.)

Edit 2: I think the problem is in the CropImage module -- I made a test field with a regular image field type and that works as expected. I got an error about ImageSizer at one point, but haven't seen it again. So there's a problem with the module. (I'm using Apeisa's latest version).

[mr-fan]

There are two versions of this kind of module.

https://processwire.com/talk/topic/643-release-thumbnails/

and some fork with extended features that's named CroppableImages:

https://processwire.com/talk/topic/8709-croppableimage/

Which module you running?

PHP version?

[JoshoB]

I've removed the CropImage module and am using the default Images field. I still get problems! Specifically, I get this one: "Pageimages: Removed 'images' temp file(s) for page". I'm guessing it's perhaps some kind of permissions problem? Strangely, it sometimes *does* work in Chrome. I've never experienced something like this.

Edit: could be a server problem? Like I said, it worked fine on XAMPP. Just don't know where to look...

[JoshoB]

I've read elsewhere that switching to OldSchool could work. However, where do I implement this?

Edit: increased PHP memory limit via PHP (in config.php). I managed to upload one picture. All others afterwards failed with the same non-error (getting stuck at 100%). It's quite frustrating. :-/

Edit 2: Apache error logs keep referring to this: "PHP Warning:  set_time_limit() has been disabled for security reasons in /sites/XYZ.com/test/wire/core/ImageSizer.php". I'm guessing that's the problem. No idea how to fix it, though. Never had this issue before.

[JoshoB]

"Solved" the issue by commenting out the contents of the function in question (part of core). Image fields work now. I'll remove the comments when the site's been moved to its definitive location and see if the issue reappears.

Edit: and apologies for posting three times in a row. ;-)

[felic]

Similar problem here.

Refering to https://processwire.com/talk/topic/8712-imagefile-upload-problems-without-errors/?p=92979

Changing the PHP ini file does not make any difference i am afraid. 

PW V. 2.6.1 stable, any settings/permissions are identical to former installation (PW V. 2.6.0), no modules/plugins, Image Fieldtype, Debug mode is active.

Wether drag/drop or select from input leads to:

Header Response within chrome dev tools:

After saving the page following message appear:

It seems to me, there might a bug in the js ajax code(?).

Anyone have any hints how to solve this? Would be great ;-)

Thx in advance. 

[felic]

Refering to https://processwire.com/talk/topic/8712-imagefile-upload-problems-without-errors/?p=92979

Changing the PHP ini file does not make any difference i am afraid. 

Correction. Applying

always_populate_raw_post_data = -1

to the php.ini as a workaround do the job and enables image upload again.

[johnstephens]

Correction. Applying

always_populate_raw_post_data = -1

to the php.ini as a workaround do the job and enables image upload again.

This is exactly what I needed to get image uploads working on my vagrant box (scotch.box).

Edit: Had this problem on another vagrant box today, searched for the solution, and found this post—but I forgot where to find the php.ini file on scotch.box.

So here are the baby steps, future self:

1. Connect to the box shell:

   vagrant ssh

2. Open php.ini in vim:

   sudo vim /etc/php5/apache2/php.ini

3. Find the right line:

   /always_populate_raw_post_data<CR>

4. Uncomment the line:

   0x

5. Save and quit:

   ZZ

6. Restart Apache:

   sudo service apache2 restart
   

7. Exit the vagrant shell:

   <C-d>

[Arcturus]

I've run into the same issue.

It isn't present at all on XAMPP with PHP v.5.5.1 and Firefox v.41.0.2, but once I transferred my site to a CentOS v.7 server running PHP v.5.5.30 (same browser) I couldn't upload images anymore until I did the "oldschool" workaround outlined by AlanP. The php.ini setting change had no effect for me.

[Arcturus]

By now I should just assume that any bizarre issue I run into with ExpressionEngine or Processwire is being caused by ModSecurity (which I doubt anyone runs in their dev environment). I'm sure that module serves an important purpose, but man, is it ever good at creating problems that look like they're scripting errors.

I had four different web development toolbars telling me that the issue was with JqueryCore.js, specifically:

FIREFOX DEVELOPER TOOLBAR
-----------
Use of getPreventDefault() is deprecated.  Use defaultPrevented instead. JqueryCore.js:2:0
SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data JqueryCore.js:2:13582

FIREBUG
-----------
SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
http://[site]/wire/modules/Jquery/JqueryCore/JqueryCore.js?v=183
Line 2
...trim(t);if(e.JSON&&e.JSON.parse)return e.JSON.parse(t);if(S.test(t.replace(T,"@"...    

CHROME
--------
Uncaught SyntaxError: Unexpected token <v.extend.parseJSON @ JqueryCore.js?v=183:2(anonymous function) @ InputfieldFile.js?v=118:200

IE11
------
SCRIPT1014: Invalid character
File: JqueryCore.js, Line: 2, Column: 13575

However, when I scoured the server logs it began to look like ModSecurity was killing the process during a 302 redirect. Disabling that particular rule through the console in cPanel WHM fixed my image upload issues immediately.

Note about the OldSchool Workaround

I have no explanation for this, but for some reason when I did the OldSchool workaround (essentially replacing the whole if statement with just InitOldSchool(); ), I got a working old school upload as a superuser, but reports from regular users that they were still getting the non-working HTML5 uploader. I had created their accounts days after I made the fix to InputfieldFile.js, so it wouldn't have been a cache issue. Strange, but something you'll want to test for if you go that route.

[choppingblock]

Just to add my solution to this issue:

I ran into this on a Basic Hosting Package on Strato (this is one of the biggest german discount Webhosters).

None of the above workarounds worked for me, but then I found a hint in the Strato FAQ:

I needed to disable the filter for guestbook-spam in the security settings, as this was causing a 503 Apache error.