[drupal-devel] node-associated image module--advice wanted
I'm thinking of upgrading my old node_image module and looking for some advice. The basic aim: to have node-associated images in two sizes--full and thumbnail, to display in node lists and full displays. When I wrote the module, a thumbnail image could be displayed with the node 'teaser' (e.g., on a taxonomy term page) and a full size image with the full node display. The module also included inline image uploading and taxonomy term image association. I didn't upgrade node_image for 4.5, mainly because new modules had been produced replicating much of the functionality (image_assist for inline image uploading, taxonomy_image for term images), and doing a better job. But, to my knowledge, we don't have another way of associating images with nodes. What I'm wanting advice on is, what approach to take? We've come a long ways in image handling in Drupal, but we still have a number of somwehat incompatible approaches. We can now associate images with users, themes, taxonomy terms, and nodes, but in each case there's different logic and user interface. 1. The user atavars (images associated with users). This approach adds a field to the user create/edit form, uploads an image file, and stores the file reference in a "picture" field (in the user table). 2. The theme screenshots (images associated with themes). I haven't looked closely at the implementation logic. 3. The taxonomy_image module (images associated with taxonomy terms). This approach handles images separately from taxonomy term creation/editing and creates, storing image path information in a dedicated table. 4. The (new and improved) image.module (images as nodes). This includes support for multiple sizes (e.g., thumbnails) and handles each image as a node. The question: which of these approaches is the best model for node-associated images? Which one would be the best to follow in the interests of moving toward a uniform approach to image association?
Hi.
I'm thinking of upgrading my old node_image module and looking for some advice. Great!
I didn't upgrade node_image for 4.5, mainly because new modules had been produced replicating much of the functionality Please keep considering this, when updating your module. We really do not need more of the same. Not even when it does that more-of-the-same in a slightly different way.
IMO we should really get ourselves together and develop *one* *standard* image to node system. Why? * usability: One good working solution, that is maintained over development cycles will help our consistency and help people getting used to one system. * completeness: one full implemented sulution obviously is much better then three half implemented. Even if 1 < (3 * 0.5).
but in each case there's different logic and user interface.
What path to take: IMO starting with this problem in mind is a very good start. :)
The question: which of these approaches is the best model for node-associated images? Which one would be the best to follow in the interests of moving toward a uniform approach to image association?
IMO none of them, really. IMO the model does not really matter, as long as it is used consistent and everywhere! My idea, is that we have various technologies to achieve the same theing for an end-user: show an *inline* image on a place in a text. We, developers, see all sorts of images: nodes, attachements, files, uploads etc. And thus we tend to treat them different. Wrong, wrong, wrong! They might *be* differentm, yes, but they should never be treated that way. The end user should never, ever, have to bother about the technology behind an image. so, that all sayd: We need a simple, extendable (is that a word?), and *global* (as in standard, as in used everywhere) way to add an inline image to *any* text. Enter filters: IMO a simple filter token, in the form of [image: XXXXXX] should do the trick. Then the next step would be to make sure all texts (comments, nodes, descriptions, biography, blocks, mission, footer, header, whatevers, etc) are ran trough filters. How exactly [image: XXXXX] would work does not (yet) really matter IMO. and what XXXX can, or should be, does not matter either IMO. It could be the filename, a nodeID, etc. But it should be standard, and easy to remember and learn (node ids are not easy to remember and not easy to learn). And there could be various "command line options" for that token. (only described in a help text under "advanced" ). Those options can be stuff like CSS classes, sizes, alt texts etc. but IMO the defaults should be automatically created and should be good: A user *may* give a size, but is never forced to; the default sizes, when not given are good enough. so, to get back to your question: I do not beleive we need yet another image to node implementation, but rather an "abstraction layer" that will be used by users, and by applications like img_assist. Ber --
On Saturday 23 April 2005 03:38 am, Ber Kessels wrote:
My idea, is that we have various technologies to achieve the same theing for an end-user: show an *inline* image on a place in a text. We, developers, see all sorts of images: nodes, attachements, files, uploads etc. And thus we tend to treat them different. Wrong, wrong, wrong! They might *be* differentm, yes, but they should never be treated that way. The end user should never, ever, have to bother about the technology behind an image.
Apologies in advance for tooting my own horn, but I just wanted to point out that I consider an integration of Drupal components an important feature and have tried to implement this in my img_assist module. A couple of examples: 1) When inserting an inline image, it knows the capabilities of the receiving textarea. If it can handle input formats a filter is inserted. If not HTML is used. Img_assist even has hooks for rich-text editors to register a callback upon image insertion, all transparent to the user (unless they have permission to choose their own output). 3) Images are collected from the files table rather than being module dependent. So it doesn't matter if an image was uploaded with upload module, image module or something else, it'll show up in the image browsing window. Matt
On 4/23/05, Ber Kessels <berdrupal@tiscali.be> wrote:
Enter filters: IMO a simple filter token, in the form of [image: XXXXXX] should do the trick. Then the next step would be to make sure all texts (comments, nodes, descriptions, biography, blocks, mission, footer, header, whatevers, etc) are ran trough filters. How exactly [image: XXXXX] would work does not (yet) really matter IMO. and what XXXX can, or should be, does not matter either IMO. It could be the filename, a nodeID, etc. But it should be standard, and easy to remember and learn (node ids are not easy to remember and not easy to learn). And there could be various "command line options" for that token. (only described in a help text under "advanced" ). Those options can be stuff like CSS classes, sizes, alt texts etc. but IMO the defaults should be automatically created and should be good: A user *may* give a size, but is never forced to; the default sizes, when not given are good enough.
The image_filter module (http://drupal.org/node/9707) already does exactly this. With this module, you can enter "[image:nid]" in the body of a node, and that string is replaced with a thumbnail of the image specified by that nid. Latest version of this module is for 4.5, and I doubt it would work with the new image module, given all the changes - but it really should be upgraded to 4.6. I use image_filter on my site, whenever I'm writing a new article, and I want to whack an image in somewhere. The module has a whole bunch of parameters, such as alignment, thumbnail heigt/width, etc., making it easy to customise each inline image. It should allow you to enter the node title instead of the nid (usability issue) - but that's something the 4.6 version can address when it's released. I agree that using a filter is the best way to go about handling images in nodes. I'd also like to see filtering be applied to all text that's outputted on the page. That is, things other than the body of a node (e.g. taxonomy descriptions, headers, footers, mission statements, block content) should have filters applied to their text. Jaza.
Was there any more discussion on this issue? Are you working on something Nedjo? I am very interested in something like this. While I understand Ber's desire to make a full abstraction layer I guess I wanted to check what our main functionalities would be. Personally I am most interested in this: I want to be able to associate an image with taxonomy when I create that taxonomy at (www.example.com/admin/taxonomy/edit/term/# or www.example.com/admin/taxonomy/add/term/#). Then I want to be able to access this image in my style's via the $terms array. On top of that I want to be able to let child taxonomies of a term with an image cascade up and show that image. And as always these should be wraped in links to the taxonomy lists. I think this was the idea behind taxonomy_image (not updated to 4.6 yet/ever?). Could we lay out what other functionality we want to have in a node associated image? I am going to working on hacking this functionality into my themes, but I would be glad to help get this working. I am a little nubile in these areas so forgive me if I am repeating an ongoing conversation. bryan
On top of that I want to be able to let child taxonomies of a term with an image cascade up and show that image. And as always these should be wraped in links to the taxonomy lists.
I think this was the idea behind taxonomy_image (not updated to 4.6 yet/ever?).
Yes, taxonomy_image will allow you to do this. I have not had the time to upgrade that module to 4.6 yet, but I plan to by the weekend. It hasn't happened yet as I was planning to see if the new image.inc could replace some of the custom functions currently performed within the taxonomy_image module. The taxonomy_image module intentionally has a very narrow feature set. I have no intention of making it any more complicated. I rely on the module for my website, so it will continue to be upgraded and maintained. I usually try and upgrade my modules prior to an official Drupal release, but have been lacking in time of late. Cheers, -Jeremy
What I'm wanting (and what node_image had) is simply to have a parallel ability to associate images with nodes, just like we have for taxonomy terms in taxonomy_image. This is in practice, e.g., at gworks.ca (still running drupal 4.4!) where nodes and terms can have their associated images (both thumbnail, as on the main page, and full size, as on taxonomy and node pages), with term images substituting where a node has no associated image.
On Apr 25, 2005, at 10:53 PM, Jeremy Andrews wrote:
Yes, taxonomy_image will allow you to do this. I have not had the time to upgrade that module to 4.6 yet
Sorry to be a nag, but did you make any progress on this? I would love to use your module but might have to program my own custom solution soon. Any way I could help? thanks, bryan
Sorry to be a nag, but did you make any progress on this? I would love to use your module but might have to program my own custom solution soon. Any way I could help?
It's ueful to contact a module author, but you can always help by submitting a patch to an existing module needing upgrading. Just: * read over the documentation in the handbook on what's needed to convert modules * make needed changes to the current CVS version * test, make any more needed changes, generate a patch * create an issue for the upgrade using drupal's issue system, posting your patch (or, if you don't have the ability to generate patches, post the revised code).
Yes, taxonomy_image will allow you to do this. I have not had the time to upgrade that module to 4.6 yet
Sorry to be a nag, but did you make any progress on this? I would love to use your module but might have to program my own custom solution soon. Any way I could help?
Submitting a patch would be great. I didn't have time last weekend, and I won't have time next weekend. Maybe during the following week. -Jeremy
participants (6)
-
Ber Kessels -
bryan kennedy -
Jeremy Andrews -
Jeremy Epstein -
Matt Westgate -
Nedjo Rogers