[drupal-devel] New 4.6 Image module
Hello, Over the last couple of days I have been experimenting with James' new image module, and I think it is very good. I have also been doing some testing with htmlarea and it is all working. I have put up one patch, which instead of using the file_transfer() I have changed it so that it will do a header('Location: ...') to the image so that when you are using public files the image module will not take up as much resource. I have also created 2 new image toolkit includes for imlib, and the php imagick library so that you are not executing a shell command to do manipulations. I know that there was some discussion about moving this new version of the image module from James' sandbox into contributions. Now with 4.6 get closer, I think that we need to do this sooner rather than later so that more general testing can be completed by the time 4.6 is released. I think that what we should do is rename the current image project and cvs to image old. This is because the new image module is a completely new development, and thus should start the bug reports and everything fresh. This will make it much easier to maintain problems between the old and the new. This is a great new improvement for drupal, but we need to get this development moving forward for drupal 4.6 James. Great work. -- Gordon Heydon <gordon@heydon.com.au>
On 19 Mar 2005, at 09:44, Gordon Heydon wrote:
I know that there was some discussion about moving this new version of the image module from James' sandbox into contributions. Now with 4.6 get closer, I think that we need to do this sooner rather than later so that more general testing can be completed by the time 4.6 is released.
Absolutely. The old image module needs to be replaced with James' new image module. The sooner, the better because the old image has been a source of frustration for those making the jump to Drupal 4.6.
I think that what we should do is rename the current image project and cvs to image old. This is because the new image module is a completely new development, and thus should start the bug reports and everything fresh. This will make it much easier to maintain problems between the old and the new.
I don't think we should rename the old module. If the upgrade path works, it is perfectly acceptable to overwrite the old one. It is not the first time a module gets rewritten. -- Dries Buytaert :: http://www.buytaert.net/
On Sat, 2005-03-19 at 11:24 +0100, Dries Buytaert wrote:
I think that what we should do is rename the current image project and cvs to image old. This is because the new image module is a completely new development, and thus should start the bug reports and everything fresh. This will make it much easier to maintain problems between the old and the new.
I don't think we should rename the old module. If the upgrade path works, it is perfectly acceptable to overwrite the old one. It is not the first time a module gets rewritten.
I only say this because a line needs to be drawn between the the old and new. We either need to close all outstanding bugs and feature requests, This is a new development, the existing bugs and feature request most likely do not apply. -- Gordon Heydon <gordon@heydon.com.au>
I have put up one patch, which instead of using the file_transfer() I have changed it so that it will do a header('Location: ...') to the image so that when you are using public files the image module will not take up as much resource.
perhaps file_transfer() itself could do the redirect for public files? also, does anyone else think that adding a redirect for every image node might cause poor experience for users on a high latency connection? imagine an image galle ry page with lots of image nodes. I wonder if we are not sacraficing user experience in favor of some server processing cycles.
On Sat, 2005-03-19 at 06:32 -0500, Moshe Weitzman wrote:
I have put up one patch, which instead of using the file_transfer() I have changed it so that it will do a header('Location: ...') to the image so that when you are using public files the image module will not take up as much resource.
perhaps file_transfer() itself could do the redirect for public files? also, does anyone else think that adding a redirect for every image node might cause poor experience for users on a high latency connection? imagine an image galle ry page with lots of image nodes. I wonder if we are not sacraficing user experience in favor of some server processing cycles.
The example of a gallery doesn't really apply. If you were to create a gallery you would not use the image/view/nid path to load the image but rather the real path. The image/view/nid path is only used as a simplified path for users and external application such as Xinha/HTMLArea to link an image into content, without having to enter a long and unknown path. This is actually one of the reasons that I have proposed the creation of a filter component for the image module so that you can enter a simple path and it will return the actual path. The use of the image/view/nid is a necessary feature for people who are entering in content to simplify the entry. but will not be the main method of entering a path to an image. -- Gordon Heydon <gordon@heydon.com.au>
On 19-Mar-05, at 3:44 AM, Gordon Heydon wrote:
Hello,
Over the last couple of days I have been experimenting with James' new image module, and I think it is very good. I have also been doing some testing with htmlarea and it is all working.
glad to hear it!
I have put up one patch, which instead of using the file_transfer() I have changed it so that it will do a header('Location: ...') to the image so that when you are using public files the image module will not take up as much resource.
This is a good idea ... but I also agree that it should likely live in file_transfer itself.
I have also created 2 new image toolkit includes for imlib, and the php imagick library so that you are not executing a shell command to do manipulations.
I know that there was some discussion about moving this new version of the image module from James' sandbox into contributions. Now with 4.6 get closer, I think that we need to do this sooner rather than later so that more general testing can be completed by the time 4.6 is released.
It's gonna happen real soon now ;)
I think that what we should do is rename the current image project and cvs to image old. This is because the new image module is a completely new development, and thus should start the bug reports and everything fresh. This will make it much easier to maintain problems between the old and the new.
As dries mentioned, I've built an upgrade path so that the delineation will be 4.6 - later and there is no need to duplicate projects (so there is less confusion).
This is a great new improvement for drupal, but we need to get this development moving forward for drupal 4.6
Indeed. Thanks for your work Gordon, -- James Walker :: http://www.walkah.net/
On Wednesday 23 March 2005 13:29, James Walker wrote:
This is a great new improvement for drupal, but we need to get this development moving forward for drupal 4.6
Indeed. Thanks for your work Gordon,
Please pardon if this is a dumb question, but what is the relationship between the various versions of this module in CVS? There are three recent copies of image.module in the current CVS for contributions, as of tonight: 21469 2005-03-08 17:22 ./sandbox/walkah/image/45/image.module 21646 2005-03-08 17:22 ./sandbox/walkah/image/image.module 73187 2005-03-08 17:22 ./modules/image/image.module Now, it's fairly clear the difference between the first two -- one is for Drupal 4.5 and the other presumably for 4.6 (HEAD). But what about the third one? Where does it fit in? That's a vastly different file size, such that "diff" isn't even useful here. I'm trying to test the upgrade process from the stable image.module from Drupal 4.5 to (something) for Drupal 4.6, but so far it seems that no matter which version I try, the associated image.inc file from the module directory conflicts with the image.inc module from Drupal's core "includes" directory. I feel really stupid for not being able to make this work; I know I'm just overlooking something, but there are so many permutations possible for this that I realized I'm beating my head against the wall. Should I upgrade the image module within Drupal 4.5, then go to Drupal 4.6, or the other way around? So I offer this proposition: Someone tell me the right way to do the update process, and I'll provide a test report in return. I've got a working but non- production site with a couple of photo albums and several different resolutions for a nicely-varied test run. (And I have backups so I can reset the conditions to re-run the test.) Thanks for any suggestions. Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them scott@4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/scott.pubkey
* Scott Courtney (scott@4th.com) wrote:
On Wednesday 23 March 2005 13:29, James Walker wrote:
This is a great new improvement for drupal, but we need to get this development moving forward for drupal 4.6
Indeed. Thanks for your work Gordon,
Please pardon if this is a dumb question, but what is the relationship between the various versions of this module in CVS?
There are three recent copies of image.module in the current CVS for contributions, as of tonight:
21469 2005-03-08 17:22 ./sandbox/walkah/image/45/image.module 21646 2005-03-08 17:22 ./sandbox/walkah/image/image.module 73187 2005-03-08 17:22 ./modules/image/image.module
The second one is the version of the image module that is going to be in 4.6, this is basically a complete rewrite of the one in the modules/images. module/images in the old version that is going to be removed very soon.
Now, it's fairly clear the difference between the first two -- one is for Drupal 4.5 and the other presumably for 4.6 (HEAD). But what about the third one? Where does it fit in? That's a vastly different file size, such that "diff" isn't even useful here.
I think that the version in the 45 directory is to be used as an upgrade path, so that you can move to the new version in the directory above.
I'm trying to test the upgrade process from the stable image.module from Drupal 4.5 to (something) for Drupal 4.6, but so far it seems that no matter which version I try, the associated image.inc file from the module directory conflicts with the image.inc module from Drupal's core "includes" directory.
To get this one working, just remove the include image.inc from the top of the image.module file. Don't feel silly, at the moment we are in a difficult position where the version in James sandbox is ready for cvs, but it has not been moved to the module directory. James said that this is going to happen very soon, and things will be alot easier. -- Gordon Heydon <gordon@heydon.com.au>
On 23-Mar-05, at 11:30 PM, Gordon Heydon wrote:
Now, it's fairly clear the difference between the first two -- one is for Drupal 4.5 and the other presumably for 4.6 (HEAD). But what about the third one? Where does it fit in? That's a vastly different file size, such that "diff" isn't even useful here.
I think that the version in the 45 directory is to be used as an upgrade path, so that you can move to the new version in the directory above.
Actually - the 45 version is just to have a version of this module that works with 4.5.x - 'cause some people just couldn't wait ;)
I'm trying to test the upgrade process from the stable image.module from Drupal 4.5 to (something) for Drupal 4.6, but so far it seems that no matter which version I try, the associated image.inc file from the module directory conflicts with the image.inc module from Drupal's core "includes" directory.
To get this one working, just remove the include image.inc from the top of the image.module file.
Don't feel silly, at the moment we are in a difficult position where the version in James sandbox is ready for cvs, but it has not been moved to the module directory.
James said that this is going to happen very soon, and things will be alot easier.
Gentlemen - please update your CVS checkouts :) (it's moved) -j -- James Walker :: http://www.walkah.net/
* James Walker (walkah@walkah.net) wrote:
Gentlemen - please update your CVS checkouts :) (it's moved)
woohoo, What I will do is add my image tool kits as patches to the image project so they can be included, or if you want you can just grab them from my sandbox. -- Gordon Heydon <gordon@heydon.com.au>
Its a small step for a walkah, but a giant leap for DrupalKind. :) Op donderdag 24 maart 2005 06:41, schreef Gordon Heydon:
woohoo, What I will do is add my image tool kits as patches to the image project so they can be included, or if you want you can just grab them from my sandbox. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
participants (7)
-
Bèr Kessels -
Dries Buytaert -
Gordon Heydon -
gordon＠heydon.com.au
-
James Walker -
Moshe Weitzman -
Scott Courtney