Hi,

I've been trying to nail down an odd issue where I can't remove an image once it has been added to a node. The image is loaded in as a FileField (with ImageField), and there can be multiple images added.

The specific error message is: "An HTTP error 500 occurred. /filefield/ahah/page/field_image1/1"

I can upload images just fine, just seems to be something funky going on with the post request to remove the image. Does anyone have any ideas where I can look to help resolve this?

Let me know if some other information would be helpful.

Thanks!

CommentFileSizeAuthor
#13 Firebug-Error-Response-JSON.zip71.5 KBJoyy
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

prairiehippo’s picture

Just as a follow up - I'm pretty sure it has to do the server setup.

I had to enable "RewriteBase /" in order to get Clean URLS working on the server. Digging into things with Firebug, I notice that I get an Error 500 everytime I load the edit node screen. Everything loads correctly in the browser and can be edited (except for the problem I mentioned above), but the very first GET returns the 500 error.

So, to summarize, I'm not entirely sure this is a bug with FileField, but it is this module that is failing in this configuration. I've tried removing straight file fields to no avail.

If anyone can point me in the right direction towards fixing this, I would be very grateful.

Thanks!

allforabit’s picture

I was having this problem also. As far as I can see it was to do with a conflict with another field. I removed an on/off textfield from the content type and it started working correctly again. I then re-added the on/off textfield field and it still seemed to work fine. Don't know why but it did the trick anyway!

JefferyMac-dupe’s picture

Experienced precisely this same issue described above, but it was isolated to a few specific nodes on the site I was developing.

I spent a full day pulling my hair out on this, but eventually I traced the problem back to an Apache module -- the Post that was submitted when the user tried to upload or delete an image in imagefield would trigger a mod_security2 rule violation *if* the contents of the node body contained the word "from". Esoteric to say the least.

If you have root access on the server and you're running mod_sec, check the mod_sec logs and proceed from there.

The solution I implemented was to disable the mod_sec rule that was being triggered.

quicksketch’s picture

Category: bug » support
Status: Active » Fixed

Thanks everyone for your input here. I don't think there's anything to be done on the FileField side so I'm marking as fixed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jrust’s picture

Argh, same error, but it only occurs in IE. Subscribing just so I don't lose track of some of the solutions here.

jrust’s picture

Followup, my problem turned out to be #404234: Ajax bug on upload/delete Ubercart images

bfdi533’s picture

Status: Closed (fixed) » Active

We are experiencing this on or site and it has nothing to do with mod_sec as we are not running this (not even installed on the server).

How do I go about tracking this down? I do not really want to create the fields in this content type to get this fixed as there is lots of content now. I see someone mentioned firebug. How do i use this to track the error down?

lonestar790’s picture

Hey Guys-

An HTTP error 500 occurred.
/filefield/ahah/profile/field_content_image/0

I am having the same problem too. I am up to date with Filefield and ImageAPI. All but one of my content types allows me to upload into the field. All of my content types upload into field_content_image so I can make view call across all of my content. I have added another separate image field to the content type that is giving me problems and the other image field does not work as well. However every where else it works fine. I have checked the server memory and the permissions and all seem right. Any suggestions would be great!!. Is there any way to disable the ahah for the field?

Thanks-

Tony

goophy’s picture

Hi Tony I have the same problem as you, were you able to fix it ? any sugesstions?

suydam’s picture

This problem is possibly related to ModSecurity settings in Apache. That's certainly the culprit in my situation.

Check your apache error logs.

More information: http://drupal.org/node/368422

It's also discussed briefly in CCK issue queue: http://drupal.org/node/265255

quicksketch’s picture

Status: Active » Closed (fixed)

Thanks suydam. Once again nothing to be done by FileField, so I'm closing this again.

Joyy’s picture

Version: 6.x-3.0 » 6.x-3.10
Category: support » bug
Status: Closed (fixed) » Active
FileSize
71.5 KB

Hi,

I am facing similar problem as mentioned in comment #8.

When I try to delete an image using filefield in a blog content type, I get the error "An Http error 500 occured.
/>/filefield/ahah/blog/field_content_images/0\"

