fixing our image handling
Apr 27 2007 17:12
At the moment on libcom.org we have loads of ways to display images:
1. imagefield/imagecache/thickbox - the quick upload box at the top of articles which generates the thumbnails, different sizes and new javascript popup thingies etc.
2. image.module - you have to upload the image seperately as a node, then link manually from the article itself - this is what we're currently doing for most extra images.
3. file uploads - we never do it, but you can upload a file to a node, choose not to list it, then use html to link to it the same as image.module
4. /gallery
I think we should clean this up before we go too far. Here's a suggestion:
1. imagefield/imagecache/thickbox - this works great, nothing needs to be done as far as I'm concerned apart from ironing out bugs
2. image.module I think we should use this only for image galleries or standalone images, although stuff that's already in there can be left there without doing any harm at all.
3. With images that we want in the body text of articles (say history where there's three or four images in an article, and you want them with the text), I reckon we should use file uploads, inline.module (http://drupal.org/project/inline) and hook those up with imagecache/thickbox. That way we have all images attached to an article linked to it in the database itself instead of spread out in different places, and with imagecache/thickbox they'll be more standardised in how they're displayed. This only requires installing and configuring inline.module
4. I think we should aim to get rid of the standalone gallery software by the end of the year (so 8 months time to get it sorted, roughly when we might be upgrading to drupal 6). The way to do this would be to use the new mass import function in image.module (you can do imports of images from folders) to preserve what we want from /gallery. Most of them don't have much text associated anyway, especially CPE stuff. We can then switch on the image gallery in image module (which also works with thickbox), and have proper galleries of images in drupal organised by tags instead.
That will mean that all images on the site, apart from some old ones in articles (which we can leave as is unless we're tidying up anyway) will be displayed via one of these three ways:
main image quick upload (same as now)
extra images uploaded from within article creation and put in articles using inline module
standalone images using image.module (same as now but plus proper image galleries).
all three integrated with thickbox so they behave largely the same to end users. It should make it much easier for contributors to add extra images to articles as well.
Does that sound reasonable? Anything I've missed?
May 3 2007 09:32
#2
yeah that sounds great catch
May 3 2007 16:49
#3
cool. The only thing we need to do right now is install inline.module and see if it actually works how it should. There's some other stuff I want to do first though.
May 8 2007 17:19
#4
alright, I think this needs refining more.
if we have image.module and imagefield.module then it's duplication, and imagefield/imagecache/thickbox does it better anyway. Plus we don't have that many images on the site, and we ought to be able to delete the nodes without deleting the images (where it's been used just to put an image in an article).
So, a revised outline:
* main image using upload form same as now
* extra images either using 1. file uploads + inline module or 2. an extra upload form for extra images on certain node types + inline.module - 2 would allow us to deal with theming, and also have things like image galleries from all photos in an article
* standalone images go in a new "image" content type, which just has a title, image and description + tags, possibly support for more than one image. Then we do image galleries using views/thickbox.
The major disadvantage to this is there's no stable bulk import, but it looks like there's a half-decent one here: http://drupal.org/node/100234 which might be good enough to transfer some from /gallery
that sound alright? It'll be less configuration, but possibly more work moving things across from gallery. It's definitely the best way to avoid lots of work later though.
May 19 2007 09:13
#5
OK now down to this I think:
* main image same as now
* extra imagefield which allows multiple images (not displayed automatically in node teasersor full article) + inline.module to put them anywhere we like in the article itself. This means we can imagecache and hopefully thickbox them,if not now then it'll be a switch on thing later.
* standalone images go in a new "image" content type, which just has a title, image and description + tags, possibly support for more than one image. Then we do image galleries using views/thickbox.
Another advantage of inline, is we can link to pdf attachments inline as well without manual linkage - so might have autoformatting of PDF links and stuff like that. No need to worry about that at the moment though.
I've killed all the old broken image nodes from the first version of library that were still in there.
This leaves us:
6 pages of image nodes. Two ways of converting them:
1. if the image is just for putting in an article, ideally find the article itself, attach it as an imagefield, then replace the img src code with inline. That will fix some nasty align="right" coding as well.
2. if it's standalone create a new imagefield image with title and tags, then delete the node -> there's no conversion script, but I don't think it will be that many in total. That way things like libcommunity graphics stay intact.
After that - /gallery to transfer
Will try additional imagefield in history - since that's where most of the extra images are.
May 19 2007 13:37
#6
inline.module now works fine in library, but not history/news which both use "article" instead of "body" fields (cck issue). Have posted bug report.
also - have to use file uploads rather than additional imagefield (at least for now).
This doesn't stop us moving standalone images out of image.module though, so will start setting that one up.
May 19 2007 14:05
#7
ok new content type called "standalone" image. Anything which is by itself can go there, then it'll go into tag listings / image galleries with views later on.
Easiest way to transfer is to go to admin/content then filter by type "image", transfer the full size image and anything else over, then delete the original image node.
Jul 23 2007 10:58
#8
Does anyone know where:
http://libcom.org/images/demonstration-against-south-korean-police-violence
and
http://libcom.org/images/collectivised-cnt-tram
are used?
Other than the hospital occupations pamphlet, this is done!
Jul 23 2007 11:41
#9
Jul 23 2007 11:43
#10
Jul 23 2007 11:52
#11
Thanks.
Done!
Man that was painful. Ceremonious deletion of image.module in about 45 seconds!
Jul 23 2007 11:57
#12
Jul 23 2007 12:00
#13
w00t!
Jul 23 2007 12:07
#14
OK.
So now:
For articles with one image, attach it using the form in the article page.
For articles with two or more images - attach the subsequent images as "files" using the file attachments form at the bottom of the page. Then use html
use html:
<img src="/files/images/filename.jpg" alt="something descriptive" title="something descriptive" />
If you need it left or right, add class left or class right:
<img src="/files/images/filename.jpg" alt="something descriptive" title="something descriptive" class="left" /> <img src="/files/images/filename.jpg" alt="something descriptive" title="something descriptive" class="right" />
Don't forget the alt tag and the title tag.
Or just use bbcode, that's fine too.
If there's images not attached to an article, or you've got lots of images that are worth having in their own right, then make a "standalone image" (to be renamed to "images" very soon) - and add them to that. You can then link to them from the main article, but only do that if an image gallery is worth having itself.
Eventually we'll get autothumbnails and thickbox going for inline images, but it's a bit broken for now, so file upload and html/bbcode at least won't break later.
Jul 23 2007 18:07
#15
made the thumbnails a bit bigger (we can change any time). This is how the image galleries look with a few more images:
http://libcom.org/vgallery/v/news/osaka
compared to:
http://libcom.org/gallery/v/news/osaka/
I reckon it compares pretty well.
Jul 23 2007 18:24
#16
A couple of points.
I think it's nicer to have the titles visible rather than hover over (although a lot of gallery pictures aren't labelled)
It also helps to break it up a little, maybe just putting white borders to seperate the pictures a little bit.
Also the thumbnails are not just smaller they have been cropped as well, not sure how much this will matter, although if you want to do the image library then that could start to get annoying.
Jul 23 2007 19:12
#17
The titles are visible in the thickbox pop-up thing, but yeah we should have them in the default view. John. mentioned as well. I think we can do it later with the theme - will apply to anything with a title already.
Also agree about white space, that's easy to fix, will look later on tonight.
With cropping - that's necessary to get them square - other wise you get weird things going on with portrait and landscape images. Not hard to change later though as well.
Jul 24 2007 13:00
#18
the cropping is good - the old one did that too.
i think that looks great catch, nice one
Jul 26 2007 20:26
#19
John - about uploading images not working - I saw something about imagefield not liking it if you use it in two tabs at the same time. Any chance that was the problem?
If it is, we can post bug report, if not then I've got no other ideas atm.
sounds good, especially the thick box integration - i'm planning to write that 'personal recollections brighton anti-war' thing for the library and i've got some scans of newspaper front pages that really need thickbox to make sense