View support with imagecache resizing images

My patch allows you to select the default imagecache profile in the taxonomy_image admin, if you have imagecache enabled. It enables view support, where you can also choose which profile (normal or link.) It needs a little clean-up, but it works for my purposes.

imagecache is optional. If you don't have it installed, this patch will just add views support, and adds a function which may still be useful:taxonomy_image_path.

This is sort of unrelated, but I used this patch to the views taxonomy module to allow nice lists of taxonomy terms with nodes (using term DISTINCT)

That seems to be just the job.

I was giving up with taxonomy_image since it doesn't allow easy sizing and had tried to implement it with another content type - nightmare.

I tried applying the patch using TextMates (a mac text editor) diff bundle and got an error reporting 'garbage in patch'. I applied the changes manually, and it seems to work.

It's really nice to be able to select the imagecache sizes in the view field listing.

Now its time to work out how to display a single taxonomy image for a listing of nodes in that category.

Thanks Konsumer

That's strange. The patch seems to work fine for me. Try using "patch -p0 < filename.patch" on the command-line, in the future, on a fresh cvs version (not a previously patched version.)

As for displaying one image at the top, put this in the view header:

replace "catbg" with your imagecache profile name.

I don't have CVS. I'm using the 5.x-1.x-dev version of Taxonomy image.

I tried 'patch -p0 < taxonomy_image.module.patch' in the directory with the patch and the module file and got the following …

I'm afraid I don't know if I am trying to patch incorrectly, or if the versions are the same, patching usually works via the diff bundle in textmate.

The module appears to work fine, but it would be nice if this was committed to a release version of taxonomy_image, or even a new module (taxomomy_imagecache_image ?)

PS
I ended up using a 'views block' to show the single category images header, since I can feed it arguments and use it on multiple pages.

Thanks,
Drew

Try this patch, instead. I used diff on the stable dir. Maybe that will fix it.

forgot to update the version.

Just applied this patch and things are working well except for the following:

In my view, I pull up the term that a node is tagged with and the view displays correctly -- node with it's associated tag. When I add the taxonomy image to be displayed with the node, the node is displayed TWICE! one with just the term and one with both the term and the taxonomy image. Weird no?

Any thoughts are greatly appreciated! I'm so close!!

***********************

oops. Sorry...answered my own question by applying the views patch suggested in comment #1.

http://drupal.org/node/195790

Yep. Basically I had the same issue and solved it with the other patch (that patch is a general taxonomy distinct filter, so it works for everything)

Glad it worked for you.

I will review this after I get bugs and support request done.

Subscribing

Actually, the Imagecache support was fairly simple. But there are a few things that worry me:

1. If Imagecache is being used, I am ignoring 'width' and 'height' entirely. Is that okay with everyone?
2. Imagecache does not have 6.x support and he hasn't announced any intentions for that. This could delay TI's 6.x support.
3. There is a beta version that will require ImageAPI. I have not tested with this. If someone upgrades Imagecache without ImageAPI (yes it can be done), I don't want people blaming me for their WSOD.
4. Imagecache has a pretty long issue queue that isn't getting smaller.

Oh, one added "benefit" is that I use "theme('image'," now, so it can be changed in the theme layer if you so choose.

@Konsumer, I'm attaching my version of this support as a zipped module file replacement (not the info or install). Can you save your current version and try this one, please?

Anyone else is welcome to try it as well and provide feedback.

BTW, there is a special added bonus. Brownie points go to whoever notices it first.

Nancy,

It seems you added access control to allow admin users to disable Taxonomy Images. Not sure I will need that. It also seems you removed the ability to call taxonomy_image_display() with the Imagecache profile appended to the arguments
eg …
taxonomy_image_display($tid, $tags, $ic_profile) … as in Konsumers original patch.

It means I cannot call taxonomy_image_display() in a separate module to make a custom block with imagecache scaling.

I'm either missing something or am I supposed to apply Konsumers patch to the above Module?

Thanks.
Drew

Hmm, my copy here says function taxonomy_image_display($tid, $tags = null, $profile = null) and allows the profile to be specified. I just looked at the zip file above and it's there too.

The user disable feature has been there a while, and you don't have to allow it.

And, BTW, $tags should be an attributes array now, as everywhere else in Drupal. However, I still allow them to be a string as before.

