WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#33849 closed enhancement (wontfix)

Add a page hook to customize.php page

Reported by: alexvorn2 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.4
Component: Customize Keywords:
Focuses: ui Cc:

Description

As we have do_action( 'widgets_admin_page' ) hook into widgets.php page we need the same for customize.php page

Hook name can be do_action( 'customize_admin_page' ) after <div class="wp-full-overlay expanded"> html tag.

This action will help everyone to add custom html elements, for me for example it is a must for adding wp_editor.

Change History (15)

#1 @westonruter
6 years ago

  • Keywords reporter-feedback added

Why not use the customize_controls_init the action? If you need to add HTML to the Customizer you can use the customize_controls_print_footer_scripts action.

#2 @alexvorn2
6 years ago

  • Keywords reporter-feedback removed

this action customize_controls_print_footer_scripts is used to lately (late).

I tried adding a wp_editor function with this action and the editor does not show... but If I add it earlier hook (as I described in the ticket) - it shows.

If you look into the DOM source of the page of using this hook customize_controls_print_footer_scripts to add elements, you can see that the HTML elements are at the end of the page, so I think this action is created for adding footer scripts but not HTML tags.

#3 @westonruter
6 years ago

  • Keywords close added

I think you should just embed wp_editor inside of the control itself. I just googled to find an example of this already being done: http://digitalzoomstudio.net/2014/10/wordpress-theme-customizer-how-to-add-a-wordpress-editor-field/

#4 @alexvorn2
6 years ago

  • Keywords close removed

the wp_editor I try to add is for a widget, in the widget I have a button the opens the editor...
and not for a field in the Customizer, this is other case.

Note: This ticket was created for adding different HTML elements, not only for my needs.

Why we have the action for the widgets.php page and not for the customizer.php?

#5 follow-up: @celloexpressions
5 years ago

I think there is another ticket looking at the issue of using wp_editor instances in widgets or the customizer. Generally speaking, I would prefer not to add another generic hook to customize.php since things should generally be changed via the customizer API.

#6 in reply to: ↑ 5 @alexvorn2
5 years ago

Replying to celloexpressions:

I think there is another ticket looking at the issue of using wp_editor instances in widgets or the customizer. Generally speaking, I would prefer not to add another generic hook to customize.php since things should generally be changed via the customizer API.

Why we have the action for the widgets.php page and not for the customizer.php?

#7 follow-up: @westonruter
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

There is also the customize_controls_enqueue_scripts action which is what is used instead of admin_enqueue_scripts.

As for adding a TinyMCE editor dynamically with JS, see #35760.

As for how to get the existing statically-output WP editor from PHP to work in the Customizer, you can also refer to the Customize Posts feature plugin: https://github.com/xwp/wp-customize-posts

#8 in reply to: ↑ 7 @alexvorn2
5 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to westonruter:

There is also the customize_controls_enqueue_scripts action which is what is used instead of admin_enqueue_scripts.

As for adding a TinyMCE editor dynamically with JS, see #35760.

As for how to get the existing statically-output WP editor from PHP to work in the Customizer, you can also refer to the Customize Posts feature plugin: https://github.com/xwp/wp-customize-posts

Thanks for your cooperation for providing better wp_editor using JS only, buy my ticket is for adding HTML tags, and adding a wp_editor was an example.

How for now I will be able add new html tags in the header if I need them into the body?

Please do not close my ticked until there is a valid solution or the idea is not worth implementing, but I think idea is nice because if we have a hook into the widgets.php page then we need a hook here too, so the conclusion is: or we add here a hook or we do not add and remove the hook in the widgets.php page too.

#9 @SergeyBiryukov
5 years ago

  • Milestone set to Awaiting Review

#10 follow-up: @westonruter
5 years ago

  • Keywords close added

@alexvorn2 I closed it because I thought it was clear how to add new elements to the page via the example of the Customize Posts plugin. That plugin adds a TinyMCE editor via the customize_controls_print_footer_scripts action successfully. If it does not appear for you, then you'll probably need to adjust the CSS to set the proper z-index (which can also be seen in the Customize Posts plugin). Otherwise, you'll need to use JS to place the element into the required place in the document.

#11 in reply to: ↑ 10 @alexvorn2
5 years ago

Replying to westonruter:

@alexvorn2 I closed it because I thought it was clear how to add new elements to the page via the example of the Customize Posts plugin. That plugin adds a TinyMCE editor via the customize_controls_print_footer_scripts action successfully. If it does not appear for you, then you'll probably need to adjust the CSS to set the proper z-index (which can also be seen in the Customize Posts plugin). Otherwise, you'll need to use JS to place the element into the required place in the document.

I would like to hear someone else thoughts, because it seems you just want to close this ticket for no reason.

Let it be a hook why bother closing this ticket again and again, a page hook does no harm anybody.

And till now I don't understand what you mean to add new HTML elements with your plugin, I think a hook add_action( 'customize_admin_page' ) is the only solution for adding elements to customize.php page, if you mean adding elements with javascript/jQuery code then this idea is not nice from my point of view.

#12 @alexvorn2
5 years ago

This hook is not only for TinyMCE editor but for and other HTML elements.
The customize page with it's functions is very buggy and it require a lot of improvements.

#13 @westonruter
5 years ago

The Customizer interface is almost entirely driven by JS. It is not unreasonable to assume JS should be required for placing an element in the interface. @celloexpressions has already responded above indicating that adding a new hook is undesirable. I still don't see a need for a new hook when we already have customize_controls_print_footer_scripts for injecting markup into the page. This hook can be used for adding any elements (such as templates) which can then be placed in the required locations with JS.

#14 @celloexpressions
5 years ago

I agree; if HTML does need to be added outside the scope of panels, sections, and controls (all of which support fully customized markup with custom objects), it should be injected with JavaScript, via the customize_controls_print_footer_scripts action.

#15 @DrewAPicture
5 years ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

@alexvorn2 Two Customizer component maintainers (one of whom is a core developer) have already concurred that adding a hook for customizer.php isn't the way to go.

As @westonruter alluded, simply adding a hook similarly to how widgets.php is implemented is not comparable – the Customizer is almost entirely JavaScript driven and has a vastly different architecture.

The Customizer also isn't strictly considered the front-end or back-end, but rather a middle ground, so using 'admin' nomenclature would be incorrect in this context. That middle-ground state is largely why there are Customizer-specific hooks that already enable you to implement what you're trying to do, as explained by @westonruter above.

As much as it seems annoying to have to accommodate a different implementation for the Customizer, it's a reality of an evolving codebase.

I'm re-closing this as wontfix.

Note: A ticket doesn't need to remain open for discussion to continue, so please feel free to do that if you wish.

Note: See TracTickets for help on using tickets.