Fatal error related to asset upload

There were about 10 versions of this one PDF in Assets -- evidently the number of times the client tried to upload them. They were all nulls (i.e., file links could not be found, no previews). I deleted them while leaving the original unbroken PDF in place.

I don't know what was wrong with his efforts to upload the PDF; he sent me the file and it does not appear to be corrupt.

Not sure. I went to Assets first and removed the failed items, then went to the Collection edit form and found the error message blocking the rest of the form. So it may be the removal that triggered the error.

The form appears normally on other Collection item edit pages: no error messages.

No, the error appears where the PDF field should be. Can't get into the field. I'm assuming I have to get into the DB or do a restore at this point; not sure how to do the former.

Stupid of me to forget about Undo!

Okay, so I was able to Undo back to a state where the PDF field was no longer blocked by the error message.

The client wants to update that existing PDF. I have the PDF the client's trying to upload. It's not corrupt as far as I can tell; Acrobat has no issues resaving/optimizing it.

When I try to choose the new PDF from the collections field, the process seemed to fail. No error message, the form just refreshes and the field looks unchanged.

I navigated to Assets and sure enough, there was a new asset displayed with the right name. However, there is no preview; clicking on the preview link says "file not found."

So I deleted that bad Asset and tried to upload the PDF into Assets directly. THIS time I got errors:

Warning: exif_read_data(phpSTkzy4): File not supported in /home/[redacted]/core/lib/PerchImage.class.php on line 532

Warning: Cannot modify header information - headers already sent by (output started at /home/[redacted]/core/lib/PerchImage.class.php:532) in /home/[redacted]/core/lib/PerchUtil.class.php on line 1383

Warning: Cannot modify header information - headers already sent by (output started at /home/[redacted]/core/lib/PerchImage.class.php:532) in /home/[redacted]/core/lib/PerchUtil.class.php on line 1384

Warning: Cannot modify header information - headers already sent by (output started at /home/[redacted]/core/lib/PerchImage.class.php:532) in /home/[redacted]/core/lib/PerchUtil.class.php on line 1385

Warning: Cannot modify header information - headers already sent by (output started at /home/[redacted]/core/lib/PerchImage.class.php:532) in /home/[redacted]/core/lib/PerchUtil.class.php on line 1388

Warning: Cannot modify header information - headers already sent by (output started at /home/[redacted]/core/lib/PerchImage.class.php:532) in /home/[redacted]/core/lib/PerchUtil.class.php on line 1391

Warning: Cannot modify header information - headers already sent by (output started at /home/[redacted]/core/lib/PerchImage.class.php:532) in /home/[redacted]/core/inc/top.php on line 17

Just now tried to upload a PNG to Assets and got the same errors as above. So it's not a PDF issue; Assets upload is broken somehow.

I've been at Runway 3.0, so I upgraded to 3.0.9 and placed your EXIF false line in /config/config.php.

Unfortunately, that did not fix the issue. When I try uploading any new resource to any bucket via Assets, the upload appears to take place, but there is no preview and a dead link results.

FTP confirms no new file has been uploaded.

The only difference is I no longer get that cluster of error messages "Warning: exif_read_data..."

I've got a ticket in with the hosting provider (dreamhost.com) to try to determine if the platform has been updated recently. We're only using 8% of our RAM and 15% of our disk space (and that includes a dev subdomain).

I have backup set for Dropbox bucketing every six hours, which has created about 500MB of files, but that burden's on Dropbox, correct? At least, I see no "backups" or "dropbox" directory on the server itself.

Looking at server access and error logs has not been helpful. Error logs are mostly empty and when they aren't seem to relate to bot-blocking, not file upload activity.

I have my /resources/ directory placed outside the perch folder and have been poking around in it trying to see if anything's uploading. Then I noticed that all the various bucket folders and files all have the same modification date: the day we took the site live. This seemed odd, as I was certain we have uploaded resources since pushing the site live.

On a hunch, I SFTP'd into the site's STAGING subdomain, and sure enough, all the various PDF and image files we've been trying to upload are in staging.clientsite.com!

I'm bemused by this, because I'm pretty sure I tested file upload when we went live. I must have inadvertently updated an older version of my config.php file at some later date.

So, my question now is how best to fix this. I was trying the multiple config files trick and clearly got it wrong.

For our production site, I have a config.php file that looks like this:

<?php

    include(__DIR__.'/config.dh.php');  

    define('PERCH_LICENSE_KEY', '[redacted]');
    define('PERCH_EMAIL_FROM', '[redacted]');
    define('PERCH_EMAIL_FROM_NAME', '[redacted]');

    define('PERCH_LOGINPATH', '/[my-custom-perch-directory-name]');
    define('PERCH_PATH', str_replace(DIRECTORY_SEPARATOR.'config', '', __DIR__));
    define('PERCH_CORE', PERCH_PATH.DIRECTORY_SEPARATOR.'core');

    define('PERCH_HTML5', true);
    define('PERCH_RWD', true);
    define('PERCH_TZ', 'America/Chicago');

    /* Default Undo Buffer is 30, which I find is too high. */
    define('PERCH_UNDO_BUFFER', 5);

    /* Test fix for file upload bugginess 9/2017 */
    define('PERCH_ENABLE_EXIF', false);

The include file config.dh.php is meant for the staging subdomain at staging.clientsite.com:

<?php

    define('PERCH_SITEPATH', '/home/[redacted-user]/staging.clientsite.com/');

    define('PERCH_SCHEDULE_SECRET', '[redacted]');

    define('PERCH_DB_USERNAME', '[redacted]');
    define('PERCH_DB_PASSWORD', '[redacted]');
    define('PERCH_DB_SERVER',   'mysql.clientsite.com');
    define('PERCH_DB_DATABASE', '[redacted]');
    define('PERCH_DB_PREFIX',   'perch2_');

    define('PERCH_RESFILEPATH', '/home/[redacted-user]/staging.clientsite.com/resources');
    define('PERCH_RESPATH', '/resources');

    define('PERCH_IMAGE_LIB', 'imagick'); /* imagemagick is available on host; better quality thumbnails? */

    define('PERCH_SSL', true); /* only for staging and prod */

    define('PERCH_DEBUG', false);

    /* Site Behind Login blocks visitors unless they have a login. Set false or comment out for live site! */
    define('PERCH_SITE_BEHIND_LOGIN', false);

So, it seems evident that my staging config file is misdirecting file uploads to the staging.clientsite.com/resources directory. What's the best way to fix that?

If I repeat a properly-targeted PERCH_RESFILEPATH command within my production config.php BELOW the include, will it overwrite the staging version of that command?