Forum

Thread tagged as: Problem, Error, Runway

Fatal error related to asset upload

Client's been merrily modifying his site (Perch Runway 3.0) but appears to have broken something.

He was trying to upload a new PDF to replace a current PDF in a particular Collection item. Something went wrong and it appears he tried uploading the PDF about ten times. Now the edit page for that item stops rendering at the point that the PDF asset field appeared, and this appears instead:

Fatal error: Uncaught Error: Call to a member function icon_for_type() on boolean in [redacted]/sherp/core/lib/PerchFieldTypes.class.php:1843 Stack trace: #0 [redacted]/sherp/core/apps/content/PerchContent_Util.class.php(583): PerchFieldType_file->render_inputs(Array) #1 [redacted]/sherp/core/runway/apps/content/modes/collection.edit.form.post.php(160): PerchContent_Util::display_item_fields(Array, '86', Array, false, Object(PerchForm), Object(PerchTemplate)) #2 [redacted]/sherp/core/runway/apps/content/modes/collection.post.php(2): include('/home/wowderkeg...') #3 [redacted]/sherp/core/apps/content/collections/edit/index.php(31): include('/home/wowderkeg...') #4 {main} thrown in [redacted]/sherp/core/lib/PerchFieldTypes.class.php on line 1843

The [redacted] is me obscuring the path for client privacy.

I'm not sure how to fix this problem, as we can no longer edit the item in any way. Suggestions appreciated!

Perch Runway: 3.0, PHP: 7.0.21, MySQL: mysqlnd 5.0.12-dev

Joel Davies

Joel Davies 0 points

  • 2 months ago
Drew McLellan

Drew McLellan 2387 points
Perch Support

Can you see the item in the Assets app?

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.

Drew McLellan

Drew McLellan 2387 points
Perch Support

Has removing the failed items resolved it?

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.

Drew McLellan

Drew McLellan 2387 points
Perch Support

Can you pick a new item in its place?

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.

Drew McLellan

Drew McLellan 2387 points
Perch Support

Are you able to undo?

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.

Drew McLellan

Drew McLellan 2387 points
Perch Support

I think it's that your server has a buggy EXIF implementation. Try turning it off:

define('PERCH_ENABLE_EXIF', false);

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..."

Drew McLellan

Drew McLellan 2387 points
Perch Support

Ok, it sounds like there could be another issue. Has anything else changed on the server? Is there plenty of available disk space?

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.

Drew McLellan

Drew McLellan 2387 points
Perch Support

Correct, that wouldn't affect your server - the point of the backup is that the files leave your server.

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?

Drew McLellan

Drew McLellan 2387 points
Perch Support

Why are you loading the staging config on the live site at all?