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

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.

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)

    * user warning: Can't DROP 'PRIMARY'; check that column/key exists query: ALTER TABLE image DROP PRIMARY KEY in /home/greatbre/public_html/includes/database.mysql-common.inc on line 386.
    * user warning: Duplicate entry '39074-thumbnail' for key 1 query: ALTER TABLE image ADD PRIMARY KEY (nid, image_size) in /home/greatbre/public_html/includes/database.mysql-common.inc on line 374.
    * user warning: Can't DROP 'image_fid'; check that column/key exists query: ALTER TABLE image DROP INDEX image_fid in /home/greatbre/public_html/includes/database.mysql-common.inc on line 448.
    * user warning: Duplicate key name 'fid' query: ALTER TABLE image ADD INDEX fid (fid) in /home/greatbre/public_html/includes/database.mysql-common.inc on line 434.

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

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?

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.=

@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.

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

Could we have an update on the issues which still remain, preventing a 1.0 release? I'd be happy to help fix/test and it would be really good to get an official release soon.

Jonathan

Could the PHP 5.3 fix be rolled into it? This would be fantastic! I've patched my beta 3 release and haven't updated to beta 4 as I'm not sure if its been implemented or not.

http://drupal.org/node/540486#comment-2243702

@dom_b: that issue isn't on this module.

@jonathan1055: any help testing is greatly appreciated. There are quite a few small-ish patches marked as needing review in the issue queue. The biggie though is the occasional duplicate key errors people get when upgrading from 5 to 6; I'd like those to be definitively licked before I'm happy calling it an official release.

Tracking. In the next few months, I will hopefully be able to test some of the remaining patches marked as "needs review". Don't know if I'll be able to test the upgrade path from 5->6 though - I'd have to create some fake image nodes in a Drupal 5 site & then upgrade, I suppose.

Hi, I get the following error when activating image module

warning: Illegal offset type in isset or empty in /mypath/sites/all/modules/image/image.module on line 635.

Please file a new issue report for this.

I reckon #583076: Error on Database Updates for 6100 when upgrading to Beta3: 'duplicate entry' for primary key (the one bug that's holding us back) and #231622: Use imagecache as a process for normal image.module presets (because it's cool) and we're releasing a 1.0.

Let's get it out before CPH!

Well, our 6.x release is a brand new beast anyway -- Views support, etc etc. We're free to add new features as part of it. Also, I'm not sure I have the energy to work on a 2.x after that (which yknow, would technically be a 3.x but YKWIM).

I do see your point though.

How would adding derivatives that are secretly imagecache files affect modules that depend on Image 1.0? If

subscribing. Looking forward to seeing a new (even beta) release soon :)

Releasing a new beta now.

This is hopefully the final beta. I'll give this a week or two then release a 1.0.

Oh. I just made the beta6 release.

You at CPH?

...apparently not ;)

It's been over a week and no bugs reported on the latest beta. Yay!

I reckon we can commit #231622: Use imagecache as a process for normal image.module presets for the 1.0 release. From the point of view of image module, it just adds a level of code between the module and the image operation definitions with the hook. Also, I'm not sure the release management system would let us have a 1.0 and a 1.1-beta-1 showing at the same time.

I can't properly upload an image. I get the following error message when saving an image:

The selected file /var/lib/drupal/files/<sitename>/images/temp/logo.png could not be copied.

The file 'logo.png' gets selinux permission 'httpd_tmp_t' which is probably the cause of the error.

A thumbnail for the image is generated and resides together with the original image in

/var/lib/drupal/files/<sitename>/images/temp

The node corresponding with this image (logo.png) is saved and allows one to view the thumbnail, just not the original image.

I can attach images to content and the images are properly uploaded and available in the

/var/lib/drupal/files/<sitename>

directory.

I'm using the GD2 image toolkit.

Nevermind. The 'bug' has been discovered.

The images directory was owned by root:root with permissions 775. Changing ownership to :apache solved the issue.

Ok. Glad to hear it's resolved.

Please file new issues for problems in future!

It's been a month since the last beta. We've had a few minor bugs reported on that; all have been fixed.

Sun -- how about we release 1.0?

I'd say yes, go for it :-)

Jonathan

That would be great - I've not had any problems using Image in a long time.

By the way, what is going to be the recommended upgrade path for D7?

See #513096: The Future of Image in Drupal 7 (which could probably do with summarizing...)

Thanks, joachim. I commented over there & did my best guess at a summary. I'd appreciate if you or another person who is heavily active in this module could comment.

1.0 is out. Let the bug reporting begin....