Image 1.0

Note: Mostly ordered by issue number (should provide sane additional weighting).

Critical bugs:
#166145: Images directory declared "The directory does not exist." but changing image_default_path in variable table works
#470720: Disabling then reenabling image module makes the gallery vocab forget about images

Upgrade issues:
#483330: Upgrading from 5-1 to 6-dev lost some images due to bad data in {files}
#439240: upgrade looks for nid filed in files table but field doesn't exist
#424386: images saved to files table with bad data in filename column
#207557: update 5-1 to 5-2 gives user warning: Duplicate entry '611-thumbnail' for key 1 query in image_update_5200
#208785: image_update_5200 fails on MySQL < 4.1

Bugs:
#158805: Remove derivative image size rebuild messages + #226121: don't manipulate images on hook_load
#210571: Previous image not deleted when replacing image
#374423: image attach ignores image module's maximum sizes
#403044: php notices - image
#406286: Inline module causing Image to remove uploaded image
#411568: derivative paths should be taken from the corresponding original file, and not from the default
#420422: image status report is unreliable
#177374: Move sizes settings into table, only rebuild changed sizes + #257168: Prevent unnecesary rebuilding of derivative images
#575790: cross-browser support for gallery style
joachim: that fix about files with no extension
joachim: hook_enable clean up

Required improvements:
#81102: Attach Multiple Images with image_attach using Drupal upload mechanism
#360643: Allow sharing image files from different modules (image translations)
#424258: image_create_node_from() should produce error messages
#72579: Image_attach granular permissions
#412288: restructure theme_image_attach_body/teaser

Views support:
#405456: Galleries made with views
#234845: Image gallery. Add option to hide empty galleries
#298441: Duplicate images in galleries
#340523: How to choose the gallery cover image?
#454290: Restore views image size argument

Optional bugs to fix:
#431344: Image gallery term translations not displayed
#464622: Check existence of image content type on install

Optional improvements:
#44057: Use core-style content permissions
#103793: Add token support for image file directory and image names
#210122: Rewrite image_gallery to use of Taxonomy's admin ui
#409974: Change gallery permission from 'administer images' to 'administer image galleries'
#424556: Optionally override $attributes for image_display()
#445074: Add a theme function for the attached image block.
#431348: Original size image template?
#564488: Allow users to specify gallery LI size

Added some more.

Q: Would it make sense to release a beta now to a) get people to use the better code we have already, and b) to be able to quickly commit further changes, i.e. turning dev into real dev to get those issues sorted out?

Depends what we're using 'alpha' and 'beta' to mean, but I'm definitely in favour of making a release now for people to help with testing. I'd call it another alpha as we're not feature-complete yet.
We're very low on testers who patch, high on testers who try alpha/beta releases, so I think we should adapt our release strategy to that.

ok - we should do some manual testing then and directly publish a new alpha release afterwards.

I tested to upgrade from alpha-1.4-to latest dev.
Besides some warnings during update.php ( mentioned by other issues that those warning could be safely ingored)

A lot of improvement! no issue found so far.