Sorry,
Entirely my mistake, my download folder already had a complete copy of the module untar'd, I assumed that was from your zip file. Installing that on my test site made me think it was missing the extra code. I have just noticed that the version I had installed was the 5.x-1.x-dev (2007-Jun-19) version, hence the lack of user admin settings.

I guess I should have realised from your posts stating that the zip didn't contain the .info ot .install files.

So far it works with the 1/2 dozen taxonomy images & imagecache profiles.

Thanks,
Drew

Great, thanks, Drew. Did you, by any chance, try a View with this code?

Hint: add an image to a term that doesn't have one yet.

I created a view and added the field Taxonomy Image and selected an imagecache preset. It showed up in the views listing as expected.

I also added a new image to an 'imageless' term but I can't see anything new? Sorry you may have to be more explicit to get me to understand :)

Drew

I fixed the node types on the image management page. That's been driving me crazy since I started using TI.

Differences between my version and Konsumer's

1. Views support should be the same - I used his code. Thanks, Konsumer.
2. Slight differences in Help text - should have no effect.
3. I don't default to "ORIGINAL" - I think this is a site-specific setting.
4. But I do have "<none>," which will turn off Imagecache use. It is the default.
5. I don't remove the "old" settings. This allows the caller to override using Imagecache at run time.
6. While it achieves the same effect, I did not move the old resizing to a new function. I probably should have.
7. I am following Drupal coding standards.

I think most of these are only going to be visible to the admin. But the developer has a bit more flexibility, IMO.

BTW, I just noticed that I duplicated the "Picture resizing" title - I'm changing those to "Picture resizing - automatic" and "Picture resizing - manual".

LOL,
Now I see. I hadn't really given that bug @post 19 much thought, it's nicer now it works.

I'm glad you are following Drupal coding standards, I'm just learning module writing at the moment, there's so much to remember, maybe we need a coding standards module :-P

Thanks Nancy,

Drew

3. ORIGINAL is not site-specific, it's the default behavior, it means "don't use imagecache", which seems to be what you did in 4. This follows the convention of other modules that use imagecache profiles, especially in views.
5. I don't understand this.
7. What Drupal coding standards am I not following?

I'm fine with either version, and happy that my code was helpful, especially if that gets into TI, I'm just sort of confused about the differences. I see a lot of surface changes in the diffs, but can't actually discern any functional difference between the 2. This makes it hard to review, as it seems like it's just the same thing with ORIGINAL changed to <none> and small changes to help. I want to understand the differences so I can comment on any improvements that you made to my code, and I'm sure I'm missing something.

@drew: http://drupal.org/project/coder ;-)

@konsumer:
3. Hmm, I'm not very familiar with using Imagecache. Do I need to add "ORIGINAL" as an option or is it the same as my "<none>"? I want to leave something so that Imagecache can be totally overridden.
5. Your code hides the standard TI resizing choices if IC is enabled. As I said, I want the run-time ability to override IC.
7. I can't remember them all (use Coder to find them), but I know there was at least indentation (2 space rather than 4), concatenation formatting, and control structure ("} else {") errors.

You're not necessarily missing anything. Your code is the largest part of the changes. Perhaps, in the end, my changes are only cosmetic. If you can't detect any functional differences, then it's the same.

Whenever you say the word, I can commit this. I changed "<none>" to "ORIGINAL". I put the two resizing techniques into separate (collapsible) fieldsets.

I also added a class to the radios; I suggest you add this to your CSS:

Fix committed to -dev.

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

#3 - konsumer :

Your views header snippet for displaying taxonomy image at the top of a view works well for me. Thanks for the code.

I'm glad this was committed, thanks Nancy and Konsumer.

There is a couple of things that are not quite right yet though.

1. The image cache preset selection could do with the option to use the image with a link to the category - just like images displayed in a node view or image cache files displayed via a view.

eg The imagecache Preset would say…
ImageCache_Profile_name (normal)
ImageCache_Profile_name (with link)

2. From a usability point of view a list select list would fit better, I have around a dozen presets and its confusing as radio buttons.

I suspect these are relatively minor changes so I will try to make a patch, I'm just posting incase anyone else has spotted this and started already. I realize Drupal 6 is knocking at a lot of developers doors at the moment and now is not a good time to be picky :)

D

Thanks, Drew. Since this issue is already closed, please open a new one - well, actually two.

It's interesting, most people prefer the radios rather than a select list.

We already have a D6 version, so that's not an issue.