Filter for wp_editor() arguments on attachment edit screen

[navitronic]

Hi,

I have run into an issue where I need the WordPress wysiwyg editor (rather than the stripped down version currently there) on the edit media page.

I have looked at the code that generates the page and there seems to be no filter or action available to override the tinymce value when the call the wp_editor is made.

Would it be possible to add a filter here, so that the false value is overridable if needed?

Thanks,

Adrian.

[kirasong]

Filter for wp_editor() description arguments

[kirasong]

Hi Navitronic!

Thanks for your ticket. Apologies for the wait on a reply! I like the idea, as I see why you might want to set it up that way, and have attached a potential patch​ to add a attachment_description_editor_args to allow filtering of the wp_editor() settings for the attachment description field..

[DrewAPicture]

The hook docs in 24472.diff​ look good.

Might swap out that "See docs for wp_editor() for details." sentence for a standalone @see wp_editor() tag between the @since and @param lines.

[helen]

I don't mind this, necessarily, but some args shouldn't be filterable, like the textarea_name. This also makes it easier to expose attaching attachments to attachments, which isn't horrible, but just wanted to point that out.

[kirasong]

Do not allow filtering of textarea_name

[kirasong]

helen: Agreed. Went ahead and forced textarea_name in 24472.2.diff​.

Per your comment, we could force an array of args if you think that other fields like media_buttons also should not be allowed to be changed.

Alternately, we could whitelist filtered parameters, but I can see potential use cases for the rest.

[helen]

I'm still hemming and hawing over this, which tells me that this is a punt at the moment.

nacin: feels weird that this particular location gets a filter

DH-Shredder: Think there's a better way to handle it, perhaps globally? At the time, I only thought "why not," if there's not a better way to modify it.

DH-Shredder: Since we're pretty liberal with filters

helen: nacin: DH-Shredder: i guess it is kind of weird since other wp_editor() instances for content don't have it... but then we should probably allow for the editor instance to be unhooked/otherwise removed so people can register their own.

[helen]

#28259 was marked as a duplicate.

[SergeyBiryukov]

Related: #28338

[JPry]

I believe the patch I uploaded should address both this ticket and #28338.

[DrewAPicture]

Looking at 24472-3.diff​, I don't think we need two filters here.

Seems like a single filter at the end of the function would suffice, perhaps with an array merge to prevent filtering of textarea_name (like we do with things like admin_body_class), and maybe passing $settings in addition to $set.

[azaozz]

Replying to DrewAPicture:

Yeah, we don't need two filters. All default setting can be overridden with $settings and should always be set, no point to allow plugins to change them separately.

Thinking a filter only makes sense on the passed in $settings before they are merged with the defaults. It's inadvisable to filter the return value as we may need to add some pre-processing similar to resetting $set['editor_height'], etc.

So this should probably be:

public static function parse_settings( $editor_id, $settings ) {
	$settings = apply_filters( 'wp_editor_settings', $settings, $editor_id );

	$set = wp_parse_args( $settings,  array(
	...

[DrewAPicture]

See comment:14

[DrewAPicture]

24472.3.diff​ adds only the single filter as prescribed by @azaozz in comment:15.

[SergeyBiryukov]

In 28944:

Add a filter for wp_editor() settings.

props DH-Shredder, JPry, DrewAPicture.
fixes #24472.

[SergeyBiryukov]

In 28945:

Use correct variable.

props azaozz.
see #24472.