Make WordPress Core

Updates from Andrew Ozz Toggle Comment Threads | Keyboard Shortcuts

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

    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.

  • Andrew Ozz 4:31 pm on October 14, 2015 Permalink
    Tags: , ,   

    Shortcodes roadmap — clarifications 

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

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

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

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

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

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

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

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

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

    • FolioVision 5:39 pm on October 16, 2015 Permalink | Log in to Reply

      This is a great summary Andrew.

      I’d say we should keep the simplest shortcode syntax possible even if it means that some plugins can no longer freestyle with shortcodes. John Godley wrote software years ago called Sniplets which is meant to allow developers to call PHP inside posts.

      Horses for courses. Shortcodes should not be Sniplets but relatively simple syntax. Certainly without html elements inside.

      Why not deprecate complex shortcodes now with removal in 4.6? That gives us developers lots of time to comply and adapt without making WordPress core software more complex (worse).

    • Jon Brown 11:07 pm on October 18, 2015 Permalink | Log in to Reply

      This is a great summary.

      I’ve mentioned many time over the years, without anyone seeming to think it was the great idea I do that there should be some sort of “smart image/media object”. My reasoning is I’ve long wanted a way in which images could be inserted in posts such that processing could occur at the time of page render. The major use case for me being wanting to insert an image that could call in media metadata (copyright, etc..) and have the meta data updatableble in the DB and then automagically update on page render, rather than hard coded in a short code (ie. gallery/caption). It seems however that this sort of things might also be useful for responsive images (RICG) that could literally point to a single database entry, but later at the time of page render be updated according the current theme settings, etc…

      Perhaps the way forward is an alternative “smart/advanced shortcode”. One which only inserted and manipulated through an advanced UI. The standard current short code could than be kept simple, with the few plugins that currently need advanced functionality moving forward.

      At the same time, perhaps this would be of help to RICG and others?

    • maxwelton 12:57 am on October 20, 2015 Permalink | Log in to Reply

      My initial thought (as someone who writes a lot of “one off” plugins to suit particular clients, some of which have long lists of configurable options per post) is wouldn’t it be nice if a user could:

      • Use a button next to the media gallery button to open a dialog where they can choose from a “nice names” list of registered shortcodes, and insert one of their choice
      • If that inserted shortcode has required parameters, a box similar to the “edit image” box opens automatically. This box is essentially a metabox containing fields defined by the developer in the same way a regular metabox would be added to a post, obviously on a special hook or filter…
      • User fills in their choices and clicks ok.
      • In the visual editor, shortcodes with parameters get an edit icon within their shortcode (or the entire shortcode is “hot” or an icon, and not discretely editable), which opens the parameters box again.
      • In the text editor, each shortcode with parameters will be shown with some sort of ID string matching the auto-generated ID (“gallery-7” or whatever) WP created when the shortcode was inserted. Using this ID allows users to find said metabox in a section below the editor (hidden in visual mode?), or perhaps the shortcode selection dialog can show both a list of available shortcodes and a list of those embedded in-page; clicking on the in-page ones opens the parameters dialog for that shortcode. Clicking on “delete” in the parameters box removes the shortcode from the editor (easy enough to say…)

      This would make the editor a lot cleaner and allow for complex parameters to be passed to the shortcode, including HTML markup, images via gallery dialogs, etc., etc.

      The shortcode handling function is passed the custom ID WP generated, which the function uses to retrieve the parameters from postmeta (I’m imaging core saving the contents of the parameters metabox to a single custom field with the same ID referenced above, as a serialized array).

      Obvious questions include “what happens when you delete a shortcode with opening and closing codes AND nested shortcodes?” and “what happens when a user in text mode alters a shortcode manually and it no longer meets the criteria for being “savable” (ie, either a shortcode which has no required parameters or one whose internal ID matches a metabox with those values filled in).

      Anyway, I might try this approach for my next complex plugin, if time allows, just to see if its workable.

    • Tom Belknap 7:46 pm on December 15, 2015 Permalink | Log in to Reply

      Just wanting a clarification: are we looking to end the practice of nesting shortcodes? Because I’ve found shortcodes to be helpful with creating blocks of post_content HTML without using actual HTML in the Editor screen. For example, I use custom shortcodes to create Zurb Foundation grid blocks within content.

      I’d hate to have to lose such functionalty. It allows me to create much more robust layouts simply. No, as Ozz points out, they’re definitely not for end users. But given how much of the Internet is powered by WordPress, I’d hate to think that we’re limiting ourselves unnecessarily?

  • Andrew Ozz 8:30 pm on August 30, 2015 Permalink
    Tags: ,   

    Shortcodes roadmap 

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

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

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

    What are shortcodes:

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

    What shortcodes are not:

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

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

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

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

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

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

    • Scott Fennell 10:03 pm on August 30, 2015 Permalink | Log in to Reply

      Thank you for your work on this topic. There is one use-case that I have not seen come up yet in these discussions. Example:

      [my_shortcode before="<div class='my_class'>" after="</div>"]

      Where the output would be

      <div class='my_class'>whatever</div>

      That’s a situation I have across hundreds of sites. Does this use-case stand in jeopardy?

      I understand the need for a stricter parser for the greater good as you say, but count me in favor of doing this in a way that leaves a possibility for backwards compatibility.

      • Scott Fennell 10:05 pm on August 30, 2015 Permalink | Log in to Reply

        Sorry, my example got munched. Here’s what I meant to ask about:


      • Ipstenu (Mika Epstein) 11:37 pm on August 30, 2015 Permalink | Log in to Reply

        Scott, as I understand it yes, that would be in jeopardy. Putting HTML output in a shortcode is something that should always be avoided.

        There is simply no good reason for trying to support mixing of shortcodes and tags with the current parser.

        That’s what he means. Mixing shortcodes and html tags is tricky, dangerous, and complicated.

        Better would be:

        [my_shortcode class=my_class]

        And then if you wanted to have an option of span or div, you’d make that a variable as well in the shortcode.

        [my_shortcode type=span class=my_span_class]

        Structural shortcodes are always weird, though, and kind of a janky way around the usual end goal which is “I need to put divs in my post and I can’t use pure HTML because if I swap to the GUI editor they’ll get yanked.”

        • Scott Fennell 4:10 pm on August 31, 2015 Permalink | Log in to Reply

          Thank you for the explanation, that’s very helpful. Two things:

          1) My company has about 1,200 live blogs/client websites that are using this use case. It seems like all of those use cases are going to break if we don’t intervene somehow. Would you agree? If so, do you have any advice for how I might do that? The best idea I can think of is to update the plugins that offer those shortcodes and, at the same time, do some kind of bulk search and replace across all of the posts in all of those blogs, perhaps using WP-CLI. This would be a very scary and expensive endeavor for my organization.

          2) If we can manage to steer the shortcode roadmap in a way that is backwards compatible, that will help instill trust in automatic updates. If not, it will erode trust in automatic updates.

          Any thoughts on this?

          • Andrew Ozz 5:38 pm on August 31, 2015 Permalink | Log in to Reply

            Of course there will be ways to prevent breakage. Most likely HTML tags in shortcode attributes will be entity encoded. Instead of using the before attribute directly, you will have to check if it has the expected value and then decode it.

            If you change your shortcode, you can do bulk replace in all posts, or you can “transition” to the new syntax when posts are edited.

            This will never be deployed in an automatic update. That’s why we are making a roadmap, to plan how to best handle the changes. Most likely this will happen over several releases, with adequate time for plugins to adapt.

            • Scott Fennell 6:47 pm on August 31, 2015 Permalink

              Right on. What is the best way for me to stay abreast of this particular issue? Will all of the great work happening in core, it can be hard to track issues of particular significance.

            • Andrew Ozz 7:39 pm on August 31, 2015 Permalink

              Best would be to follow this blog and watch the “shortcodes” tag. You can also subscribe to the trac tickets when they get created.

      • Robert Chapin 2:31 am on August 31, 2015 Permalink | Log in to Reply

        This was one of the scenarios discussed on Slack, summarized on my blog as well. It seems one of the features we need to add on the roadmap is multiple enclosures. Currently there is only one enclosure possible for each shortcode. For the extra flexibility, we would introduce a way to enclose multiple, separate HTML snippets.

      • Marcus 1:20 pm on August 31, 2015 Permalink | Log in to Reply

        Hi Scott, I have a similar scenario in one of my plugins, but I think (someone, correct me if I’m wrong!) it’s quite easy to get around whilst adhering to the new rules:

        [shortcode before="<ul>" content="<li>placeholders</li>" after="</ul>"]

        can simply become:


        same effect, and frankly it’s easier to read!

    • pingram3541 3:47 am on August 31, 2015 Permalink | Log in to Reply

      This has been a concern of mine for a long time. You have plugins that have gained a very large following over the last few years such as WYSIWG back and front end “composers” that truly should have been built around post meta in the first place but instead use (exploit) the shortcode API and often have a significant impact on performance and security.

      However I can’t help but feel this has happened because of the lack of design control built into the core. It’s very attractive to someone who may know html and css very well but maybe not so much with php or even js. Especially when they’ve had shortcomings with false expectations of what the post content editor was truly intended for. I’ll admit early on I had these growing pains myself.

      The question is, has that changed? With the recent release of 4.3 and the new formatting shortcuts from the core team it seems business as usual – post content is a place for writing, not coding, however comparing it to the vast numbers that use it for designer drag and drop plugins and complex shortcode scripts with tons of attributes, I’d say we’re not focusing on what the public seems to be demanding, tools like webydo, webflow and the like. So do we just let that be and shrug it off as “yeah well they’re doing it wrong, its on them if they want to do it that way and pollute their content” or do we find a way to meet in the middle, tailor to both and make this the most flexible and designer friendly CMS ever?

      • Andrew Ozz 6:10 pm on August 31, 2015 Permalink | Log in to Reply

        Yes, as I mentioned above the current situation is result from lack of documentation and too permissive parsing.

        Shortcodes are generic placeholders. They are suitable for many different uses, but not for everything. Plugins that need to store complex structured data in post_content can use many ways to do so.

        For example, a simple span with data-myattr=(JSON encoded string) will probably work better and be much faster than a tree-like structure of nested shortcodes. Of course there are other ways to do the same thing and stay HTML compatible.

        Additionally the plugin implementing that will know what to expect and can sanitize it much better and “cheaper” than core trying to sanitize a number of generic placeholders with attributes.

    • smartpixels 5:07 am on August 31, 2015 Permalink | Log in to Reply

      Shortcodes can use a JS API may be react.js so we can render these tags inside WordPress editor a lot easier.I totally agree that the shortcodes API have been misused a lot.

    • jadpm 7:18 am on August 31, 2015 Permalink | Log in to Reply

      I think there are a series of premises here that just do not follow, but I also assume that some decisions have been talen already and we are just being given the oportunity to at least be informed of them. Not that bad after all.

      For example, with the simple definition given to shortcodes (“placeholders”) it just does not follow that they should not be used inside HTML attributes, or that they are same-class structures as HTML tags. Even less if you truly think that the right place to store metadata is, well, metadata. How do you show off that metadata on a theme-agnostic way, if you do not use placeholders?

      Following the same idea of just being placeholders (one must understand that they placehold… something else, right?), why can’t you placehold a classname, a width, a link URL, that is actually stored in postmeta? Sentences like “There is simply no good reason for trying to support mixing of shortcodes and tags with the current parser. ” just prove that some people have not put that into thought for a very long time, or have even looked at how this is being used in the wild at all.

      Yes, we all know about security concerns, and that we must address the problems, even by restricting the usage to what is being suggested here: a closer API that sets the tone of what is accepted or not (something we did not have, and resulted in calling “unaccepted” out of the blue). But let’s try to be open and clean here. Yes, there are legitimate usages of shortcodes mixed with HTML tags, and yes, there are security reasons to not allowing that. Let’s restrict that because of the security reasons, not because there are no legitimate uses.

      Just my 2c as part of the so called ones that “use shortcodes in very unintended ways”, meaning… as placeholders.

      • Andrew Ozz 6:57 pm on August 31, 2015 Permalink | Log in to Reply

        Shortcodes are “generic” placeholders meant to be treated as text in HTML context. They were actually meant to be user friendly way to add “dynamic” content to post_content and to be “user editable”, i.e. the users should have been able to type shortcodes in both the visual and text editors. A lot of the currently used shortcodes are like that.

        Of course you can use placeholders in HTML attributes. I’m sure there are some user cases where it may be useful to dynamically change attributes on front-end page load. However shortcodes are not suitable for that as implemented. Seems best would be for plugins that require that to implement their own placeholders. If we really need global generic placeholders for use in HTML attributes, best will be to introduce another syntax for them.

        The reasons for trying to change the current shortcodes usage are not just to improve security and increase speed. We should also analyze the “most complex” use cases and perhaps extend the API or implement another means of making them work well.

        • jadpm 7:12 am on September 1, 2015 Permalink | Log in to Reply

          So, as I said before, there are legitimate uses for shortcodes as generic placeholders beyond what “they were intended” for, even when there was no word on what that meant at all, and it is being defined now by restricting its usage.

          Again, as I said before, at least now we are being given a warning, which is not that bad after all. You might want to review your logic, because describing shortcodes as generic placeholders and then telling that someone needing a global generic placeholder might want to implement their own syntax seems, well, confusing. I can not find any difference between something generic and something globally generic, sorry.

          As a result, lots (I mean lots) of developers are going the WP_Embed route: moving the parsing of custom shortcodes introduced by plugins to an early stage, way before the do_shortcode callback in the the_content filter. Because, well, that is what happens when a legitmate use case is called non-existent. I wonder how that will affect security. Last time I asked, I was told security concerns could not be discussed.

          I really hope we will keep on being updated on changes coming to this API. Thanks for that, anyway.

          • Andrew Ozz 8:32 pm on September 1, 2015 Permalink | Log in to Reply

            By “global generic placeholder” I meant a placeholder that is defined in core for use both inside and outside HTML tags. That wasn’t clear, sorry.

            The idea is that plugins that really really need dynamic HTML attributes would implement their own, non-generic placeholders which will be used only in HTML attributes and would be much easier to parse and sanitize.

            Yeah, copying how WP_Embed::run_shortcode() works is not a good way forward. That may work for now but will probably change soon.

            If you have any security concerns that involve current code, please email security@wotrdpress.org. This is the only “proper” way to address them. If you have “security hardening” ideas, feel free to open ticket(s) on trac.

            We are creating the Shortcodes Roadmap to address all of these concerns, and to welcome ideas, opinions and eventually patches from everybody that is interested in using this API in the future.

    • bduclos 8:29 am on August 31, 2015 Permalink | Log in to Reply

      When you say “There is simply no good reason for trying to support mixing of shortcodes and tag”, do you mean in the attributes? Will we still be able to put HTML inside shortcode content? e.g .

    • Dave Navarro, Jr. 4:20 pm on August 31, 2015 Permalink | Log in to Reply

      I have dozens of plugins that use shortcodes from inside of HTML attributes. So if you plan on killing that, you need to come up with an alternative. I very much disagree with the premise that shortcodes should not be used inside of HTML tags. The relationship between HTML and shortcodes is a marriage made in heaven. And removing the functionality is shortsighted in my opinion.

      • Andrew Ozz 7:12 pm on August 31, 2015 Permalink | Log in to Reply

        Yes, having placeholders in HTML attributes may be handy in some cases. For example: when front-end page loads require different attributes. However shortcodes (as currently implemented) are not suitable for that.

        Plugins that need to regularly change HTML attributes on the front-end will generally be better off defining their own placeholders or using data-myattr="needed values" and replacing that on runtime. There are several options that are better than using shortcodes.

    • Peter Wilson 3:56 am on September 1, 2015 Permalink | Log in to Reply

      A more defined API is great – thanks Andrew & others involved. A hearty +1.

      I back any effort to avoid mixing HTML within shortcodes or shortcodes within HTML attributes. Like all things editor, approach it as a tool for users, not coders.

  • Andrew Ozz 1:31 am on July 9, 2015 Permalink
    Tags: , , ,   

    Editor changes in WordPress 4.3 

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

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

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

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

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

    As always, feedback is very welcome.

    • Samuel Wood (Otto) 1:39 am on July 9, 2015 Permalink | Log in to Reply

      FYI to support team members. Any major editor JS change causes massive issues, because of caching. Bottom line, adding a version to the JS files, like we do, doesn’t solve the problem for people like CloudFlare users and people with overly crazy caching situations. Expect that these changes will cause big upticks of reports of breakage and silly demands to revert. CLEARING CACHES WILL FIX IT. The trick is finding out what kind of cache they use, and then clearing that.

      Just saying. This always happens for every major JS change.

      • Andrew Ozz 3:32 am on July 9, 2015 Permalink | Log in to Reply

        Yeah, this used to be a really big problem some time ago. Lately the situation has been improving. We have been updating TinyMCE and the custom plugins in each new WordPress release. There are still some reports of editor JS errors, but far less than few years ago.

    • Leo Caseiro 2:08 am on July 9, 2015 Permalink | Log in to Reply

      Hi @azaozz believe the PHP function is wpautop()

    • crispinbalfour 7:56 am on August 21, 2015 Permalink | Log in to Reply

      I am not sure whether this is a place to ask this but I have posted a query and nobody is responding.

      I have updated to 4.3 and now the GT3 Page builder in Skew Theme is not working. The developer gave me a fix so I can at least see the content in the Text Area module, but there are no buttons for inserting/editing links any more.

      The developer indicated this was a bug with Tiny MCE in the latest release – is this the case? From what is written above Tiny MCE is no longer a part of things, and the GT3 is not going to work anymore?


    • hernangonzalez 9:49 pm on August 23, 2015 Permalink | Log in to Reply

      This change seems to be a headache for those who had chosen to no use wpautop() on their blogs (disabled via plugins or custom themes) and who want to control the HTML markup themselves.

    • lokidude99 10:47 pm on August 26, 2015 Permalink | Log in to Reply

      Seems to have broken all my sites that used qtranslate plus a plugin that seems to have recently become unsupported.

      Debug mode throws no errors and the only error I see in the console is ..

      Uncaught TypeError: Cannot read property ‘canvas’ of undefinedb.closeAllTags @ quicktags.min.js?ver=4.3:1d @ editor.min.js?ver=4.3:1(anonymous function) @ editor.min.js?ver=4.3:1i @ tinymce.min.js?ver=4203-20150730:2m @ tinymce.min.js?ver=4203-20150730:2

      When you click on the visual tab in the editor.

      Any suggestions on where I should look to fix this?

      Urgently need assistance on this.

    • WooRockets 8:32 am on September 9, 2015 Permalink | Log in to Reply

      Thanks for informing us about the problem with the visual editor. Current we are using wp_editor() function for our plugin: WR PageBuilder, and it isn’t working on WordPress 4.3 (it was working well on WordPress 4.2). I’d really appreciate if you could suggest me a way to fix this problem. Thank you very much.

    • WooRockets 8:48 am on September 9, 2015 Permalink | Log in to Reply

      Please see screenshot problem here:



      • Andrew Ozz 3:47 pm on September 9, 2015 Permalink | Log in to Reply

        Looks like an error in an “inline” script on that page. To troubleshoot: best to enable `SCRITP_DEBUG`, then look at the script where the first error occurs. My guess is that the plugin doesn’t select the editor switching buttons properly.

    • abeeken 8:48 am on September 14, 2015 Permalink | Log in to Reply

      Hello people, hopefully this is the correct thread for this; it’s the only one that I can find that seems to pertain to the problem I’m having!

      So, I’ve got a Network install that I’m running a very specific suite of sites on for use at our University. A feature I’ve included in this is that certain pages allow registered users to add content via a TinyMCE editor instantiated using the wp_editor() function. This was working all fine and great until I updated to WP4.3 at which point the editor loads the Visual and Code tabs, but none of the formatting buttons – in fact, it’s always displaying in the text view with no formatting at all. In addition, the Admin menu bar is also not displaying for any pages which display the wp_editor() field.

      Is this a known issue in 4.3 or is it likely to be something to do with my particular install? I’ve tried switching themes, disabling plugins etc but it specifically seems to be tied in with my using this function.

      Any help or confirmation of this issue would be greatly appreciated.

  • Andrew Ozz 6:33 pm on January 18, 2014 Permalink
    Tags: , , ,   

    TinyMCE 4.0 is in core 

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

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

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

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

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

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

    • Shapeshifter 3 7:24 pm on January 18, 2014 Permalink | Log in to Reply

      Mr. Ozz,

      I’ve been using the TinyMCE Spellchecker plugin but recently disabled it while reviewing your progress with TinyMCE 4.0. I was going to leave it installed (but disabled) until the developer updates it. Would you recommend that I completely uninstall it instead?

      • Andrew Ozz 9:03 pm on January 18, 2014 Permalink | Log in to Reply

        The updated ‘spellchecker’ plugin currently doesn’t work with the (old) PHP back-end. This is a somewhat moot problem as all newer browsers have built-in spellcheckers. Furthermore Jetpack includes the After the Deadline module which also checks grammar.

        I know that the TinyMCE team has plans for the ‘spellchecker’ plugin, but for now it has been removed from the default editor configuration.

    • PeterRKnight 7:31 pm on January 18, 2014 Permalink | Log in to Reply

      I’ve been looking forward to this so bad. Awesome news!!

    • Jeremy Felt 7:43 pm on January 18, 2014 Permalink | Log in to Reply

      Great news, thanks @azaozz!

    • Mike Schinkel 9:04 pm on January 18, 2014 Permalink | Log in to Reply

      Hi @azaozz,

      This is indeed good news!

      Do you (or anyone else) know if it will make it easier to have more than one TinyMCE instance in a single admin page?

      • Andrew Ozz 9:15 pm on January 18, 2014 Permalink | Log in to Reply

        Creating multiple TinyMCE instances has been quite easy for some time 🙂

        From PHP all that’s needed is to call `wp_editor()` and pass any initial content and an unique HTML ID. From JS you can simply call `tinymce.init({ my_settings_obj })`. TinyMCE 4.0 also supports “inline” instances, so any part of the screen can be made editable (of course that would need some more JS to handle saving).

    • adamsilverstein 5:06 am on January 19, 2014 Permalink | Log in to Reply

      Thanks again Sir Ozz for your diligent work on this. Its going to make a huge difference for everyone editing content every day in WordPress ! Even if they don’t notice how much has improved, the improvements will benefit them. Its a bit of open heart surgery at the core of WordPress and you are the man to handle it!

      So cheers to you from the untold masses who benefit from your work! Thank you!

    • emzo 11:21 pm on January 19, 2014 Permalink | Log in to Reply

      Great work on this!

      Do you happen to know if TinyMCE 4.x can be moved around in the DOM without breaking? With the 3.x release, dragging/moveing a WP metabox containing a TinyMCE instance it causes TinyMCE to break. I believe it’s down to how certain browsers deal with moving iframes within the DOM, and it is possible to circumvent the problem by removing the TinyMCE instance then re-adding it after moving, but it is a bit of a faff. Does TinyMCE 4.x help with this issue in any way?

      • Andrew Ozz 12:02 am on January 20, 2014 Permalink | Log in to Reply

        Haven’t tried that yet, but 4.0 is more resilient than 3.5, so hopefully it works. If not, a relatively simple workaround would be to not initialize the instance on page load and have a button/link “Edit”. Then on initialization lock down the postboxes so they cannot be moved: $( selector ).sortable('disable');.

    • Piet 1:16 am on January 20, 2014 Permalink | Log in to Reply

      Great stuff, reading the 4.x documentation now.

      After downloading current core from git and trying it out, I noticed that a tooltip has been added to the buttons. Does anyone know how to include that tooltip as my plugin now shows the tooltip en.undefined

      • Andrew Ozz 1:37 am on January 20, 2014 Permalink | Log in to Reply

        IMHO the best way to learn the new API is to check the default plugins. Most of them add a button and also a menu item (4.0 can show a menubar too). The menubar is not shown by default in WordPress but that might change.

        The translations API in 4.0 is changed too. All strings are in English and are matched directly against the loaded translation. The ‘compat3x’ plugin patches it to make it back-compat. If you see ‘undefined’ perhaps refresh the browser cache again (just in case) and trace where it comes from. You should be seeing some kind of a string.

    • Jeff Chandler 7:38 pm on January 20, 2014 Permalink | Log in to Reply

      Using the bleeding edge nightlies for 3.9, am I suppose to see a noticeable different between the visual editor of WordPress 3.8 and what was added to WordPress with TinyMCE 4.0? I don’t see much of a difference except for a dark background tooltip when hovering over the buttons and the removal of the Paste From Word button.

    • Paal Joachim Romdahl 12:46 pm on January 21, 2014 Permalink | Log in to Reply

      Looking at the interface for 4.0 the use of tables is still much in use (from what I saw that the tinyMCE web site). It would be nice to create columns/boxes in a similar way to creating tables. As one would be able to place content inside the cells (dashed lined area) create buffers between the cells as a margin.

      This way one would be able to create boxes/columns in an easy visual way using the table look and feel.

      Perhaps even add a background color, curved lines, shadow etc..:)

    • needle 11:33 am on January 22, 2014 Permalink | Log in to Reply

      My existing wp_editor() code defines the buttons that I want to have appear by populating the ‘tinymce’ array that is passed to wp_editor() as part of the $settings array. But now, because the ‘advanced’ theme is no longer present, the editor no longer works. What’s the procedure for recreating this functionality with TinyMCE 4.0?

    • David Wells 8:56 pm on April 16, 2014 Permalink | Log in to Reply

      Our tinymce button is done from the tinymce toolbar with the 3.9 update and tinyMCE 4.0

      I’ve read http://www.tinymce.com/wiki.php/Tutorial:Migration_guide_from_3.x but don’t see any thing specific to our case.

      Our code was adding an additional button to the toolbar: https://github.com/inboundnow/leads/blob/master/shared/inbound-shortcodes/js/tinymce.js#L41-L183

      Can anyone see what the issue might be? or can you point me in the right direction to fix?

      Many thanks

      • Andrew Ozz 11:15 pm on April 25, 2014 Permalink | Log in to Reply

        The TinyMCE API has changed, adding a “simple” button works pretty much like in 3.x, however for adding a drop-down or a split button you’ll need to use the new API. There are some examples in the TinyMCE default plugins.

    • Mr. Vibe 9:47 am on April 17, 2014 Permalink | Log in to Reply

      +1, similar case as @David wells. Tried the compact3x plugin and it does not work. Any ideas ? The codex is not updated and we’re hanging in the middle of nowhere.

    • Jacob N. Breetvelt 10:13 am on April 17, 2014 Permalink | Log in to Reply

      Can you lease help me in fixing this?

      /* wppa-tinymce.js

      • Pachkage: wp-photo-album-plus
      • Version 5.2.17
      • /

      // closure to avoid namespace collision
      // creates the plugin
      tinymce.create(‘tinymce.plugins.mygallery’, {
      // creates control instances based on the control’s id.
      // our button’s id is “mygallery_button”
      createControl : function(id, controlManager) {
      if (id == ‘mygallery_button’) {
      // creates the button
      var button = controlManager.createButton(‘mygallery_button’, {
      title : ‘WPPA+ Shortcode Generator’, // title of the button
      image : wppaImageDirectory+’albumnew32.png’, // path to the button’s image
      onclick : function() {
      // triggers the thickbox
      var width = jQuery(window).width(), H = jQuery(window).height(), W = ( 720 < width ) ? 720 : width;
      W = W – 80;
      H = jQuery(window).height();
      H = H – 115;
      tb_show( 'WPPA+ Shortcode Generator', '#TB_inline?width=' + W + '&height=' + H + '&inlineId=mygallery-form' );

      var isNew = wppa_getCookie('wppanewstyle') == 'on';
      if (isNew) document.getElementById('mygallery-newstyle').checked = 'checked';
      return button;
      return null;

      // registers the plugin. DON'T MISS THIS STEP!!!
      tinymce.PluginManager.add('mygallery', tinymce.plugins.mygallery);

      // executes this when the DOM is ready
      // creates a form to be displayed everytime the button is clicked
      // you should achieve this using AJAX instead of direct html code like this
      var xmlhttp = wppaGetXmlHttp(); // located in wppa-admin-scripts.js
      // wppa-ajax.php calls wppa_make_tinymce_dialog(); which is located in wppa-tinymce.php

      var url = wppaAjaxUrl+'?action=wppa&wppa-action=tinymcedialog';
      xmlhttp.onreadystatechange=function() {
      if (xmlhttp.readyState == 4 && xmlhttp.status!=404 ) {
      var formtext = xmlhttp.responseText;

      var form = jQuery(formtext);

      var table = form.find('table');

      // handles the click event of the submit button

      var type = table.find('#mygallery-type').val();
      var temp1;
      if (table.find('#mygallery-album').val()) temp1 = table.find('#mygallery-album').val().split('|');
      else temp1 = [''];
      var album = temp1[0];
      var tags = table.find('#mygallery-tags').val();
      var andor = document.getElementById('mygallery-andor').checked;
      var size = table.find('#mygallery-size').val();
      var align = table.find('#mygallery-align').val();
      var temp2;
      if (table.find('#mygallery-photo').val()) temp2 = table.find('#mygallery-photo').val().split('.');
      else temp2 = [''];
      var photo = temp2[0];
      var temp3 = photo.split('/');
      photo = '';
      for ( i=0; i 0) {} // Ok, positive number
      else if (size == ‘auto’) {} // Ok, auto
      else {
      alert(‘Sorry, you made a mistake\n\nSize must be a positive number or auto\nA number less than 100 will be interpreted as a percentage of the current column width\n\nPlease try again’);
      if (size < 100) size=size/100;

      // Check for inconsistencies
      if ( type == 'cover' ) {
      if ( album == '#topten' || album == '#lasten' || album == '#comten' || album == '#featen' || album == '#tags' || album == '#all' ) {
      alert('Sorry, you made a mistake\n\nA — special — selection has no album cover\n\nPlease try again');
      if ( type != 'photo' && type != 'mphoto' && type != 'slphoto' && type != 'generic' && type != 'upload' ) {
      if ( album == 0 ) {
      alert('Sorry, you made a mistake\n\nPlease select an album\n\nPlease try again');
      if ( type == 'photo' || type == 'mphoto' || type == 'slphoto' ) {
      if ( photo == 0 ) {
      alert('Sorry, you made a mistake\n\nPlease select a photo\n\nPlease try again');
      if ( type == 'filmonly' && ! newstyle ) {
      alert('Sorry, filmonly is as newstyle shortcode available only.\n\nPlease check the new style checkbox and try again.');
      if ( type == 'upload' && ! newstyle ) {
      alert('Sorry, the upload box is as newstyle shortcode available only.\n\nPlease check the new style checkbox and try again.');
      if ( album == '#tags' && ! tags ) {
      alert('Select at least one tag and try again.');

      // Make the shortcode
      var shortcode = '%%wppa%%';

      if ( type == 'generic' ) {
      else if ( type == 'photo' || type == 'mphoto' || type == 'slphoto' ) {
      shortcode += ' %%'+type+'='+photo+'%%';
      else if ( album == '#tags' ) {
      shortcode += ' %%album=#tags,';
      var sep = andor ? ',' : ';';
      var last = tags.length – 1;
      for (var tag in tags) {
      shortcode += tags[tag];
      if ( tag != last ) shortcode += sep;
      shortcode += '%%';
      else {
      var temp = album.split('|');
      if ( temp[0] == '#topten'|| temp[0] == '#lasten' || temp[0] == '#comten' || temp[0] == '#featen' ) {
      if ( cnt != '0' ) {
      shortcode += ' %%'+type+'='+temp[0]+','+alb+','+cnt+'%%';
      else if ( alb != '0' ) {
      shortcode += ' %%'+type+'='+temp[0]+','+alb+'%%';
      else {
      shortcode += ' %%'+type+'='+album+'%%';
      else {
      shortcode += ' %%'+type+'='+album+'%%';

      if ( size != 0 )
      shortcode += ' %%size='+size+'%%';

      if ( align != 'none' )
      shortcode += ' %%align='+align+'%%';

      // Make the new shortcode
      var newShortcode = '[wppa type="'+type+'"';

      if ( type == 'generic' ) {
      else if ( type == 'photo' || type == 'mphoto' || type == 'slphoto' ) {
      newShortcode += ' photo="'+photo+'"';
      else if ( album == '#tags' ) {
      newShortcode += ' album="#tags,';
      var sep = andor ? ',' : ';';
      var last = tags.length – 1;
      for (var tag in tags) {
      newShortcode += tags[tag];
      if ( tag != last ) newShortcode += sep;
      newShortcode += '"';
      else {
      var temp = album.split('|');
      if ( temp[0] == '#topten' || temp[0] == '#lasten' || temp[0] == '#comten' || temp[0] == '#featen' ) {
      if ( cnt != '0' ) {
      newShortcode += ' album="'+temp[0]+','+alb+','+cnt+'"';
      else if ( alb != '0' ) {
      newShortcode += ' album="'+temp[0]+','+alb+'"';
      else {
      newShortcode += ' album="'+temp[0]+'"';
      else {
      if ( album || type != 'upload' ) {
      newShortcode += ' album="'+album+'"';

      if ( size != 0 ) newShortcode += ' size="'+size+'"';
      if ( align != 'none' ) newShortcode += ' align="'+align+'"';
      newShortcode += '][/wppa]';

      // inserts the shortcode into the active editor and save the newstyle checkbox
      if (newstyle) {
      tinyMCE.activeEditor.execCommand('mceInsertContent', 0, newShortcode);
      wppa_setCookie('wppanewstyle', 'on', '365');
      else {
      tinyMCE.activeEditor.execCommand('mceInsertContent', 0, shortcode);
      wppa_setCookie('wppanewstyle', 'off', '365');

      // closes Thickbox

      function wppaGalleryTypeChange(value) {

      if (value == 'generic' ) {
      else if (value == 'photo' || value == 'mphoto' || value == 'slphoto' ) {
      else {

      function wppaTinyMcePhotoPreview(id) {

      function wppaTinyMceAlbumPreview(id) {
      var html = ”;
      var temp = id.split(‘|’);
      var count = temp.length – 1;

      if (count > 0) for (var i = 1; i <= count; i++) {
      if ( temp[i] != '' ) html += '‘;
      else {
      html = ‘


      if ( temp[0] == ‘#topten’ || temp[0] == ‘#lasten’ || temp[0] == ‘#comten’ || temp[0] == ‘#featen’ ) {
      else {

      function wppaGalleryAlbumChange(value) {
      if ( value == ‘#tags’ ) jQuery(‘.mygallery-tags’).css(‘display’, ”);
      else jQuery(‘.mygallery-tags’).css(‘display’, ‘none’);

    • llazarus 11:23 am on April 17, 2014 Permalink | Log in to Reply

      Upgraded to 3.9 and tinyMCE 4.0. I am unable to Edit a hyperlink – if I select the link and click Insert/Edit Hyperlink, the existing link is erased.

      Also, when pasting a link from Word that has a target=”_blank”, the extra code is removed – this making more work for me as I specifically generate the link to open in a new window. Is there anyway to stop the target=”_blank” being removed?

      Many thanks

    • TTBoS 10:22 pm on April 17, 2014 Permalink | Log in to Reply

      A similar problem is with onmouseover and onmouseout WP removes the html code from the article / news.

    • alfredocubitos 2:27 pm on April 18, 2014 Permalink | Log in to Reply


      how can I get data passed with the “tiny_mce_before_init” filter?
      In my old plugin I get the data with “tinyMCE.activeEditor.settings” but with tinyMCE I can’t get any data.
      Or has the “tiny_mce_before_init” filter changed?

      Thanx for your answer

      • Andrew Ozz 10:59 pm on April 25, 2014 Permalink | Log in to Reply

        No, the filter hasn’t changed and tinymce.activeEditor.settings works as before. Seems there is another problem. The init settings can also be accessed with ‘tinyMCEPreInit.mceInit.editor_id’ where ‘editor_id’ is the id of the instance you need.

    • thanhluan710 5:10 am on April 19, 2014 Permalink | Log in to Reply

      Hi all.
      I upgraded WordPress to Version 3.9 and I have a problem with Visual Editor.
      My site is for coupon. When I write a post on Visual Editor on “Visual” tab and I want insert html code, I move “Text” tab. For example code:

      Click here to WordPress:

      Well done. A post is successful but When I update post, I see:

      Click here to WordPress:

      Link was lost. I can not open a new tab when click button. On WordPress version 3.8.3, all is good. I turned off all plugin but not success. I install new site with WP 3.9 but same.

      Please me. Thank you.

    • Karen Pogosyan 2:05 pm on April 22, 2014 Permalink | Log in to Reply

      Hello, everyone, just updated wordpress to new 3.9, new features are great, love them. Only got some issues with tinyMCE 4. I use wp_editor to create multiple tinyMCE editors with custom field.

      $tinymce_opt = array(
      	 'height' 	 => "250",
      	 'plugins'  => "ninzio_button, line, gap, slider_colorbox, icon_list, icons, font_size",
      	 'toolbar1' => "formatselect,fontselect, styleselect,|,bold,italic,underline,|,justifyleft,justifycenter,justifyright,justifyfull,|,link,unlink,|,forecolor,removeformat,charmap,undo,redo",
      	 'toolbar2' => "ninzio_button, line, gap, slider_colorbox, icon_list, icons, font_size",
      	 'toolbar3' => ""
      $settings = array (
      	'tinymce'       => $tinymce_opt
      wp_editor( ${"layer_$i"}, "layer_$i", $settings);

      everything is fine. the problem is that it does not understand plugins (my custom shortcodes, that i created). Custom shortcodes work fine in regular wp editor, but iwth multiple wp_editor, it just don’t find them.

      In colsole i get error 404 can’t find

      for example “line” shortcodes

      http://localhost/0_test/wp-includes/js/tinymce/plugins/line/plugin.min.js 404 (Not Found)

      All my custom shortcodes are ignored, not found.

      Does anyone know, how to tell tinyMCE + wp_editor to use custom shortcodes?

      Thanks very much!

      • Andrew Ozz 10:45 pm on April 25, 2014 Permalink | Log in to Reply

        As your custom MCE plugins are not in the default location, i.e. not in wp-includes/js/tinymce/plugins/, you have to load them as external plugins using the ‘mce_external_plugins’ filter.

    • Stagger Lee 8:09 pm on April 23, 2014 Permalink | Log in to Reply

      Can someone share code snippet for functions.php to disable some buttons (and new toolbar) in comment forms ? Old one doesnt work anymore witj new tinymce.

      Btw, new WP 3.9 and new Tinymce are real candy. Real enjoyable to work with latests WP.

      Have difficult to understand why Drupal chosed Ckeditor for core in its Drupal 8 version.
      Ckeditor aka “look at me i am from outer space with my huge buttons and huge shadows that never near fit to themes”.

      • Andrew Ozz 10:54 pm on April 25, 2014 Permalink | Log in to Reply

        That should be set in the plugin you’re using for adding TinyMCE to the comment form. If that plugin uses wp_editor(), it may be possible to use the ‘mce_buttons’, ‘mce_buttons_2’, etc. filters. Having a code snippet in functions.php is not the best way to do that 🙂

    • Thomas S. Butler 10:31 pm on April 25, 2014 Permalink | Log in to Reply

      As the author of the Google Fonts Manager plugin, I am having this issue as well. The custom font dropdown no longer appears and the TinyMCE documentation is no help at all. The plugin was using the following functions: theme_advanced_buttons1_add_before, theme_advanced_fonts and tiny_mce_before_init to add the font options. It no longer works and I’m stumped (so far) as to how to address the issue.

      • Andrew Ozz 11:28 pm on April 25, 2014 Permalink | Log in to Reply

        Would have been better to use a WordPress filter, ‘mce_buttons’ or ‘mce_buttons_2’, to add the button. Would have worked without a change. All the ‘theme_advanced_*’ settings are gone from TinyMCE as there is a new theme. Have a look at the settings: http://www.tinymce.com/wiki.php/Configuration, seems you need ‘font_formats’: http://www.tinymce.com/wiki.php/Configuration:font_formats.

      • Stagger Lee 8:54 am on April 26, 2014 Permalink | Log in to Reply

        Thank you Andrew. mce_buttons never worked for me, maybe i used wrong code snippet.
        I know what you are saying, but this way i block even Admins to all Tinymce options and icons.
        Cant use plugin for this because they dont exist. One exist but is outdated.

        This code snippet works for me now, unfortunately had to remove new menu toolbar at the top even for admins with Tinymce advanced plugin (global setting).


        add_filter( ‘comment_form_defaults’, ‘rich_text_comment_form’ );
        function rich_text_comment_form( $args ) {
        wp_editor( ”, ‘comment’, array(
        ‘media_buttons’ => false, // show insert/upload button(s) to users with permission
        ‘textarea_rows’ => ’10’, // re-size text area
        ‘tinymce’ => array(
        ‘menubar’ => ”,
        ‘toolbar1’ => ‘fontsizeselect,bold,italic,underline,strikethrough,bullist,numlist,alignleft,aligncenter,alignright,blockquote,link,unlink,|,undo,redo,media,image,emoticons,’,
        ‘toolbar2’ => ”, // 2nd row, if needed
        ‘toolbar3’ => ”, // 3rd row, if needed
        ‘toolbar4’ => ” // 4th row, if needed
        ‘quicktags’ => array(
        ‘buttons’ => ‘strong,em,link,block,del,ins,img,ul,ol,li,code,close’
        ) );
        $args[‘comment_field’] = ob_get_clean();
        return $args;

    • nextstep 5:20 am on April 26, 2014 Permalink | Log in to Reply

      How do I restore the icons? I hate the menu options — it’s now multiple click to find what I want (not what you want to give me. The menu — in my opinion — is a definite step backwards.

    • urkekg 8:29 am on April 26, 2014 Permalink | Log in to Reply

      Hi all,

      I’m not sure if this is right place to post this question, but let me try 🙂

      We need a class field in Link Insert/Edit plugin (WP_Link). Is that mod on the way, or I can submit diff I did to enable this? I altered core files /wp-includes/js/wplink.js and /wp-includes/class-wp-editor.php

      Also, we need some docs regarding custom colour swatches and number of rows. Here is my answer to that question on StackOverflow http://stackoverflow.com/a/23183406/1509769

    • Stagger Lee 9:04 am on April 26, 2014 Permalink | Log in to Reply

      Maybe someone from the core team should take a look at it. Maybe i am plain stupid and miss something in the front of oy nose, but i struggle from website to website to customize editor for my comment form. Losing much time on it every time.

      Second problem is my code snippet in functions.php for overriding editor works in admin part but not at the front end. Not so easy to style comments editor. Use of !important declarations are so bad, but had to use them. Right now i find it more easy to go and change it directly in the core, CSS. What to do, cant lose much time on it every time.

    • Stagger Lee 9:27 am on April 26, 2014 Permalink | Log in to Reply

      As i know and i am aware people from Drupal team in latest years sniff things around WP as undercover agents, and imitate some good things. You can take something good from them too. For instance Text formats and editor profiles for writing and editors. So simple and so easy. Easy to customize all butons, options, and override CSS (or JS) files for each profile/format.

    • akamaxbuz 10:04 pm on May 16, 2014 Permalink | Log in to Reply

      What about keeping the format styling when pasting from Pages? I use Pages to edit my client’s dock files. Styled text from Pages does loses the style format when I paste it into the 3.9 edit pane. This is a problem.

  • Andrew Ozz 8:20 pm on January 25, 2013 Permalink
    Tags: ,   

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

    • Assign contributors for each component: Autosave in the browser storage, Post locking, Login expiration warning.
    • Further discussion on workflow for post locking, perhaps look at the plugin by jayminkapish on #18515.
    • Free-form Q&A.
  • Andrew Ozz 12:58 am on January 19, 2013 Permalink
    Tags: ,   

    Autosave and Post Locking 

    Components and design

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

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

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

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

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

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

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

    Office hours

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

  • Andrew Ozz 3:50 am on August 11, 2012 Permalink

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

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

  • Andrew Ozz 7:53 am on February 14, 2012 Permalink  

    Team update: Editorial 

    The first cycle finished yesterday. First run patch for supporting HTML in image captions is on #18311. Includes handling of the HTML in both editors and basic UI for inserting a link in the image properties tab in the gallery.

    For the second cycle: testing, refining and committing HTML support for image captions, finishing up DFW support for editors not on the write screen, other editor enhancements and code improvements for example using the native MCE dialogs for our plugins instead of thickbox.

  • Andrew Ozz 9:36 pm on February 9, 2012 Permalink  

    Team update: Tableteers 

    Cycle ending on February 22.
    (George Stephanis and Zach Abernathy)

    1. Admin Left Nav Menu Scroll Independently ( Enhancement )
    The idea is for the Main Left Nav to scroll independently of the body, and metaboxes on the right to create the most usable interface for tablet users. This will create more of an “app” effect best for navigating and using the WordPress admin without the use of an actual app. It was decided not to go this way in #19994.

    2. Clean Up Touch UI for Left NavMenu / Flyouts ( Bugfixes )
    While the flyout is mostly usable in it’s current state, it is not as intuitive as it needs to be for the best user experience. They are ineffective at best on the Kindle Fire’s Silk Browser, but work pretty well on the iPad. We need to examine all target devices to ensure interactivity is supported cross-device.

    3. Possibly add support for dragging of meta boxes
    In the desktop version of WordPress a user has the ability to move metaboxes around to customize their interface. However, touch-and-drag support is not as intuitive on a tablet. There are possible work-arounds that need to be explored. Alternately, there is the possibility of pre-determining the number of columns and not support drag-and-drop.

    4. Dashboard and write screen columns (with @media)
    Determining the number of columns that are present in landscape view versus portrait view. This would need to be tested on a per device basis to determine the optimum number of columns. In WP 3.3 this effect was generated via JS. We should be able to yield better performance by handling this via CSS.

    5. Resolve Amazon Silk Browser ( Kindle Fire ) WYSIWYG Incompatibility
    Currently, the WordPress WYSIWYG (TinyMCE) does not work in the Android Fire Silk Browser, but it does on the native Android browser. This is due to the Silk browser still not supporting the `contentEditable` attribute properly.

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