One of the two mentioned critical bugs (#470720) is fixed (Joachim wrote a patch which applied cleany); if nobody objects over there, I think this one could be closed (trying to push towards 6.x-1.x-beta ;-)

Greetings, -asb

Image 1.0-alpha5 out now!

So let's proceed. Nothing RTBC? Why not? :P

We're low on testers.
(I admit to being a lousy patch tester -- lack of time at the moment and lack of a quick way to get a new site up to test.)
Do we have a policy on when to mark as RTBC? How many testers should a patch have?

heh, yeah, same for me - I think we're all lousy testers then ;)

For "simple" patches, 1 or 2 confirmations are sufficient. Normally, the same would apply to all patches - however, in Image module's case, I'm often also worried about testing with existing example data...

All that being said, I'm very unsure whether it makes sense to still work on heavy improvements/features...? Should we perhaps revisit our goals for 1.0 and only do what's required? And, in parallel, move forward with a new HEAD branch, where we prepare for #513096: The Future of Image in Drupal 7 ?

Yeah. we should maybe focus on the upgrade issues and the bugs.

> Should we perhaps revisit our goals for 1.0 and only do what's required? And, in parallel, move forward with a new HEAD branch,
> where we prepare for #513096: The Future of Image in Drupal 7?

Please remember that some (if not many of us) will still use D6 for a couple of years. I'll be very glad if I'll have started to migrate my sites to D6 when D7 hits the shelves... Considering the amount of substantial changes in D7 it's not unlikely that D6 - and it's contributed modules - will have a very, very long life (say, at least until 2012). Please don't abandon us before we even reached D6 ;)

Greetings, -asb

+1 for doing what's required

Many of us just want basic image capabilities which are production stable. This is long overdue for D6. Advanced requirements can be handled with Imagefield, Imagecache etc.

I can do testing (and patching) but not for D5 upgrades. I've installed alpha 5 on a prototype I'm building and got the reported warnings.

* Failed: ALTER TABLE {image_attach} DROP PRIMARY KEY
* Failed: ALTER TABLE {image_attach} DROP INDEX iid

* Failed: ALTER TABLE {image} DROP PRIMARY KEY
* Failed: ALTER TABLE {image} DROP INDEX image_fid

I think #445074: Add a theme function for the attached image block. should be moved up in priority -- the poor theming in image_attach is really, well, poor.

All that being said, I'm very unsure whether it makes sense to still work on heavy improvements/features...?

I would say stabilise Image 1.0 - no new features, but make it rock solid, and then move onto moving the tools over the the fields/CCK world where image.module 2.0 is a migration script, and image attach is for imagefield too (and same for image assist).

Ok -- here's what I reckon we should do:
1. Try to get as many patches written, tested, committed in the next 2 weeks.
2. Day 1 of DrupalCon have an image module coding and testing sprint.
3. Release a 1.0-RC at the end of that day, whatever state it's in. Commit whatever patches we reckon are ok.
4. See what feedback we get over the next few days. As we've previously said, this module has a LOT of users, but very few of them take part in patch testing. That means we get more feedback from rolled releases than from patches, which tend to sit around for months.
5. Have a second sprint on Saturday or Sunday of DrupalCon to fix any issues that get raised.
6. Release.

#14/15: Second that. Stable release asap.

Ok, I've registered a code sprint: http://paris2009.drupalcon.org/forum/image-10
Please post there if you plan on coming.

I am in the process of upgrading a D5 that has considerable amount of images (991) and they rely on img_assist to upload them. I still haven't decided if I should stick with this approach or move to an IMCE approach. I know I'll lack some features and flexibility but if I just need image handling and uploading that might make more sense, although I'll have to migrate existing data.

If I go with using image module I will be testing the module, testing upgrades and probably be able to test patches if necessary. So before going on with it I'd like to ask afew questions... what combination of modules should I use?

image 2.x + img_assist 2.x ?
image 2.x +img_assist 3.x ? Asking about this for what I saw on http://drupal.org/node/358296

Besides the main dev branch of each module, what's likely best for me to use on this upgrade that will soon be a production site? Shall I use the dev version of each main trunk or stick to the latest released ones (whether alphas or betas)? After upgrading, would everything be on a fairly usable state or code is still too buggy?

Thanks,
a.=

@hanoii: Image 5.x-2.x is the same as 6.x-1.x; there is no 2.x for 6.x (someone used a wrong version number when creating that branch). If you are going to upgrade with Image module, then you should be safe to do so (though we still have some bug reports about the upgrade path in the queue, which only a few people seem to be able to replicate).

img_assist 2.x and 3.x only differ regarding Wysiwyg integration. 3.x is definitely better, but cutting-edge (so it may contain some glitches). If you don't use Wysiwyg, then there is no difference.

@sun: thanks for the insight. I am planning on using wysiwyg-6.x-2.0 here, so shall I safely go with img_assist 3.x? What is the integration difference, 2.x will not work at all with wysiwyg or will work differently? And what do you think it's best to use, latest -dev (or CVS for that matter) or better start with the released versions? If I go over with the upgrade, I'll report back if I find any of the upgrade issues and, if I can, will try to provide a solution.

I intend to be at the ice cream sprint at AF83 on the 31st, 5pm Paris time.
Can anyone else interested in image module be there, or be on IRC?

Details and times will be updated here: http://paris2009.drupalcon.org/forum/image-10
Please comment there if you plan on taking part.

I like image module very much, but I have to stay with version alpha6, because of http://drupal.org/node/571268 (error in gallery module and lightbox does not work)...

Looking at that list of issues, I'd say we're pretty much ready for a release.

I'd like to improve theming in image_attach.

Other than that, the remaining issues can wait for people to file patches and go into a 6-1.1 release.

Before doing the next release, I'd like to do a sanity check on a couple of the committed patches. Additionally, I think it's now time to resurrect the Code clean-up issue and do a major clean-up of the coding-style and documentation.

Yeah, that would be a good idea.
Still kicking myself for that bad commit that broke *boxes!!!
We have a code clean-up issue? IIRC I did a commit ages ago adding doxygen function headers to some of the code.

subscribe