WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 4 months ago

#30277 new enhancement

Split up Customizer JS into separate files and remove self-booting jQuery.ready call

Reported by: westonruter Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.4
Component: Customize Keywords: needs-patch
Focuses: javascript Cc:

Description

The customize-controls.js file is huge and is named incorrectly now with #28709 and the fleshed-out models for Panels and Sections. The file should be broken up into customize-sections.js, customize-panels.js, and customize-utils.js. The last of which should include the private function exposed as public methods off of wp.customize.utils. This may also include the wp.customize.init() mentioned in #29071. We need to stop booting the Customizer inside of these JS libraries with a direct jQuery.ready call, and instead let the including page invoke that. This is critical for code reusability and for unit testing. For instance, the customize.php page could do in the footer:

<script>
jQuery(function () {
    wp.customize.init( _wpCustomizeSettings );
});
</script>

For wp.customize.utils, see existing patch at: https://github.com/xwp/wordpress-develop/pull/47

Change History (21)

This ticket was mentioned in Slack in #core by westonruter. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by kienstra. View the logs.


3 years ago

#3 @celloexpressions
3 years ago

Per slack, we'll need to patch this right before commit, and are planning on doing this right before beta so that we don't invalidate all outstanding patches on this file.

#4 @ryankienstra
3 years ago

Here is one way this might be done. I know this will have to wait until right before beta.

This splits customize-controls.js into customize-sections.js, customize-panels.js, and customize-utils.js: https://github.com/xwp/wordpress-develop/pull/54

Intialization happens in the footer of customize.php, with wp.customize.init( _wpCustomizeSettings );

It also moves the api.Container class to customize-base.js.

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

This ticket was mentioned in Slack in #core by celloexpressions. View the logs.


3 years ago

#6 @ocean90
3 years ago

  • Keywords 4.2-early added
  • Milestone changed from 4.1 to Future Release
  • Type changed from task (blessed) to enhancement

#7 @boonebgorges
3 years ago

  • Version changed from trunk to 3.4

#8 follow-up: @westonruter
3 years ago

Related: #28510 (Split javascript files in media into modules)

I suggest we hold off on splitting up Customizer JS until the organization of the Media JS is settled on.

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

#9 in reply to: ↑ 8 @ocean90
3 years ago

Replying to westonruter:

I suggest we hold off on splitting up Customizer JS until the organization of the Media JS is settled on.

The media split landed in core, see #28510.

#10 @westonruter
3 years ago

  • Keywords 4.2-early removed

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


9 months ago

#12 @westonruter
9 months ago

  • Milestone changed from Future Release to 4.8

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


7 months ago

#14 @jbpaul17
7 months ago

  • Milestone changed from 4.8 to 4.8.1

Per yesterday's bug scrub, we're going to punt this to 4.8.1.

This ticket was mentioned in Slack in #core by westonruter. View the logs.


7 months ago

#16 @westonruter
7 months ago

See also #40834 (Introduce a JS module pattern to WordPress).

#17 @westonruter
6 months ago

#38806 was marked as a duplicate.

#18 @westonruter
6 months ago

  • Milestone changed from 4.8.1 to 4.9

#19 follow-up: @westonruter
4 months ago

  • Milestone changed from 4.9 to Future Release

I think this makes the most sense to be done as part of a Customizer rewrite, perhaps in a feature plugin powered by the new endpoints and making use of React or Vue to power the UI, while naturally maintaining the same Customize JS API.

#20 in reply to: ↑ 19 @celloexpressions
4 months ago

Replying to westonruter:

I think this makes the most sense to be done as part of a Customizer rewrite, perhaps in a feature plugin powered by the new endpoints and making use of React or Vue to power the UI, while naturally maintaining the same Customize JS API.

As long as this is entirely an "internal" rewrite and the JS API remains fully backwards-compatible, I can get behind this idea. That would definitely be the best time to restructure files. I am somewhat skeptical of full backwards compatibility being achievable with such a rewrite, but that's the primary requirement that we would need to consider in such a project.

#21 @westonruter
4 months ago

Backwards compatibility was maintained when the monolithic Media JS was broken up into separate files.

Note: See TracTickets for help on using tickets.