Error message

You need to log in or create an account to access this page.

I have created a function that will add files to the drupal db using:

$file = new stdClass();
    $file->filename = basename($file_drupal_path);
    $file->filepath = $file_drupal_path;
    $file->filesize = filesize($file_drupal_path);
    $file->uid = $uid;
    $file->status = FILE_STATUS_PERMANENT;
    $file->timestamp = time();
drupal_write_record('files', $file);
$fid = db_result(db_query("SELECT fid FROM {files} WHERE filepath = '%s'", $file->filepath));

And then added that file to my uberimage field within my content type with:
$node->field_page_main_image[0]['fid'] = $fid to the fid reference value of a field that is set to use the Uberimage widget. When I view the page, it displays the file correctly (in the right size and placement, etc--which makes me think it is using the uberimage_formatter correctly). But when I try to edit the page, the Uberimage widget is empty--showing an "upload image" button.

Do you have any idea how I can fix this?

Thanks for any suggestions...

Comments

dellis’s picture

dellis commented

Update:

It turns out that I needed to have the my_image_field[nid] = my_image_field[fid] (I had been leaving the image_field's nid empty). Anyway that fixed one problem, but now I need to find a way to save the height and width element of the image into a data format that uberimage will accept, as now I'm getting "Division by zero" errors from around line 633 in aef_image's function: _aef_image_creator_fetch_data

I'll keep digging on it myself in the meantime. Thanks for any help.

dellis’s picture

dellis commented

Update:

So it is definitely throwing the "Division by zero" error because the width and height values aren't being established for the image I've manually uploaded.

If I put a static value into the width and height variables in aef_image.module (lines 554-555), the error disappears, the node saves, the manually uploaded + attached image shows up in the thumbnail view (next to the title, legend and credit field), but when I expand the image formats drop-down, I get blank images. When I click on "edit" next to one of the custom image presets to re-crop/re-scale the image, the page refreshes and the image is no longer attached to the uberimage field--the thumbnail, etc are replaced with the "empty" upload button interface.

dellis’s picture

dellis commented

Still no luck on this end... any ideas/suggestions would be a huge help. Thanks

dellis’s picture

dellis commented
Title: file created with php, how can it respect the uberimage widget? » image uploaded with php -- can't "edit" within uberimage widget

Looks like if I make sure that my images are dumped to the default files directory (not a sub-folder or different folder) the division by zero errors go away. However, I still can't get the "edit" function to do anything but refresh completely and revert to an upload button (empty field).

So... it seems that when I go to the edit page, the uberimage field is reading my automatically created image data just fine--it even is showing a preview of the image in each of the custom sized imagecache settings. But, when I try to customize one of those sub-images, the widget doesn't seem to remember the image was attached to it. Like it resets from somewhere else...

dellis’s picture

dellis commented
Title: image uploaded with php -- can't "edit" within uberimage widget » image uploaded with php -- can't "edit" within uberimage widget - cached form values?
dellis’s picture

dellis commented
Status: Active » Closed (fixed)

Okay, looks like the thought of cached form values led me to the solution. It turns out that line 457 of theme_aef_image_aef_utilities_image in aef_image.module

  //This is an aef_image!
  if(isset($field_value['fid']) && isset($field_value['nid']) && isset($field_value['filepath']) == false)

Requires that the aef image field's nid value == 0; I had been using the fid value (in both places). When I was making changes to the values already in the database to match that of a "manually" uploaded aef image, and then reloading the form, it continued to show the same problem--but only because the form values had been cached already! (found this through line by line of theme-developer-enabled form_state review)

I changed my custom code to set the nid to "0", which according to this function should have tripped the "exception" case for aef images, and sure enough it worked!! It looks like I'm now quite able to upload images and custom crop the dynamically generated sizes at will.

I'll set this one to closed.

dellis’s picture

dellis commented