JavaScript Chat Summary for May 30th

Foreword: The topic of integrating a new JavaScript framework in WordPress has proven to be both lively and contentious. The summary that follows is a best effort at an objective and accurate recap, but you are encouraged to review the original Slack transcript for the complete unaltered context (Slack registration required).

Below is a summary of the discussion from today’s JavaScript chat (agenda, Slack transcript, last week’s summary):

Introduction

  • The conversation that followed from last week has taken heavy aim at considering only React and Vue as candidates. Have we been certain to exhaust all other options?
  • Backbone features will continue to be maintained in core for the foreseeable future
  • The decision to be made is one affecting new features to be built
  • Developers will still have flexibility in choosing their preferred tools for themes and plugins
  • We need to know what we’re building in order to make sound technical decisions. This year’s focuses can serve as a start: the post editor (Gutenberg), Customizer expansion in moving toward theme building functionality, and REST API-based reimplementations of existing features (examples including Quick Draft, post listing)

Alternative Suggestions

  • Deciding on React as the framework of choice in WordPress.com Calypso was the result of prototype implementations of various frameworks (at the time, 3+ years ago) and judging the success of each.
  • Preact could serve as a stand-in for a React-like paradigm if we consider ourselves blocked by React’s patent grant or ideological differences between Facebook the company and WordPress the project.

Contrasting Candidates for Consideration

The bulk of the conversation considered the merits of React and Vue only, largely contrasted on the basis of developer onboarding, ideological alignment between WordPress and for-profit companies, and the extent to which each sets the foundation for successful future maintenance of the features we seek to implement.

  • Vue in practice: There have been no examples surfaced for projects relating to WordPress and the sorts of features we want to build (examples welcome in comments).
  • Ideological implications: We should consider what it means to align WordPress with any particular framework. There’s a worry that the values of Facebook as a company are at odds with those of WordPress.
  • Concerns about React: its learning curve and licensing (specifically, a termination clause included in its patent grant)
  • React is a pattern as much as it is a library, as evidenced by proliferation of compatible libraries like Preact, Inferno, Rax, and others.
    • Patterns emphasizing declarative rendering, one-way data flow, and embracing JavaScript the language. WordPress has historically stayed true to the fundamentals of the languages, largely foregoing template languages or other domain-specific languages in PHP.
  • Embracing JavaScript the language
    • Building rich applications is not comparable to history of applying JavaScript minimally in small interactions. Modern JavaScript is necessarily more involved to learn than a library like jQuery because we are building more complex functionality.
    • Are we really setting a foundation for developers to succeed into the future if we obscure the language with a template language like Vue’s (logic example)? Are we being inviting to new developers who began programming using JavaScript, or providing skill-learning opportunities that are broadly applicable?
    • Vue offers render functions similar to React, but their existence could undermine the perception of Vue being simpler if we’re acknowledging that the limits of the framework necessitate additional paradigms encompassing the entirety of React. Or is the argument of React’s complexity something else?
  • Conversely, there is a strong sentiment that Vue has a much friendlier developer onboarding experience. WordPress has prospered by its approachability, and our patterns in JavaScript should reflect this too. Vue’s documentation is undeniably superb.
    • Regardless of any framework decision, making educational resources available will be important
  • The role of corporate backing: Is Facebook’s investment in React a benefit in its supporting longevity of the project, or would it hold us hostage to the whim of their decision-making?
    • Vue is largely maintained by a single contributor (related: bus factor) funded via Patreon to work full-time on the project
    • It is not in Facebook’s interest to make large backwards-incompatible changes, because they too would suffer in their maintenance of hundreds of thousands of components across their products
  • On the complexity of React: is this more accurately attributed to supporting tooling? Specifically build tools like Webpack, and patterns for state management like Redux. For better or worse, React is largely unopinionated on architecture not affecting view rendering.
    • Would we need similar tooling for Vue? Both Vue and React offer no-tooling-required options, but both also push developers toward a build process (single file components for Vue, JSX for React)
    • Is build configuration something that we’d expose to developers anyways? Maybe not for the configuration itself, but a build process generally limits ability to directly modify files on a remote server.
    • Build tooling could be a worthwhile inevitably for developers to learn
  • Readability: Vue components may be more readable for new developers because they leverage HTML-like elements and attributes
  • Approachability: Ease of getting started can be a double-edged sword if it fails to teach fundamentals of the language that would be necessary for continued maintenance. The demands of rich interfaces necessitate a deep understanding of the language.
    • At the same time, we must not ignore that WordPress would not be where it is today if not for its ease of getting started. If we achieve maintainability but nobody is willing or capable to maintain it, then nothing is accomplished.
  • To differing sentiments between the developer chat and resulting commentary on last week’s summary: there are clear React leanings observed in the Slack chat, whereas the summary comments largely favored Vue.
    • How can we disassemble surface-level claims of “complex” and “simple” into a detailed understanding of why these feelings exist?
  • The broad impact of choosing a framework: Plugin and theme authors should have the freedom and flexibility to choose their desired tool.
    • In this framing, it should primarily be a decision of core contributors to make if it is they who are to be affected.
    • But is a framework decision going to count as a vote of confidence and unnecessarily skew perceptions one way or the other to choosing the best tool for the job?
  • Learning from the past: Why does Media Library see so few contributions? What lessons can we learn from this to avoid having this conversation again in a few years time, or is that an inevitability?
  • Future compatibility: Templating languages tend to have short lifespans. An example was raised of a Vue 2.0 breaking change regarding v-for as evidence suggesting that deviations from the core language are subject to change and therefore undermine stability. Learning the syntax of a language can be simple at the cost of understanding the underlying flow of data.
  • Process for adoption: A rewrite is unfeasible, and therefore modularity is an important consideration. Do we see the future dashboard as a collection of small applications, or a monolithic single-page application? There appear to be differing opinions on this.
    • Instead of rushing to adopt a new framework, where can we find ways to reduce our footprint, especially in light of revised browser support?

