Overriding oxUtilsPic::resizeImage()

Hello,

I want to replace / override oxUtilsPic::resizeImage() in the manner

resizeImage(){
do something;
return parent::resizeImage();
}

Although oxUtilsPic is not to be found on the list of not overrideable classes, my module isn´t loaded. I would highly appreciate any hints.

check here: http://wiki.oxidforge.org/Tutorials/image_handling_changes#Extending_new_image_handler

Hello,

thanks for this valuable information!
How ever, as I need to work with a productive shop of v 4.4 that will not be updated tll 2012, I would still need an way to override resizeImage().

Thanks a lot

oxUtilsPic should be overloadable in usual way. Could you post the complete code and steps you tried?

Hello,

I resorted to extend _resize(), but would extend anythink that gives the desired result.

In /modules/ is the file myresize.php :

<?php
  //add to modules: oxUtilsPic => myresize
  class myresize extends myresize_parent
  {
    protected function _resize( $aImageInfo, $sSrc, $hDestinationImage, $sTarget, $iNewWidth, $iNewHeight, $iGdVer, $blDisableTouch, $iDefQuality )
    {
        exit(); //if script exits, I know this has been called.
        
        return parent::_resize( $aImageInfo, $sSrc, $hDestinationImage, $sTarget, $iNewWidth, $iNewHeight, $iGdVer, $blDisableTouch, $iDefQuality );
    }
  }
?>

The resizing works without alternation or desired exiting.

Well i tried with a 4.4.4 and it exits. Maybe oxutilspic is instantiated too early, in this case it would help to add this to config.inc.php (but you also need the line in system/modules):

$this->aModules = array(
'oxutilspic' => 'myresize'
);

Thanks for your effrots. I did try that, but had no success so far. How ever, as my change seems to be depreciated in a future update, I decided to hardcode it into the oxUtilsPic.php file.

The shop I work on has dozens of modules, but none for oxUtilsPic. Does it make any difference in what order they appear in that modules-textarea in the admin?

Thanks again

Zsolt

No i don’t think the order makes any difference. Oxutilspic is a singleton, it is created only once with the first call to oxutilspic::getInstance, “oxnew” is used there, so if your module is present in config-array “aModules” at this time it should work. If you want to figure this out some day, you could debug oxutilsobject and see what is happening there.