I'm using the latest stable versions of Imagefield and CCK, and wondering if there's a way to set a default image. Is this possible?

Comments

jpetso’s picture

Status: Active » Fixed

The 5.x-1.x versions don't have this feature, you need to use the 5.x-2.x ones (DRUPAL-5--2 branch from CVS, not yet released). The 2.x release works sufficiently stable, it should be at least as good as 1.x.

phasmaphobic’s picture

Is there a way to acquire the 5.x-2.x version?

jpetso’s picture

Yup, there is. If you follow the "View all releases" link on the project page, 5.x-2.x can be seen in a prominent position. It doesn't show on the main page because the maintainers can only choose one branch as "officially displayed".

phasmaphobic’s picture

Excellent. Thanks for the info!

phasmaphobic’s picture

Hm. The default pic doesn't actually seem to be applied as a default pic.

Just for testing purposes, I've created a new content type "Thingy" and attached a single imagefield to it, specifying a custom pic as the default (which it made me upload). It loads the image right there, too. Content type saved, I created a new Thingy, left the image location blank, and saved it, and the resulting page does not show a default image.

I've verified the display presets are correct, and then I edit the new Thingy and specify an image to upload, that image does upload and display correctly in all the associated views and pages.

I can supply any other data on it you need, if it helps.

jpetso’s picture

Title: Are default images possible? » How to insert a default image
Version: 5.x-1.1 » 5.x-2.x-dev
Status: Fixed » Active

I haven't tried this functionality yet (and don't feel motivated to check back on this now), so I don't know if it works correctly or what needs to be done to get the default image to show. Anyways, a status update for this issue.

storbaek’s picture

We need the option of an default image as well. I can confirm the issues mentioned in the previos post and in addition to this, it does not seem to be shown under 'Edit' after submitting the node.

storbaek’s picture

Hi there

The functionality has clearly been developed, but it still doesn't work. So the module has a clear bug! What is the status in this one. We would like to volunteer for testing if needed!

ms2011’s picture

Component: Miscellaneous » Code
Category: support » bug
Status: Active » Closed (duplicate)
ms2011’s picture

Status: Closed (duplicate) » Needs review
StatusFileSize
new1.76 KB

This adds the rest of the default image functionality. The part that was missing was a section in hook_field($op='view') and the corresponding part in hook_field_settings($op='callbacks').

(see attached)

Keep in mind that the current method may not be compatible with your other CCK field formatters like Thickbox, because the $fid = 0. I did make a patch for Thickbox, though: http://drupal.org/node/198311

dopry’s picture

Status: Needs review » Fixed

I tested it, she works... hurrah, and thanks. commited to DRUPAL-5--2

baja_tz’s picture

StatusFileSize
new10.35 KB

I can't get it to work in my views. Doesn't suppose to or I'm making something wrong?
imagefield: 5.x-2.x-dev
cck: 5.x-1.6-1
download method: public
views: 5.x-1.6

moshe weitzman’s picture

Yes, there is no support for default image in Views. Lets tackle that at http://drupal.org/node/162664

ms2011’s picture

StatusFileSize
new6.62 KB

Ok, yes, sorry about that everyone...

I have changed the approach to imagefield default images. Instead of avoiding an entry in the {files} table and attempting to pass around a $file['fid'] = 0 (which would have required patches to thickbox and imagecache), I just decided to create the entry and avoid all that mess.

So, now it works in imagefield, thickbox, imagecache, and views! No need for any other patches to those modules.

(see attached)

ms2011’s picture

Status: Fixed » Needs review
ms2011’s picture

StatusFileSize
new1.16 KB

...and this one is an add-on patch to the previous which makes the '... as link' field formatters work, too.

(see attached)

moshe weitzman’s picture

Priority: Normal » Critical

This looks very promising. I will try to review it soon. I think the approach is sound.

eigentor’s picture

I tried to patch the rc Version of December 6, but the patching failed. (giving me a .rej. file) Do I have to use the July Dev Version instead?
Or is the December Version already coming with the patch?
I tried it out as it is (the rc version) and my default image shows up inside a view, so it seems to work. Haven't tried with thickbox and other things though.

dopry’s picture

The last patch to apply cleanly to DRUPAL-5--2. Can you re-roll?

Also can you add more inline documentation, and explain the changes the patch makes here in the issue queue better?

ms2011’s picture

Status: Needs review » Needs work
StatusFileSize
new6.51 KB

Note to self: Don't cleanup whitespace (convert all line-breaks to Linux (LF), replace tabs with 2 spaces, strip end-line whitespace) on modules I don't own--sometimes it's just better to play nice. :)

There were also a couple changes to the DRUPAL-5--2 branch since I initially uploaded the patch.

I also found and fixed a bug that would delete the default image you uploaded if you saved the form without a file upload.

I also added a new feature which deletes the default image if you uncheck 'use default image' and save the form.

Here are both patches updated and re-rolled for the DRUPAL-5--2 branch:

(see attached)

The patch enables imagefield to accept default images by saving them in the {files} table (vs. the previous method of returning a fake $items array where $item['fid'] = 0, and then having to patch imagecache, thickbox, etc. in order to get that past their validation function(s)). Then, by manipulating hook_field($op='load'), hook_field($op='view'), and providing custom Views field handler functions, it checks nodes for existing images and inserts a default image when no other images are provided.

moshe weitzman’s picture

did you mean to set the status to 'needs work'?

ms2011’s picture

Status: Needs work » Needs review

*sigh* no, that must have been the mousewheel...

dopry’s picture

This patch doesn't seem to work for me...

I have a page with a table view and two field, my imagefield and the node title... I'm using the default formatter in the view. I do not see the default image... single value, not required imagefield. Am I missing something?

jpetso’s picture

Status: Needs review » Needs work

I don't like the patch. it's a hack. The issue here is that Views doesn't pass the widget because it handles all instances of a field at the same time, not caring about the content type that contain the different instances.

So the widget settings are content type (instance) dependent, and the field settings handle all instances. The right thing to do would therefore be a move of the default image settings from the widget settings to the field settings, where they can be accessed also from Views as $field['setting'] instead of $field['widget']['setting']. I say this patch is wrong, even if it might work.

yched’s picture

I agree with jpetso. Views treats the field as shared (even potentially) by several content types, so you shouldn't expect the view fields to have any instance-specific behaviour.
This is exactly the sort of things that draw the line between what's 'widget-' (read : instance) or 'field-' specific ("Why is the 'foo' setting forced to be the same between all content types" is a classic feature request on cck fields...)

dopry’s picture

Should be totally fixed for both imagecache and imagefield.

dopry’s picture

Status: Needs work » Fixed
liquidcms’s picture

Status: Fixed » Active

sorry to set back to active.. but perhaps you could state what version of these modules makes this work???

i have:

ImageCache 5.x-1.3
ImageField 5.x-2.x-dev (2007-Dec-17)

upgrading to latest imagefield i now get the default image showing for the node view; but it doesnt work in views

i did have most of this working with an older version and some patch code - but just realized it also didnt work with views.

perhaps i need imagecache 2.0 as well????

dopry’s picture

Status: Active » Fixed

You will definately need the most recent imagecache commits if you're using an imagecache preset as a formatter.

If you're using the 'Default' formatter in your views it should work.

liquidcms’s picture

Status: Fixed » Active

was about to post that updating to latest 1.x dev of imagecache fixed my problem.. and it did for one view.. but now busted in many places that were working with older versions and patches.

i can see the default image on the node itself; but most of my views show nothing

some views have the image as simply the path to the imagecache preset folder while others are simply blank.

would be soooo useful to have this work.. :)

liquidcms’s picture

so just to be clear..

i went ugraded back to latest of both these modules (figured if i need to fix this myself i should start with the latest code):

ImageCache 5.x-1.x-dev (2007-Dec-17)
ImageField 5.x-2.x-dev (2007-Dec-17)

- deleted all the default images that i manually put in icache folders before (necessary since icache wasnt creating anything)
- remove the theme_imagecache code i had in my template.php

- upload a new default image for my imagefield

- i can see that the image does get uploaded but i now have NO defaults in any of my views
- there are no icache files created

perhaps i need to be using icache 2.x.. ill try that next

liquidcms’s picture

ahh sorry didnt see your post... so this doesnt work then (and by that i think i mean the way someone would expect it to work)??

how can i use the "default" formatter? what's that??? you mean the preset value under "option" for the field in the view.. well that kind of defeats the entire point of imagecache doesnt it??? i have one view to use 1 preset and another view to use a different preset.. "default" has no meaning if you are using icache.

and by "most recent imagecache commits" ? any chance you cuold just tell me what version i need.. i have:

ImageCache 5.x-1.x-dev (2007-Dec-17)
ImageField 5.x-2.x-dev (2007-Dec-17)

both dated yesterday - not recent enough??

dopry’s picture

Status: Active » Fixed

Please do a clean install and test these features, before trying a custom install... Please open your issue with details specific to your situation instead of constantly reopening this issue! It sounds like you have a somewhat non-stock setup and this issue is already long enough, don't muddy it any more.

dopry’s picture

And yes I committed this code just hours ago. So yesterday would be too old you need to be working out of CVS or waiting for the packaging scripts to update the dev tar balls.

liquidcms’s picture

Status: Fixed » Active