Conclusion and Action Items

With WordCamp Europe quickly approaching and this conversation having encompassed two JavaScript chats, it’s expected that a review of the discussions and formulation of action items should take place during the WCEU contributor day and at the Community Summit.

The topic of next week’s JavaScript chat will not focus on this decision, but you are encouraged to leave your comments below relating to this week’s topic or a suggestion for next week.

#javascript, #summary

Dev Chat Summary: June 21st (4.8.1 week 1)

This post summarizes the dev chat meeting from June 21st (agendaSlack archive).

4.9 ideas and brainstorm

  • No immediate 4.9 timeframe, but the planned timing for 4.9 will come shortly after we confirm the major focuses of 4.9 and will be closer to 3 months than 9 months in duration
  • @jorbin: Scheduled customizer changesets going live could be a big win
  • @westonruter: adding statuses for changesets: being able to draft a changeset to come back to later, and then to be able to schedule it to go live.
  • @youknowriad: We have some REST API needs in Gutenberg:
    • Retrieving The permalink using the API (making more things available from wp-json/wp/v2/settings)
    • An API endpoint to save/get random settings (we’d use it to save some layout options)
  • @androb: Expanding link boundary behavior in TinyMCE to other inline elements
  • @androb: TinyMCE has a new mobile-optimized UX that will also result in a responsive toolbar, this should land in the 4.9 time frame
  • @androd: tweak the TinyMCE UI to be closer to Gutenberg (e.g. toolbar color, default font) to get users used to the Gutenberg UI before releasing that in WordPress 5.0
  • @saracannon: look at customizer revisions in a way that we might want to look at Gutenberg revisions in the future from a visual standpoint and start making progress there (@melchoyce: see mockup for customizer revisions on #21666)
  • @melchoyce: code editing improvements across core — CSS editing, the plugin/theme code editor, etc. Making it better to use and harder to mess up and break your site (see #31779)
    • @clorith: As soon as we do this, we need to handle the issue of lacking forked plugins, lacking child theming etc
    • @westonruter: add a warning to encourage people to be aware of the dangers of editing code without version control (see #41078)
  • @melchoyce: evisions for everything – Customizer revisions, page/post revisions, code editor revisions…
  • @hugobaeta: reduce the amount of declared colors (namely shades of gray) in the admin, more info on codepen and a little backstory on this flash talk at WCUS last year
  • @melchoyce: some in-progress tickets for improving theme switching: #39692, #39693
  • @melchoyce: also Customizer menu improvement – #40104
  • @melchoyce: automated testing in place for theme switching (@netweb to work on this)
  • @melchoyce: making “page on front” less confusing (again)
    • @westonruter: harmonizing with menus and page hierarchies. Merging those concepts together
  • @melchoyce: finish the gallery widget (@m1tk00 to work on this)

4.8.1 agenda

  • @westonruter: resolve text widget removing code issue (see #40951) alongside implementing HTML code widget (see #40907), three options proposed, one recommended
  • a11y bug-scrub will happen next Monday, will focus on 4.8.1 milestoned tickets
  • approaching 4.8.1 tickets as more traditional regression types of issues
  • Tentative timeline for 4.8.1 last week of July

#4-8, #4-8-1, #4-9, #core, #dev-chat, #summary

4.9 and Gutenberg

I am really happy with the 4.8 release: the potential impact on new users and community event attendance is big, and the entire community really pulled together to make it a success.

I’m sure many people are curious and anxious about the Gutenberg editor. You can of course follow along and participate on GitHub, and we’re hoping that a plugin for easy install and usage will be available soon.

I’d like to give Gutenberg some extra gestation time as a plugin, ideally getting it to 100k active sites over the next month or two, before we merge. It’ll be easier (and safer) to get people to install and auto-update a plugin than switch their sites to trunk. We could even put a promo for it in 4.8.1.

In the meantime I think we can do another user-focused 4.9 release with the theme of editing code and managing plugins and themes, doing v2s and polishing some features we brought into WP last year. Weston and Mel already have some good ideas there, and we can start to discuss and brainstorm at the Dev chat next week. This will also allow the Gutenberg-driven release to be 5.0, which is a nice-to-have but not the primary driver of this decision.

Hopefully I will see some of y’all at WordCamp EU, and regardless be sure to tune in to my session tomorrow which you can livestream from the WordCamp Europe homepage.

Customizer sidebar width is now variable

A common request for the Customizer has been to grant more room for the controls that appear in its sidebar. Ticket #32296 was created to allow the sidebar pane to be user-resizable with a grabber just like the Dev Tools pane in Chrome can be resized. After a lot of back and forth, the scope was reduced to remove the user-resizable aspect and to instead address a more fundamental issue that the sidebar is exceedingly and unnecessarily narrow on high-resolution displays. So while 4.8 doesn’t include a user-resizable controls pane, there is still a feature plugin for possible future merge. Important to that end, the changes that have been merged begin to introduce the fundamental prerequisite for a variable-width sidebar pane: responsive controls.

As can be seen in [40511] and [40567], no longer should Customizer controls assume that their container will always be 300px wide. Given the new responsive breakpoints for high-resolution screens, the pane can now be between 300px and 600px wide depending on the screen width. And actually this has already been the case on smaller screens (e.g. mobile) where the preview and pane aren’t shown at the same time; it now also applies to very large screens where there is ample space for both the preview and a wider pane.

Custom controls in plugins and themes should utilize alternative approaches to doing layout than using pixel widths. Use of percentage-based widths or flexbox will help ensure that controls will appear properly in larger displays, while also making controls future-compatible when the sidebar width could be user-resizable.

#4-8, #customize, #dev-notes

Removal of core embedding support for WMV and WMA file formats

With the introduction of the video widget (#39994) and audio widget (#39995) it was discovered that the WMV and WMA file formats are no longer supported by MediaElement.js as of v3. While core is currently shipping with MediaElement.js v2.22, these file formats only play if the Silverlight plugin is installed, something which is less and less common since the plugin is no longer supported as of Chrome 45 and as of Firefox 52. So with the planned upgrade of MediaElement.js from 2.22 to 4.x (see #39686), it is a good time with the WP 4.8 major release to remove support for the formats. This has been done in [40813] for #40819.

Plugins may continue to add embedding support for these file formats by re-adding them via the wp_video_extensions and wp_audio_extensions filters, for example:

function add_wmv_to_wp_video_extensions( $extensions ) {
    $extensions[] = 'wmv';
    return $extensions;
}
add_filter( 'wp_video_extensions', 'add_wmv_to_wp_video_extensions' );

function add_wma_to_wp_audio_extensions( $extensions ) {
    $extensions[] = 'wma';
    return $extensions;
}
add_filter( 'wp_audio_extensions', 'add_wma_to_wp_audio_extensions' );

Plugins would also need to implement fallback rendering routines via the wp_video_shortcode_override and wp_audio_shortcode_override filters, or else use a different library than MediaElement.js altogether via the wp_video_shortcode_library and wp_audio_shortcode_library filters.

Note that there is no functional difference before and after the removal of WMA and WMV support. When MediaElement.js doesn’t support a format, it displays a download link. Before and after [40813], the following is ho  the audio and video shortcodes look like with WMA and WMV files respectively:

In the admin, the functional difference is that these formats are not listed as being available for selection in the Video and Audio widgets. Additionally, when you Add Media in the post editor, there is now no option to embed the player for these formats; only a link to the media will be provided, just as when attempting to add non-media files to content.

#4-8, #core-media, #dev-notes, #mediaelement

WCEU & Weekly Multisite Chat Summaries

During lunch at WordCamp Europe, there was an informal discussion with some contributors who have an interest in multisite. This post is meant to summarize those discussions and create a plan for organizing and improving the multisite component moving forward.

Present for discussions: @flixos90 @stephdau @spacemonkey @desrosj

Weekly Component Dev Chats

Because all contributors cannot be present every week, there have been a few instances where deep discussions have reoccurred in consecutive weeks due to a different set of people being present. This has slowed progress, and also limited feedback to only those who can attend.

The meeting discussions sometimes veer off course to items that are not necessarily a part of the current component goals. Weekly bug scrubs have also on occasion turned into detailed discussions (more on this later).

For these reasons the following items were proposed:

  • Post a meeting agenda weekly at least one full day prior to scheduled dev chats.
  • Post a meeting summary after the meeting.

The meeting agendas will help keep the conversations on target and ensure they are productive. They will also help contributors decide which meetings they want and need to attend. If someone has anything that they would like to contribute but is unable to attend, they can post a comment on the agenda post.

The meeting summaries will help inform all who were unable to attend by communicating what was discussed. It will also help prevent discussions from reoccurring in consecutive weeks when a different set of contributors are present. Anyone can also comment on the meeting summary with any additional feedback. If there is a lot of feedback on the summary, the topic can be slated for more discussion during the following week’s dev chat.

These two things have proven effective for both the Core and JavaScript chats, and should also help the multisite component.

Multisite Roadmap

In an ongoing effort that will continue through the next couple weeks, a component roadmap is being discussed. Roadmaps are great for identifying the current problems that should be solved in a general order and establishing a direction. The roadmap should also describe why each problem needs solving with examples, and what steps potentially could be taken to reach a solution.

By listing out the goals and needs of the component in the rough order they should be tackled, dev chats can be more targetted and the component can progress more effectively.

Currently, the primary goals of the multisite component are implementing a REST API endpoint for sites and improving the user endpoint to support all multisite functionality. It is also likely that a networks API endpoint will be introduced, although that is a lower priority than the other two. Sites and networks are the only WordPress core component without a REST API endpoint.

Information Sharing

Since WordPress.com has had a Sites endpoint for quite a while now, @stephdau shared some links after the meeting with the other attendees. He emphasized that nothing there is secret and there is a desire to share information and collaborate. He also stated that much of the code is actually packaged in Jetpack.

Ticket Gardening

As of this being published, there are 160 bug tickets for the multisite component in Trac. It would be great to decrease this. As mentioned above, weekly bug scrubs occasionally turn into continuation discussions of the previous dev chat. Having specific ticket lists to work through on a given day may help more effectively manage tickets belonging to the component, gardening them into the appropriate milestones.

@johnbillion also mentioned in a separate discussion that he has an offline list of multisite bugs that he has noticed. He will be going through Trac at some point to ensure each issue has a Trac ticket (although most already do).

Follow Up

As a follow-up to this meeting, @flixos90 created a Google Doc to help collect thoughts and serve as an organizational document for the multisite component.

Weekly Office Hours

The meeting’s chat log

Attendees: @jeremyfelt @flixos90 @johnjamesjacoby @desrosj @sergey @spacedmonkey @saracannon @stephdau @earnjam

This week’s office hours were used to recap the discussions above and gather further input. @flixos90 shared the Google Doc linked above, and then discussions were had to determine if the policies roughly outlined are viable for common procedures in multisite. Eventually, after the necessary tweaks are made to the document, it will be posted on this blog and on the Networks and Sites component page. This will ensure more permanent visibility and also allow other components to possibly follow some of the ideas for their workflows as well.

Key points summarized from the document by those who were at WCEU:

  • Not repeating ourselves week to week is important. Meeting recaps will inform people who cannot attend office hours. Agendas will keep meetings focused.
  • Responsibility for creating agenda and recap posts (especially the recaps as they’re more work) should rotate between multiple contributors. This is a great way to help onboard new contributors and foster interest in the component.
  • There should be more targeted ticket lists to focus on during bug scrubs. Try to tackle the ones that relate to our roadmap goals and properly prioritize.

At times, the component does get a little slow. Even during these times, an agenda should still be posted. It was also decided that there should be one agenda post (stating the agenda for both the week’s upcoming bug scrub and office hours), and one summary per week. Having consistent agendas will help us stay on target. Establishing a roadmap as needed will also help. “The multisite group is currently focusing on these 3 things from X date to X date” could be a useful way to clearly state the current goals. This would fit well on the component page.

It was decided to change “bug scrub” to “ticket scrub” as it is not limited to discussing bugs. Also discussed was having people who can focus only on bug fixes without needing to worry about when new features will land around them. This would be very helpful to the component. Current contributors each have different strengths and utilizing these strengths effectively should be a priority.

Increased documentation around why decisions are made needs to happen. This will help future contributors understand why specific actions are taken, and why certain features are implemented how they are.

Better utilizing Trac’s “good first bug” was discussed. These tickets are very helpful for picking up new contributors and giving them a positive experience contributing to the component. Ensuring that good first bugs are in fact easy to fix is important. Good first bug tickets should not remain open for multiple releases though. Otherwise, there is a risk for a negative experience when the contribution is not immediately accepted. There was, however, some disagreement on this. Leaving easy fix tickets could be counter-productive.

There was also some post-meeting discussion about making multisite contributions to core easier. Currently, VVV does not allow a multisite install to be created using trunk. This would make writing and testing patches much easier.

Next week, @flixos90 will run office hours. @spacedmonkey will run office hours the week after that. The rough plan for office hours the next three weeks is:

  • Continued discussion on component organization and, afterward, on the sites API
  • Site meta
  • Network meta

Next week’s ticket scrub will focus on tickets without a response followed by tickets awaiting review.

To conclude the meeting, @spacedmonkey was officially approved as a component maintainer. Congratulations!

If you’re interested, please come to our meetings or leave a comment on this post with your thoughts. Multisite office hours are held every Tuesday at 16:00 UTC, while our ticket scrub is held every Monday at 17:00 UTC, both in #core-multisite. The next ticket scrub will be Monday 17:00 UTC and the next office hours will be Tuesday 16:00 UTC.

#multisite, #networks-sites

Dev Chat Agenda for June 21st (4.8.1 week 1)

This is the agenda for the weekly dev meeting on June 21, 2017 at 20:00 UTC:

  • 4.9 ideas and brainstorm
  • 4.8.1 agenda
  • Dev chat coordination
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-8, #4-8-1, #4-9, #agenda, #dev-chat

Addition of TinyMCE to the Text Widget

In its first couple years, WordPress lacked rich/visual text editing. Before TinyMCE was incorporated in WordPress 2.0, users had to edit post content as raw HTML with some support from the Quicktags buttons. When widgets were introduced in WordPress 2.2, the Text widget was included which allowed a user to add content to their sidebar. Nevertheless, unlike the post editor, the Text widget did not incorporate TinyMCE, nor did it include Quicktags. For twelve years, since TinyMCE was added to core in 2005, users have had to hack around with HTML in their Text widgets to do things as simple as make text bold or add links. This has been featured even as recently as the 4.7 release video. Well, as of WordPress 4.8, the Text widget is finally getting the same treatment as the post editor with the introduction of TinyMCE for visual text editing, while still supporting raw HTML editing via a Text tab but now with the additional help of Quicktags:

Text widget: visual tab Text widget: text (HTML) tab

A primary reason for the long delay in incorporating TinyMCE into the Text widget was the difficulty of cleanly instantiating another copy of the WordPress visual editor dynamically after the page has loaded. Since WordPress 3.3 there has been the wp_editor() PHP function for instantiating an editor for the initial page load, but there was no facility for instantiating editors afterward, such as when adding a new Text widget to a sidebar. So in #35760 a new JS API was introduced for dynamically instantiating WP editors on the page: wp.editor.initialize(). This JS API is used for the new TinyMCE-powered Text widget; for more, please see Editor API changes in 4.8.

Note that by default the Text widget only features buttons for bold, italic, unordered list, ordered list, and link. If you want to add additional buttons to the toolbar, you may use a plugin to enqueue the following JS to add the blockquote button, for example:

jQuery( document ).on( 'tinymce-editor-setup', function( event, editor ) {
	if ( editor.settings.toolbar1 && -1 === editor.settings.toolbar1.indexOf( 'blockquote' ) ) {
		editor.settings.toolbar1 += ',blockquote';
	}
});

Likewise, a custom button can be added via code like:

jQuery( document ).on( 'tinymce-editor-setup', function( event, editor ) {
	editor.settings.toolbar1 += ',mybutton';
	editor.addButton( 'mybutton', {
		text: 'My button',
		icon: false,
		onclick: function () {
			editor.insertContent( 'Text from my button' );
		}
	});
});

A reason for why there is no “Add Media” button for the editor in the Text widget is that WordPress 4.8 also includes dedicated media widgets for adding images, video, and audio to sidebars. Another reason is a current technical limitation whereby arbitrary media embeds (oEmbeds) fail to work properly outside the context of post content (see #34115). For this reason if you try to embed a video or something else by pasting in a URL it will not currently expand into the embedded content. The same is true for shortcodes: they are not processed by default since many shortcodes presuppose a global $post as the context within which they expect to be running. Plugins may opt-in selectively to support individual shortcodes by filtering widget_text as they have had to do for many years now.

While not supporting shortcodes, the updated Text widget does have some of the same filters applying to it as the_content, in particular:

  • wpautop
  • wptexturize
  • capital_P_dangit
  • convert_smilies

The Text widget has supported a “filter” instance property which was reflected in the UI via a checkbox for whether or not to automatically add paragraphs and line break tags (wpautop). For the updated Text widget, this checkbox is removed entirely in favor of aligning its behavior with the post editor where this behavior is always enabled. These filters only apply on Text widgets that have been updated/touched after the 4.8 upgrade. When a Text widget is modified in 4.8, the filter instance prop gets set to a static string “content” and then it will apply a new widget_text_content filter which then apply the above functions to the widget text.

Important: When pasting HTML into the “Text” (HTML) tab of the Text widget, any extraneous line breaks should be removed or else unwanted paragraphs and line beaks may result. This is particularly important when you paste in script or style tags (as in the case of 3rd-party JavaScript embeds), since auto-inserted paragraphs will cause script errors; this will be fixed in #2833. This behavior aligns with longstanding behavior in the post editor, so it is not new, although it does differ from how the Text widget has previously behaved. As noted above, for previously-existing Text widgets that had the “auto-add paragraphs” checkbox unchecked (and thus the filter instance prop set to false), the previous behavior of not doing wpautop will be maintained: only once the widgets are modified will any extraneous line breaks need to be removed.

The incorporation of TinyMCE into the Text widget has necessitated constructing the widget’s form fields differently than how they are normally done. Widgets in core have historically utilized static HTML for their control form fields. Every time a user hits “Save” the form fields get sent in an Ajax request which passes them to the WP_Widget::update() method and then the Ajax response sends back the output of WP_Widget::form() which then replaces the entire form. (Note widgets in the Customizer behave differently since there is no Save button in the widget, as updates are synced and previewed as changes are made; read more about Live Widget Previews.) This worked for static HTML forms in the past, but TinyMCE is a JavaScript component. To avoid having to rebuild TinyMCE every time the user hits Save on the admin screen, the Text widget puts the title field and TinyMCE text field outside of the container that is “managed” by the server which gets replaced with each save. (A similar approach has also been employed by the new media widgets in 4.8.) The fields in the Text widget’s UI sync with hidden inputs which get synchronized with the server; in the Customizer, changes to the TinyMCE field will be previewed after 1 second with denouncing. The container for the Text widget’s fields is .text-widget-fields and the traditional container for a widget’s input fields as rendered by WP_Widget::form() is .widget-content:

Themes should already account for the most common HTML elements within the text widgets and provide appropriate styles for them—the addition of the editor toolbar increases the likelihood its elements will be used in the future. Most default themes needed additional styles for ordered and unordered lists within widgets, so theme authors are encouraged to double-check their themes and test them with content in the text widget that includes markup provided by the editor toolbar.

Initial groundwork for shimming JavaScript into widgets was added in 3.9 via the widget-added and widget-updated events. A more recent proposal for making JavaScript more of a first class citizen in widgets can be found in #33507 and the media widgets incorporate some of its patterns that were also prototyped in the JS Widgets plugin. The synchronization of a widget’s state (instance properties) via hidden text fields can be eliminated once a widget’s state can be fully represented in a JavaScript model.

The Text widget is implemented as a Backbone.js view which is available at wp.textWidgets.TextWidgetControl. Instances of this view are then stored in the wp.textWidgets.widgetControls object. The widget’s control JS will only instantiate for a given widget once it is first expanded, when the widget-added event fires. What’s more is that the widget will only first initialize once the container is fully expanded since TinyMCE is not able to initialize properly inside of a container that is animating. In order to capture when TinyMCE inside the Text widget is initialized, you should use a TinyMCE event like tinymce-editor-setup. Note also that due the Document Object Model, when a widget is moved to a new location in a sidebar and this the TinyMCE iframe is moved in the DOM, this dynamically-created iframe is reloaded and thus emptied out. For this reason, every time a Text widget is moved to a new location the TinyMCE editor in the widget will be removed and then re-initialized. Keep this in mind when extending.

Keep also in mind that the Text widget will likely undergo many more changes with the incorporation of the Gutenberg editor, and that widgets themselves will likely see many changes to align with Gutenberg’s editor blocks which are now being prototyped.

#4-8, #dev-notes, #editor, #widgets

JavaScript Chat Summary for May 23rd

Below is a summary of the discussion from yesterday’s JavaScript chat (agenda):

Introducing a JS module pattern to WordPress

@omarreiss helped lead the discussion and kick-started the conversation by opening a detailed and thoughtful ticket in trac (#40834) which introduces modules, their goals and how we could go about using them in core. The discussion was around considerations specific to WordPress and a need for modularity was mentioned – @westonruter called out this need for the Customizer,  see #30277. Ideas for code that could be extracted into modules included quickedit, core date utilities and wp.media.view.FocusManager.

The decision was made to move in the direction of using Webpack (and ES6 imports) as our bundler of choice, and to work first on switching out browserfy in our current build chain.

Choosing a future JavaScript framework

Discussion started on choosing a new framework for use in core. The main frameworks discussed so far were React and Vue. Attendees shared their hope, goals and criteria for choosing a new framework and mentioned: stability, longevity, mature, well-adopted, proven in a WordPress context, accommodating to accessibility requirements, interoperability with existing code, architected to support predictable data flows and composability, alignment with efforts like Calypso,  composable, extensible, testable and ease of developer adoption.

@kopepasah promoted Vue.js, saying he found it “much more approachable and highly extensible” and also “Vue single file component is amazingly organized and easy bundle and build.” See https://vuejs.org/v2/guide/single-file-components.html.

@rmccue pointed out that the React core development philosophies match up to ours quite well: https://facebook.github.io/react/contributing/design-principles.html

@afercia raised accessibility and wanted to know which framework was best suited to offer support, specifically in handling cases where direct DOM access and manipulation is needed.

@aduth shared the reasoning behind the choice of React for the Gutenberg project: https://github.com/WordPress/gutenberg/tree/master/element#why-react

As anticipated, the decision was not settled in the meeting and discussion will resume in next week’s meeting. Currently, React appears to be the favored candidate. Please add to the conversation in the comments below, and join us for further discussion at our next meeting, scheduled for May 30, 2017 at 13:00 UTC

For the full meeting notes, see the Slack logs.

#javascript, #summary