The current state of browser support for the new editor is that older browsers are not explicitly supported, but a fallback in the form of a text area will be provided. The current editor will be provided as a plugin.
Core
More discussion on browser support
In his post »Continued Discussion on Browser Support«, Jonathan Desrosiers introduced the new proposals for an editor fallback, which were proposed in the dev meeting on March 8. Besides the variants, which were mentioned in the last weekly recap, there was among others the proposal to install a fallback plugin automatically, if an old browser is detected.
There was also an own meeting on that topic.
Browser support meeting from March 15
The team discussed the topic roughly one hour, and the results are the following (quoted from Slack):
- A »text« editor available to everyone is the best fallback - new visual editor will leave old browsers behind.
- The current version of the editor packaged in a plugin
- The admin will display a notice of some sort to users of older browsers explaining the new experience, and how they can install a plugin for a better experience
- The editor team will use their research for the new editor to decide what buttons need to remain in the “text” editor for older browsers.
- A more general discussion about browser support policies will be had at the Community Summit before WordCamp EU.
Dev meeting from March 15
In the dev meeting, the results from the browser support meeting were introduced. Besides that, there was a call to test the media widgets (especially the image widget) – the newest version of the widgets is on GitHub.
Misc
- »Dev Chat Summary: March 8th (4.7.4 week 1)«.
- »Editor Experience Survey«. (Participate!)
Design
Editor meeting from March 15
The editor team decided to start feature plugin development now slowly. At this state, the team also has to define the APIs and data structure. More info about the meeting in the post »🎯 Core Editor Meeting Notes 2017-03-16« by Ahmad Awais.
Plugins
Clarification of Guideline 8 – Executable Code and Installs
Since Jetpack announced to make it possible to install themes from WordPress.com on WordPress.org installs, the plugin team was asked a few times if this violates guideline 8, writes Mika Epstein in her post »Clarification of Guideline 8 – Executable Code and Installs«. This is the rule (quoted from Mika’s post);
»The plugin may not send executable code via third-party systems.«
In specific, these items (also quoted):
- »Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.org’s
- Installing premium versions of the same plugin«
In short: No, jetpack does not violate this guideline. The guideline is more meant for plugins which have only the function to install or update other things.
Besides that, Jetpack does not insert the UI for theme installation into your WordPress backend — you have to log in on WordPress.com and connect to your WordPress.org site from there. Such services are permitted and Mika names ManageWP as another example.
More in detail in Mika’s post.