Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By nedjo on
I'm creating this topic as a space for discussion of image support in Drupal--where it is now, where it's going, who's taking on what, how we might coordinate efforts towards integrating existing support into the Drupal core.
There are several "contributions" within Drupal toward image support in Drupal. These include:
- image.module
- node_image.module
- imageapi
Together they provide some useful functionality. But there are also limitations:
- significant overlap/lack of integration
- limits stemming from lack of integration into Drupal core
For example, proper, theme-independent display of images "associated" with particular nodes and taxonomy terms (a feature of node_image) would require patches to several core modules (on this point, see this post).
There are probably two basic components to core image support:
- an API for handling image files and associated database information
- feature implementation (display, input and upload, formatting, etc.)
Toward potential integration of image support into the Drupal core, some questions for discussion:
- What are the current initiatives and who are the developers?
Are there initiatives I've missed? Is there already a lead indentified in the Drupal development team? Are current image-related "contributions" all suited for integration into the core, or are there portions that would best remain stand-alone modules? - What is the appropriate forum for image support discussion with the Drupal development team? Is there a member of the Drupal development team available to play a lead or liaison/mentorship role?
While the standard process of submitting patches works fine for minor enhancements, for major initiatives (potentially affecting many core modules and themes) discussion, planning, and leadership and/or mentorship from the development team would be a big boost. - How can we usefully divide tasks and responsibilities?
This could be, for example, a lead on each of the API and feature sides. - What is a wish-list of features for core image support?
This might include features currently sketched in in modules plus more.
For my part:
- I feel like the image support I've sketched in - particularly "associated" images for each node and taxonomy term - only really makes sense as part of the core (since adequate support would require edits to core modules).
- I welcome the image API initiative and would be happy to adapt code to work with it.
- In general, I'm interested in contributing to integrating image support into the Drupal core
Thanks, I look forward to suggestions and comments from other members of the Drupal community.
Nedjo Rogers
Comments
Document handling
I believe document handling is a much needed feature. Here is how I'd like to use it. There might be other use cases though.
I'd like to be able to upload one or more documents and associate them with a node. The documents are most likely to be images, though sometimes I'd like to upload a PDF, Word document or patch too. We should use a single upload form for all kinds of documents. Think document handling, not image handling.
image handling = generic document handling + specialized image extensionsBack to my use case. Once the documents are uploaded, I want to know their relative paths (eg.
files/foo.jpg) so I can use them in my post. Thus, I don't want Drupal to add a download link or to display the images for me: I want to control their placement, size, and descriptions. I realize that some people might want to have Drupal automatically show images for them at the bottom of their post (eg. in case you are not familiar with HTML), so maybe we should have 'show' flag for each uploaded document. When the flag is set, Drupal shows the document for you.I'm glad you are taking a lead in this, Nedjo. This should be part of core, so I'm looking forward to your patches and to work on this with you.
Yes, Document Handling
Would it make sense to have each file type be processed (parse and store meta-data, update search indexes, etc) by a more specific node if an appropriate node is available? This conversation seems to be parallelling the one here:
http://drupal.org/node/view/6850.
In fact, tinkering with the node_image module is what brought about the realization that some document storage framework needs to be developed.
Nedjo, if I can be of help, let me know. I don't know if my preconceived notions would hinder or help, but I'll make them available if you're interested ;)
Media Handling
Why not media handling? What about a module that handles all popular media realia? I have yet to find a CMS that offers this capability. Drupal could be the first on the block to offer a true multimedia gallery experience. Take the offerings of Coppermine and Menalto Gallery as a reference foundation and go from there.
I agree with this
Multimedia handling would be a very good addition to a CMS, and I'd like to see Drupal get there, as I'm currently most interested in it.
Could be that:
image handling = document handling (including metadata import) + general media handling + still image extensions
Yes, doc handling first then images
I agree that it's best to set up document handling in general before moving on to specific document types (like images). Being occupied with other matters and not having much to add to document handling design in any case, I've been waiting until an approach is in place before wading back in to look at the specifics of images. I note that document handling is now one of the areas being developed for the 4.5 release and so will try to get back up to speed....
I don't think of this as a tw
I don't think of this as a two step process of upload then associate. This may be the way an organized person (or a programmer ;)) who prepares a article offline and then uploads it works, but it is probably not the way most community sites work. Many people interactivley create their posts by uploading files and inserting them into their text. You upload the files as part of the node creation process. Now that being said I think we actually may be saying the same thing just wanted to make sure.
I have the base handling already written to allow uploads of files to a node. Check out the attachment.module in my sandbox (ccourtne). This allows uploading of multiple files to the same node and downloading of them. It also will work with any node type it is based on the node_api instead of being a node type itself.
What needs to be added is plugin's to this module. These plugins should be able to add capability to an attachment. The plugin should be able to identify by filename / mime type if it knows how to work on the file. For example an image attachment plug in would allow a new tag that displays the node as a thumbnail.
Check the mailing list for some conversations about how to handle filenames and downloads.
Craig
I agree that a multi-step pro
I agree that a multi-step process for creating attachments will not suffice for many users. One of the problems, though, is providing the user the proper input form fields to properly create a node (as opposed to just attaching a file).
Maybe through the magic of DHTML a list of forms for all possible attachment node types could be dynamically included, but this seems like a clumsy solution for several reasons. I think a popup window is the easiest solution to implement, as you can use each node type's existing node api to render, validate and save the form submission. Using the nodeapi, you can wrap javascript around the regular node creation process that communicates back to the parent window as well as offer a [close] button when done. I propose a popup window as a first step toward adding attachments. Maybe a more elegant solution exists, but the popup solution is relatively easy to implement.
Do you have suggestions for ways that plugins could collect the required form fields to create an attachment node on the same page as the parent node? Resolving this would get us closer to a useful tool.
An example I used in another discussion suggesting reasons for node attachments instead of file attachments is:
If you wanted to attach a recipe to a story, as well as an image of the finished product.
The image module is certainly file oriented, but recipe is not. You may also want the recipe and image to exist outside of the scope of the story and accept comments on each individually.
I don't think documents are nodes
I don't think documents are nodes in and of themselves. You create a node (story, blog, etc...) and attach a document to it. You don't create a new node for the document. I think we need to define document as it relates to Document Management, and I see that as managing binary files which are associated with a given node.
This does not preclude us from creating node types whose only purpose is containing a document. For example an image node for galleries. For the recipe example, I think that is a different feature you want. If your image and recipe should stand on their own, I think it is appropriate to create them as separate nodes first. Now we're really asking for a way to directly relate or associate nodes not attach documents. That is fundamentally different from documents and attachments. I think it is equally useful but would have a different solution.
One thing to keep in mind is transactionality. You can not create the actual database records for any sub nodes (which attachments would be in your original scenario) until the user clicks submit for the main story. This virtual eliminates pop-ups as a solution not to mention there is small change pop-ups or client side scripting will make it's way into core (at least from what I remember of old conversations). Also think about editing an existing node and removing it's attachments. That becomes very nasty in both code and user experience, What are you deleting the reference between the two nodes or the node itself? This would likley vary from node to node on the same site.
I think the most common use of Document Management is to add illistrations or pictures to stories. Let's not complicate the simple case when it won't make the complicated scenario (multiple associated nodes) much easier to create.
If we can agree these are two different feature sets the solutions are greatly simplified. Attaching files requires very little information aside from the filename. I have already implemented a module and patch set that allow files to be attached. Please try it out and let me know what you think. It currently applies against the 4.4 tree I'm working on make it apply against head. What needs to get added is the capability for plug-ins or modules that can add more specific handling to different types of attachments.
Associating nodes could be done just by adding url's in the body. Or we could create a way to search for other nodes. I have not put much thought into doing this. It is not something I need for my site. ;)
The other question I have wondering around in my mind is whether attachments should be part of node module or should it be implemented as a separate module like I have it right now. I'm starting to lean towards modifiying the node module. Individual node types should be able to turn on/off the standard attachment handing as well as call an api to add/modify/remove an attachment.
Dries or any of the core maintainers lurking to comment on this?
I don't have time for a full
I don't have time for a full response now, but I would suggest you look at the recent nodeapi additions here: http://drupal.org/node/view/6612
They offer all of the required tools, IMO, to implement file attachments, and most of the tools required to implement node attachments. Yes, these are, for the most part, two different solutions.
I think problems that require attached nodes are somewhat distinct from problems requiring attached files. Typically, the attached file is of a predetermined format (an image, for instance). It's when you want to collect more metadata that I think an attached node becomes appropriate. When you talk of plugins, I wonder why not use existing functionality and just create a node? I guess these are merely opinions that we have based on our percieved usefulness of each solution.
As for popup-window transactionality, one could use form keys (ala slashcode) in the parent node and popup windows could reference this during their creation of content. When the parent window is submitted, this form key is used to join the attachments to the new node. If, after some arbitry amount of time has occurred, the attachments with the form key still have no parent, they could be reaped as garbage.
Actually those changes only c
Actually those changes only cover an very small fraction of the code required to maintain attached files. If you haven't already you should take a look at the code I've already written to manage attached files. In cvs under sandbox/ccourtne/modules/attachemnt there are three parts node.module patch (partially overlaps with the changes you referenced), file_api changes (allow maintaining directories which is required for large scale use of files), and the attachment module itself.
I think the root of our difference in opinion is around the other baggage a node carries with it. In the simple problem which is I want to add an image to my story. It makes no sense to associated the image to a separate taxonomy, give it a body, teaser, separate publish state, etc. All of those things are required elements of a node which make no sense for just adding a download file or image to a story. The body of the story is the body for the image or download file. I do not search for an attachment in these cases I search for the node they are attached to. I never want to maintain them as separate nodes in my admin screen. I should not be able to delete or disable the child node if the parent still exists.
I run a site for local miniature war gamers. We post battle reports which document what happen in a game. These will usually feature several several images. I really really don't want these images showing up as nodes in admin or get the overhead of tracking individual views to each image. The battle report is my story it is the unit I want as an admin to work with. I also need images as nodes for my pictures of armies this is where individual pictures have context and need to be classified, searched, and commented on. Node association is really a specialized taxonomy in this sense so I can group related pictures together.
Don't get me wrong I think the node framework is great for things that fit it's model. Just trying to articulate why I think Document Management is not a node framework problem.
I know there are ways to merge two windows into one transaction. IMO they all get ugly and require some sort of session level storage (which drupal has very few tools to manage). I have admired drupal because of it's ability to function with no server side session storage (or very little at least).
File and Node Attachments
It is becoming clear to me that there are two distinct problems and a mostly unique solution for each of the problems. The only overlap between file attachments and node attachments is the "attachment" part.
You have stated in your requirements that you have no need to do anything with the file attachments other than display them along with their parent node. The benefits of this would be great performance and simple data management. For this limited requirement set, your module appears to be an excellent solution (I read the code but have not used it).
The goal that I have in mind is to have much more interaction with the attachment. I want the attachment to be able to (optionally) exist on it's own, to be searchable, categorizable, rendered in ways specific to the data itself, etc. I think the node medium more fits my requirements for attachments. I won't go into the full requirements/benefits/costs in general, as that has been laid out in another discussion (http://drupal.org/node/view/7578). Comparatively, though, using nodes for storage allows you to use existing code and offers more flexibility in it's management, but what is gained in features is lost in performance. If you need the features of attached nodes, your site will have to be robust enough to handle it.
I don't know if the overlap between these two feature sets warrants much in the way of shared code. The code that I've started on is framed out similarly to your attachment.module. As nodeapi modules, both will implement similar code, but do differrent things.
Do you (or anyone) agree that these are distinct requirements and should be handled separately, or should an attempt be made to merge them? I think weighing down a lightweight file attachment module such as your attachment.module with node attachment management code would be an unnecessary burden. I would imagine that a site would probably use one or the other, but not both (typically). Opinions anyone?
Problems with seperating them...
I see needs for both. The most obvious examples have been remarked on before: stories with attached or embedded images, and images in a gallery format.
The problem with handling these totally seperatly is that there IS a lot of code overlap, both in file storage and thumbnail generation/handling.
If you go with both the attachment AND node path, that could lead to different filetype wrappers for each file.
As mentioned in that other thread, I am for having a seperate API for file handling that supports different document types, regardless of this.
~ WhiteFire
yup
I agree that these are two different modules. You articulate the reasons very well. It doesn't matter that they share some services. They differ enough that a module which does both will be unweildy (see image.module).
I like the idea of each
I like the idea of each document/image/media object being its own node. This is similar to what the author of the quotes module did with the last round of changes. At first I balked but once I got my 47,000+ quotes imported I thought it was nice. My site uses the Taxonomy_image module to provide some of the functions I wanted for images. ( http://patentlystupid.com ) But I would welcome a more methodical approach.
Appropriate forum for core changes?
I agree that there is a lack of process around getting large changes or additions to the drupal core. I submitted a large patch / module addressing this earlier to the dev mailing list soliciting feedback. I actually received very little.
Is there a better way to ask for comments on changes geared toward getting into core?
DEPs
If there isn't already a process in place, maybe something like a PEP, a 'Python Enhancement Proposal" or the corresponding template used in JSR (Java), or I suppose PHP (I don't know what it is) would be useful? It may be overkill, but we could use some basic parts of it.
Explanation of a PEP for example:
http://python.org/peps/pep-0001.html
The document explains the overall process, here's the bulk of the content of a PEP:
The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
The final implementation must include test code and documentation appropriate for either the Python language reference or the standard library reference.
Maybe overkill
I don't think that level of "Process" is necessary. But some simple documentation on where to submit a patch and who needs to supply feedback before it will be applied.
Referring to documents/images
In the end, I would like to be able to refer to documents and images in the same way I can refer to other nodes (pages and such) now, with the Wiki-like syntax that Drupal already uses for internal crosslinks.
I'd like to be able to choose to whether to link to an image node, for example, or embed it in a page.
See my post in this thread: http://drupal.org/node/view/9059#14920.
I'm not sure how image linking the forum here is handled (http://drupal.org/filter/tips#image) but if this is commonly available in Drupal (I'm new) then that's great. Something to use and build on.
See attached_node module
If you look at the contributions repository in CVS, you'll find a module called attached_node. It is basically a filter that translates meta tags as you discussed in the Integrating Drupal for Bloggers discussion. It currently works with CVS Head as of 8/19, and I intend to carry it along with whatever changes happen before the release of Drupal 4.5.
After 4.5 solidifies, I'll integrate this into the node_api calls so that attachments can be created on the fly and the meta tags can be auto-generated.
Need to eliminate the endless variables during image mod install
The path and other variables seem to make the install of image mod with GD and Imagemagick a magnet for trouble. Please see the last years posts and step back for a moment and look at the overall picture. Many of the complaints come from the install process being overly complex (its not complex really but obscure ). The answer is not to diminish the reconfigurability. I don't know what the answer is but notice how many times the problem is actually two fold yet appears as one thing. This kind of error is nearly impossible to nail down. My guess is that is is even worse -- i.e. 3 or 4 things. Often when developers fix the problem they don't know why as it is the product of hours and hours of trial and error. Even informed support seems to be guessing most of the time. Ill restate what I said this morning.. I think demagogic (imagemagik) or the overeliance on imagemagick is a possible area of uncertainty that may be very hard to deal with. Certainly something is making this one hard to handle.. Its not from lack of effort either.. I'm probably wrong about all this as it is just an impression and i've not had time to actually think it through. Will do so and then give my newlly formed incorrect thoughts at that time.. thanks guys.
an example of what I'm saying
http://drupal.org/node/view/9066
http://drupal.org/node/view/10211
See those thread -- the top one mostly for examples.