Make WordPress Core

Tagged: editor Toggle Comment Threads | Keyboard Shortcuts

  • Matias Ventura 4:52 pm on January 17, 2017 Permalink |
    Tags: editor   

    Editor Technical Overview 

    As we start looking at the editor from a technical perspective it’s important we identify the main obstacles and requirements we face before we start conjecturing solutions. As @matt wrote before, the editor focus aims to make writing rich posts effortless. This has taken the path of treating a post as being composed of distinct pieces of content called blocks. These pieces should be easy to insert and manipulate, providing rich and contextual interfaces to interact with as you craft a post.

    So how do we go about turning this into a reality? Content in WordPress is, fundamentally, HTML-augmented text; that is to say, it has no inherent data structure. This has been a very important aspect of WordPress and a force for the open web—it speaks to the sense of ownership and freedom WordPress gives you, since it’s always easy to get the full content of your publications—yet the lack of structure gets in the way of the goal to treat content as composed from individual pieces. (This reality also became an issue for the development of post formats a few years ago, but I digress.)

    It’s relatively easy to add structure, but it’s not trivial to do so in a way that doesn’t harm data integrity, portability, and the cohesiveness of the post_content. So let’s lay out a first requirement:

    ① Shape of the Data: Portable Text

    To ensure we keep a key component of WordPress’ strength intact, the source of truth for the content should remain in post_content, where the bulk of the post data needs to be present in a way that is accessible and portable, while still providing additional structure on top of HTML semantics for our editing tools. Data needs to be praised and respected. This additional structure would hopefully be invisible to the document’s display context, as it ensures the rendered content is viewable in situations that may not be aware of blocks at all. (Think of email clients, RSS, older editor versions, mobile editors, database dumps, etc.)

    Storing things separately means post_content becomes either a pointer or duplicated data, which fragments the source of truth since they can get out of sync easily. (A few content block plugins do this by storing structured data in postmeta and pure data in post_content.) On the other hand, storing things together means structure can become gibberish if it’s not formatted properly before display.

    How can we then offer users a great experience when creating or manipulating content without sacrificing the spirit of integrity and data reliability that is expected from WordPress? Good representations of the data would also make it easier to develop robust collaboration tools in the future by allowing us to lock things in a more fine grained way. I believe this is important to figure out soon to allow us to prototype quickly, so I’ll follow up with an initial proposal by the end.

    Honouring HTML leads to a second requirement:

    ② Simplicity and Semantics of Representation

    Unless we are improving the semantics of the document we should minimize what markup we add to identify a block; for example, avoid adding extra DOM elements or attributes, both for simplicity and standards sake. WordPress has been a champion of web standards, and we should not venture away from this quality. How can we add structure in a way that remains invisible to the output (as meaningful content as possible) but gives the necessary hooks to infer a structured view for editing purposes?

    While we discuss how to structure the content to include invisible demarcation of blocks, the aspect of their nature leads to a third requirement:

    ③ Static & Dynamic Blocks

    Blocks can be either static or dynamic. That is to say, some blocks can be stored with all the necessary aspects needed for their display, while others need to be processed before generating their final output (shortcodes, embeds, widgets, etc). This distinction is important because the most common two blocks people will naturally use are text and images. We should not break their clarity as we treat them as blocks.

     # Static
    Here’s some text.

    # Dynamic
    [text id=123] // Pulls "Here's some text" from somewhere.

    This conceptual separation of blocks is useful for designing our project, yet they generate abstract complexity which users should not be exposed to, leading to a fourth requirement:

    ④ Consistent Experience

    One of the biggest benefits of blocks is that composing a post becomes more intuitive and reliable. Everything is inserted under the same assumptions; discovering what can be inserted is a natural part of inserting content. To the user all blocks behave in a consistent and familiar way, even if they provide tailored UIs for their controls.

    The user should also be able to edit a post in a different system (mobile, REST, older version of core, apps like Mars Edit, etc), even if they lose the advantages of block editing. That’s another reason why post_content as source of truth matters, compared to storing a JSON structure in postmeta. Having things in two places means they can get out of sync depending on what tool you used to edit.

    These nuances of data, UI, and display lead to a final and more general requirement, which is understanding the system we’ll be crafting:

    ⑤ The System

    The editor experience has three fundamental aspects to its system: the UI used to manipulate a block; the demarcation of the block; the rendered output of the block. These are all separate concerns, from the tools we craft to edit a post, to the document syntax that holds the data structure, to the way the final output is generated to be displayed as HTML. (With static blocks that last aspect may be of no significant concern since the document doesn’t care about the presence of static blocks, it just displays them.)

    Picturing these concerns as connected but fundamentally separate would help us figure out the best design and technical solutions for each stage, while avoiding us taking aggressive moves by coupling expectations. For instance, JavaScript is a natural technology to look at when it comes to the ability to manipulate and interact with content blocks, yet it may not be the best at all when it comes to rendering the final post to a viewer. Avoiding painting the whole flow under the same light should allow us to focus efforts, because we don’t have to change everything.

    ❶ Coda

    As a final coda, and following @joen‘s design exploration, let’s keep in mind that our first goal should be to set up a reliable foundation to allow us to iterate quickly and test assumptions. I propose we focus initially on a few static blocks (text, image with and without caption, quote) to limit scope of the project.

    In which ways can we fulfil ① and ② from the above requirements?

    Shortcodes fall short in that they are not invisible, they are opaque, not standing to the scrutiny of semantics, and are also painful to parse. Alternatives could be data-* attributes in the HTML elements or custom elements (paving the way for web components, perhaps), yet we need to be careful with adding cruft.

    One other possibility is to look at HTML comments as a way to provide explicit demarcation to post_content without affecting the node structure of the document for something that is inherently spurious to the HTML semantics. WordPress already uses comments for the more tag (<!--more-->) and splitting content into pages in a way that has proven to be quite robust.

    It could look something like this:

    <!-- wp:image -->
      <img src="/">
      <figcaption>A picture is worth a thousand words</figcaption>
    <!-- /wp -->

    There are drawbacks, benefits, and implications with each that we should discuss separately. Are there any other possible solutions?

    Please, join us in #core-editor if you are interested. We’re holding weekly meetings in Slack, Wednesdays at 19:00 CET.

    • Mike 5:33 pm on January 17, 2017 Permalink | Log in to Reply

      There is a trend towards the use of more attributes and elements. The editor needs to allow for this or for others to create a plugin to do this.

      • programmin 10:07 pm on January 17, 2017 Permalink | Log in to Reply

        How does it not already? Are you referring to how KSES strips out data-attribute=”attributes” in html?

    • Davide 'Folletto' Casali 5:34 pm on January 17, 2017 Permalink | Log in to Reply

      Thanks for outlining this so crisply. Stating all the requirements clearly is something often overlooked, and I feel it’s a great starting point. I’m sure there are going to be things to be expanded in the following weeks, but seeing everything together in this way is excellent.

      Agreed on all the pieces. Let’s the discussion move forward! 🙂

    • FolioVision 7:09 pm on January 17, 2017 Permalink | Log in to Reply

      Wow, that’s quite an essay on the content editor. We’ve been doing this for a long time and know the lay of the land. We even built a WYSIWYG editor we can’t give up (we tried for two years). First in praise of the WordPress editing experience: the Media Library has grown to be very powerful and easy to use. It’s awesome. We were delighted to retire the original image editing module we were using last year and fully integrate the Media Library.

      Still what are the issues with WordPress content editing which drive us to maintain a separate WYSWIYG editor?

      Hint, it’s not the money, thousands of hours have gone into this purely GPL and non-commercial product. It’s not boredom. We have too much to do in three lifetimes and very short weekends already.

      It’s not shortcodes. Shortcodes are great and reliable ways to easily and visibly add content to posts. As soon as you start trying to hide the pieces, reliability falls through the cracks. It’s why lawyers still use WordPerfect.

      Why were we unable to give up our own FCK WYSIWYG editor? Code and javascript mangling. The WordPress TinyMCE editor does not reliably maintain paragraphs and linebreaks. It’s a bit WYSYMightNotGet. When creating complex nested tables and code examples our editor never fails (don’t thank us, thank FCK in Poland, we just maintain a solid WordPress port).

      What is missing with the shortcodes and code inside a fairly utilitarian textbox is true WYSIWYG. The only way to preview a post properly is to open it up with “View Post” and then reload the page to see any changes. This is slow and clunky.

      We’ve done what we can to improve WYSIWYG by in our editor by allowing with just the tiniest modification of your theme CSS real WYSIWYG. This only covers the CSS though and not the javascript or the short codes.

      What would make the WordPress editing experience amazing would be a live preview tab which turns the shortcodes and media into their visuals.

      We’ve looked long and hard at alternative edit experiences (updating FCK to CK was very hard and there aren’t really any world changing benefits: CKeditor is roughly the same experience albeit, better behaved on mobile). When we looked around at an editor to build for WordPress we settled on redaktor.js. Andrew Oz is very sceptical about Redaktor’s suitability for WordPress (licensing issues aside, just speaking technically):

      I like it too. However it’s far from being ready for anything more than
      comments/bbPress editor. Been following several jQuery based editors,
      all have little more than the default browser contentEditable functionality.

      This one is definitely more polished than most but still lacks a lot of
      things. For example: no plugins, no way to extend it other than hack
      into it, very minimal APIs, try copying and pasting something from
      another browser tab, then look at the HTML. And a big one: no undo/redo
      for all actions?

      I don’t know… Probably some will as it is nice. However considering
      the amount of work needed, not sure if that would be enough. Roughly it
      would take a good team of several full-time developers at least a year
      to bring it closer to TinyMCE.

      Nearly all JS editors get off the ground fast by adding UI to the
      browsers built-in contentEditable functionality. Once there, most try to
      tackle few more tasks and stop. The next step requires a lot of work:
      creating APIs, dealing with tons of browser quirks, etc.

      Currently there are several other editors at approximately the same
      stage. The problem is that a lot of the functionality for editing HTML
      should be in the browsers. It can be handles much better there than
      trying to extend the limited contentEditable mode with JS.

      So unless the browser vendors decide to sit down and make and implement
      a nice specification for editing of HTML, don’t see how this situation
      would change.

      We are a long way from 2012. Redaktor is awesome visually, very fast, beautiful preview, lightweight fast editing tools for media. In short everything we’d like the WordPress editing experience to be. In my opinion, TinyMCE will never have that shiny and fast and brilliant feel. It’s in neither the personality or the technology of the software.

      Alas Redaktor is not open source. A platform license would be $199. I’d happily pay it myself for WordPress but it cannot be as it’s against our community GPL principles.

      Perhaps there is something else out there which comes close and does have an open source license or at least a split license like CKeditor and FCKedit?

      That’s the holy grail. The same editing capabilities in the editor, legacy shortcodes but fast responsive and with **immediate full preview**.

      What we should avoid at all costs would be to deprecate shortcodes and create endless compatibility issues. Such a decision would cripple the platform and leave most of our shared library of powerful and obscure plugin obsolete.

      • chatmandesign 4:51 pm on January 18, 2017 Permalink | Log in to Reply

        I’m a big fan of CKeditor. It’s a popular enough option for this I have to assume the WordPress team already has reasons they haven’t adopted it so far, but it really seems like a perfect fit here:

        1) Available under GPL license.

        2) Includes built-in support for managing blocks of content.

        3) Extensible architecture supports plugins.

        4) Robust, battle-tested, actively maintained—and used by a host of major companies and projects, so it will likely stay that way.

        5) As an added bonus, it supports inline editing that could be integrated into the Customizer or some form of front end editor.

    • buzztone 11:45 pm on January 17, 2017 Permalink | Log in to Reply

      Really helpful overview – I look forward to following development of this project.

    • Joy 12:03 am on January 18, 2017 Permalink | Log in to Reply

      I agree with @FolioVision that shortcodes should remain intact, and would even go so far as to say that they should be the basis of content blocks. Why isn’t there a list of registered shortcodes available when editing a post? Why can’t the editor show the shortcode as a block with the parameters editable? Why wouldn’t the preview call do_shortcode() to show what that block looks like? And why can’t widgets be handled the same way, as part of the content?

      • Xavi Ivars 12:15 am on January 18, 2017 Permalink | Log in to Reply

        And that’s what (more or less….) Shortcake already does as a plug in: shortcodes can register UI to define how they should be edited, appear rendered in the WYSIWYG editor and in plain old-style text in the text editor

    • Weston Ruter 1:35 am on January 18, 2017 Permalink | Log in to Reply

      Thanks for the great writeup. I see a lot of alignments between this and the solutions being prototyped in the JS Widgets feature plugin. The plugin specifically aligns in terms of “the UI used to manipulate a block” and “the rendered output of the block”, leaving “the demarcation of the block” to encoding data via structured HTML/Microdata/comments. Likewise in:

      JavaScript is a natural technology to look at when it comes to the ability to manipulate and interact with content blocks, yet it may not be the best at all when it comes to rendering the final post to a viewer.

      The JS Widgets plugin specifically focuses on the use of JavaScript for managing the block’s attributes (widget instance) whereas by default PHP is used to render the block to HTML.

      WordPress needs to have a standard interface for how to define a block which can represent its state, present a UI for manipulating its state, and render its state onto a template. The widget provides such an interface, and with modernization and iteration I think the widget can serve as a standard interface for defining a block which can be used both in post content as well as in widget sidebars and elsewhere.

      Also, a general note that the JS Widgets plugin is focused on improving the WP_Widget API itself. It is not concerned with widget areas (sidebars) and thus is not focused on how widgets are managed in sidebars on the widgets admin page or via the widgets panel in the customizer. Rather, the plugin is about iterating on fundamental widget building block and allowing it as an interface to be leveraged and re-used in other contexts, such as to manage content blocks in the editor (as prototyped for the Post Elements in Shortcake). It’s also not concerned with the storage of widgets, as in the case of Shortcake post elements the instance data is stored as shortcode attributes, though the instance data could be stored as data-* attributes, inside of HTML comments, in HTML5 Microdata, and so on.

      • Matias Ventura 4:36 pm on January 18, 2017 Permalink | Log in to Reply

        Thanks! The stages I see us progressing from would be:

        • Define structure of post_content document that includes representation for both static and dynamic blocks.
        • Parsing of document on the fly to infer more manageable structure (JSON representation).
        • Implementation of general UI layer around manipulation and insertion of blocks.
        • The system to generate final output of dynamic blocks.

        Those last two could converge in a single API, but I think we’ll see if that’s the best path once we get closer to prototyping it.

    • Weston Ruter 1:47 am on January 18, 2017 Permalink | Log in to Reply

      Also, circling back to Twenty Seventeen and its “front page sections” feature (subset of #37974). There’s a lot of overlap between that proposed feature and nav menu items, as well as with widgets and blocks in the editor. I think it is key that we define a common interface that can be used in all of these contexts. The nav menu item in core could be re-implemented using a specific kind of such block, and the nav menu should be a block container just like a widget sidebar is a block container and the post content is a block container, though each may have restrictions on the kinds of blocks they allow. They should all re-use the same underlying block API which is a thing that has a set of attributes, a UI for managing them, and a method for rendering them onto a template.

    • dmccan 2:38 pm on January 18, 2017 Permalink | Log in to Reply

      Thank you for laying out the challenges and requirements. A couple of things came to mind:

      • While I think it is a good idea to limit the scope in order to set up a reliable foundation, there is value in identifying the types of ‘blocks’ that we might want to support in the future. Such a backdrop would be good before starting to iterate so that we know that an architecture is capable.
      • From a user perspective, the #1 shortcoming of the editor is the lack of true, easily editable columns. There are true (not shortcode) column solutions available for WordPress.
      • There are two dimensions: layout and content. From a layout perspective, ‘blocks’ are content that fits into rows and columns. In the requirements discussion, perhaps layout needs to be addressed.
      • In the Coda section you mention data attributes and HTML comments for demarcating blocks, what about divs with reserved class names? That is standards compliant. Bootstrap got a lot of mileage out of that approach.
      • Matias Ventura 4:24 pm on January 18, 2017 Permalink | Log in to Reply

        While I think it is a good idea to limit the scope in order to set up a reliable foundation, there is value in identifying the types of ‘blocks’ that we might want to support in the future.

        Definitely! Starting small should not stop us from considering if our solutions are a good fit for more complex blocks.

        I purposely left out layout considerations at this stage (including columns) because they are a bit ortogonal to the basic requirements here. It’s probably worth focusing on how to address layout in a separate instance, starting with the design goals for it. There are questions like «Do we have layout blocks (column, box) that hold child blocks?» or «Do you setup layout placeholder that you fill in or is layout a result of disposition of blocks?» that have their own complexities.

        > what about divs with reserved class names?

        This is partially questioned in ②. We should avoid creating spurious DOM nodes for the sake of representing “blocks”, unless the semantics of the document are improved by doing that. The requirement is about separating the demarcation of where a block begins from the markup of the block.

        The demarcation should be simple and consistent to allow easy parsing, but it should not pollute markup. For instance, the best representation of many blocks are native HTML elements and wrapping them in divs with classes would worsen the document representation (a paragraph, a blockquote, etc).

        Thanks for the thoughtful reply.

    • jhned 3:04 pm on January 18, 2017 Permalink | Log in to Reply

      Here’s how I currently put “blocks” in my page content: I use Advanced Custom Fields Pro to set up flexible content layouts, that are generated and appended to the post content using the `the_content` filter. The problem with that is that I end up with tons of post meta boxes on complicated pages, which slows editing down.

      I think the best way for us to achieve this idea is to go full front-end editor. Reason 1: tinyMCE is notorious for stripping out markup. Reason 2: editing on the front-end gives users an accurate view of how the “blocks” are going to look. Reason 3: the UI for each block could be focused on the data, and then silently insert any markup necessary in the background.

      In addition to your points, @matias, I would also suggest that we ought to create an API for developers to define custom blocks, much like how we have the Shortcode API.

    • davidperez 3:45 pm on January 18, 2017 Permalink | Log in to Reply

      Why don’t go to allow insert widgets inside content? Shortcodes are hard for users. With blocks of widgets are more intuitive and the user can set all fields needed for th block easily….

    • Mark Root-Wiley 4:29 pm on January 18, 2017 Permalink | Log in to Reply

      Just want to say that this is great and makes me feel much better about some of my concerns about the future of WordPress. Getting Portability and Semantic listed as top priorities is awesome! I also think that if the editor is truly going to get overhauled, following the WCAG Authoring Tool Accessibility Guidelines from the start should be a priority. I assume that as with most accessibility work, tacking it on afterwards will almost certainly be a nightmare while including it up front won’t just make the tool accessible but more usable.

    • chatmandesign 4:32 pm on January 18, 2017 Permalink | Log in to Reply

      It seems to me that associating editable blocks with chunks of editor content without mangling the “pure data” is essentially about how to best store metadata for those chunks. I think there are two good options:

      1) HTML data attributes. Storing metadata related to chunks of HTML is literally why they exist, so it seems like a pretty good option. The benefits here are that we’d be leveraging an existing standard, instead of creating something new where it may not be needed; it keeps the metadata with the data it belongs to; and is easily extensible without risking conflicts (providing name spacing is used). The only real downside, as you noted, is that it adds some cruft to the markup—however, a post_content filter could be added to remove editor-related data attributes in display contexts.

      2) Store editable block metadata in postmeta, associated with HTML elements by ID. Storing metadata about posts is the whole purpose of the postmeta table, after all. The benefits here are largely similar: we’d be leveraging an existing WordPress system, rather than trying to create something totally new, and it’s easily extensible with name spacing. The big difference is that the metadata is stored completely outside the content itself; I think whether that’s good or bad overall may be debatable, but one definite positive is that it adds no cruft to the markup (beyond IDs, which is pretty minimal), and no extra filtering step is necessary.

      I think the big question then is: how tightly coupled should the block metadata be to the blocks themselves? The answer depends how we’re going to use it. The implication in this post is that the post_content should be raw, valid HTML that’s ready for output without extra steps to generate content from it (unlike with the existing shortcode system), and I’m inclined to agree with that for static blocks. In that case the metadata is _only_ relevant to the editor, so I don’t see any benefit to keeping the metadata stored in the HTML itself. The HTML only needs to store the final result.

      If we want to support truly dynamic blocks that pull in current data from elsewhere without requiring a manual post re-save, there are more factors to consider. In that case, the data can’t really be stored in the post. These would require some processing to display, with the block metadata potentially pointing to an external data source. It’s not too much of a stretch to imagine that sensitive data like API keys might get stored in the block metadata by some plugins—I don’t think that would be best practice, but I could easily see it happening—which makes me think that in the case of dynamic blocks, storing the metadata in the HTML could increase the risk of unintended data leaks.

    • James Nylen 6:08 pm on January 18, 2017 Permalink | Log in to Reply

      Instead of `` I think the closing tag should be `` for clarity.

      Do we anticipate a need for these custom “tags” to be nested? This is probably something we should decide up front and either plan for, or prevent.

      • James Nylen 6:11 pm on January 18, 2017 Permalink | Log in to Reply

        WP ate my HTML comments… for clarity. Instead of !-- /wp -- it should be !-- /wp:image --.

      • Mel Choyce 5:26 pm on January 19, 2017 Permalink | Log in to Reply

        I think many of them will have to be nest-able, especially once we get into the customization and layout side of things.

    • Greg Ichneumon Brown 12:50 am on January 20, 2017 Permalink | Log in to Reply

      I think one other thing to add to the list is speed on the front end. We’ve seen many cases where just outputting the final rendered content (especially on APIs) means processing the post content with very large regexp logic (especially the shortcode logic) that then can make returning a dozen posts from an api take many seconds. Most of this was all CPU time. We’ve looked at caching and other options on WP.com, but they’ve been very complicated.

      In summary: performance is a feature, particularly of our APIs and it may be good to start testing that early on.

  • Matt Mullenweg 10:32 pm on January 4, 2017 Permalink |
    Tags: , editor,   

    Focus Tech and Design Leads 

    There are three main focuses this year: the REST API, the editor, and the customizer.

    For the REST API we’re going to work on getting first party wp-admin usage of the new endpoints, and hopefully replace all of the core places where we still use admin-ajax.

    The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.

    The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

    Each focus will have a tech lead, and a design lead, and I’ll be working closely with each to make sure we’re aligned and moving diligently in the right direction even though we don’t have the normal release hooks. These starting leads will be:

    REST API: Ryan McCue and KAdam White.

    Editor: Matias Ventura and Joen Asmussen.

    Customizer: Weston Ruter and Mel Choyce.

    Given there is no set timeline for releases that would normally set a term, these leads are free to bow out at any time they feel they can’t contribute fully and we’ll find a replacement.

    You might be wondering what each lead is responsible for. The REST team gave some thought to this for their focus, and this is the list they came up with:

    Tech Lead responsibilities:

    • identify and ensure implementation of first-class REST API usage within WP-Admin,
    • replacing/refactoring admin-ajax use.
    • overall REST API architecture
    • infrastructure and endpoint performance
    • security at an infrastructure and endpoint (data-exposure) level
    • improving authentication options and documentation
    • working with the Design Lead to build new, or expand on existing, endpoints
    • working with the Design Lead to address usability feedback for the infrastructure and endpoints

    Design Lead responsibilities:

    • usability of endpoints for internal or external clients
    • usability of the infrastructure from the perspective of a API client
    • working with the Editor and Customizer focus teams to collect requirements and gather feedback
    • identifying ways to improve the overall experience for folks building clients or consuming endpoints (like documentation)
    • Jon Brown 10:38 pm on January 4, 2017 Permalink | Log in to Reply

      This all sounds awesome and I’m excited to see the fruits of this new paradigm.

      I do have one technical question I haven’t heard addressed… how are these being handled code/repo wise?

      Otto can come after me with a whip… but wouldn’t each of these major efforts be much easier managed as separate git branches than with SVN’s patching/branching system? I just can’t wrap my head around ever being able to merge the results of each of those efforts independently any other way.

      I’m not trying to start yet another svn/git war… just asking, what’s the plan for the fruits of this effort being merged into trunk someday?

      • Matt Mullenweg 10:41 pm on January 4, 2017 Permalink | Log in to Reply

        It is super tempting to also want to change all our tools and workflows at the same time, but we shouldn’t try to innovate in too many areas at once. So no SVN / Git war today. 🙂

        • Jon Brown 5:42 am on January 5, 2017 Permalink | Log in to Reply

          I guess my question wasn’t clear. What’s the plan?

          I totally understand the logic of not switching tools… The existing SVN patch paradigm seems unwieldly for anything this size. Is the plan to utilize SVN branches and merging? figured it out as we go?

      • Ryan McCue 1:33 am on January 5, 2017 Permalink | Log in to Reply

        As well as what @matt said, a lot of these pieces will (hopefully) tie in with each other quite heavily, and I expect we’ll all be working together a fair bit, so separate branches probably wouldn’t help. 🙂

    • Tammie Lister 10:39 pm on January 4, 2017 Permalink | Log in to Reply

      Congratulations everyone leading! Really looking forward to seeing the focuses evolve.

    • Luke Cavanagh 10:40 pm on January 4, 2017 Permalink | Log in to Reply

      Seems an interesting change of focus for WP core. Where will other features as plugins stand, if they do not fit within the three main focus areas?

    • Scott Kingsley Clark 10:47 pm on January 4, 2017 Permalink | Log in to Reply

      I’d like to get the Fields API into the Editor focus if the meta boxes and fields on the screen fits into your definition well enough. There may be a lot of crossover between what the Fields API could take on and the remarks you’ve made above about the Editor focus which would make a great pairing.

      • Matt Mullenweg 10:51 pm on January 4, 2017 Permalink | Log in to Reply

        Could look at it later in the year, I think the first half will be focused on more foundational things.

        • Scott Kingsley Clark 10:59 pm on January 4, 2017 Permalink | Log in to Reply

          OK, I’m just concerned as we add new methods for adding structures that Fields API has even more work to be done in order to unify them. But glad you’re not opposed to it. I can rest soundly now 🙂

      • Nick Halsey 12:13 am on January 5, 2017 Permalink | Log in to Reply

        On the other hand as the editor becomes integrated with the customize API via customize posts/broader live preview, the customize API could potentially be used directly for fields that manage any type of content throughout WordPress (this is already possible, but perhaps not obvious in terms of resulting usability). It’s probably best to wait and see where that heads before going too much further with a separate fields API.

      • Marcus 12:13 pm on January 5, 2017 Permalink | Log in to Reply

        I think Fields API is one of those things that is getting overlooked, yet would benefit the project so greatly by providing standards and consistency for developers working with WP.

        From the consistency/standardization point of view, I envisage similarities with how the introduction of Custom Post Types created a standard for content other than regular posts/pages.

        Whilst I don’t know much about the Customize API, I think Fields API make an awesome foundation for fields used in any other API or UI.

        • Scott Kingsley Clark 1:30 pm on January 5, 2017 Permalink | Log in to Reply

          I imagine that the Customizer API would ultimately fetch configurations from the Fields API to make use of them in its own context, but that Fields API would stretch across WordPress beyond things that need previewing.

          • Marcus 2:39 pm on January 6, 2017 Permalink | Log in to Reply

            Exactly! Everything on WP uses fields for gathering info; plugins, themes, customizer, core… yet each implementation handles it in its own way. A single API for this will help in so many ways.

      • Jon Brown 8:17 pm on January 6, 2017 Permalink | Log in to Reply

        +1 on getting the Fields API into the Editor focus. It seems to make sense that content blocks would use the Fields API and both would become available to the customizer.

    • Rachel Baker 11:01 pm on January 4, 2017 Permalink | Log in to Reply

      Congratulations to all the Focus Leads!
      Defining the responsibilities of the two roles was a valuable exercise for the REST API team. Thanks for sharing @matt.

    • Luke Cavanagh 11:10 pm on January 4, 2017 Permalink | Log in to Reply

      Final question I know performance was mentioned before, where will that focus fit? Thanks for the info.

      • Matt Mullenweg 2:18 am on January 5, 2017 Permalink | Log in to Reply

        What goes in a minor release will broaden a bit, which I know is something we have to approach carefully, but performance is very important and improvements will be something I will consider for being in a minor release.

    • Chuck Reynolds 11:37 pm on January 4, 2017 Permalink | Log in to Reply

      yay progress; very excite… let’s go!

    • Nick Halsey 1:29 am on January 5, 2017 Permalink | Log in to Reply

      Since I’m going to be generally much less available (and completely unavailable during US business hours) starting next week, I’m going to leave my thoughts on priorities and next steps for the customizer here.

      I’ve done some preliminary research on the process of making things in different industries. Preview, and live preview, is always a goal because it provides implementors with the best chance to understand what they’re making as they create it. In most cases a truly live preview is not possible due to physical constraints; for digital products and WordPress, though, live preview is possible and represents the best opportunity for improving user experience. See http://celloexpressions.com/blog/trust-wordpress-with-live-preview/ for details.

      The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

      Because unified live preview is critical to improved user experience and trust, the best approach is probably to implement the new editor experience within the customize API, thus creating it with contextual live preview as an integral part of the experience from the start. Improving the editor within an “admin” interface that lacks live preview doesn’t address the fundamental problems with the current content editing experience and creates something that still has to be entirely rebuilt and reimagined within a live preview context eventually.

      If the editor is built on the customize API first, rather than rethinking the editor and then bringing it into the live preview API, the customize and editor contributors would be able to join forces to focus on improving the content editing experience much more effectively. The customize component has been seeing a lot of contributors helping out (over 60 in 4.7) and their knowledge of the customize API would be a big help in tackling the technical and design challenges of rethinking the editor within the unified live preview context; the opposite is unlikely to happen.

      Either way, these are the next steps that I would prioritize in working toward an improved and unified live preview experience, which could encompass much of the editor focus and would then set the stage for improving the broader approaches to “customization” on top of what’s existing:

      • Implement a term status API so that terms can be previewed
      • Complete the new theme installation experience (proposed plan)
      • Develop a core customize inline editing/partials API within the customize preview
      • Iterate on Customize Posts and the front-end editor plugin to provide inline editing within the customize preview API (this would be the basis for new editor work)
      • Load the customizer directly from the front end, making it feel like a front-end edit mode rather than a mix between the admin and front end
      • Rework option navigation UX in the customize controls pane, UX of inline editing vs. editing in a separate pane, visible edit shortcut UX, and the way posts of any type are accessed to edit (perhaps integrating with menus?) – I know @folletto has thoughts here that would be valuable
      • Iterate on Customize Snapshots and changesets to provide UI for revisions, drafted changes, and scheduled changes unified across a site’s posts and options
      • Implement term editing within the customizer (unified live preview framework)
      • Merge Customize Posts, with refined UX (this would be a likely place for editor-contents work to happen as well)

      My general feeling is that we need to bring live preview to content editing before the editor and customizer goals above (in the post) can be effectively tackled, so that there’s a complete framework to build those; however, work on these goals can progress simultaneously if expectations are established appropriately at the beginning.

      I’m not sure how much time I’ll be able to contribute moving forward, but my priorities (as a user first) are to advance the proposed roadmap I listed above.

      • Andrew Ozz 4:07 am on January 5, 2017 Permalink | Log in to Reply

        Nice thoughts and ideas. I’ve also been thinking about this and agree with many of the above points.

        My general feeling is that we need to bring live preview to content editing

        Yes. Even not “live preview to content editing” but rather “inline content editing where no preview is necessary”. As far as preview is concerned, the best experience is to edit “the real thing”, i.e. some form of front-end editing directly into the theme.

        Because unified live preview is critical to improved user experience and trust, the best approach is probably to implement the new editor experience within the customize API, thus creating it with contextual live preview as an…

        I’m not sure what “unified” live preview and “contextual” live preview mean. The best “preview” is when something is edited inline. Unfortunately this is not available in the current customizer. The second best is when the editing UI is inline, right at the place that is affected by the edit. This also is not available in the current customizer.

        If the editor is built on the customize API first, rather than rethinking the editor and then bringing it into the live preview API…

        Don’t think this is good. As far as I see the current customizer UI will have to be redesigned together with the way it works. Don’t see a reason why the UI should be similar to a “frameset” site from the late 90’s. We can do a lot better than that 🙂

        Rework option navigation UX in the customize controls pane, UX of inline editing vs. editing in a separate pane, visible edit shortcut UX, and the way posts of any type are accessed to edit (perhaps integrating with menus?)

        Exactly (I read that as UI not UX). Further, the customization will happen from the theme/front-end, the “control” sidebar will go or be replaced with a proper navigation menu, everything will be 100% JavaScript and REST API driven, most controls will be inline or in some form of dialogs (with ample space/not overcrowded) that will have help or hints build right into them, etc.

        • Nick Halsey 7:17 am on January 5, 2017 Permalink | Log in to Reply

          Thanks for the reply. I should clarify some of the terminology I used:

          • Live preview and inline editing (can/should) mean the same thing. The basic idea is that you see the end product as you create it. Inline editing is a more specific form of live preview.
          • Expanding on that, most interactions should probably happen directly “on the site” (or in the preview). However, there are cases where that doesn’t make sense (for example, a theme’s color options or changing a post format) – that’s where some sort of sidebar, modal, popup, or other approach would be necessary, and this is where we need a lot of research and design work to find the best solution. A hybrid solution like this also makes theme compatibility and progressive enhancement with theme-support much more realistic.
          • “Unified” live preview is essentially being able to edit any part of a site within the same editing mode/workflow (without having to publish any changes).
          • “Contextual” live preview would be something like front-end editing, versus an editor that provides live previews of styling for the content area and media within it but is missing the context of the rest of the site, and may not be able to accurately reflect the way all content is displayed as a result.
          • In terms of API, the customize API is currently the core framework/API for live previewing anything. I might use customize API and live preview API somewhat interchangeably because I see this as the best path forward as a basis for building everything; @westonruter could probably discuss the advantages to that direction in more depth.
          • The customize API is 90% of the way to being able to fully manage live previewing any change to a site with controls to make changes happening either inline or in a separate place (the current customize “pane”). Specifically, once “Develop a core customize inline editing/partials API within the customize preview” is implemented on top of the base partials API currently in core, the customize API would support both approaches to making changes pretty robustly, as opposed to starting from scratch. That would also do a lot for the goal of unified live preview (and theme/back-compat) if content editing comes into the same framework that’s already used for many non-content options.

          So I think we’re largely in agreement about end goals, and should spend some time refining the direction on how to get there, both in terms of tech and design 🙂 The current “customizer” should certainly evolve in terms of usability but the internals are beginning to converge with long-standing feature plugins and the editor goals into something that could really take WordPress to the next level with unified live preview and inline editing as a central focus.

        • Weston Ruter 12:59 am on January 6, 2017 Permalink | Log in to Reply


          The best “preview” is when something is edited inline. Unfortunately this is not available in the current customizer. The second best is when the editing UI is inline, right at the place that is affected by the edit. This also is not available in the current customizer.

          Right, it isn’t available but as of 4.7 it is possible. With the introduction of changesets and with selective refresh it is now possible to live preview. Actually, it was possible even before this as was prototyped in Customize Inline Editing but now it is possible implement that concept without ever loading customize.php or enter into any iframe at all. I want to build on the new edit shortcuts to provide a UI to start inline editing an element while on the frontend.

          As far as I see the current customizer UI will have to be redesigned together with the way it works.

          Yes, the current customize.php app should fade away as we bootstrap the customizer into the frontend context. Controls should appear in the sidebar only when needed. Otherwise, controls can appear inline even with direct manipulation where possible.

          The benefit of using the Customize API is not only having a framework for previewing changes but also we get “for free” an system for batching together an arbitrary number of changes (menus, widgets, options, etc) and having them all go live together once a changeset is published (even after it is scheduled or going through an editorial review process).

          Also, I think that the more we can treat “the Editor” as a component rather than the admin screen the better. As with #35760 we should be able to instantiate a TinyMCE editor anywhere to manipulate content and content blocks, whether this be on the admin screen or in the customizer. For example since Shortcake integrates with the TinyMCE editor then the Post Elements interfaces it provides then (mostly) automatically become available to the TinyMCE editor embedded in the customizer via the Customize Posts plugin.

        • Weston Ruter 1:05 am on January 6, 2017 Permalink | Log in to Reply

          So the Editor component should be appear on the admin screen and on the frontend (with customizer bootstrapped). When you do “Preview” from the edit post screen this should take you to the frontend with the customizer bootstrapped so that not only can you preview the changes you made on the edit post screen but you can also continue to edit changes in that context and see the additional changes live. This is implemented today in Customize Posts.

    • Ryan McCue 1:35 am on January 5, 2017 Permalink | Log in to Reply

      Looking forward to working with you Matt, as well as all the other leads. Exciting times. 🙂

    • Julien 6:53 am on January 5, 2017 Permalink | Log in to Reply

      Great news, we’re definitely looking at Editor “blocks” features.

    • Ahmad Awais 9:21 am on January 5, 2017 Permalink | Log in to Reply

      Congratulations all the tech and design leads. I am excited to see what’s next.
      I think most of the time I contribute this year will go towards Customizer, looking forward to working with you @westonruter & @melchoyce!

      Moreover, I am very much interested in standardizing REST API authentication area as much as e can while keeping it flexible.

      @matt the concept of editor blocks sounds very much interesting to me. The only question rather a suggestion is that if we make the process more transparent, then it will help the theme developers in the long run. Right now, as a theme developer, I am not sure what to expect from WP 4.8’s editor. A more clear timeline will go a long way to help both WordPress and us (theme devs). For example…
      1. Setting the right expectation: What to expect from the final version of Editor.
      2. The concept of “Blocks” is exciting, expanding more on it, early on, will help us prepare our new themes accordingly.
      3. Transparency will lead to more and better comprehension, which in turns can bring more contributors to the WP core. I for one, plan to contribute my fair share to the editor this year, mostly because it has a direct impact on the revenue my company makes.
      4. If possible, the focus of editor could be supported by data/numbers; editing is BTW most important feature of WordPress, even a teeny tiny change to that component will impact more than 100 Million users? (A rough guess). It’s only fair, that what we change here is supported by feedback from the community and that we can comprehend how it impacts the future of writing/editing and theming in WordPress. It will not only help us make an informed decision but will help theme devs prepare for it in advance. WIN-WIN?!

      Having not set release cycle is something new, but setting the right expectations, that I think can help?
      What are your thoughts about this?

      • Weston Ruter 6:03 pm on January 6, 2017 Permalink | Log in to Reply

        @mrahmadawais My perspective is that WordPress already has the key pieces for content blocks in the form of widgets, shortcodes, and TinyMCE views. I think the gallery shortcode should be considered perhaps the proto content block. The Shortcake plugin has demonstrated content blocks in the editor and this plugin has a significant number of installs at 10,000+. I now have a proposal drafted for using widgets as the underlying construct for the shortcode UI and storage mechanism, while shortcodes and TinyMCE views would continue to be how the content blocks are embedded and visualized in the content editor. My opinion is that Shortcake combined with widgets will provide us with the key pieces for content blocks, where a content block an be used either in the post content editor or in a sidebar widget area.

        I’m waiting to publish my technical proposal until @matveb has has had a chance to review. I fully expect the process of designing and implementing content blocks to be done openly and transparently.

        • Ahmad Awais 7:10 am on January 7, 2017 Permalink | Log in to Reply

          @westonruter great, looking forward to it.

        • Weston Ruter 6:03 pm on January 9, 2017 Permalink | Log in to Reply

          I’ll also reiterate that this “Widgets as Content Blocks” proposal is just a proposal. I’m eager to get feedback on it and the JS Widgets feature plugin because I think it has a lot of promise for content blocks and also for widgets in general. But given this year being design-lead, the technical proposal post may wait to be published until design has first set the direction for the editor.

    • Davide 'Folletto' Casali 10:16 am on January 5, 2017 Permalink | Log in to Reply

      I couldn’t agree more on the combination of a design and a tech lead, as well as having explicit reference people for each project.

      I’m happy to see this direction, and specifically the people chosen there are probably the best choices I can think of. It’s going to be great. 🙂

    • Joen Asmussen 10:30 am on January 5, 2017 Permalink | Log in to Reply


      Interesting times ahead. Can’t wait to see what cool stuff we’ll build together!

    • Mel Choyce 4:21 pm on January 5, 2017 Permalink | Log in to Reply

      Looking forward to working with all the other leads this year! 🙌

  • Ella Van Dorpe 1:22 pm on December 24, 2016 Permalink |
    Tags: editor, , ,   

    Idea: Uniform Resource Identifiers as an alternative to Shortcodes 

    The idea is that any objects embedded in a post’s content have their own home and should be seen as separate resources. Data would be stored elsewhere.


    • https://example.com/resources/contact-forms/email-ella/
    • https://example.com/resources/charts/php-versions-wordpress/
    • https://example.com/author/iseulde/
    • https://example.com/galleries/yummy-chocolates/
    • https://example.com/surveys/wordpress-editor-2016/
    • https://external.com/some-map-or-form/

    Object Types

    This approach could be good for:

    • Forms such as contact forms, surveys and polls.
    • Visualised data such as diagrams, charts, graphs and tables.
    • Lists of items such as a galleries, playlists and lists of posts.
    • Albums or manually composed collections of items where the presentation is uniquely different from a normal list.
    • Any content that needs to be reused or organised separately. Anything that can be re-sourced. 😉
    • Any external resources.

    This is not good for:

    • Layout.
    • Text conversions.


    • External embeds work similarly in WordPress through oEmbed.
    • Images, audio and video are embedded by their URL in HTML.
    • Media have their own “attachment” post type in WordPress.
    • Many plugins already have a separate post type to store their data.
    • I’ve seen some news media do this already for things for like graphs (post, resource).


    • A URL (or “link”) is a concept that is already familiar to many users.
    • URIs are designed for these sort of things. Think about images — it would follow the same paradigm.
    • The content is treated as a separate resource, and can be reused, just like shortcodes, but it forces separation.
    • WordPress allows you to create “pretty” semantic URIs, so the resource can be described for a better experience.
    • A cool side effect is that others could embed these easily on their site through oEmbed. WordPress already supports this.
    • If there’s a problem, the URL will act as a fallback.


    A quick way to implement this for WordPress 4.4 and higher is registering a new post type. This will handle most things, you just need to provide a custom embed template with the template_include filter. An external resource can be filtered with the Embed API and TinyMCE View API, even if it doesn’t support oEmbed.

    Challenge: Variants and Settings

    Either each variant of an resource needs its own ID, or settings could be passed with a query string. I think the use of settings should be minimised — for example, columns for a gallery object may be better set per ID. Settings can certainly be useful for things like autoplay, for example YouTube allows you to set the start time.

    Challenge: Alignment

    This is great if the URL is added on a separate line, but aligning the object is not evident. This is a challenge for shortcodes too. At the moment the core galery shortcode does not allow you to allign it, and the caption shortcode has an attribute for it. Similarly the URl could have a query parameter for alignment, but that doesn’t sound ideal. Alternatively the paragraph could be floated, or it needs to be wrapped in a `div` element to float mid-text. Another approach is to always wrap the URLs in a (custom) tag that can have display information. Again, think about how images are embedded in HTML.

    Challenge: Namespace

    Shortcodes would have a similar problem, though slug clashes are probably more likely. Ideally plugins should use their own prefix, but this may be seen as ugly. Another way to avoid clashes with other post types is a sub type for “attachments” or “resources”.

    Challenge: Extra Queries

    I don’t see this exactly as a challenge, as it’s the nature of the concept, but it may be used as an argument against it. Many shortcodes already make use of custom post types to store data and embedding media (or anything else) also requires extra queries. If and how this should be cached is another problem.

    I would love to hear your thoughts on this alternative, especially from those who use shortcodes for this type of objects in the post content. If you already use a custom post type, why not take advantage of embedding instead of creating shortcodes? If you want to embed external resources, why wrap it in a shortcode?

    If you have other alternatives, I’d love to hear about those too!

    • Celso Bessa 1:37 pm on December 24, 2016 Permalink | Log in to Reply

      At first glance, seems like a great idea. I am kind of exploring a similar concept in a new product project. +1

      As for the extra queries, taking as certain that 1) those objects will be used in several posts and 2) they probably won’t change often; maybe leveraging query and response caching will be requirement for this type of object/post.

    • Martin Sotirov 1:39 pm on December 24, 2016 Permalink | Log in to Reply

      I like this idea but the title is misleading as these are two separate use cases.

      Shortcodes CAN be used to embed things but I think that’s a kind of misuse. I try to use them only to enable the user to change the layout without knowing anything about HTML.

      • Ella van Dorpe 2:09 pm on December 24, 2016 Permalink | Log in to Reply

        Sure, and then lots of plugins are kind of misusing them, even core. 🙂

      • Jon Brown 3:55 pm on December 24, 2016 Permalink | Log in to Reply

        Some (me at least) would argue using shortcodes for things easily done with HTML is a misuse of shortcodes… that they were intended for when code needed to run, for example galleries, forms, etc,

        This proposal would do away with shortcodes primary purpose for existing. I like the proposal, just not sure feel it’s a shortcodes replacement proposal where shortcodes could be deprecated.

        • Mike Schinkel 10:13 pm on December 24, 2016 Permalink | Log in to Reply

          I think this proposal implemented and shortcodes could easily co-exist.

          However if after numerous versions of WordPress it becomes clear that shortcodes are now redundant and a less ideal solution then they could be deprecated then. But I personally doubt finding them redundant would ever be the case.

    • lkraav 2:34 pm on December 24, 2016 Permalink | Log in to Reply

      I’m using https://wp-types.com/home/views-create-elegant-displays-for-your-content/ to achieve this (or at least similar) embedding concept today. It does require building up templates for how you want the thing to display so really requires above-average user understanding. The process could certainly be simplified towards the concepts presented in this article.

    • PeterRKnight 3:47 pm on December 24, 2016 Permalink | Log in to Reply

      This idea overlaps a lot with developments around widgets (see for example https://core.trac.wordpress.org/ticket/35669)

    • Wayne Allen 4:29 pm on December 24, 2016 Permalink | Log in to Reply

      I can kind of see the point for things that are like external resources, but otherwise the usability seems low (lots more characters). Also I’m not sure what problem this is trying to solve.

    • Weston Ruter 4:40 pm on December 24, 2016 Permalink | Log in to Reply

      Yes, I like this. I’m hoping that a new iteration on widgets (e.g. #35669) can serve as the long-desired content blocks, and embedding an existing widget into a post would require a reference to that widget. It could be done with a new core `[widget]`shortcodes with an `id` attribute, which may work equally well here, but it could also be a URL. It’s just for a widget I’m not sure there would/should be a permalink to that individual widget (there should certainly be a REST API endpoint nonetheless).

      Note that oEmbeds get cached in postmeta so these “shortcode URLs” could also be cached similarly. Nevermind when to invalidate 🙂

      A lot of shortcodes can’t be standalone and thus shouldn’t have a discrete URL. But I suppose this is not what the proposal is trying to address and it wouldn’t replace shortcodes altogether but rather provide an alternative syntax.

      • Ella Van Dorpe 11:33 am on December 25, 2016 Permalink | Log in to Reply

        Yes, this is not a complete replacement for shortcodes, but only an alternative for some types. Do you have any shortcodes in mind that can’t stand alone and are not layout or text conversions?

        • Weston Ruter 7:15 am on December 26, 2016 Permalink | Log in to Reply

          @iseulde I suppose a widget would be an example of something that couldn’t stand alone. Then again, pretty much anything could be served standalone if there was a wrapper page around it. Attachments are envelopes for media and the permalink for an attachment wraps the media in a template. Something similar could be done for other such internal post type oEmbeds.

          • Ella Van Dorpe 9:29 am on December 26, 2016 Permalink | Log in to Reply

            What kind of widgets? 🙂 I guess I would see widgets more as content in content areas where each “block” is something more specific.

            • Weston Ruter 8:05 pm on January 3, 2017 Permalink

              @iseulde All widgets I guess. I mean, would it make sense for there to be a standalone page that just displayed a single Meta widget, for example?

    • J.D. Grimes 4:43 pm on December 24, 2016 Permalink | Log in to Reply

      I think this is a great idea, but it would be most usable if it was accompanied by a “resource picker” UI on the edit post screen. And also the ability to create a new resource of a particular type right there. I say this because I’m coming from the perspective of using shortcodes to display tables of aggregated data, not so much a post type that can already be created on another screen and then the URI grabbed and embedded.

      However, as others have said, I don’t think this is an idea that can completely replace shortcodes, because they are also used for formatting and to display very small bits of data (like one piece of metadata for a user), which isn’t worth the resource fetch, IMO.

      Although perhaps one way to reduce the need for fetching the resources with oEmbed would be to detect when they could be created locally to the current request, by simulating the query for the object.

    • iLen 5:07 pm on December 24, 2016 Permalink | Log in to Reply

      It seems to me a good idea, the external web or internet should send the construction attributes of the html type shortcodes – in turn an embed. This with the embed and embed appendix of wordpress could do. I see a lot of use in this.

    • Ricky Lee Whittemore 5:30 pm on December 24, 2016 Permalink | Log in to Reply

      This seems like a great path forward and a picker UI for Visual mode seems logical. Would love for widgets to be moved to post type as well. I prefer the Component/Content Block nomenclature but I can see an argument to use widget as namespace or naming convention.

    • LewisCowles 5:36 pm on December 24, 2016 Permalink | Log in to Reply

      Oh… seems I mis-read it the first time (when I shared to social media), this isn’t replace shortcodes with oEmbed, it’s add oEmbed along with shortcodes and possibly communicate the difference, the situations etc. It’s a lovely idea!

    • FolioVision 6:07 pm on December 24, 2016 Permalink | Log in to Reply

      John Godly came up with the core of this a decade ago with his Sniplets plugin. Sniplets didn’t categorise the content particularly deeply so there could be more done with a content library. I see Sniplets never took off but there are more recent versions of the Sniplets concept which are quite popular and well thought of (@artstorm). That covers the simple uses for me.

      After that there are also shortcodes for the more complex programmatic enhancements. I have trouble differentiating between what you are suggesting Ella and shortcodes. This seems to me to introduce additional complexity to WordPress with only modest benefits. I’m a great advocate for keeping things simple.

      Maybe I’m missing something. If you have time to post a simpler list of benefits to restructuring WordPress in this way, perhaps it would help.

    • Mike Schinkel 10:15 pm on December 24, 2016 Permalink | Log in to Reply

      LOVE, LOVE, LOVE your idea. What’s so beautiful about it is its elegance and how it reuses existing solutions.

      Some feedback that assumes your proposal is for inclusion in core vs. how to write a plugin to do the same:


      It would seem that post types are a perfect fit for this. So much that adding an `’embeddable` => true` argument when calling `register_post_type()` could be used to specify that a post type is embeddable _(unless we wanted all custom post types to be embeddable by default then `’embeddable` => false`)_

      This could be extended to allow the `embeddable` argument to accept an array containing default settings for all embeds of that post type.

      Further, rather than require use of `’template_include’` why not extend the template hierarchy and look for template with the name format of `embed-{$post_type}.php` but default to `embed.php` when no specific embed template is available?

      This can be dealt with in one of two way; one simple and the other powerful:

      1. Follow the lead of post types; use the rewrite slugs and ignore namespacing as custom post URLs currently do
      2. Use the rewrite slugs and create an Embeds configuration page in the WP admin where all `embeddable` post types are listed and the admin user can change their namespaces and their default settings. This would in some ways be similar to the Widgets configuration page.

      Come to think of it, allowing admin users to change slugs for post types should probably be associated with URLs in general so admin users can use post types from different plugins that have conflicting slugs?

      This could be handled using default settings, and on a one-off basis with a URL parameter (more on URL parameters below.)

      Variants and Settings

      While I agree that many aspects should be handled per ID — because they are facts about the object being embedded — it is not uncommon to have aspects that are related to how the embed is being placed in the document, such as height, width, alignment, etc.

      So I would really hate to see these embedded URLs be required to be wrapped by `

      ` tags; that would destroy most of the elegance of the solution and revert back to a hacked-up extension. URL parameters are tailor-made for creating variants of a URL.

      Embed URL + Variants Edit Dialog
      But I agree that URLs with parameters can be off-putting for less technical users. To address I think we could embrace the fact that WordPress will be able to recognize these URLs when editing able wrap them with on-hover controls for editing the URL and its URL parameters.

      The `embeddable` argument for `register_post_type()` could easily include a list of available URL parameters and their data type so the variants edit dialog could display field formatting and helpers, as appropriate.

      Having an edit dialog would make it easy for non-technical users and it would also act as a training aid to allow them to learn how the URL parameters worked as they would see the URLs being embedded with the same information they typed.

      Matching URLs that should display as URLs

      I did not see this addressed; I think wrapping in a `` with a class like `wp-no-embed` would handle this nicely.

      Extra Queries

      A reasonable caching strategy could easily address this concern. Caching the embed’s HTML into a post_meta field that can be updated when the post type that it points to is updated.

      And let me say again, LOVE the idea!

    • Samuel Wood (Otto) 3:18 pm on December 25, 2016 Permalink | Log in to Reply

      Not really seeing this as a replacement for shortcodes. It fills some of the same gaps, but not really.

      However, the underlying notion of expanding embeds, and possibly even making internal-only embeds (bypassing the extra http overhead with oEmbed) is a very worthy idea. Especially if you extend it beyond the current iframe level.

      But ditch the idea of shortcode replacement therapy. It doesn’t really fit for most cases where shortcodes properly make sense in the first place. It does fit for cases where shortcodes have been misused, which is indeed legion, but not for “correct” use of shortcodes.

      • Pascal Birchler 12:56 pm on December 29, 2016 Permalink | Log in to Reply

        Internal-only embeds already bypass the HTTP overhead, see `wp_filter_pre_oembed_result()` and `get_oembed_response_data()`.

    • chatmandesign 4:55 pm on December 27, 2016 Permalink | Log in to Reply

      As others have noted, this is not a replacement for shortcodes, but Ella clearly didn’t intend it to be. This is basically a solution for handling content re-use within a WordPress site. There are a number of plugins that provide a similar feature currently (e.g., [Spots](https://wordpress.org/plugins/spots/)), and I’ve implemented some custom solutions on a couple sites myself; it seems to be a common enough need that standardizing a solution within core could be beneficial.

      I would tend to agree with J.D. that there should be a UI for picking a resource for inclusion. Currently there’s an shortcode that turns URLs into oEmbed iframes… Might something like an [import] shortcode be the most consistent way to implement this?

    • FolioVision 5:19 am on December 28, 2016 Permalink | Log in to Reply

      Tim, many people including you suggest using custom post types to store this content. Very often the content is a PHP fragment or something else which does not sit well in a normal post. By storing the snippet content as a custom post one is severely limiting its flexibility. Here’s how the author of Post Snippets describes his plugin:

      snippets of HTML, PHP code or reoccurring text that you often use in your posts and pages. You can use predefined variables to replace parts of the snippet on insert. All snippets are available in the post editor via a button in the Visual and HTML modes. The snippet can be inserted as defined, or as a shortcode to keep flexibility for updating the snippet. PHP code is supported for snippets inserted as shortcodes.

      This is a lot simpler than creating custom post types. Integrating an optional WYSIWYG editor would be a lot simpler than adding all the overhead of full custom posts to each snippet.

      Ladies and gentlemen, let us not over engineer WordPress. Simplicity of structure and ease of use should be our watchwords.

    • cavalierlife 9:40 pm on December 28, 2016 Permalink | Log in to Reply

      I’m with FolioVision. Snippet plugins already exist, and if core wants to integrate such a thing, fine, but let’s keep it simple.

    • Mike Glendinning 10:02 am on December 29, 2016 Permalink | Log in to Reply

      Agree that all embeddable content should be a first-class “object” but disagree strongly that URIs should be used to reference these for editing and content management.

      The URI for an object is a generated and changeable attribute, not a key and we already hard-wire too many such references within managed content, making it difficult to move sites between locations, implement some SSL environments, serve responsive images, make use of CDNs and so on. There are already dozens of tickets highlighting these sorts of issues.

      Better, I think that objects reference each other using their managed identity (e.g. post ID) which is then expanded dynamically to the appropriate URI when a page is rendered. Isn’t this sort of thing what a content management system is for? As well as providing much more flexibility, this also enables better context-sensitive editing (e.g. allowing pick-lists for objects and their allowed attribute values).

      • Ella Van Dorpe 12:37 pm on December 29, 2016 Permalink | Log in to Reply

        Yes, this is a valid concern. Thanks for bringing it up!

      • Ken Newman 4:35 pm on January 16, 2017 Permalink | Log in to Reply

        Alternatively, what if the embed link was a REST URI? Those urls would be less likely to change.

        The advantage is that the core templating system wouldn’t have to handle these embed requests, but instead the REST API endpoint would be created to handle an HTML response format (as opposed to a JSON or XLM request). Additionally, content that doesn’t need a public post type would be easier to handle this way (and use a pre-existing system).

        I haven’t dug into it, but much of this architecture should already be there for this. 🙂

        I do think it’s fine to resolve a pretty-permalink down to it’s object, using the normal handling of such, with all it’s failure points (i.e. changing slug), and if the object has configuration for HTML response via REST, return that, else the plaintext URI.

    • Mark Root-Wiley 3:45 pm on January 5, 2017 Permalink | Log in to Reply

      My first reaction is that I like this a lot. I also think most comments that raise specific concerns are quite valid.

      Rather than repeating anything that’s already said, I’ll just share one broad thought: With the new focus on *design*, this especially feels like a technical solution in search of a problem. I like the idea in the abstract, but right now, it’s hard to evaluate without a shared problem it’s attempting to solve.

      Similar to some other discussions I’ve seen lately, starting with data storage doesn’t seem like the best way to approach something that absolutely needs a UI to function well. Developing a UI will almost certainly make clear what problems need solving. As the OP mentions, if a proposed UI frequently requires settings/customizations, then URIs aren’t an appropriate solution.

  • Andrew Ozz 4:39 am on October 28, 2016 Permalink |
    Tags: , , editor,   

    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

    • Fahid Javid 5:40 am on October 28, 2016 Permalink | Log in to Reply

      Nice improvements!

    • Retrofitter 6:42 am on October 28, 2016 Permalink | Log in to Reply

      Nice touch moving the header drop down, thanks

    • espiat 7:53 am on October 28, 2016 Permalink | Log in to Reply

      Perfect. Thanks.

    • Ahmad Awais 10:16 am on October 28, 2016 Permalink | Log in to Reply

      Nice, I was looking forward to this one. @azaozz just wondering, the feedback from folks on this ticket didn’t transition into props? I think for a ticket like this, feedback can be considered as much important as the contributions to any other ticket. Which essentially would have transitioned into `props`. Steps like this would help people engage more and help make/steer the core decisions. I remember on of the release leads talking about how much we should be generous when it comes to props (considering them equal for anyone giving back even if it is by providing feedback in a ticket like this one). Just my two cents.

    • catchmyfame 7:28 pm on October 28, 2016 Permalink | Log in to Reply

      Will this have any impact on your TinyMCE Advanced plugin?

    • Joy 12:12 am on October 30, 2016 Permalink | Log in to Reply

      Did any of the updates affect the Text mode toolbar? It needed some love.

    • avcascade 9:21 pm on October 30, 2016 Permalink | Log in to Reply

      Thumbs up for these changes. I would like to see a button in the editor that allows me to set a background color for selected text (e.g. yellow highlighting). Right now, it’s possible to set text color, but there’s not an option to easily highlight text.

    • Diego Betto 9:22 am on October 31, 2016 Permalink | Log in to Reply

      Oh thanks! keyboard shortcuts are awesome!

    • Akuiyumi 9:05 am on December 7, 2016 Permalink | Log in to Reply

      I use the justified alignment and this is a catastrophe. Why removing? Why not leaving people the choice? Why not maybe hide it on default but also giving the opportunity to show it again and use it?
      I’m sorry for my complaing but this is very sad for me. I see that you removed it due to various causes, but I used to like it and my boss absolutely wants everything on the site to be justified. With this update it will be really difficult for me to do this.
      I will have to download a plugin just for it, just to have everything like it was before. And this is ridiculous, since the less plugin you have the better it is.
      Is there a way to show it again without plugins? I know that there are shortcodes but I don’t find them useful, not like a button. I’m asking because I haven’t updated yet, it all depends on this.

      • maweb 11:12 pm on December 7, 2016 Permalink | Log in to Reply

        I use justify too, you don’t need to download any plugin, in visual editor just select first a center or left or right alignment and then go on text editor and replace it with “justify”.
        ex: before p style="text-align: center"> after p style="text-align: justify">

        • Akuiyumi 8:57 am on December 9, 2016 Permalink | Log in to Reply

          I know the codes maweb, but writing them each time makes me waste a lot of time. My site is updated very often, each post has a lot of content in it and a lot of paragraphs. I cannot simply set the justified text once and for all, I have to set it for each paragraph. You will understand that, with wp 4.7, instead of writing a post blog in 1 hour it will take me a lot more, since I have to search in the visual editor for each part of the text that has to be justified. And I cannot simply paste the text in che visual editor tab because it will not maintain the format of the text (mainly words in bold format). That’s very inconvenient.

          • Mark Root-Wiley 7:19 pm on December 9, 2016 Permalink | Log in to Reply

            @akuiyumi, if you’re trying to fully justify every single paragraph, I’d strongly encourage you to do this with CSS. Better yet, there’s the new CSS editor in the customizer.

            Without seeing your site, it’s hard to say, but something like this should work:

            .single .entry-content p {
            text-align: justify;

            That said, this tends to not look very good in certain browsers (at least in English) and can make things hard to read.

            For others reading, don’t forget that the keyboard shortcuts still work. and are found in the Editor’s help window (click the “?” button).

        • EstherCoach 12:12 pm on December 11, 2016 Permalink | Log in to Reply

          I also agree. It doesn´t matter if there are plugins, shortcuts (alt+shift+j) or ways around it. The thing is they are making it more difficult for us when they could have just left it there in a corner. Just don´t get it. Please bring it back!

      • digit89 10:13 am on December 8, 2016 Permalink | Log in to Reply

        I totally agree, why the hell are you deciding for others if justify is good or not ? As underline ?
        God damn if I want to underline my title please what’s your opinion place here ?
        This is the most stupid thing I’ve ever seen.

    • cathd80 3:59 am on December 8, 2016 Permalink | Log in to Reply

      One more person who is really sad to see Justify go. It is standard for what I do so this is frustrating. Don’t want more plugins, but hate the sloppy look of uneven margins.

    • Joan 8:37 pm on December 8, 2016 Permalink | Log in to Reply

      It should make work easier, not complicate it.
      We need the text justification button.
      Thank you very much !!!

    • davidplusworld 11:44 pm on December 9, 2016 Permalink | Log in to Reply

      “Justifying is bad for readability.”

      Sorry but no.
      Also, while in English it’s OK to print a text aligned left, but in some other languages, it’s just bad and unprofessional layout to not justify. It’s just wrong.

      WordPress, you’ve made a terrible mistake. You need to bring back justify asap.

      • Dion Hulse 1:02 am on December 12, 2016 Permalink | Log in to Reply

        Also, while in English it’s OK to print a text aligned left, but in some other languages, it’s just bad and unprofessional layout to not justify. It’s just wrong.

        @davidplusworld Can you supply a reference for languages-other-than-english at all? It’s because I’m curious, not because I’m doubting it.

        • davidplusworld 8:20 am on December 12, 2016 Permalink | Log in to Reply

          A printed text should always be justified in French.
          Computing has somewhat changed the usage, and you’ll find texts online that are aligned left, but that’s a mistake, coming from the fact that well… html and what followed were designed by English speakers.

          It’s happening again with WordPress now. They are imposing aligned left to everyone.

          And really, regardless of languages, it’s just not WordPress’s job or function to decide for us what our texts should look like. Quite the opposite actually, it’s WordPress’s job to help us have our texts look the way we want.

          • Ipstenu (Mika Epstein) 4:26 pm on December 14, 2016 Permalink | Log in to Reply

            But… Not to sound like a jerk, HTML/Web is not Print. In US print, every sentence should be followed by TWO spaces. We don’t do that on the web. And if everything has to be justified in content on a French site, wouldn’t it be faster and easier to enforce that with CSS? text-align: justify; would be tossed into the P’tag for the body content.

            WP (and HTML in general) has always defaulted to side-align (it’s right if you use an RTL language). A ‘French Print’ Plugin would sound like the more correct fix here.

    • Rik0399 7:05 pm on December 10, 2016 Permalink | Log in to Reply

      Just to say well done to WP for again, making the decisions for the user/admins – We’re all dumb and need WP to decide for us?

      What the heck were you thinking?

      This smacks of an MS policy all over again!

      Put it back and let US the user decide whether to use it or not – what are you, Google?!

      I can only imagine what site owners must be thinking and feeling about this ‘update’ who whom have a ton of content and now, their sites look all sloppy with uneven margins!

      Good grief!

    • mgyhardsoft 11:34 pm on December 10, 2016 Permalink | Log in to Reply

      To remove “Justify” button is just a bad idea. justification actually enhances readability. O.K., I accept that someone else may have a different opinion, but for God’s ake, why to remove an existing button which will not hurt? If you don’t want it, don’t push it…
      So I would like to get back Justify button.

    • glennbukowski 8:20 am on December 11, 2016 Permalink | Log in to Reply

      Registered just to say this: Remove the underline is the most stupid decision i have ever saw in my years using wordpress.
      So, just because a fat guy on alabama don’t know how to use it to enhance the user experience, does it make it bad for everyone else?
      What’s next?
      Remove the bold because someone can mistake it for a link too?
      Or remove the images, because someone can mistake it for a video?
      And maybe remove the color text, i mean, i can mistake it for a link, right?

    • torresnet 12:15 pm on December 14, 2016 Permalink | Log in to Reply

      Why did you remove the Justify button from the text tool?
      Justifying the text leaves the layout nicer, I have had several complaints about the text not justified

    • Davide Roccato 3:23 pm on December 14, 2016 Permalink | Log in to Reply

      One more vote for the justify icon back. I want to decide for the text in my language by myself, please don’t decide for the others! There is still plenty of space in the editor. I know I can use the short-cut but I visually prefer to see the icon when it’s on/off for each paragraph! Thanks!

    • Akuiyumi 9:07 am on December 19, 2016 Permalink | Log in to Reply

      @Mark Root-Wiley thank you but I don’t have to justify everything, just most of it.

      Also I’m glad to see I’m not the only one that wants justify back. I agree with all of you, let us have the choice! You say that in english justify is bad for readability, well my websites aren’t made for english people, nor they are in english language. Don’t you know there’s a whole world out there? It’s not all around you, your language isn’t the only one in the world.
      Please put those buttons back. Yes, even the underlined text, because it doesn’t hurt anyone, and if someone mistakes an underlined word for a link… well he will just find out that is not, simple! Where is the problem?
      Instead of limiting people just because someone made a mistake (thank you for telling us we are all stupid the same), it would be better to teach them how to proper use the formats without abusing them.

    • a53classic 8:07 pm on December 23, 2016 Permalink | Log in to Reply


      I am in agreement with all the previous comments. I have yet to encounter justified text that did not display well, as is the suggested reasoning for removing it. The same with an underline. If someone clicks on underlined text to see if it is a link and discover it is not, so what? What’s the harm?!? REALLY WP?

    • grundlepod 11:57 pm on December 27, 2016 Permalink | Log in to Reply

      I hate the new editor. I want the old editor back. I hate it so much I’m thinking of moving back to Blogger.

    • deulrai 10:06 pm on December 30, 2016 Permalink | Log in to Reply

      I also want the justify button back! ASAP! This is the most not neeeded updated ever. Straight margins look clean and even if I can edit the margins in the code it is a long way around to instead just click on a button that didn’t take up any extra space in the tool bar.

      I searched like a fool for the button until someone in the support forum told me that it was gone with the latest update. I can’t see why at all. Also in Swedish straight margins is a must if you want a text to look professional and clean and as a Swedish teacher my eyes are bleeding when looking at the messed up margin now in every blog post. What happens if I don’t update my other blogs to 4.7? Will it run correct anyway? My main blog is somewhat dysfunctional now with this bad update but I just found out that my other blogs are luckily not updated. Can I keep them as that? I really hope that WordPress reads all our responses and bring back the justify button. As Grundlepod above said I may go back to Blogger if they don’t. Blogger is maybe a very square limited space but it is functional and with no distractions from writing. Coding and adjusting code is interesting for some people but for me and a lot of other people I believe we are here for a simple way to write and because of that we appreciate a click interface with buttons for the most basic writing editing.

    • Martin McKay 6:39 pm on December 31, 2016 Permalink | Log in to Reply

      Yes, I concur with the majority here. Bring back Justify and Underline.
      Whether the Editor’s like them or not, it should be for the user to choose. I use them regularly, especially Justify, a webpage looks sloppy without it. Please bring them back.

    • vichardy 5:21 pm on January 6, 2017 Permalink | Log in to Reply

      Good grief WP. I have a client that does their own editing on nearly 200 pages. They use the underline button regularly and now it’s gone??? Bad practice or not, it should be up to us to decide. Now they want me to go in and add css code for them. Please bring back the underline icon…

      Oh yeah, they also liked justify on one of their pages!

    • radtrad 6:50 pm on January 19, 2017 Permalink | Log in to Reply

      It was a very ugly mistake from WP, and none of those opinions on what X
      or Y think about justified texts or about accessibility can make
      such decision positive. The choice has to be on the hands of the one who writes, period.
      Particularly, I only write justified texts and I find those that are not
      amateurish and desorganized. I hope such an absurdity will not be applied on WP.com, as we do not have the option of plugins for correct this ERROR.

  • Andrew Ozz 2:00 am on July 29, 2016 Permalink
    Tags: , , editor, ,   

    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.

    • elliotcondon 4:08 am on August 29, 2016 Permalink | Log in to Reply

      Hi guys,

      Elliot here – ACF developer.

      I’ve just noticed an odd bug (maybe) in this version of tinymce. The tinymce JS object contains a function called ‘add’ which “Adds an editor instance to the editor collection”. This is run each time a tinymce editor is initiated.

      This function contains an odd line of code copied below which seems to ‘double’ up the ‘collection’:
      editors[editor.id] = editor;
      Note that the editor is added using the id (as expected), and then also ‘pushed’ (added again using a numeric key).

      if you check the console lo, you can see the collection using “tinymce.editors”. You can see each editor is added twice.

      Please also be aware that this function also changes the ‘activeEditor’ to the last added instance which is different to the WP JS that sets the wpActiveEditor value (to the first editor id).

      I hope this info has been useful. I’ve just updated the ACF PRO plugin with a fix to avoid some JS errors introduced by this (I think…)


    • Arno Kools 9:29 am on September 1, 2016 Permalink | Log in to Reply

      TinyMCE was NOT upgraded when upgrading WordPress to version 4.6.

      Version 4.3.10 was still used and it broke completely.
      I had to manually replace it with the latest version from the TinyMCE website.

    • enternetconnections.com 1:54 pm on November 10, 2016 Permalink | Log in to Reply

      I upgraded a woocommerce site to 4.6.1 so the content writer could use jet pack. Big mistake. Now tinymce editor is broken. The content writer can’t add or edit new posts and the owner can’t add or edit products (kept in the post table, I can’t imagine why products and orders don’t have their own table). I’ve googled this and so many people have issues, usually they complain to the theme writer and they take care of it. But he’s using the free mystyle theme. I’ve tried almost every fix out there, still no luck. I wish now I had made him use my own ecommerce code. If something isn’t working with that, I know right where to go fix it. WordPress is a beast. This guy is pulling his hair out.

  • Ella Van Dorpe 10:57 pm on April 12, 2016 Permalink
    Tags: , editor   

    Editor wish list for 4.6 and beyond – chat summary 

    This list builds on the previous wish list. You can read the full chat in the archive.


    • Allow suggestions and comments to be made, similar to what ICE does. This would make a good plugin and feature project first. @eric and @azaozz seem to be interested in working on something like this.


    • (Publish) meta box revamp. See #36474. Feedback welcome! @michael-arestad, @melchoyce, @helen@mapk@hugobaeta?

      Proof of concept.

      Proof of concept.

    • More experimenting with inline toolbars (separate for formatting and inserting). We could first do this on small screens where the toolbar would be fixed at the top, later maybe on big screens. See also #29923.
    • Could editor scrolling be improved (e.g. hide on scroll down)? See #36482, and also #31751.
    • Caption placeholder. Focusing on an image would give you a placeholder for a caption. See #32175.
    • Leaving dialog. Offer WordPress UI on leaving the page if we can with the option to save changes. See #28566.
    • Advanced panel for the inline link toolbar, so plugins can add options. See #36312.
    • More formatting shortcuts (code blocks, bold, italic…)? See #36433, and also #6331.
      Decide whether to add bold and italic shortcuts at all, how to do the triple back tick shortcut.
      Try to merge with TinyMCE’s own textpattern plugin.
      Any other things we could automatically format in the editor? Curly quotes? Thinking about wptexturize().
    • Save and update without a page reload. For this we will need to look into nonce refreshing. See #7756.
    • Autosave in the browser revamp and improvements. Add some subtle, always present UI for restoring a post from in-browser autosave. Try to better detect when a restore may be needed (and show the current notice). See #36479.
    • Handling nested shortcodes. See #30094. I’m skeptical about this one, but please do let us know what your thoughts are if this interests you.
    • Save custom colours. See #31479.

    Under The Hood

    • Consider the new non-editable TinyMCE plugin for our non-editable views. See #36434.
    • Consider the TinyMCE API for inline toolbars, see #36480.
    • Responsive images for TinyMCE. See #36475. Depends on whether we will be saving the srcset and sizes attributes in post content, @joemcgill?
    • Handle inline image blobs in TinyMCE.
    • Different placeholders for more and nextpage tags. See #29804.
    • Auto embed bug. See #25387.

    Call for Contributors

    If you would like to see more of these features implemented sooner, join us. Everybody can contribute as designer, UX expert, developer, tester, the area you feel most comfortable with. Describing your workflow, how you use the editor, and what you find difficult or easy is also a very good way to contribute.

    You can also leave feedback on the relevant tickets.

    Let us know if you have more suggestions or ideas to add to the list.

    The next chat will be Wednesday, 13 April, 18:00 UTC in #core-editor.

    Andrew and Ella

    • WP Sites - Brad Dalton 7:33 am on April 13, 2016 Permalink | Log in to Reply

      Use of pre and code tags in the text editor. At the moment, you need to switch to the visual editor so anyone who has disbaled the visual editor and wrapped opening and closing PHP tags in code or pre tags, will find the code doesn’t display.

    • Martin Stehle 8:05 am on April 13, 2016 Permalink | Log in to Reply

      About Curly Quotes: there is a gap between the typography rules and the keyboard layout: missing keys to set the correct quotation marks.

      E.g. in german a cited sentence is bordered with „…“ but there is no key for that on a german keyboard layout: So you have to use the wrong "…" instead.

      It would be great if the editor corrects the quotation marks automatically based on the website language. About world wide standards of quotation marks: https://en.wikipedia.org/wiki/Quotation_mark#Summary_table

    • programmin 3:15 pm on April 13, 2016 Permalink | Log in to Reply

      By “inline toolbar” are you referring to support for TinyMCE inline mode (iframe-less) using contenteditable=”true” instead of an iframe, as in https://www.tinymce.com/docs/demo/inline/? That would be super useful to themes that want editor on frontend, inheriting all styles that they should be inheriting from the page. Is this inline live editing something you are planning on for default wp, similar to how the customizer lets you live-edit the theme settings?

    • Ahmad Awais 6:36 pm on April 13, 2016 Permalink | Log in to Reply

      Looking forward to these changes. Would love to contribute.

    • Ipstenu (Mika Epstein) 9:45 pm on April 13, 2016 Permalink | Log in to Reply

      I would take nested shortcodes off the list, given the rabbit hole that is shortcodes in general right now. That’s a project in and of itself :/

    • aidanlane 1:58 am on April 14, 2016 Permalink | Log in to Reply

      +1 for:
      meta box revamp
      Save and update without a page reload
      Autosave in the browser revamp and improvements – **currently not clear enough that they are happening or not**


    • LucP 9:34 pm on April 20, 2016 Permalink | Log in to Reply

      Hi! Wanted to hook into this conversation, as it might be interesting to also include this:

      Currently the publishing flow is still lacking some clarity. I’ve asked around and a whole lot of people still (instinctively) make the mistake of pushing “publish” when they meant to save a new copy of the draft.

      Especially if you have plugins enabled that auto-push posts to social media this can be a hassle. I know there’s keyboard shortcuts but that’s hardly an interface for the average user.

      If you’re rethinking Save, update and the general publish flow, i’d definitely like to help out!

  • Ella Van Dorpe 6:15 pm on April 4, 2016 Permalink
    Tags: , editor   

    Editor chat 4.6 

    This Wednesday, 6 April, 18:00 UTC we’ll have our weekly editor chat in #core-editor. This time we’d like to discuss the roadmap and ideas for 4.6, so please join us if you can and are interested in pushing the editor forward. If you can’t attend feel free to comment here, or on the summary of the chat that we will post on this blog afterwards.

  • Ella Van Dorpe 8:41 pm on March 28, 2016 Permalink
    Tags: , , editor   

    The Editor in WordPress 4.5 

    Inline Link Toolbar

    From WordPress 4.5 you will be able to link text with an inline toolbar, which replaces the link modal. You will still be able to access the modal with the gear icon in the toolbar, if you’re using one of the advanced fields or are using a plugin that extends the modal. Eventually we will try to move all those fields inline, though still under an advanced toggle and not visible by default. For those interested, see #36312.

    Inline link toolbar.

    Text Patterns

    We also added some more text patterns, or shortcuts if you like: `text` will change to <code>text</code> and --- (or more dashes) will change to <hr> while typing. We considered adding patterns for bold and italic, but there was no consensus yet and we’d like to test the inline text patterns first on an HTML tag mostly used by developers. See #33301.

    • Aaron Jorbin 9:00 pm on March 28, 2016 Permalink | Log in to Reply

      Are there any hooks to modify either the text patterns or inline link toolbar? How about for controlling the links list in the inline link? Is it possible to add information such as the post format to that list?

    • Peter Luit 6:41 am on March 29, 2016 Permalink | Log in to Reply

      Please, I already asked it before, just add the ‘open in new window’ option right in this inline toolbar, so without having to go to the normal link options……

      • Ella Iseulde Van Dorpe 10:04 am on March 29, 2016 Permalink | Log in to Reply

        Why would you like this option? We don’t encourage this as it changes default browser behaviour. It should be up to the user to choose whether to open in a new window/tab or not. With this attribute you are forcing it. I know there are some cases where it maybe could be a good idea, but definitely not enough to display the option in the inline toolbar.

        • Ipstenu (Mika Epstein) 4:37 pm on March 29, 2016 Permalink | Log in to Reply

          Would it be possible to have some filter set it to show by default? So it’s hidden, but if people like Peter ‘need’ it for whatever reason, they can force it to display?

          Obviously that would be a future enhancement.

        • ginowhitaker 4:11 pm on April 28, 2016 Permalink | Log in to Reply

          You must be kidding. Every website I’ve built using WP has needed links that open in a new window. Whether it’s as simple as a quick external reference, but you don’t want to lose your place on a page, or because of legal reasons,target=” _blank” is used a lot. Clients request this all the time.

        • adrieet 11:44 am on May 9, 2016 Permalink | Log in to Reply

          Not sure how to put this: BUT its not your place to tell Millions of Bloggers how to use their external Links by destroying simple functions. If someone wants to make Links open in a new Tab or new Window then then it should be possible. Also please check how many people have installed plugins to set external Links to Nofollow. All this simple functions are made much more difficult and unreliable, with this user unfriendly in line thing. I need 5 tries to set every fu..ing link now. To set a new link or check if a link is set correctly you have to click on the Link thing and then go back to the text and click on the open link editor sh.t. If you added a link in the “in line field” and then click on the “link options” the Link is deleted! Do you discourage Links in general?

      • Aaron Jorbin 5:10 pm on March 29, 2016 Permalink | Log in to Reply

        Using target=”_blank” (which is used to open in a new window) is often an anti-pattern and there are very few valid use cases for it. It takes away control from the reader, breaks the back button, and is “like a vacuum cleaner sales person who starts a visit by emptying an ash tray on the customer’s carpet”[1].

        Here is some reading on the subject:

        1) https://www.nngroup.com/articles/top-10-mistakes-web-design/

      • Evan Herman 8:59 pm on March 30, 2016 Permalink | Log in to Reply

        Just write a plugin and add the button yourself. Probably 30 or so lines of code to get it done.

      • bactisme 9:18 am on April 18, 2016 Permalink | Log in to Reply

        I too really would like to see that append. Same for nofollow.

    • Primoz Cigler 4:16 pm on March 29, 2016 Permalink | Log in to Reply

      Excellent for more text patterns!

    • Rask 7:03 pm on March 29, 2016 Permalink | Log in to Reply

      > We considered adding patterns for bold and italic, but there was no consensus yet and we’d like to test the inline text patterns first on an HTML tag mostly used by developers.

      I’d say most people would be just fine with the Markdown asterisks and underscores for emphasis elements (bold and italic). E.g. _this is italic_ and *this is bold*. Just like `code uses backticks` in Markdown.

      Now that I think of it we could create a profile system for various formatting shortcuts like IDEs and other software offer profiles for hotkeys? This way people could turn them off, or take a pick from “common” choices, one being Markdown for instance. People can disable the visual editor presently too.

      Some time ago I voiced support for Markdown support in the editor feature wishlist, but that was taken down quite instantly. Glad to see Markdown influenced formatting making its way to the editor now. 🙂

    • malkah 7:12 am on April 14, 2016 Permalink | Log in to Reply

      is it possible to go back to the old link modal. its so much better.

      • Ella Iseulde Van Dorpe 8:21 am on April 14, 2016 Permalink | Log in to Reply

        What part did you find better?

        • Sapphire 8:24 pm on July 16, 2016 Permalink | Log in to Reply

          I’ll answer that. With this one, it takes more button clicks to get to the window where I can set target_blank, and regardless of what you say, it is expected now with mobile (because the user can’t easily open links in a new tab, and typically they want to). With this one, it has a glitch where sometimes the little inline window won’t go away unless you click something else, click the link button, and click the unlink button. This is a nightmare when creating link roundup posts, which many bloggers do on a weekly basis. Also, in many cases, when I go into the old link modal to set options, it sometimes shows not the current link text I’m working with and have highlighted, but the last link text I finished working with. Thus forcing me to retype the link text in the window.

          This is a neat idea, but it introduced so many more problems than solutions for many of us.

        • cassihl 1:17 pm on July 18, 2016 Permalink | Log in to Reply

          Yes, please implement a way to go back to the old link modal. The new way is more confusing to teach to clients. It’s more straightforward what you are supposed to do in the old modal.

    • SebastiaanO 7:23 pm on April 14, 2016 Permalink | Log in to Reply

      I think this addition is an improvement. Currently, the custom added editors I added in a plugin are not handling the links anymore, resulting in a js error. Any tips on how to load custom TinyMCE editors in WP 4.5?
      Maybe use another button for “link” in the toolbar? (see snippet below – using the tinyMCE file in the wp-includes dir).

      plugins: “paste,wplink,visualblocks,code,charmap”,
      height: height,
      menubar: false,
      block_formats: “Paragraph=p;Header 1=h1;Header 2=h2;Header 3=h3;Header 4=h4;”,
      toolbar: “formatselect,bold,italic,underline,link,unlink,bullist,numlist,visualblocks,code,charmap,pastetext,removeformat”

      • SebastiaanO 7:42 pm on April 14, 2016 Permalink | Log in to Reply

        Fixed: When loading a custom TinyMCE editor, now also configure to load the “wordpress” plugin to inherit the new functionality (or have a link button that won’t work).

    • tssblog2016 6:51 pm on April 20, 2016 Permalink | Log in to Reply

      I tried inserting a link into a post and it’s not showing up. What am I doing wrong

    • mashupmom 4:16 pm on April 23, 2016 Permalink | Log in to Reply

      I also would love a way to revert to the old link editor — this change is messing with my workflow. The inline editor will not disappear in Chrome and obscures text after I create a link. It’s now extra clicking and steps to open up the full link editor to make a link nofollow. I used to just be able to highlight, add link, paste link, close, and now have multiple extra clicks and steps — this adds up when you need to add multiple links.

    • Nevis-1 1:14 pm on April 25, 2016 Permalink | Log in to Reply

      Bring back the old link editor, the new one sucks.

    • rickcurran 3:27 pm on April 26, 2016 Permalink | Log in to Reply

      I am seeing problems with the new link editor simply because of the choice of icons used. Clients are clicking the X icon thinking that this is how to close the inline link editor but instead this removes the link.

      It would seem much more consistent to use the same “Insert/Edit link” and “Remove link” icons that the main toolbar uses, rather than the pencil and X icons. Doing this would make it more obvious as to the function of these buttons as users are already familiar with the existing icons for adding and removing links.

    • jchew 12:09 am on May 3, 2016 Permalink | Log in to Reply

      I am having an issue with initializing the inline link toolbar in a custom instance of the WP editor.

      The instance is added in a dynamically loaded modal using the wp_editor function and some JavaScript. It has been working correctly up to WordPress 4.5, but is now broken.

      There are some parts that work. When I click the button to add/edit a link, the text does get highlighted as a placeholder, it’s just that the toolbar does not show. The markup for the TinyMCE plugins does get added to the bottom of the document and if I open and close the media editor attached to the new instance, the inline link toolbar will then function correctly.

      There are no JavaScript errors when the toolbar is not functioning correctly, it just doesn’t seem as if the JavaScript handlers are bound correctly or something.

      This is a bit of a weird one, but I would super appreciate any help or advice that anyone might have.

      Here is the JS code I use to initialize the WP editor instance.

      var $element = jQuery('#newcontent');
      var qt;
      var textfield_id = $element.attr('id');
      window.tinyMCEPreInit.mceInit[textfield_id] = _.extend({}, tinyMCEPreInit.mceInit['content']);
      if(_.isUndefined(tinyMCEPreInit.qtInit[textfield_id])) {
          window.tinyMCEPreInit.qtInit[textfield_id] = _.extend({}, tinyMCEPreInit.qtInit['replycontent'], {id: textfield_id})
      qt = quicktags( window.tinyMCEPreInit.qtInit[textfield_id] );
      //make compatable with TinyMCE 4 which is used starting with WordPress 3.9
      if (tinymce.majorVersion === "4") {
          tinymce.execCommand( 'mceAddEditor', false, textfield_id );
      window.switchEditors.go(textfield_id, 'tinymce');
      //focus on this RTE
      window.wpActiveEditor = textfield_id;
      • jchew 4:15 pm on May 5, 2016 Permalink | Log in to Reply

        An update, this issue does appear to be tied in with the Bootstrap modal in which I am adding the instance of wp_editor.

        I am not sure what about opening and closing the WordPress media modal makes this come un-stuck. I have tried manually re-focusing on the wpbody-content ID when the modal / editor is initialized using the following code, but that did not work.


      • jchew 8:58 pm on May 5, 2016 Permalink | Log in to Reply

        Solved.. it turns out the link dialog does not work if the body has the “modal-open” class.

    • adrieet 11:49 am on May 9, 2016 Permalink | Log in to Reply

      Can you please tell me how to get the old “user friendly” add link function? The Inline thing is not working most of the time and its much overblown and unusefull. I want many links to open in new tabs and to be nofollow. Before it was much easier. Just click on add link, copy the URL in and add the checkmarks for open in new window and nofollow. Now you have to find the spot where “inline link” thing is and click on the link options. Then it shows me a messy list of pages and blog posts “wtf”. If I add a URL in the in-line and then want to edit the options, the link is deleted.

    • rosebakes 6:31 am on May 24, 2016 Permalink | Log in to Reply

      I do not like the new inline link function at all. I prefer to have the option to open in a new window and add “no follow” without having to click 3 or 4 times. I understand that it’s your opinion that “open in a new window” shouldn’t be forced, but as a reader/user, I prefer it on EVERY website I use and I’ve never had a single complaint on my blog. Besides, the new link editor makes adding links take so much longer with multiple clicks to make the changes I want. Also the inline window will not go away or always display next to the link I’m editing – it’s very glitchy. I think those of use who prefer the options to open up immediately should have it. It’s really disrupting my writing process. Is there a way to go back to the old one? I hate this update!

    • Nico Martin 9:43 am on May 25, 2016 Permalink | Log in to Reply

      Hy there I just released a Plugin, that might solve all your problems:

      Advanced WPLink

      With this plugin you are able to enable/disable the inline link. Besides that it gives you the possibility to add a rel=”nofollow” tag and some stylings.

  • Andrew Ozz 11:22 pm on March 8, 2016 Permalink
    Tags: , , editor   

    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.

    • Mike Schinkel 2:34 am on March 9, 2016 Permalink | Log in to Reply

      @azaozz Nice work!

    • swinggraphics 4:00 pm on March 10, 2016 Permalink | Log in to Reply

      Was this a highly requested feature? The complaints I have and those I talk to about links in WP are never that the interface needs a tweak, but that URIs (pretty much everywhere, like media) need to be protocol-independent and relative rather than absolute (or with placeholder for site id in a network).

    • Peter Cralen 4:17 pm on March 12, 2016 Permalink | Log in to Reply

      Great enhancement, thank you.

      A common task for links is set up also the target – Open link in a new tab. It would be helpful if there is also little check box (maybe with some icon) to do this task without needs to open old modal dialog.

      After this new inline dialog, setting a target is harder than before, it requires one extra click, and it opens another modal. If something has to be easier, it’s not necessary to do another thing harder for users.
      I think there is enough space inside that inline modal dialog for this check box.
      In this case, maybe old modal box could be removed completely in near future.

    • Torgut 9:29 am on April 15, 2016 Permalink | Log in to Reply

      My number one priority regarding WordPress is not find a way to get rid of this Link Modal change. I can’t work with this new concept. For me it’s basically absurd. It’s the first time I have a hard time understanding a change in WordPress. Probably it will mean a new plugin, which I wouldn’t need if not to correct the situation.

      • Pascal Birchler 10:33 am on April 15, 2016 Permalink | Log in to Reply

        Can you elaborate on why it is “absurd”? I have only heard good things about the new inline link dialog so far and I’m sure we all would love to hear what can be improved.

        • dkatiepowellart 12:47 pm on April 25, 2016 Permalink | Log in to Reply

          It isn’t a matter of learning to adopt the feature —
          I’ve had to do this ridiculous thing 4-5 times on each post —
          I figured it out — but how stupid is this change to what was a simple tool?
          It used to be when you were writing you chose ONCE to have your links open in
          a new page (Two clicks) then clicked ONCE and popped the url in and wa-lah, there it was, already set to open in a different window.
          Unless you saved or exited, it remembered you wanted your url links set to open in a different page.
          Now, the person (or omigod do not tell me this was a group decision to fix what was not broken) who created the “shortcut” which is NOT a shortcut unless you want to drive your readers to another site which is BTW stupid —
          makes us click THREE times
          EACH TIME to have our link open in a new window…
          So if I have 4 links, it used to be I clicked 6 times.
          NOW I click 12 times.

          Stop fixing things which are not broken.
          Get rid of this absurdity.

        • dkatiepowellart 5:18 pm on May 9, 2016 Permalink | Log in to Reply


          That should explain it. Although it seems no one here is looking.

  • Ella Van Dorpe 8:46 pm on January 16, 2016 Permalink
    Tags: , editor   

    Editor wish list for 4.5 

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar