Posted by BarisW on April 24, 2007 at 7:41pm
7 followers
Jump to:
| Project: | ImageField |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
I made a form in CCK with an imagefield and deselected "Required".
However, if I create a node without an image and publish it, it still shows the image container.
I use it in combination with Imagecache, but I don't think this is the problem. If I disable imagecache temporary, the problem still occurs.
Output:
<div class="field field-type-image field-field-afbeelding"><div class="field-items"><div class="field-item"><a href="/pmi/node/"><img src="http://localhost/pmi/files/imagecache/page_thumbnail" alt="" title="" /></a></div></div></div>where 'afbeelding' is the name of the imagefield.
It looks like imagefield doesn't check if the image exists. Does anyone know how to solve this problem?
Comments
#1
I now see that there are empty rows in the table *content_field_afbeelding*
The row only contains data about vid, nid.
field_afbeelding_fid, Title and Alt are empty.
Any help?
#2
I can confirm this problem. It happens when you specify a imagecache derivatives on the Display fields" tab of Content types (admin/content/types/page/display)
For example, I added an optional image field called Feature image to my Page content type. I also have two imagecache derivatives: small and medium. If, in the display table, I set Teaser to small and Full to medium, if I submit a Page node without an image, I get broken image links every time. Even if one was never submitted.
A trip to the devel Render tab shows the following output (relevant excerpts only)
field_feature_image
Array
(
[0] => Array
(
[fid] => 0
[title] =>
[alt] =>
[view] => <img src="http://example.com/sites/example.com/files/imagecache/medium" alt="" title="" />
)
)
content
Array
(
[field_feature_image] => Array
(
[#weight] => 0
[#value] =>
<div class="field field-type-image field-field-feature-image">
<div class="field-items">
<div class="field-item">
<img src="http://pyramidpowersytems.5.harkeydesign.net/sites/pyramidpowersystems.com/files/imagecache/medium" alt="" title="" /> </div>
<h1>TEST</h1>
</div>
</div>
[#access] => 1
)
)
#3
What would help if we could set a default image for the imagefield at the administration level. It would then give us the opportunity to define our own thumbnail image, or even just a transparent gif to avoid the broken image that shows up in IExplorer.
#4
Possibly better solution: if no image is included, nothing should show up -- no placeholder image, no empty img tag, nothing.
#5
It's a hack for imagecache but it works:
http://drupal.org/node/88136#comment-230649
My version of imagecache is 5.x-1.3 and the line to change is 744.
#6
Hm... I'd say this looks a lot like the issue that was recently fixed in imagefield's DRUPAL-5--2 branch. Check out this patch, in the meantime I assume that this bug is a duplicate of the one stated above.
#7
If we had subject lines to comments on Drupal.org, this one would be:
In any case...
As a matter of consistent UI, if you've got a CCK field where, as Sixcolored says, "Required" is deselected, that means the field is optional. It doesn't have to be there. If it isn't there, there shouldn't be an error or default image of any kind.
This is how the system should work by default.
That said, of course, there's no reason not to make a default image available -- based on whether the CCK field is required or not.
I think that would work the best.
#8
@jpetso
Sorry, I just missed your post.
That thread is so confusing, it made me dizzy. I wasn't sure what problem was being addressed: whether the database entries were being cleaned up or the empty 'img' tag problem was being fixed.
Thanks for the pointer though. I'll try out the new version.
#9
Sorry, the thread is indeed confusing. I'll make sure to include the right comment anchor and maybe a link to the corresponding filefield issue which explains the problem much better than the imagefield one. (The bugs are one and the same, though.)
#10
And as far as I know, there are no fixes that have been applied to 5-1, the current Drupal release, correct? Also, the temporary fix referenced by patachon above doesn't seem to work, I'm assuming because this is actually an imagefield issue, not an imagecache one.
Duplicate or not, I'm not sure we can call this fixed until it's been applied to 5-1.
thanks,
Patrick
#11
By the way, my current hack fix around this is to test the strlen of what imagefield is returning in my customized node.tpl.php file. When there's an empty image, it's returning some dangling anchor tags, which in my case come to about 25 characters in size... anything greater than that I'm assuming is a valid image.
In this example I'm using the imagefield to upload an alternate thumbnail for CCK Video, so if the alternate exists I want to display that, if not I want the video field to display its thumbnail normally. field_video_alt_thumbnail is the imagefield.
<?php if (strlen($node->field_video_alt_thumbnail[0]['view']) > 25): ?><div class="video_teaser "><a href="<?php print $node_url ?>"><?php print $node->field_video_alt_thumbnail[0]['view']; ?></a></div>
<?php else: ?>
<div class="video_teaser "><?php print $node->field_video[0]['view']; ?></div>
<?php endif; ?>
#12
This is a really annoying, stupid bug. Please fix soon. There needs to be a little more logic in the code that decides to output these fields.
#13
Also, this is a critical code bug. I am kinda in shock how long this is taking to fix. Considering Drupal has no native image handling and CCK, imagefield, and imagecache have been represented as being the Drupalish solution, bugs like this need to go to the top of the queue. Here's the logic: if the image exists, print the image; else, print nothing. There.
#14
Please see my latest post on http://drupal.org/node/88136#comment-268349 with a new patch for imagefield for Drupal 5.1 to deal with the database issues. Seems to fix the problems I was having here.
Please note, after applying the patch, I had to resubmit old nodes to get the database entries to update appropriately (i.e. I clicked "edit" for the node and then "submit")
Patrick
#15
Well,
since http://drupal.org/node/88136 shows that a fix has been rolled for both Drupal 5.1 and 5.2 I'd say we can call this issue a duplicate and close it.