[6.1] Rebuild the image filter to a registry allowing custom filters outside the main namespace

[wilsonge]

Pull Request for Issue #31804 .

Summary of Changes

Refactor the image filter class to have custom namespaces by using a registry for loading classes.

Why is this b/c changing at this stage?

Because there is a poor user experience for third party extensions who'd have to custom autoload code to add custom filters (as evidenced by the fact we were doing this in our own tests until yesterday)

Testing Instructions

• Check loading a custom image class with a custom namespace
• Check drone tests continue pass when loading a custom registry

Documentation Changes Required

Yup - refactor the namespaced stuff.

[soockee]

Tried to create a custom image and add a custom filter to the Registry of the CustomImage class, which is in another namespace, e.g. Joomla\CMS\Customimage
This seems to work, but is it intended behavior that the Image class and the CustomImage class share the registry and all their newly registered filters?

Inside a Plugin in /plugins/system/

                $image = new CustomImage(imagecreatetruecolor(1, 1));
		// Verify that the filter type exists.
		$serviceRegistry =  CustomImage::getServiceRegistry();
		if(!$serviceRegistry->hasService($type)){
			$serviceRegistry->register($type, SuperBrightness::class);
		}
		$className = $this->getClassName($type, $serviceRegistry, CustomImage::class);

		// Instantiate the filter object.
		$instance = new $className($image->getHandle());

		if(!$this->isValid($instance, SuperBrightness::class)){
			throw new \RuntimeException('The ' . ucfirst($type) . ' image filter is not valid.');
		}

I also tried to replace the registry of the Image class with a custom Registry in another namespace, The Image class expects the registry to be of type \Joomla\CMS\Image\ImageFilterRegistry and therefore it seems no custom registry ( that is in another namespace ) can be provided.
Is it intended to not be able to overwrite the Registry of the Image class?
I imaging that my custom registry provides different( e.g. custom filters ) for already existing filter keys like

'brightness' => Filter\CustomBrightness::class,

registry replacement snippet, in which the custom registry provides a custom brightness filter, but fails

                Factory::getContainer()->set(\Joomla\CMS\Image\ImageFilterRegistry::class,new \Joomla\CMS\Customimage\ImageFilterRegistry); 
		$options[IMG_FILTER_BRIGHTNESS] = 50;
		$image = new Image(imagecreatetruecolor(1, 1));

                // This does not work, because the Image class expects a specific ImageFilterRegistry 
                // It Throws: 
                // Return value of Joomla\CMS\Image\Image::getServiceRegistry() 
                // must be an instance of Joomla\CMS\Image\ImageFilterRegistry, instance of Joomla\CMS\Customimage\ImageFilterRegistry returned
		$image->filter("brightness",$options);  

Appended the source code for the plugin imagefiltertest which could be placed in plugins/system/ and the library Customimage which could be placed in /libraries/src/

imagefiltertest.zip

[HLeithner]

This pull request has automatically rebased to 4.2-dev.

[joomla-bot]

This pull requests has been automatically converted to the PSR-12 coding standard.

[rdeutz]

@wilsonge what are we doing with this PR?

[HLeithner]

This pull request has been automatically rebased to 5.0-dev. No new features will be merged into Joomla! 4.3 series. Joomla! 4.4 series is a bridge release to make migration from Joomla! 4 to 5 as smooth as possible.

[HLeithner]

This pull request has been automatically rebased to 5.1-dev.

[HLeithner]

This pull request has been automatically rebased to 5.2-dev.

[HLeithner]

This pull request has been automatically rebased to 5.3-dev.

[HLeithner]

This pull request has been automatically rebased to 6.0-dev.

[HLeithner]

This pull request has been automatically rebased to 6.1-dev.

[HLeithner]

This pull request has been automatically rebased to 6.2-dev.