When I check the error logs in the server, I get this,
PHP Parse error: syntax error unexpected '<' in /home/DOMAINNAME/domains/www.DOMAINNAME.com/prod/profiles/drupal_commons/modules/contrib/cck/content.module(1694) : eval()'d code on line 1 referer: http://www.DOMAINNAME.com/node/XXXX/edit

I also checked with Firebug and I get JSON output error (see attached file).

But I cannot recreate this error in my Local WAMP environment.

Local WAMP setup:
GD library bundled (2.0.34 compatible)
Memcache admin Memcache included
Memcache integration Memcache integration functions are loaded
Memcache version 2.2.5
MySQL database 5.1.36
PHP 5.3.0
PHP memory limit 512M
PHP register globals Disabled
Unicode library PHP Mbstring Extension
Update notifications Enabled
Upload progress Not enabled
Web server Apache/2.2.11 (Win32) PHP/5.3.0
getID3() 1.7.9-20090308
jQuery UI 1.6
jQuery Update 1.3.2

WebHost Setup:
GD library 2.0
Memcache integration Memcache integration functions are loaded
Memcache version 3.0.4
Memcached version 1.0.2
MySQL database 5.1.49
PHP 5.3.3-7+squeeze3
PHP memory limit 512M
PHP register globals Disabled
Unicode library PHP Mbstring Extension
Update notifications Enabled
Upload progress Not enabled
Varnish status Varnish running.
Web server Apache
getID3() 1.7.9-20090308
jQuery UI 1.6
jQuery Update 1.3.2

