Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Placeholder to coordinate Image 6.x-1.0 release.
Placeholder to coordinate Image 6.x-1.0 release.
Comments
Comment #1
joachim CreditAttribution: joachim commentedNote: 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
Comment #2
sunAdded 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?
Comment #3
joachim CreditAttribution: joachim commentedDepends 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.
Comment #4
sunok - we should do some manual testing then and directly publish a new alpha release afterwards.
Comment #5
skyredwangI 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.
Comment #6
asb CreditAttribution: asb commentedOne 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
Comment #7
sunImage 1.0-alpha5 out now!
So let's proceed. Nothing RTBC? Why not? :P
Comment #8
joachim CreditAttribution: joachim commentedWe'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?
Comment #9
sunheh, 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 ?
Comment #10
joachim CreditAttribution: joachim commentedYeah. we should maybe focus on the upgrade issues and the bugs.
Comment #11
asb CreditAttribution: asb commented> 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
Comment #12
Neil Adair CreditAttribution: Neil Adair commented+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
Comment #13
joachim CreditAttribution: joachim commentedI 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.
Comment #14
NaheemSays CreditAttribution: NaheemSays commentedI 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).
Comment #15
joachim CreditAttribution: joachim commentedOk -- 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.
Comment #16
Leeteq CreditAttribution: Leeteq commented#14/15: Second that. Stable release asap.
Comment #17
joachim CreditAttribution: joachim commentedOk, I've registered a code sprint: http://paris2009.drupalcon.org/forum/image-10
Please post there if you plan on coming.
Comment #18
hanoiiI 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.=
Comment #19
sun@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.
Comment #20
hanoii@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.
Comment #21
joachim CreditAttribution: joachim commentedI 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?
Comment #22
joachim CreditAttribution: joachim commentedDetails and times will be updated here: http://paris2009.drupalcon.org/forum/image-10
Please comment there if you plan on taking part.
Comment #23
Vojta CreditAttribution: Vojta commentedI 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)...
Comment #24
joachim CreditAttribution: joachim commentedLooking 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.
Comment #25
sunBefore 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.
Comment #26
joachim CreditAttribution: joachim commentedYeah, 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.
Comment #27
mcurry CreditAttribution: mcurry commentedsubscribe
Comment #28
jonathan1055 CreditAttribution: jonathan1055 commentedCould 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
Comment #29
dom_b CreditAttribution: dom_b commentedCould 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
Comment #30
joachim CreditAttribution: joachim commented@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.
Comment #31
EvanDonovan CreditAttribution: EvanDonovan commentedTracking. 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.
Comment #32
agnez CreditAttribution: agnez commentedHi, 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.
Comment #33
joachim CreditAttribution: joachim commentedPlease file a new issue report for this.
Comment #34
joachim CreditAttribution: joachim commentedI 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!
Comment #35
sunI'm really not sure whether ImageCache integration - as cool as it might be - should be part of 1.0. Considering the possible implications, it rather sounds like a 2.x change to me (and when thinking about "2.x", and considering D7, I'm not sure whether it's worth the struggle). Please bear in mind that there are various other modules that depend on Image's current 1.x behavior.
I'd highly recommend to publish a clean 1.0 first. Afterwards, there will likely have to be a 1.1 to fix any remaining bugs. Thus, any serious/larger changes should really go into 2.x, IMHO.
Comment #36
joachim CreditAttribution: joachim commentedWell, 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
Comment #37
arski CreditAttribution: arski commentedsubscribing. Looking forward to seeing a new (even beta) release soon :)
Comment #38
joachim CreditAttribution: joachim commentedReleasing a new beta now.
This is hopefully the final beta. I'll give this a week or two then release a 1.0.
Comment #39
sunLet's directly jump to 1.0?
Comment #40
joachim CreditAttribution: joachim commentedOh. I just made the beta6 release.
You at CPH?
Comment #41
joachim CreditAttribution: joachim commented...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.
Comment #42
sunNot sure whether it makes sense to defer a stable 1.0 for that patch. That patch has to be 100% backwards compatible anyway, so I'd say it can go in for 1.1, too.
And, yes, there can only be one major version for a project at the same time.
Comment #43
pirmin CreditAttribution: pirmin commentedI 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.
Comment #44
pirmin CreditAttribution: pirmin commentedNevermind. The 'bug' has been discovered.
The images directory was owned by root:root with permissions 775. Changing ownership to :apache solved the issue.
Comment #45
joachim CreditAttribution: joachim commentedOk. Glad to hear it's resolved.
Please file new issues for problems in future!
Comment #46
joachim CreditAttribution: joachim commentedIt'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?
Comment #47
jonathan1055 CreditAttribution: jonathan1055 commentedI'd say yes, go for it :-)
Jonathan
Comment #48
EvanDonovan CreditAttribution: EvanDonovan commentedThat 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?
Comment #49
joachim CreditAttribution: joachim commentedSee #513096: The Future of Image in Drupal 7 (which could probably do with summarizing...)
Comment #50
EvanDonovan CreditAttribution: EvanDonovan commentedThanks, 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.
Comment #51
joachim CreditAttribution: joachim commented1.0 is out. Let the bug reporting begin....