would like it to be stock.. trying to get it there - but need to get this working a month ago so used some patches (maybe yours??) and some template code someone posted.

like i said in my last post.. i reverted everything back to stock.. but sounds like code a day old.. i'll pull from cvs and give that a shot.. thanks a ton...

and .. btw.. i do think imagecache has got to be one of the coolest Drupal modules out there.. and i have used a lot of them :)

dopry’s picture

Status: Active » Fixed

how can i use the "default" formatter? what's that??? you mean the preset value under "option" for the field in the view.. well that kind of defeats the entire point of imagecache doesnt it??? i have one view to use 1 preset and another view to use a different preset.. "default" has no meaning if you are using icache.

for the second time....

You need imagecache 2.x aka DRUPAL-5--2 for 'default image'/views integration with imagecache presets. 1.x will not work!

If you are using Imagefield 1.x you can test the feature by using the 'Default' formatter used provided by the 2.x imagefield.module.

If you don't know how views/cck fields/formatters interact I suggest you read the CCK handbook. After you RTFM come back and create your own issue.

Anonymous’s picture

Status: Fixed » Closed (fixed)

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

ms2011’s picture

Version: 5.x-2.x-dev » 5.x-2.0-rc2
Status: Closed (fixed) » Needs review
StatusFileSize
new5.99 KB

Ok, so I upgraded to ImageField 5.x-2.0-rc2, ImageCache 5.x-2.0-beta, and ImageAPI 5.x-1.0-beta. I did have to run update.php, and delete/recreate my imagefield fields, and clear cache. However, the default image field stuff still wasn't working 100% for me, although it did seem closer. There were a number of things I saw that needed to change:

  1. 'Default value' and 'Default image' were both options on the field configuration page. Very confusing having two default image fields to upload an image to. I uncommented your line for 'default value' => CONTENT_CALLBACK_CUSTOM and that made the one we're not using disappear. Works for me.
  2. The imagecache field formatter for _linked wasn't displaying images. This turned out to be a typo in imagecache (see also: my patch for imagecache).
  3. The imagecache field formatter for _linked wasn't linking to the node ID. This was because it simply wasn't present as $item['nid']. I solved this by adding in the custom field handler functions from the previous patch, which add the nid to the object during display.
  4. There was no way for modules/themes to get the $item['filepath'] easily. For example, a node object with an imagefield CCK field on it (e.g. $node->field_image) would only contain values like fid, title, and alt. No filepath. Even then, if no file was uploaded, the fid was 0. So this is actually two problems. In general I saw some repetition with the way default files were detected and handled, so I moved it all into _imagefield_file_load() which now handles detection of $field['use_default_image'] and replaces empty images. Then I also had to modify hook_field($op='load') to return the $item['filepath'] in a way that it could be appended to the $node object. This way developers can now just use $node->field_image[0]['filepath'] and it will either contain the path to the file, the path to the default file (as per $field['use_default_image'] setting, or 0 if no image is uploaded and use_default_image is off.

(see attached patch)

There is still one minor problem; maybe you can solve it. If you go to the node/#/edit page and scroll down to an empty imagefield field, you will see the default image as if it were previously uploaded by someone. Ideally, this should be blank, no? It even shows the filename of the default image and provides the user with the option to delete it. Although, if they try to delete it, it doesn't appear to work. It will disappear from their node/#/edit form, but the file is still in Drupal's files directory, and it appears just fine everywhere else. Kind of odd.

Hope this helps! :)

ms2011’s picture

StatusFileSize
new7.48 KB

@jpetso: Thank you for clarifying the difference between field and widget settings and behavior; I love your definition, very clear and concise:

Widget settings are content type (instance) dependent, and field settings handle all instances.

However, I disagree with your's and yched's arguments re. default images in imagefield...

Why should I have to create a new imagefield CCK field every time I want a new default image? I want one imagefield CCK field to be reused across multiple node types, and with each node type having its own unique default image. It's more flexible--why not? Plus, it's way more convenient when you're dealing with views that combine the display of multiple node types, and you want the imagefield from each node to appear in that view.

With that, here's a patch to move all the default image settings from hook_field_settings() to hook_widget_settings():

(see attached)

NOTE: Depends on patch above.

ms2011’s picture

StatusFileSize
new685 bytes

Re. my comments earlier about the remaining minor problem, this solves it. It works by watching for an empty $item['fid'] in imagefield_widget($op='form'), and it was easier than I thought! :)

(see attached)

NOTE: Depends on previous patches above.

dopry’s picture

Status: Needs review » Closed (fixed)

Please do not open closed issues for follow-ups! Open new issues for each bug and post the appropriate patch to it. Do not post patches for multiple bugs in one issue.