I have tried following:

  1. Checked with my web host whether Mod_sec is installed and whether it shows error. My web host clarieifed that Mod security is not installed.
  2. Checked with web host whether using PHP as FastCGI there's a MaxRequestLen value that can be set here "/etc/httpd/conf.d/fcgid.conf".If it is set to something like 128KB then change it to 15MB "MaxRequestLen 15728640". To which web host clarified that they do not use FastCGI.
  3. Checked the file system permissions, which were set properly as per http://www.lullabot.com/articles/keeping-drupals-files-safe
  4. The modules and settings are almost the same on my Local WAMP environment and the Web Host
  5. Increased PHP limits in .htaccess file as,
    php_value memory_limit 512M
    php_value realpath_cache_size 100M
    php_value upload_max_filesize 100M
    php_value post_max_size 100M
    php_flag magic_quotes_gpc off
  6. Forced web host to use php5 with following lines in .htaccess file,
    AddType x-mapp-php5 .php
    AddHandler x-mapp-php5 .php
  7. Switched the upload progress display for a file or image field from a bar progress meter to a throbber. Even removed APC Upload progress.
  8. Talked to [bfdi533] from above comment #8 and got this reply,
    "I am sorry to say that I never did really fix the issue. We ended up deleting the filefield for the image from the content type, saving the content type and then re-adding the filefield to the content type and then the field worked for us. The problem was that we lost all of our images that were associated with this field and I had to use custom CLI php code to get the files "linked" back into the filefield field. Very painful and I might have the PHP code lying around somewhere if you want but it was very ugly and ran into big problems with the server running out of memory regularly so I kept having to edit the code and run it again starting at a different NID and then edit the code to start where the last one crashed, etc. Not pretty but we got the content back in there on over 5000 nodes. Ouch.
    Sorry, I wish I had better news but that is what we did. Never did really get fixed. "

    I tried removing the image field from blog content type (but still used by other content types) and saved the content type. Then again added the (existing shared) field but it did not solve my problem.
  9. Checked error logs in my server which gave this,
    PHP Parse error: syntax error unexpected '<' in /home/DOMAINNAME/domains/www.DOMAINNAME.com/prod/profiles/drupal_commons/modules/contrib/cck/content.module(1694) : eval()'d code on line 1 referer: http://www.DOMAINNAME.com/node/XXXX/edit
  10. Checked error with Firebug (see attached JSON error output)
  11. Tried to turn php error display WSOD type / http 500 errors by adding following lines at the top index.php file,
    ini_set("display_errors","1");
    error_reporting(E_ALL);
    Note: This stopped the error and removed image using the remove button. (though the file doesn't get deleted from the server)
  12. There is hackish way to solve this, which I kept as a last resort. For the 'Remove' button to work and not give Http 500 error, I had to bypass the AHAH process. For this I commented out Lines 314-325 in the file, /filefield/filefield_widget.inc
    /**
     *    '#ahah' => array( // with JavaScript
     *     'path' => 'filefield/ahah/'.   $element['#type_name'] .'/'. $element['#field_name'] .'/'. $element['#delta'],
     *     'wrapper' => $element['#id'] .'-ahah-wrapper',
     *     'method' => 'replace',
     *     'effect' => 'fade',
     *   ),
     */
    

    Now, the removal works but in a hackish way that it reloads the Node Edit Form while deleting the file. However, I still need to find a proper solution for this.

My web host is convinced that it is a code error (as reported in the error log) or some incompatibility with php/library versions.

P.S.: I have solved my upload Http error 0 by disabling 'show memcache output in every page' in memcache admin settings.

quicksketch’s picture

Category: bug » support

PHP Parse error: syntax error unexpected '<' in /home/DOMAINNAME/domains/www.DOMAINNAME.com/prod/profiles/drupal_commons/modules/contrib/cck/content.module(1694) : eval()'d code on line 1 referer:

This means that you probably have PHP code in a textarea somewhere, such as for a default value. This may happen accidentally if you have WYSIWYG editor that is inserting empty <p></p> tags into a textarea intended for PHP code. I'd suggest checking the line number mentioned in the error and work backwards from there.

Joyy’s picture

Hi,

Thanks for the reply. I am getting the same PHP Parse error for other pages as well, which are not even a Node (with Node Edit Form/Wysiwyg). For example, one page has only a set of 'Views' displayed via Panels. Another page is a User's profile page.

Though I tried to remove all empty codes like <p></p> from this particular Node Edit (where I am getting http error 500) but I am unable to stop PHP Parse error coming in the ERROR LOGS. And there is no log of the actual error.

In my Server ACCESS LOGS, it gives following Http Error 500 logs:
POST /filefield/ahah/blog/field_content_images/0 HTTP/1.1 500 1555 http://www.DOMAINNAME.com/node/1908/edit Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
GET /node/1908/edit HTTP/1.0 500 42333 http://www.DOMAINNAME.com/blog/XXXXXXX Mozilla/5.0 (Windows NT 6.0) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.60 Safari/534.24

And just to remind you that i am unable to recreate the http error 500 during deleting images in my LOCAL WAMP Environment.

Regards,
Joyy

quicksketch’s picture

The call to eval() that is causing this error has to do with the "allowed values" for some field on your site. Here's the bit of code that is mentioned in your errors that you posted above:

1692   if (isset($field['allowed_values_php'])) {
1693     ob_start();
1694     $result = eval($field['allowed_values_php']);
1695     if (is_array($result)) {
1696       if ($flatten) {
1697         $result = content_array_flatten($result);
1698       }
1699       $allowed_values[$cid] = $result;
1700     }
1701     ob_end_clean();
1702   }

Check the configuration of your fields in the content type that is giving you trouble. One of them contains the bad PHP code.

Joyy’s picture

I understand that this could be the root cause of the problem. However, i have a lot of fields and modules (like emfield, xmlsitemap, Locations and Gmap, Options widget linked to Rules for publishing workflow) enabled and it would be daunting task to disable/fiddle with each one of them to find the root cause.

However, setting php to display errors in .htaccess file as below removes the error (at least makes it hidden/overriden and remove the image from the field),
php_flag display_errors on

Also I checked the apache logs in my local WAMP and I found the same PHP parse errors in the list there, however possibly due to some setting in php.ini they were getting "ignored".

Then, I was finally able to recreate the error in my Local Wamp setup by adding following line of code in the .htaccess file:
php_flag display_errors off

Joyy’s picture

Status: Active » Closed (works as designed)

Hi,
I believe found the problem.
In one of the fields in the content type, I had 'Radio buttons / Check boxes', and to remove the additional 'N/A' button which creeps up if you start with empty Allowed values list for the , I had added following PHP code:

  unset($vars['form']['group_if_in_fieldset']['field_the_radios']['value']['']); //remove the pesky CCK N/A radio

I guess it was caught up in cck content.module allowed php values (probably cause i had mistakenly included delimiters as well) and was causing the PHP Parse error.