Image/File Upload Problems without Errors

[iNoize]

had the same error after 2 days of searching and trying is this the solution 

/etc/apache2/mods-available/fcgid.conf

<IfModule mod_fcgid.c>

  FcgidConnectTimeout 20

  MaxRequestLen 104857600  // you have to increase the value 

  <IfModule mod_mime.c>

    AddHandler fcgid-script .fcgi

  </IfModule>

</IfModule>

[bernhard]

had this issue today with my vagrant scotchbox and found this solution: https://github.com/scotch-io/scotch-box/issues/124

maybe of interest for someone

[joe_g]

I fixed this issue in a different way: 

I saw the ajax request printed a warning "Cannot set max execution time limit due to system policy", so I commented out line 955 in core/ImageSizerEngine.php

seems to work

j

[bernhard]

@joe_g keep in mind that whenever you update your processwire installation this issue will return (if your hoster didn't change the config until then)

[thlinna]

Had the same problem with nginx 1.10.3, and here is the solution I found from StackExchange:

Quote

Be certain you have included your increased upload directive in ALL THREE separate definition blocks (server, location & http). Each should have a separate line entry. The result will like something like this (where the ... reflects other lines in the definition block): 

http {
    ...
    client_max_body_size 20M;
}    

This above block may be found from /etc/nginx/nginx.conf file. The following block was in /etc/nginx/conf.d/default.conf in my server environment.

server {
    ...
    client_max_body_size 20M;
}

location / {
    ...
    client_max_body_size 20M;
}

Location of nginx configuration files may vary depending on your configuration. Please refer to nginx documentation if different from above paths. Of course one may increase or decrease the upload size limit from 20M to best suit own needs and preferences. 

[Batyr]

Hi everybody,

I also have the same problem, I developed my website locally and the uploading pictures part worked just fine. After a certain period of time when I wanted to add a new child of the page and upload image it won't work. It shows nothing. BUT when I edit the pages that I have already created locally before submitting to the server, it works just FINE!, at work my boss wants me to add more items, but I can't do it since the image upload is not working. I saw the error in Chrome Dev tools. It says 404 Not Found, basically the image is not found, but when I enter the file with FileZilla the image is there.

Any help is greatly appreciated. Thanks in advance!

 

[ethanbeyer]

Is there something about the way that ProcessWire handles uploads that is different from other systems?

It seems I am often using some obscure PHP setting workaround (`always_populate_raw_post_data=-1`) or changing something at the server level. I hate wordpress, but I've never needed to perform any server admin to get their uploads to work–vagrant box or otherwise–does anyone know the reason ProcessWire is finicky here?

[ethanbeyer]

With the previous question out of the way, I am also having the same issue. I'm still trying to debug this, but for some reason, the network response to https://example.com/admin/access/users/edit/?&id=1266&InputfieldFileAjax=1 is a 404 with the HTML of my homepage.

[szabesz]

4 hours ago, ethanbeyer said:

always_set_raw_post_data=-1

https://stackoverflow.com/questions/28278705/always-populate-raw-post-data-trouble-accessing-request-payload-from-backbone?answertab=votes#tab-top

I guess you are on PHP 5.6. Can't you upgrade to at least to 7.0.x?

[ethanbeyer]

19 hours ago, szabesz said:

https://stackoverflow.com/questions/28278705/always-populate-raw-post-data-trouble-accessing-request-payload-from-backbone?answertab=votes#tab-top

I guess you are on PHP 5.6. Can't you upgrade to at least to 7.0.x?

 

I didn't realize the `always_populate_raw_post_data` option was for 5.6. The server that's bricking uploads is on 7.0.29.

 

Symptoms:

1. Uploads show the progress bar, and then the spinner shows up. It never goes away. Checking the page's directory in `/site/assets/files/{id}` shows that the file has uploaded, and isn't corrupted. ProcessWire isn't recognizing this because the response from the AJAX is the content of the site's homepage. I have disabled modules to no effect.
2. It seems that the uploader is specifically having trouble with JPGs.

Debugging Info (from TracyDebugger thank you @adrian) :

ProcessWire: 3.0.123
PHP: 7.0.29
Webserver: Apache
MySQL: 5.6.41-84.1

allow_url_fopen: 1
max_execution_time: 600 (changeable)
max_input_nesting_level: 64
max_input_time: 600
max_input_vars: 1000
memory_limit: 512M
post_max_size: 30M
upload_max_filesize: 30M
xdebug:
xdebug.max_nesting_level:

mod_rewrite: 1
mod_security:

GD: bundled (2.1.0 compatible)
GIF: 1
JPG: 1
PNG: 1

EXIF Support: 1
FreeType: 1
Imagick Extension: 1

BatchChildEditor: 1.8.10
ConnectPageFields: 0.1.8
EncryptDecryptRc4: 1.0.0
HtmlBodyClasses: 1.0.0
ImportPagesCSV: 1.0.6
InputfieldSimpleMDE: 1.0.5
Migrations: 0.3.1
PageCleanEmptyDirs: 0.0.3
PageRenameOptions: 1.0.5
ProcessChildrenCsvExport: 1.7.0
ProcessDatabaseBackups: 0.0.4
ProcessDirectoryMemberTools: 1.1.1
ProcessMigrations: 0.1.3
ProcessWireUpgrade: 0.0.7
ProcessWireUpgradeCheck: 0.0.7
TemplateCacheOverview: 0.0.3
TracyDebugger: 4.10.19
VirtualParents: 0.0.1
WireMailSmtp: 0.3.0

Things I've tried:

1. Upload a JPG. Spinner. Open that same JPG in Photoshop, save it as a PNG (tripling its filesize) and upload. Upload takes, PW recognizes it. Save page. Resave the PNG as a JPG, upload that. Uploader spins. Check directory in FTP, all the files are there.
   
2. Changed the field to use server-side resizing, no effect.
3. Changed the max megapixels from NULL to 12.0, no effect.
4. Resize the original JPG to ~1000px, upload it, and it works. o_0

---

Not sure what to do now. It seems similar to @Batyr's problem, in terms of the POST returning a 404. This does not happen on my local box with the same codebase.

Does anyone have any ideas?

 

EDIT:

The weirdest part is that this just started happening on this server. I don't know the exact date or time, as the client just informed me the image uploads were struggling.

[adrian]

Typically you want to click on the ajax called file that is uploading - Then on the response tab - that should show you any errors that are corrupting the uploading.

Also, just an FYI that your version of Tracy is a year old ?

[ethanbeyer]

haha @adrian, I have updated TracyDebugger to the most recent!

I am confused by your response because the screenshot I posted was of the Browser Tools Network tab - the "404 ... POST" you see is the JPG upload attempt. Here are more screenshots, with the request details panel open. I am not seeing any errors in the response: just the HTML for the site's homepage.

When a JPG is uploaded:

 

When a PNG is uploaded:
(and this is the same page, with no reload in between attempting these two uploads)

 

Request 1 and 3 are the JPG and PNG upload, respectively.

[ethanbeyer]

The more I look at this, the more it seems like it's an .htaccess issue. Some uploads work, some don't. I've just noticed that some Page Edit links resolve to the same 404 page, so this seems less like an image upload problem, and more like a routing problem. But as for the reason, I am completely stumped.

[matjazp]

Strange indeed. <div id="pageID"...></div> is your page404 markup? File upload is working? Try js debuging whwn upload fails. Enough space on disk?

[ethanbeyer]

1 minute ago, matjazp said:

Strange indeed. <div id="pageID...></div> is your page404 markup?

That's just what is rendered in an AJAX call to the homepage:

_main.php

<?php
// include page structure if not an ajax request
if(!$config->ajax):

    include("./_head.php");

?>
<div id="page">
    <div class="content-container clearfix">
        <div class="content current-content">
        <?php endif; // endif ajax ?>
         
        <?php // if ajax then only return $content
            echo $content;
        ?>

        <div id="pageID" data-pageID="<?php echo $page->id; ?>" class="d-none"></div>
         
        <?php if(!$config->ajax): ?>
        </div>
    </div>
</div>
<?php

    include("./_foot.php");

endif; // endif ajax ?>

 

[Robin S]

On 4/9/2019 at 3:36 AM, ethanbeyer said:

the network response to https://example.com/admin/access/users/edit/?&id=1266&InputfieldFileAjax=1 is a 404 with the HTML of my homepage.

I don't think this has anything to do with the home page specifically - it's the 404 page, which gets markup from _main.php because I expect that file is auto-appended to the template.

My suspicion is that some security policy on your server is interfering to block the normal PW behaviour, and the 404 is a side-effect. It looks like ModSecurity is not enabled though so perhaps something else. You could ask your hosting provider to check.

Are you using ImageSizerEngineImagick by any chance? Does the issue resolve if you uninstall that to use the GD default?

[ethanbeyer]

19 minutes ago, Robin S said:

Are you using ImageSizerEngineImagick by any chance? Does the issue resolve if you uninstall that to use the GD default?

@Robin S Holy macaroni. That was it. I thought I had tried everything. Where...where do I paypal you some beer money? Seriously. DM me if that's possible. I owe you big time.

[Robin S]

@ethanbeyer, no worries, just glad to help. ?

It would be good to get to the bottom of what is causing ImageMagick to suddenly fail though. @netcarver linked to this article recently in another topic: https://alexvanderbist.com/posts/2018/fixing-imagick-error-unauthorized
It deals with a new security policy relating to PDF conversion but I wonder if some other policy has been introduced that affects JPGs too. If so there might need to be a fix applied to ImageSizerEngineImagick. Maybe your host could shed some light on what policy is being triggered by your uploads? Or maybe @horst has heard something about an ImageMagick update that might be connected?

[ethanbeyer]

Thanks @Robin S, you are the realest. I am going to poke into the issue later this week because I'd also like to know what's going on with it - especially why its failure took over ProcessWire's normal routing for edits as well as error logging.