Editor changes in 4.7

There are a few noteworthy changes to the editor in WordPress 4.7.

Some of the toolbar buttons have been rearranged to make them easier to access and to encourage proper use of the HTML elements they insert.  The headings drop down is now moved to the top row, and the strike-through and horizontal rule button are moved down. This also reflects their usage.

The underline and justify buttons have been removed from the bottom row. Underlining is a bad practice as readers can confuse it with links (bad accessibility), and it does not insert a semantic element. Justifying has uneven browser implementation, and in many cases is bad for readability. Keyboard shortcuts for both will keep working.

For more information see #27159 that also has links to the discussions in Slack.

Labels for keyboard shortcuts have been added to the tooltips for buttons and inside drop downs to make them easier to discover.

As always, feedback is welcome.

Ella and Andrew

#4-7, #dev-notes, #editor, #tinymce

Editor changes in 4.6

In WordPress 4.6 TinyMCE is upgraded from version 4.3.10 to 4.4.1. There are numerous bug fixes and several new features, most notably a new inline theme (changelog).

The wpview editor plugin (that is responsible for showing gallery, video, audio, and oEmbed previews) was updated to use the TinyMCE API for non-editable elements. This brought some small changes and improvements in the UI, for example “views” are draggable now. On the back-end the wp-mce-view-unbind event was removed as it doesn’t exist in the API. It was intended for cleanup/unloading but was never very reliable. If a plugin needs to unload instance dependent scripts, it can use mutation observer to monitor when the view node is deleted. See #36434 for more information.

wpview remains an experimental API, though with each iteration it is getting closer to being finalized. As an experimental API, breaking changes are expected. As always, please test your plugin now if it modifies or depends on the editor, especially if you use experimental features like wpview.

#4-6, #dev-notes, #editor, #media, #tinymce

Link modal (wpLink) changes in WordPress 4.5

There is a new and improved inline links dialog in the Visual Editor, see #33301. When the users type in the URL field, it uses jQuery UI Autocomplete to search for local posts and pages.

The old modal dialog (a.k.a. wpLink) is still used for “Advanced” link options. It was simplified, the infinite scrolling bottom part was removed. Now this dialog also uses UI Autocomplete on the URL field to search for posts and pages. That makes it consistent with the inline dialog and leaves more space for plugins that want to add additional settings in it.

If your plugin uses or extends wpLink, please test it now to confirm all is working properly.

#4-5, #dev-notes, #editor

Shortcodes roadmap — clarifications

As mentioned in the initial shortcodes roadmap post, the main purpose of this roadmap is to find the best way for improving the shortcodes API and moving it forward. Currently it is slow, fragile, and attempts to handle a lot of edge cases. For this, the most important part is:

  • No shortcodes in HTML tags attributes.
  • No HTML in shortcodes attributes.

There are a few things that deserve to be clarified. Simple shortcodes are great. They are easy to understand and be typed directly by the users. Example: [gallery].

Unfortunately many plugins add complex shortcodes with many attributes and often with nested shortcodes. These are a nightmare for the users. They are not intended be typed directly and can be edited by some sort of UI. Using shortcodes to store this type of data in post_content is not a good idea. Since there is a UI for entering and editing, it would be better to use a simple shortcode to “hold the place”, and save all the data in post meta.

Many of these complex shortcodes also include HTML tags in their attributes. To keep that functionality, the second roadmap draft proposed an extended syntax that allows the shortcodes “content” (the text wrapped by [shortcode] and [/shortcode]) to be additionally separated by delimiters. That would allow for shortcode attributes to contain HTML tags that are stored in the shortcode content.

These delimiters are not intended to be typed directly by the users. They are intended for the plugins that have shortcode editing UI and cannot function without storing HTML in shortcode attributes.

At first look this makes the syntax needlessly complex. However after looking at how complex shortcodes are used now, it is relatively the same: these shortcodes cannot be typed directly and are useless without some sort of UI.

There have been questions about line breaks in shortcode content. It is possible to add support for this. However it will benefit only a very small amount of users. Since shortcodes “live” in HTML context, and line breaks are ignored there, typing in the Text editor and switching to the Visual editor will remove all line breaks. Typing in the Visual editor will add paragraph tags. So only users that never use the Visual editor and have to type long, complex shortcodes will see some benefit.

The Shortcode API Roadmap meeting is in #feature-shortcode today at 17z, which is 2015-10-14 1700.

#meeting, #roadmaps, #shortcodes

Shortcodes roadmap

The Shortcode API is well loved by developers. Thousands of plugins use it for many cool features.

Unfortunately it wasn’t documented well when it was added. Even now the documentation is somewhat incomplete. The API was also very permissive, allowing many unintended user cases.

The result of these early mistakes is that there are plugins which use shortcodes in very unintended ways: mixed with HTML tags, nested several levels deep, with huge attributes, etc.

What are shortcodes:

  • With one word: placeholders.
  • Convenient way to add dynamic content inside post_content at run time.

What shortcodes are not:

  • A way to conceal user input in post_content.
  • A way to store any type of data in post_content. There are better places and methods for that, like post meta.

Shortcodes “live” in the same context as HTML tags. They should obey the same rules. Also — no interlinking between HTML tags and shortcodes. Think of the [ and ] being equal to < and >.

Both <p title="<b>my title</b>"> and [paragraph title="<b>my title</b>"] should be illegal for the same reasons. Also <p title="[my-span]">. I know the current shortcodes parser mostly supports these, and some plugins use them, but that will probably need to change “for the greater good”.

There is simply no good reason for trying to support mixing of shortcodes and tags with the current parser. These cases take longer time and more resources on every front-end page load. They require much more complex code to sanitize and ensure they are safe to run. If plugins cannot operate without mixing shortcodes and HTML tags, they will eventually have to implement their own placeholders and parsers, and ensure all data is sanitized properly. This will require a lot less time, effort and processing as the plugins would know what to expect.

