WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#24472 closed enhancement (fixed)

Filter for wp_editor() arguments on attachment edit screen

Reported by: navitronic Owned by: DrewAPicture
Milestone: 4.0 Priority: normal
Severity: normal Version: 3.5.1
Component: Media Keywords: dev-feedback has-patch commit
Focuses: docs, administration Cc:

Description

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.

Attachments (4)

24472.diff (1.0 KB) - added by mikeschroder 4 years ago.
Filter for wp_editor() description arguments
24472.2.diff (1.1 KB) - added by mikeschroder 4 years ago.
Do not allow filtering of textarea_name
24472-3.diff (1.4 KB) - added by JPry 3 years ago.
24472.3.diff (881 bytes) - added by DrewAPicture 3 years ago.

Download all attachments as: .zip

Change History (23)

#1 @SergeyBiryukov
4 years ago

  • Component changed from Administration to Media

@mikeschroder
4 years ago

Filter for wp_editor() description arguments

#2 @mikeschroder
4 years ago

  • Focuses administration added
  • Keywords has-patch added
  • Milestone changed from Awaiting Review to Future Release

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..

#3 @mikeschroder
4 years ago

  • Summary changed from TinyMCE editor on attachment edit screen to Filter for wp_editor() arguments on attachment edit screen

#4 @DrewAPicture
4 years ago

  • Milestone changed from Future Release to 3.9

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.

#5 @helen
4 years ago

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.

@mikeschroder
4 years ago

Do not allow filtering of textarea_name

#6 @mikeschroder
4 years ago

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.

This ticket was mentioned in IRC in #wordpress-dev by DH-Shredder. View the logs.


4 years ago

#8 @helen
4 years ago

  • Milestone changed from 3.9 to Future Release

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.

#9 @helen
4 years ago

#28259 was marked as a duplicate.

@JPry
3 years ago

#11 @JPry
3 years ago

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

#12 @SergeyBiryukov
3 years ago

  • Milestone changed from Future Release to 4.0

#13 @wonderboymusic
3 years ago

  • Focuses docs added
  • Owner set to DrewAPicture
  • Status changed from new to reviewing

#14 follow-up: @DrewAPicture
3 years ago

  • Keywords dev-feedback added

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.

#15 in reply to: ↑ 14 @azaozz
3 years ago

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(
	...

Last edited 3 years ago by azaozz (previous) (diff)

#16 @DrewAPicture
3 years ago

  • Keywords needs-patch added; has-patch removed

@DrewAPicture
3 years ago

#17 @DrewAPicture
3 years ago

  • Keywords has-patch commit added; needs-patch removed

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

#18 @SergeyBiryukov
3 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 28944:

Add a filter for wp_editor() settings.

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

#19 @SergeyBiryukov
3 years ago

In 28945:

Use correct variable.

props azaozz.
see #24472.

Note: See TracTickets for help on using tickets.