Pimping OXIDs article image management capabilities

One thing I did not like about OXID from the very beginning was the, in my view, very cumbersome way of defining article images, particularly the need to upload each image to be used (icon, thumb and zoom) individually…

Being used from xtComerce and other shops, that you define and upload [B]one [/B]“master”-image, from which the shop software automatically creates the pictures it uses (in OXID: icon, thumb and zoom) itself, I (and many others) found, that this was too complicated.

Some months agao, I therefore made a “feature request” to change this, and add a xtComemrce-like capability to OXID in that respect, describing in some detail how I believed that could be implemented without too much effort.

As nothing has happened so far in that area, I have begun to implement that capability myself.

(As it turned out, my original proposal was “dead right”, and the capability described was not too complicated to be implemented!)

The way it is done is like follows:

  • To the “[B]oxarticles[/B]” database table has been added the “[B]oxmasterimage[/B]” field

  • The “[B]master[/B]” subfolder was added to the “[B]pictures[/B]”-folder

  • The admin-template for image manipulation was extended with the necessary fields to allow management of a “master”-image (see picture attached).

[B]If [/B]during one transaction a “master”-image is uploaded, the new functionality will [B]substitute [/B]the picture information for icon, thumb and zoom, which PHP provides (i.e. their “$_FILES”-structure), with the necessary information derived from the “master”-images’ “$_FILES”-structure.

This approach has the inherent “beauty”, that the further image-processing can be done by the available OXID image-processing routines!

The “master”-image is stored in the “master” subfolder in “pictures”, and the pictures for icon, thumb and zoom are resized based on the “master”-image and stored in their corresponding directories.

(This implies, of course, that the “master”-image must be at least as big, as the defined size for the zoom-image!)

There needed to be made some modifications to some modules, but, at the end of the day these were surprisingly few changes…

(Another proof of the fact, what a sound base the OXID software provides. Clever asses, these OXID developers!)

[B] I have got this part[/B][B] working[/B][B] already![/B]

(One thing I am not yet fully content with here, though, is the fact, that I had to do some necessary modifications to “[B]oxutilsfile[/B]” in the core module directly, because when “[B]oxutilsfile[/B]” gets activated, the OXID module subclassing capability is not yet active… [B](Any ideas on that, anybody?[/B])).

But there is still more!

Now that we have our “master”-image in place, we can adress another fine capability: [B]resizing[/B] [B]existing[/B] images, if you change the desired image dimensions…

(xtCommerce has an “Image manipulator” for that purpose.)

This capability was also sorely missed, but just not possible so far, due to the lack of a “master”-image that could be resized to yield the new icon, thumb and zoom images…

I have started work on such an “Image updater” already, which will do just that: resize the [B]existing [/B]images to reflect changes in image-dimensions.

What the “Image updater” will also be able do for you (if you should wish):

[B]If (and oly if!) [/B]a “zoom”-image is defined for an article , this “zoom”-image will become the new “master”-image, so that the old way of doing things can be converted to the new one!

For those still wanting to do it [B]the old hard way[/B]: [B]rejoice[/B]: you can do that, too!

As long as no “master”-image is uploaded in a transaction, all works like before!

I hope to be able to release that capability within a few days, sort of a x-mas present to the community!

A quick update…

(One thing I am not yet fully content with here, though, is the fact, that I had to do some necessary modifications to “oxutilsfile” in the core module directly, because when “oxutilsfile” gets activated, the OXID module subclassing capability is not yet active… (Any ideas on that, anybody?)).
I have solved this issue meanwhile, so that the new capabilities can be completely “plugged in” as (several) modules, and there is no need to modify core-modules any more (which would have been too bad…)

Although, of course, the right place for the new code is the core modules…

Also, I am quite confident, that I will be able to implement “on top” a “watermarking”-capabilty, so that you will be able to put your logo (or else) on the pictures. (The code for this is ready and needs testing…)

I am not quite sure at the moment what to do with the additional pictures and their corresponding zoom pictures…

So in the first release they will most likely not be covered at all…

My current idea about them is, however, that, if an image is uploaded for pictures 2,3 and 4, it will also be interpreted to be a “master”-picture, and stored as such in the “master” directory.

From this “master”-picture, the additional picture itself and its corresponding zoom picture would then be created.

Does this make sense?

Any other ideas on that?

Hey,

a Few Questions :slight_smile:
Possible to get a test version?
Which tool do you use to resize the images?

Iwhat would be a good idea is a checkbox for each picutre instead of that masterpicture.
set checkbox for pic 1 means it should be the master for that and resize it
same for pic 2 and so on
(while pic one is for thumb master too)

i dont like the idea of adding fields in the db, i would make a own table and JOIN it

i would also do 4 controls in the backend
1: recalc all images now
2: recalc new images only now
3: default parameter (which pic should be by default resized and master pic if NOT emtpy)
4 set all to default :slight_smile:

for recalc youve to think about script execution times too

for watermarking and co (which would be good too) you should mabe look into typo3
it has all those catabilitys (every image function depends on them there)
they us gdlib 2 and imagemagick which performs not so bad on linux servers (80 pics each min 8 mpixel down to 800x600 in 2 min on one core with a min of memmory usage)

This is interesting…

Question: What if the formats of my Icon, Thumbnail and full-size pic are different? Ex. Icon and Thumb with rounded-corners, and the full-size pic with sharp-corners?

Thanks, Ashant

[QUOTE=bofh;22438]Hey,

a Few Questions :slight_smile:
Possible to get a test version?
Which tool do you use to resize the images?

Iwhat would be a good idea is a checkbox for each picutre instead of that masterpicture.
set checkbox for pic 1 means it should be the master for that and resize it
same for pic 2 and so on
(while pic one is for thumb master too)

i dont like the idea of adding fields in the db, i would make a own table and JOIN it

i would also do 4 controls in the backend
1: recalc all images now
2: recalc new images only now
3: default parameter (which pic should be by default resized and master pic if NOT emtpy)
4 set all to default :slight_smile:

for recalc youve to think about script execution times too

for watermarking and co (which would be good too) you should mabe look into typo3
it has all those catabilitys (every image function depends on them there)
they us gdlib 2 and imagemagick which performs not so bad on linux servers (80 pics each min 8 mpixel down to 800x600 in 2 min on one core with a min of memmory usage)[/QUOTE]
No Testversion as it is not ready yet.

And as version 4.3.0 will have a similiar capability, I have halted development for now.

Wait and see what OXID wiil be doing then.

This ( http://www.oxid-esales.com/forum/showthread.php?t=3749&highlight=roadmap#post22056 ) is thr proposal I have made for this functionality.

Hi Avenger,

you know where to gether the nightly builts?
http://svn.oxid-esales.com/trunk/

Regards