We’ve been talking about this with @miqrogroove for a while now. There are several very interesting suggestions in his post on the subject: http://www.miqrogroove.com/blog/2015/shortcode-v44/.

We both agree that we need to create shortcodes roadmap, similar to the taxonomy roadmap. This will allow us to fix the shortcomings in the Shortcode API and clear the path for future improvements.

#roadmaps, #shortcodes

Editor changes in WordPress 4.3

The editor initialization was updated. The main change is that the content for both Visual and Text editors is prepared/escaped the same. We used to run the content through the PHP wpautop() when the default editor was TinyMCE. This is no longer needed as we run the textarea content through the JavaScript wpautop() before initializing TinyMCE.

In that terms wp_richedit_pre() and wp_htmledit_pre() were deprecated together with the richedit_pre and htmledit_pre filters. They were replaced by format_for_editor() and the format_for_editor filter. For more information see #32425.

Another change is the complete removal of the code for the old Distraction Free Writing mode. This code was disabled and has been unused since WordPress 4.1. We left it in core so the authors of plugins that were using it would have plenty of time to update.

If this is essential for some plugins, the files from WordPress 4.2 can be reused. For more information see #30949.

If you are the author of a plugin that uses any of the deprecated functions or filters, please update it now. If your plugin uses wp_editor(), please test it in the latest beta.

As always, feedback is very welcome.

#4-3, #dev-notes, #editor, #tinymce

TinyMCE 4.0 is in core

This is a major upgrade for the WordPress editor. There are many changes in 4.0:

  • New UI and UI API.
  • New theme.
  • Revamped events system/API.
  • Better code quality, readability and build process.
  • Lots of (inline) documentation.
  • And generally many improvements everywhere.

All default TinyMCE plugins have been upgraded. The WordPress implementation custom plugins  were upgraded too. Looking in the plugin repository, there are a lot of WordPress plugins  that add a TinyMCE plugin. Because of all the API changes, most of these plugins would need an update too. If you are the author of such plugin, please test it in trunk now.

Generally there are three groups of TinyMCE plugins added by WordPress plugins:

  • Custom plugin created specifically for the WordPress plugin. If you’ve developed this kind of plugin, please see the 3.x to 4.0 migration guide and the 4.0 API documentation.
  • WordPress plugins that add third-party or default TinyMCE plugins would (of course) need to be updated to include the 4.0 version of the plugin. The PHP global $tinymce_version can be used to determine which plugin to load.
  • Mini-plugins that only add a button to the toolbar. This works pretty much the same. It is advisable to update to use the ‘dashicons’ icon font instead of image icon.

TinyMCE 4.0 includes a ‘compat3x’ plugin that should prevent all fatal errors caused by old plugins and adds compatibility for most of the 3.x API methods. If there are any editor related Javascript errors while running trunk, please open a trac ticket quoting the first error from the browser console.

#3-9, #dev-notes, #editor, #tinymce

Agenda for today’s autosave and post locking team…

Agenda for today’s autosave and post locking team meeting at 21:00 UTC:

  • Assign contributors for each component: Autosave in the browser storage, Post locking, Login expiration warning.
  • Further discussion on workflow for post locking, perhaps look at the plugin by jayminkapish on #18515.
  • Free-form Q&A.

#3-6, #autosave-and-post-locking

Autosave and Post Locking

Components and design

As Mark pointed out earlier, this task includes several different components:

“WP Heartbeat” API, #23216. This will do polling or long-polling so the server is able to send data and notifications to the browser. The primary use will be for setting, monitoring or taking over a post lock. Additionally it will be used to send autosave data to the server. It looks like we won’t need long-polling for now as post locks are not that time sensitive. A “standard” polling every 15 seconds would be sufficient.

Post locking. How exactly to lock a post and how a user can take over the lock? Best would be to prevent user B from being able to edit the post while user A is still writing or editing. Some ideas discussed at the IRC meetup yesterday are to overlay a transparent div over the editor and/or set the form fields to read-only. There will be a button for user B to take over the lock, clicking it will prompt user A to save the post and close the browser tab. While user B is waiting to take over, we could show a non-editable “preview” of the content (even inside the editor) updated with every “heartbeat”.

In addition we would show whether a post is being edited on the Posts screen (list table) , perhaps with the same type of button to request taking over. Other ideas welcome.

Autosave to the browser’s local storage, #23220. Keep several revisions of the content on the user’s hard drive, saving every 10 seconds and “flushing” to the server every 2 minutes (same as currently). After saving to the server (including saving a draft or publishing), empty the local storage and start again. So at the end of creating or editing a post, the local storage will be empty.

This will require “plugging into” the revisions API for restoring revisions from the local storage and some UI for letting the user recover the last revision from local storage when it exists.

Log-in expiration warnings. Update the current functionality to use the new heartbeat API and improve the UX and UI. We can detect cookies expiration earlier and show a warning that would open an iframe so the user can log in again. After that interim log-in, we will need to update all nonces.

Office hours

The first feature team meeting in IRC will be next Tuesday, 22 January at 1pm PST / 21:00 UTC. Please join us if you’re interested in participating in the development of any of the above components.

#3-6, #autosave-and-post-locking

A bunch of unused images were removed from…

A bunch of unused images were removed from core in changeset 21498. Several of them were background gradients that were replaced with CSS 3 gradients. The rest have been unused in core for few releases.

However there are some plugins that use a few of these images and would need updating. Best thing to do would be to copy the images locally as that makes a plugin independent from core changes. If the images were gradients, best would be to use CSS 3 gradients (example).

#plugins