I'm currently migrating a bunch of sites from a custom CMS to Drupal. I've found modules (or good starting points) for about everything - except for images. I already have a custom image archive in use that is accessible from all those sites, which does what I want, but apparently there's no Drupal module that comes close to these features.
What I expect from such a module:
* pictures are available across all multiple Drupal installations
* automatic generation of smaller image versions
* dynamic URLs that contain the title of the image (this is both, SEF and prevents breaking links)
* easy-to-use insertion of images into nodes without any wiki like syntax
* access control system (decide who can see which pictures, have private picture gallery)
To make it short: While these prerequisites do certainly not call for any simple image (or even cck) module, none of the projects hosted on Drupal provides these features. I searched from CCK imagefield to Bitcache to Gallery2-connector modules, but none of these modules were close to what I was looking for: a fully integrated pictures display solution, with access control and clean urls.
Since I've programmed my own image archive handler for the old CMS I had to go ahead and adapt it for use with Drupal. And I'd be willing to share that code with the community, if there's interest in it.
I just want to make sure that my solution is not too specific to be an own module.
Here's in short what the module does:
* pictures are uploaded to a central folder in the file system (Linux tested only) - swfupload is used for uploading, "simple" uploading fallback is available
* any file types supported by imagemagick are available (e.g. even PSD files), they are stored in their original format but are converted to jpg on display
* meta and exif data is inserted into a central database (but it does not have to be a separate one)
* pictures are uploaded into virtual folders, managed by a MySQL table
* users have a private folder (which is shown only to them throughout any of the sites that use the same central image archive)
* there is also a public folder (which is the same for all users on the same domain - e.g. example.com)
* users can specify read write (add and modify) and delete access for pictures and folders
* access settings are inherited to sub-folders
* the insertion of pictures into nodes has been integrated with FCKEditor, which allows easy browsing and inserting of pictures
* pictures are displayed in this format: /image/2009-12-15_sample_picture_200.jpg (where the 200 denotes the required maximum resolution). The server automatically checks if there is already a 200 pixel version available and does the conversion on the fly if not. It is also checked if the current user has access to this picture. The /image/-path can be defined by the user. The current domain is used (so it is not apparent that these pictures come from a central database/folder).
* this module is views-integrated, so outputs like "show me all pictures from this and that year" can be generated while making sure that pictures to which the user does not have access are excluded
* depending on preference, different "image viewers" (Lightbox, Thickbox, etc.) are supported
I would really like to contribute and support this module, as I'm also interested in feedback from the community, hints on how to do some of the things in the code more efficiently (since this is the first time I've used the Drupal API) and ideas on how to achieve better usability.
Does anybody think adding this module would be a good idea or is it too specific?
Comments
Part of the problem, I think,
Part of the problem, I think, is that you seem to be looking for a single all-encompassing module to handle all of your requirements. Drupal often doesn't work that way; instead, you can use several smaller, more focused modules to achieve what you're looking for. Automatic thumbnailing: ImageCache. Dynamic URLs: PathAuto. Easy insertion: Several approaches to that; you mentioned FCKeditor, and that (with IMCE might be the simplest. Access control system: Again, several approaches to that, though Content Access strikes me as rather capable and straightforward. Really, the only tough part is making pictures available across multiple Drupal installations; assuming you're speaking of a multisite Drupal installation, it may be possible to use a directory in the sites/all directory as your files directory, or maybe just have each subsites' files directories be symbolic links to a common directory.
The Boise Drupal Guy!
Yep, but who doesn't look for
Yep, but who doesn't look for a module that suits all their needs ;-).
But seriously, I've actually tried the approach you suggested, i.e. combine several modules and I've been willing to make compromises, but it just didn't work out.
Examples:
ImageCache - you have to specify thumbnail sizes in advance. My users are not smart enough to do that and I don't want to set up 20 something sizes in advance.
PathAuto - does not allow you to add the exif-extracted date in the URL (might be available with exif module, though). Okay, I could have lived with that. But what happens if another user changes the title of an image inside another Drupal installation? My links would break.
Content Access/Node access - the problem with these modules, again, is that settings are stored per site only. Of course in this context they have to be valid across sites, so users don't suddenly see a blocked picture on the other site. Inheritance is also not available (but this is a general problem of Drupal). And the whole node access approach Drupal takes is not too convincing to me.
I'm indeed using a Debian multisite installation, so the sites/all directory might have worked, given proper .htaccess settings.
All in all, if there were no need to share pics and settings across sites, I would have definitely taken an approach using the other modules. But since I just had to adapt the code to Drupal and wanted to learn module development anyways, I went ahead.
But like I said, my approach might be pretty unique. So I guess I'll wait to see if there's sufficient demand for such a module before I sign up for a module.
Yep, but who doesn't look for
Well, people who have been working with Drupal for a while and know that such a thing usually does not exist, for one.
I don't get it. So you're letting your users specify what thumbnail sizes they want to create?
Well, it all depends on how exactly your image nodes are referenced (if you do indeed go with the strategy of making each image its own node). Generally speaking, if you or the module you're using is using proper coding standards, this won't be a problem, because the code will reference the node by its node ID number, and Drupal will use that to build its link to the node using whatever its correct path is at the moment.
The Boise Drupal Guy!
Well, people who have been
And possibly also people who are quite new to Drupal (I joined this year) and put smilies behind ironic statements ;-).
Implicitly, an integer is added to the image url (e.g. nice_picture_234.jpg) to tell the module the maximum extent of the image (here: 234 px). And no, the module does not allow for upsizing and/or indefinite image sizes. A default image size is set but the user can alter it when he inserts the image (just as he can add a caption etc.) - no messing around with HTML required.
I try to keep my code clean, but I have only looked roughly at Drupal's coding standards. My module also doesn't use the Drupal node system, as there already is an image database. I though about migrating it, but in fact: Drupal nodes consist of title and body in the database. I could have added CCK fields. But since the image generation, the folder display etc. were not (or not easily) achievable with Drupal modules, I just saved me the work of fitting the pics into the node system. The module does a quick and dirty search for imageid_size.jpg (e.g. 2311_200.jpg) and replaces it with e.g. 2009-12-16_image_title_200.jpg.
Remember: The objective was to get the image archive running on Drupal and then maybe turn it into a solid module, not the other way round.
Drupal has long supported
Drupal has long supported multiple installations with shared folders and database tables. Almost the entirety of what you want can already be easily achieved with a judicious configuration in settings.php. If that wasn't enough, other existing solutions: in d7, you can set up a shared file system w/ stream wrappers. You could jump into the Media backport effort and bring that solution to d6.
Image derivative generation: D7's Image styles has an api allowing you to generate images on the fly -- you'd need to create machine-defined styles, but it should be fairly easy to do; that may be possible in d6's Imagecache too. (We're digging into such things w/ Styles & the Media module).
Pathauto has an option to keep existing aliases intact.
There are at least a couple of modules already providing swfuploader support.
Full media asset WYSIWYG integration is quickly becoming a reality with the Media module, but there are other existing solutions, including IMCE, Image Assist, and others.
Lightbox/Shadowbox/Thickbox/etc integration is also available through their respective modules.
We need help on all these fronts to make things better, but we need to collaborate to stop re-inventing the wheel. Please. Let's all get a common file storage format in place (just about there in d7), and go from there.
Thanks,
Aaron
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
Thanks for your feedback,
Thanks for your feedback, Aaron. I've looked at the media module before but never continued to follow up on it - I guess b/c it's still in the dev stage - or b/c there indeed are too many media modules out there :-).
Your approach sounds very promising, though, it goes into what I think is the right direction. The badly implemented (core) media handling is - other than the missing hierarchy in core - actually one of the things I never understood about Drupal :-).
I'm glad you brought this module to my attention again. I think it's best if I continue monitoring it, give it a try once it's ready and try to contribute some of my module's functionality if possible. (If you found that anything I described could be useful to the media module, please let me know.)
So I'm not going to start yet another media module and will use the Drupal adaption of my old code until a better solution is available.
Don't get me wrong
I'm definitely not trying to stifle development -- I love to see new ideas shake the tree. And I'm on the other side of the debate about module duplication -- I am a firm believer that it is in the jungle of contrib where innovation takes place.
At the same time, everyone involved knows the specific media handling issues hounding Drupal. I believe that collaboration is the key to tackling this, since it hasn't (fully) happened yet in core. Although, with the new and improved file api & php stream wrappers in d7, we're almost there...
The exciting piece that is currently in progress is turning Media Assets into fully fieldable entities, a first class citizen in the world of Drupal, next to nodes, users, comments, and terms. We have a team in place committed to making this happen (and pushing it into Drupal 8 when the time comes), hopefully bringing Drupal's multimedia and file handling capabilities finally into the twenty-first century. Join us at #drupal-media if you're in IRC! Sounds like you have mad skillz that would be greatly appreciated. :D
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
Your case sounds like a perfect fit for a better framework
I would not use Drupal in your case..if you are not too deep into Drupal learning curve, and don't mind programming, it's not late to use something more flexible from the start. Like a better framework (Django maybe)
The code already existed. The
The code already existed. The question was what would be quicker:
a) adapting it to Drupal or
b) finding modules, configuring/adapting them (if they exist) and migrate everything.
The first one proved to be easier, especially since I'm not a fan of messing around in other people's code having to adapt it all over again when new versions come out.
I would have had to use a framework back in 2003 when I started writing this archive. But like Drupal, the frameworks I found back then where not very advanced. I admit, I had very specific requirements (automated versions, easy syntax - I used the mediawiki style as solutions like TinyMCE where not around or popular and an image archive). This (and because I wanted to learn PHP programming) is why I ended up writing my own CMS.
Seeing that especially Drupal today incorporates much of my philosophy gave me the opportunity to switch to this CMS and take advantage of the great modules provided by its large community. That way I can focus my work on content and programming what really lacks in Drupal (like proper image handling). Offering to contribute the results of that work is my understanding of giving back to the community.
In that sense, I consider Drupal a much better framework for my purposes.