Remove duplicate "generate-image" rest endpoint registration.

[iamdharmesh]

Description of the Change

While writing the V3 migration guide, I discovered that the "generate-image" REST endpoint is registered twice, once in the DallE Class and once in the ImageGeneration Class. This pull request removes the REST endpoint registration from the DallE class.

@dkotter, it seems that the REST endpoint registration in the DallE class is the most recent change we made. However, upon reviewing the code, it appears that we are registering the endpoints in Feature classes. Therefore, I have migrated the latest updates to the feature class and removed them from the DallE class.

How to test the Change

1. Go to Tools > ClassifAI > Image Processing > Image Generation
2. Turn on the Feature and enter a valid API key
3. Change any other settings as desired
4. Go to the stand-alone image generation page by going to Media > Generate Image
5. Enter in a prompt and ensure images are generated
6. Create a new post and add an Image block. Go to the Media Library of the Image block and go to the Generate Images tab
7. Enter in a prompt and ensure images are generated

Changelog Entry

Removed - Duplicate registration of the "generate-image" REST API endpoint.

Credits

Props @iamdharmesh

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests pass.

[dkotter]

@iamdharmesh So this was actually done on purpose though open to suggestions on a better approach.

Basically there's a handful of arguments (quality, size, style, format, and n) that I'm guessing won't be supported by other image generation Providers. So I wanted to add those arguments to the REST endpoint only for the OpenAI Provider.

But I couldn't find a core way to add extra arguments to a REST endpoint. I went with the approach of registering it twice, so it get's overridden with the arguments we want when OpenAI is the Provider (though saying that now, I didn't fully test to see if that worked).

I'm wondering if adding a custom filter here so the base REST endpoint can be registered in the Feature and then any Provider can add additional arguments to that?

[iamdharmesh]

@dkotter Thanks for more context on this. I was not aware of it.

I'm wondering if adding a custom filter here so the base REST endpoint can be registered in the Feature and then any Provider can add additional arguments to that?

We can add a filter hook and can add additional arguments to the rest endpoint (I did this in 59c3a51).

However, I am curious about how we can extend the adding an args in the js side. Maybe by overriding the enqueue js?

classifai/src/js/gutenberg-plugins/inserter-media-category.js

Lines 64 to 67 in 1d28d8a

	path: addQueryArgs( classifaiDalleData.endpoint, {
	prompt: search,
	format: 'b64_json',
	} ),

Also, as current duplicate rest endpoint registration is done on purpose, I am okay with it and we can close this PR if we don't want to add a new filter.

Thank you.

[dkotter]

However, I am curious about how we can extend the adding an args in the js side. Maybe by overriding the enqueue js?

Yeah, that does get tricky and not something we've fully figured out yet. I've tried to set things up to support any future work around new Features and Providers but also hard to do this without knowing for sure what Features or Providers we may add in the future, and how those will need to be set up.

For instance, we may never add another Image Generation Provider and thus none of this actually matters there. Or we may add a new Provider that functions exactly the same or one that functions completely differently. I've tried to set things up to be as extendible and flexible as possible but I'm sure in the future we'll find areas that we need to modify to support things (like adding the filter here).

On the JS side, I've thought about using the slotfill system that WordPress provides to allow Providers to modify certain things there but so far that hasn't been something we've needed to try but something we can consider in the future if needed.