WordPress.org

Make WordPress Core

Updates from September, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Robert Chapin 10:10 pm on September 2, 2015 Permalink |
    Tags: ,   

    Shortcode Roadmap Draft One (Proposal – Request for Comments) 

    This is the first draft of the Shortcode API Roadmap. It describes in broad terms a new feature set and migration that might take place across versions 4.4 through 4.7. This roadmap gives notice to plugin developers that significant changes in plugin design may be needed for compatibility with future versions of the Shortcode API. This roadmap also identifies steps taken to minimize the impact on plugin developers to allow most plugins to continue working with only small changes.

    The decision to create this roadmap arose from specific needs that are not met by the old code. Our old [ and ] delimiters were easily confused with the way those characters are commonly used in English quotations and sometimes even in URLs. The proposal to use [{{ and }}] instead should allow a better balance between being able to type in the shortcodes and avoiding confusion with any other input. With these more unique delimeters, we will be able to process registered shortcodes more efficiently because we will not have to search for them by name. Unregistered shortcodes will have more consistency because we can find them more accurately.

    Old style delimeters also gave no strong indication whether or not a closing tag was required. The proposal to use }$] as the delimeter of a shortcode with a following closing tag increases the efficiency of regular expressions, because the search for a closing tag will only happen as needed.

    Adding the new style of shortcode syntax provides an opportunity to make significant API changes. One of those major changes is to ensure that shortcodes are processed before paragraphs and before curly quotes. This will lead to greatly simplified code in related functions that currently must find and avoid shortcodes every time they run. We also have an opporunity to re-think the way shortcodes are filtered, and to give plugin authors more control over those filters when registering their shortcodes.

    4.4 – Introduce New Syntax

    A new syntax and documentation of how it works will be created in the 4.4 development cycle. Support for the new syntax will be introduced, allowing plugins to register for extra features. Core shortcodes will use the new syntax in all new posts. The old syntax will not change. Old posts will not be affected. Initial work on the syntax concept follows.

    Proposed New Syntax

    Self-Closing:  [{{shortcode}}]
    
    Attributes:  [{{shortcode  attr1="value1"  attr2='value2'  "value3"  'value4'  value5}}]
    
    Enclosing:  [{{shortcode}$] HTML [${shortcode}}]
    
    Multiple Enclosures:  [{{shortcode}$] HTML [${encl2}$] HTML [${encl3}$] HTML [${shortcode}}]
    
    Escaped Code:  [!{{shortcode}}]
    
    Stripped Unregistered Code:  [{{randomthing}}]
    
    Stripped Unregistered Enclosure:  [{{randomthing}$]  Content also stripped.  [${randomthing}}]
    
    Stripped Empty Code:  [{{ }}]
    
    Ignored Orphan:  [{{shortcode}$]
    
    Ignored Orphan:  [${shortcode}}]
    
    Ignored Orphan:  [${encl2}$]
    
    Ignored Context:  [{{shortcode <br> }}]
    
    Ignored Context:  <a href="[{{shortcode}}]">

    4.5 – Deprecate Old Syntax

    Starting in 4.5, plugins that register shortcodes without declaring support for new features will raise debugging errors to alert developers that support for the old shortcode syntax is ending.

    Old posts will continue to work normally while the old syntax is deprecated.

    4.6 – Upgrade Old Posts

    Old posts will be automatically converted to the new shortcode syntax. The Shortcode API will continue to provide deprecated support for old syntax so that there is no disruption during the conversion process.

    The API should be adequately abstracted so that old plugins are not affected by this conversion. However, as the new syntax will not support HTML inside of shortcode attributes, there is no guarantee that every shortcode will work the same way in 4.6 as in earlier versions.

    4.7 – End of Support for Old Syntax

    Old shortcodes will stop working in 4.7. Plugins that still produce the old shortcode syntax will be ignored by the Shortcode API.

    The upgrade to 4.7 will include a second pass of the conversion of old posts so that any old syntax that was added to posts during 4.6 will still get converted.

    In 4.6 or 4.7, if necessary, a filter could be added to automatically convert any old syntax still being produced by old plugins when new posts are created.

     
    • Daniel Bachhuber 10:15 pm on September 2, 2015 Permalink | Log in to Reply

      Old posts will be automatically converted to the new shortcode syntax. The Shortcode API will continue to provide deprecated support for old syntax so that there is no disruption during the conversion process.

      What about shortcodes stored in other fields?

      • Muhammad 10:18 pm on September 2, 2015 Permalink | Log in to Reply

        Hopefully, we’ll have helper functions to convert those into new format.

      • Robert Chapin 10:38 pm on September 2, 2015 Permalink | Log in to Reply

        Unless there are alternative ideas, I think plugins that do things in non-core ways will be expected to follow the roadmap with their own upgrades. If there are certain fields that are very commonly used in plugins, we should consider doing a core conversion of those, but with much caution.

      • Robert Chapin 11:10 pm on September 2, 2015 Permalink | Log in to Reply

        One alternative would be to leave the old syntax parsers available for plugin filters, while removing them from default filters.

    • AmirHelzer 10:16 pm on September 2, 2015 Permalink | Log in to Reply

      Thanks for the advanced notice on this huge upcoming change. Aren’t you worried that this process will basically break 99% of all existing WordPress sites? Almost all sites use shortcodes in one way or another (like image captions). doing automated updates to CONTENT is certainly possible, but also prone to corner cases and errors.

      It’s great to have a new API. Is it critically important to deprecate the old one?

      Also, for authors, it’s a lot nicer to have a simple [ ] syntax rather than a more complex sequence of characters.

      • Robert Chapin 10:44 pm on September 2, 2015 Permalink | Log in to Reply

        I think the conversion process will be seamless for most sites. This will mainly depend on corner cases such as plugins embedding shortcodes inside of HTML attributes.

    • Nick Haskins 10:18 pm on September 2, 2015 Permalink | Log in to Reply

      The advanced notice is great, but IMO this is absolutely ridiculous. Are there any benchmarks on how much more efficient it is having users type in more characters for a shortcode? Any benchmarks with how much more efficient core will be from having this change made? This is a HUGE change that will affect a VERY large subset of users.

      • chriscct7 10:40 pm on September 2, 2015 Permalink | Log in to Reply

        This is partially about efficiency. This has a lot to do with security, and basically making 4.2.3 impossible as possible to re-occur

        • Nick Haskins 10:45 pm on September 2, 2015 Permalink | Log in to Reply

          I’d love to see benchmarks on the regex processing of the current implementation against the proposed implementation. Re: security; ATM I’m failing to see how [{{this}}] is more secure than [this]?

        • kevinwhoffman 1:13 am on September 4, 2015 Permalink | Log in to Reply

          If the proposal has positive effects on security, it should mention them. A brief summary or a link to the issues with 4.2.3 would help inform that discussion. As of now the only focus seems to be on theoretical improvements to efficiency while complicating the process of using shortcodes.

      • FolioVision 11:31 pm on September 2, 2015 Permalink | Log in to Reply

        This is an absolutely hideous proposal with dreadful syntax. Is the goal of this WordPress project of ours not to bring software to the people? Syntax like this will be the beginning of a new and much better simple CMS which doesn’t do things in the ugliest, most complicated way possible.

        Code better database upgrades, test them properly before releasing and please stop trying to ruin the software for the end users (those who actually use the software and pay all the bills for us to build it).

        • Travis Northcutt 3:54 pm on September 3, 2015 Permalink | Log in to Reply

          “Syntax like this will be the beginning of a new and much better simple CMS which doesn’t do things in the ugliest, most complicated way possible.”

          The sky is falling!

    • Scott Taylor 10:18 pm on September 2, 2015 Permalink | Log in to Reply

      Let’s all note the “Draft One” portion of the title, and let’s all actively give feedback and participate in any decisions on the table here.

      • Nick Haskins 10:21 pm on September 2, 2015 Permalink | Log in to Reply

        My main concern is that this isn’t easier for authors, and that this will affect a very large portion of users and active sites. If I’m understanding correctly, is this being proposed because it’s more efficient for core?

        • Scott Taylor 10:23 pm on September 2, 2015 Permalink | Log in to Reply

          I have the same concerns, and hate the syntax. I also know that the current situation with shortcodes and content-parsing is potentially unstable and unsustainable.

        • Justin Sternberg 10:33 pm on September 2, 2015 Permalink | Log in to Reply

          I’m in agreement here with the concerns. This will break a lot of things because the short code API has been around so long. There’s just no way to account for all the hacks, workarounds, etc, and doing a migration effort on a WP update sounds like a mighty scary prospect.

          • leehodson 10:37 pm on September 2, 2015 Permalink | Log in to Reply

            Should be able to use the existing shortcode parser to recognize old format shortcodes then make the necessary changes to update them. It recognizes shortcodes efficiently enough at the moment.

            Can imagine breakage but as long as the updater shows the changes site admins ought to be able to determine where hands-on intervention is required.

          • FolioVision 11:33 pm on September 2, 2015 Permalink | Log in to Reply

            It seems a make work project. Are there not some important areas where we could make some real progress like integrated multilingual and better native galleries/media management (NOT reliant on external Automattic services)?

            The upgrade process here and cross-version incompatibilities are more than scary.

          • galbaras 11:44 pm on September 2, 2015 Permalink | Log in to Reply

            Backward compatibility should take into account site-specific customizations, i.e. declaring shortcodes in functions.php of a (child) theme. Most site owners use a “build and forget” approach, or at least neglect their sites for long periods. If a new version contains no support for old-style shortcode declarations, sites will break all over the web.

        • Solinx 11:09 pm on September 2, 2015 Permalink | Log in to Reply

          Yes. How am I going to explain anyone that this syntax is an improvement?

          What specifically are the reasons for not using {{shortcode}} and {{shortcode}} {{/shortcode}}? Or [[shortcode]] and [[shortcode]] [[/shortcode]]?

          Other than that the improvements to the API sound good.

          • Robert Chapin 11:18 pm on September 2, 2015 Permalink | Log in to Reply

            Lone curly braces are easily confused with PHP and other C-style code snippets. The latter square brace example is incompatible with the old syntax and would cause migration problems.

    • Andrew Ozz 10:20 pm on September 2, 2015 Permalink | Log in to Reply

      Was just about to say that this is a proposal. Scott beat me to it (as usual) :)

    • Pippin Williamson 10:22 pm on September 2, 2015 Permalink | Log in to Reply

      I would assume the answer is “yes”, but have there been benchmarks done that compare the differences in various syntaxes?

      Why [{{shortcode}}] and not {{shortcode}}?

      Most of the proposed syntax seems sane (though still curious on question above), but this one concerns me:

      [{{shortcode}$] HTML [${shortcode}}]

      For most users, that will be exceptionally unintuitive and we will almost certainly see a high error rate with users not being sure where and when a $ is used.

      • Nick Haskins 10:26 pm on September 2, 2015 Permalink | Log in to Reply

        Pippin I have to agree. If we absolutely have to move, how about something as simple as [{this}] HTML [${this}] . it’s easier to digest, and easier to remember that a $ ends a closing statement.

      • webaware 11:19 pm on September 2, 2015 Permalink | Log in to Reply

        The whole proposal sounds pretty horrible to me, but this suggestion by Pippin sounds moderately less ridiculous.

        Re: {{…}}, I would assume that’s because they are already used heavily in non-WP templating, especially JS templating.

        Essentially, this “fix” is coming rather too late in the piece and I think it’ll break more things than it solves. As a plugin writer heavily dependent on shortcodes, I can only see a greater number of support requests from broken shortcodes in my future if this goes ahead.

        Only Shortcake can save us now! :)

        • idealien 2:33 am on September 3, 2015 Permalink | Log in to Reply

          “Only Shortcake can save us now!”

          Seriously! If Shortcake were to be brought into core along with this (draft) proposed change – it would go a LONG way to mitigating the concerns many have raised around complexity.

          Without Shortcake:
          “Look – we took this feature you love and made it harder to use….But it’s safer / faster / better”

          With Shortcake:
          “Look – we made is hella-easy to use shortcodes without having to remember syntax type things. Oh, and that syntax is also getting harder b/c it needs to be safer / faster / better.”

          Car metaphor time… With Shortcake: You’re getting automatic transmission and manual is just a little bit harder to use. Without Shortcake: Manual transmission is now harder to use.

          Shortcake FTW!

      • Robert Chapin 11:33 pm on September 2, 2015 Permalink | Log in to Reply

        If we could get this to work…

        [{{shortcode}} HTML {{shortcode}}]

        Is that better? Or still confusing?

      • Mario Peshev 4:16 pm on September 3, 2015 Permalink | Log in to Reply

        I do agree with Pippin’s example with the dollar signs. Seems incredibly easy to mess up by users. I also noticed another syntax including an exclamation sign, which adds an additional layer of complexity for each and every user.

        +1 on the benchmark question. Given the several different supported syntax proposals, I’m curious to see the regex that is parsing those in a sensible and timely manner.

    • AmirHelzer 10:23 pm on September 2, 2015 Permalink | Log in to Reply

      Also, we deal a lot with shortcodes in Toolset plugins. I can’t see any evidence of any user confusing the [ ] characters for anything else than shortcodes.

      Please, besides the code changes, please also consider the huge amount of documentation update that such a change will require.

      Run a quick Google search for “WordPress shortcodes”. A few pages come from wordpress.org, but the majority are old pages, blog posts and tutorials. Nobody is ever going to update them.

      So, after making such a change, people will see two sets of documentation – with new syntax and with old syntax. You know that Google favours ‘old’ content, so the old tutorials that are never going to update will still explain to use [ ]. I don’t think that this will work out well.

      • chriscct7 10:34 pm on September 2, 2015 Permalink | Log in to Reply

        The team working on this is committed to the documentation updates that are necessary.

        • Pippin Williamson 10:35 pm on September 2, 2015 Permalink | Log in to Reply

          Core documentation isn’t an issue. It’s every plugin / theme developer in the world that also has to update their documentation.

          I don’t disagree with updating docs, just making it clear that’s the issue @AmirHelzer is raising.

          Also have to keep in mind the thousands (millions?) of blog posts and tutorials out there.

          • AmirHelzer 10:49 pm on September 2, 2015 Permalink | Log in to Reply

            Exactly. I’m sure that the core team would be quick to update documentation on wordpress.org. I’m talking about the many pages on other people’s sites that will likely never be updated.

    • Scott Fennell 10:25 pm on September 2, 2015 Permalink | Log in to Reply

      Thanks for your work on this!

      I’m trying to understand what I would need to do in order to prevent about 1,200 live blogs from breaking when this syntax is no longer supported:

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

      Andrew offered a helpful suggestion here:

      https://make.wordpress.org/core/2015/08/30/shortcodes-roadmap/#comment-27368

      If I understand his suggestion correctly, I’d be on the hook to do a search and replace in the database, which will be quite scary and expensive for my company. We have literally thousands of posts on thousands of blogs.

      Please, let’s find a way to move forward with this that leaves the old format unscathed.

      • Scott Fennell 10:28 pm on September 2, 2015 Permalink | Log in to Reply

        Sorry, meant to provide the following code.

        http://pastebin.com/1CMN731H

        Is there a reference somewhere for the comment syntax so I can stop posting gibberish?

      • Robert Chapin 11:49 pm on September 2, 2015 Permalink | Log in to Reply

        If the situation doesn’t support

        [{{my_shortcode class="my_class"}}]

        Then the alternative proposed in the roadmap is

        [{{my_shortcode}$] Optional Content [${before}$]<div class="my_class">[${after}$]</div>[${my_shortcode}}]

        We will also likely encode any HTML in attributes during a migration, so you would have the option of decoding that in your plugin.. security implications could be significant though.

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

          “We will also likely encode any HTML in attributes during a migration”

          Can you explain what you mean by migration, exactly? My imagination is running wild a bit with what you might mean by that. Do you mean to propose that, upon this update, the new version of WordPress will automatically fix my post_content across many gigabytes of posts, without me having to do anything to the posts?

          • Aaron D. Campbell 4:29 pm on September 3, 2015 Permalink | Log in to Reply

            That’s definitely the goal. Basically using the existing parser to pull shortcodes and replace them with the new syntax.

            • Scott Fennell 7:43 pm on September 3, 2015 Permalink

              Sorry for sounding clueless here but that would be … amazing. Is there a precedent for this level of work in a similar update? I’m having trouble imagining how this would be possible given a very large database like mine. Would it run as a cron job perhaps?

    • leehodson 10:30 pm on September 2, 2015 Permalink | Log in to Reply

      The new syntax is very confusing to the eye. Users would find it complicated. I feel we could make it less confusing by using back-to-back opening and closing brackets.

      For example

      Self Closing:

      []shortcode[]

      Enclosing:

      []shortcode[] Content [/]shortcode[]

      Note the forward slash between the brackets of the closing tag on the enclosing shortcode.

      Is there a reason this wouldn’t work?

    • Peter Wilson 10:51 pm on September 2, 2015 Permalink | Log in to Reply

      I’d be happier with {{selfclosing}} and {{enclosing}} {{/enclosing}} or similar. Mixing the formats seems fraught.

      Upgrading old content is a necessary evil, backward compatibility on the deprecated format defeats the purpose somewhat. Seeing some benchmarking results would be great.

      As theme and plugin developers, we have been caught out by an ill-defined API and security problems in the past, a long term roadmap makes the best of a bad situation. I’d rather a two year defined process than a repeat of 4.3.2

      • webaware 12:46 am on September 3, 2015 Permalink | Log in to Reply

        [ignoring the double-moustache issue here…] but what signifies that the self-closing shortcode is self-closing? The problem is not merely one of mixed use, it’s the calling syntax that the regex needs to accommodate.

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

          Okay, understood – that makes sense.

          {{selfclosing /}} and {{enclosing}} {{/enclosing}}, perhaps. That makes sense to me as a developer, so may be bad for a user.

          Could be double moustache, square, anything. Looking for the balance between performance and teaching.

        • Curtiss Grymala 3:44 pm on September 3, 2015 Permalink | Log in to Reply

          In HTML, what signifies that a self-closing tag is self-closing? Hint: it’s not the / at the end; that’s totally optional; in fact, even the closing HTML tag is optional in a lot of cases.

          For instance:

          <img src="/my-image.png" alt="">

          and

          https://gist.github.com/cgrymala/d61c3cacd6fb07bdcf9a
          (a complete HTML page that is 100% valid HTML)

          are both perfectly valid HTML code samples, even if they do make those of us accustomed to XHTML syntax cringe.

          In a perfect world, there would be some way to indicate when registering the shortcode itself whether or not it’s supposed to be self-closing, but that’s not always possible (I believe there are plenty of use-cases where a single shortcode works one way when it’s self-closing, and works a slightly different way when it’s wrapped around content).

          That said, I would definitely support the idea of at least trying to indicate that in the shortcode registration (for instance, if my shortcode is only ever written to be a self-closing shortcode, let me indicate that when I register it; if it’s only ever intended to wrap around content, let me indicate that when using add_shortcode()).

          • webaware 11:09 am on September 4, 2015 Permalink | Log in to Reply

            Yes, and a parser for HTML is a pretty complex piece of code, much more significant than a handful of regular expressions. Ultimately, a true parser might be needed if we want to keep shortcodes the way they are. But perhaps that discussion is better held on the new post

    • Scott Fennell 10:52 pm on September 2, 2015 Permalink | Log in to Reply

      Othe use case for shortcodes I’m hoping you don’t break: Shortcodes in widget titles and widget text fields. This has been a gloriously simple and helpful solution for our agency, and many others I’d suspect.

      • williampatton 12:36 am on September 3, 2015 Permalink | Log in to Reply

        Shortcodes can be parsed anywhere by passing it through `do_shortcode()` which is what I expect your themes are doing to make use of them in widget titles and content.

        Your use case should be just fine so long as the shortcodes used obey the newer syntax :)

    • KalenJohnson 11:10 pm on September 2, 2015 Permalink | Log in to Reply

      I’m most likely horribly biased since I’ve started the discussion about [https://core.trac.wordpress.org/ticket/33472 templating engines], but aren’t those shortcodes looking an awful lot like templating engine syntax?

      I’m mostly confused as to why users apparently would be able to remember all those different syntax’s, yet theme and plugin developers wouldn’t, or rather don’t have built in functionality to.

      Also, I also feel rather strongly that there are MANY options now that are much preferable to shortcodes. Things like ACF, Pods, etc. They are not built in to WP core like shortcodes, but really, shouldn’t we focus on getting the Fields API set up correctly rather than continuing to pursue having complicated layouts in one single WYSIWYG editor (not so much WYSIWYG when it’s littered with shortcodes).

      • Jonathandejong 5:52 am on September 3, 2015 Permalink | Log in to Reply

        I’m with this guy ^ Complicated layouts in a single WYSIWYG field just feels wrong. Altho I recognize there’s a lot more to it than just the editor (do_shortcode(), widget fields etc.).

    • Aristeides Stathopoulos 11:33 pm on September 2, 2015 Permalink | Log in to Reply

      I love it!
      It was about time we use something more unique for shortcodes…

    • nick6352683 11:51 pm on September 2, 2015 Permalink | Log in to Reply

      Priorities core developers, priorities. With so many things to still fix and add to the core, you are going to spend time and energy on this, and for the lamest excuse for doing so? Who uses square brackets for quotations? Way to break millions of web sites, for nothing!

      • webaware 12:48 am on September 3, 2015 Permalink | Log in to Reply

        [I hate to pop your bubble but] many people use brackets for essentially parenthetical in-sentence comments. :)

    • Jon Brown 11:53 pm on September 2, 2015 Permalink | Log in to Reply

      Shortcode API, yay! This is an exciting proposal, but I’ve got to echo others that the proposed syntax looks like a disaster. I get it, but I can’t imagine users will. I get avoiding the sane syntax of handlebars, angular, C, etc… but do we really have to be _that_ different. I really hope there is a better way.

      On core updating old shortcodes. I’m sorry but no, just no. Don’t you dare go changing _my content_ on a WP update. Worse still is only planning on updating post_content and ignoring all the other places shortcodes show up. Custom Fields for one, but also in PHP files.

      I’d humbly suggest two significant change to this proposal (beyond finding better syntax).
      1. Don’t plan on actually dropping support for the old shortcodes. Do show deprecated notices, just don’t stop supporting the old syntax until WP 6.0. Of all the deprecated cruft I’d love to see dropped, this will never be one of them.
      2. Build a separate utility/plugin a la the WordPress XML importer that can update old shortcodes in a user controlled fashion. Bonus if it actually scans PHP files and identifies shortcodes there. This could then either bulk update, or step through shortcodes one by one for the super paranoid.

      Summary: Simpler Syntax, No real deprecation, Separate plugin for converting old shortcodes.

    • Alex Mills (Viper007Bond) 11:56 pm on September 2, 2015 Permalink | Log in to Reply

      Going to be… interesting migrating SyntaxHighlighter over to this. Maybe this is the motivation I need to finally finish my rewrite from scratch.

    • Peter Chester 12:44 am on September 3, 2015 Permalink | Log in to Reply

      I love clarity. I love easily parseable content. However, this seems like it’s destined to cause WordPress sites around the world to break. I’m sure we’ll see heaps of bare old shortcodes from this change.

      I’m not sure I understand why it’s a problem to check that a shortcode is actually a shortcode before trying to convert it. Why are we doing this?

      Also, I have a hard time teaching people the existing simple shortcode. I expect the error rate will be quite high for people with a more complicated new format.

      > Our old [ and ] delimiters were easily confused with the way those characters are commonly used in English quotations and sometimes even in URLs.

      What are some examples? I haven’t run into this at all in all my years of working with WordPress.

      • webaware 12:59 am on September 3, 2015 Permalink | Log in to Reply

        Very common to have brackets in quotes, to fill in implied references, like this:

        “I won’t be rushing out to get my daughters vaccinated [for cervical cancer], maybe that’s because I’m a cruel, callow, callous, heartless bastard but, look, I won’t be.” Tony Abbott, November 9th, 2006

        Also for excerpted quotes, like this:

        […] We shall go on to the end, we shall fight in France, we shall fight on the seas and oceans, we shall fight with growing confidence and growing strength in the air, we shall defend our Island, whatever the cost may be, we shall fight on the beaches, we shall fight on the landing grounds, we shall fight in the fields and in the streets, we shall fight in the hills; we shall never surrender [… continued]

        For URLs, consider that PHP only handles query parameters as arrays when the parameter name has [] or [key], and some URLs pass such parameters.

    • Greg Ross 12:47 am on September 3, 2015 Permalink | Log in to Reply

      I agree with many of the above comments about the syntax, it’s cumbersome and confusing.

      HTML seems to get by just fine with a single character for it’s delimiters and I see no reason a shortcode can’t as well. Perhaps square brackets are too common, fine let’s change to something else (curly brackets seem reasonable).

      And don’t reinvent the wheel, HTML already has a standard for self-closing and encapsulated tags ( and ) use the same format for shortcodes ( {shortcode /} and {shortcode} {/shortcode}).

      This would also allow both shortcode API’s to run side by side as plugin authors and content creators updated to the new format. Perhaps even make the new syntax a feature plugin for the next few releases until it is merged in to core and then move the old API out to a plugin for several more releases.

      The timeline seems far to aggressive, shortcodes were added way back in WP2.5 and how you want to yank out the old format in just three point releases? The amount of code and content that will require updating is significant.

      My final thought is about the assertion in the proposal that shortcodes *should* only do certain things (like not pass in html as attributes). Keep shortcodes flexible, don’t artificially limit them to certain things. While it may take more to support that flexibility, it would seem to have paid off greatly in the past looking at all the things people have done with them.

      • Ben Huson 4:11 pm on September 3, 2015 Permalink | Log in to Reply

        Completely agree on not re-inventing the wheel for self-closing and encapsulated tags. Stick with the same convention as HTML using the trailing/leading slash within the syntax.

    • Justin Tadlock 1:00 am on September 3, 2015 Permalink | Log in to Reply

      On syntax:

      Users know shortcodes. WP wasn’t the first system to have them. Anyone remember the old BBCodes?

      Open bracket. Type short tag. Close bracket. Simple. Intuitive. Hard to break if you’re not doing anything crazy. Let’s make sure this simplicity is at the core of any discussion on the topic.

      I’d pretty much put the [{{shortcode}}] syntax into the non-starter category. I could get behind {{shortcode}} if we must change syntax, but mixing and matching brackets is destined to fail.

      On updating:

      One thing to watch out for when auto-updating old shortcode syntax in the post content is those of us who output code examples, especially those of us who write in Markdown and don’t need to convert our [ and ].

    • Maxime Jobin 1:04 am on September 3, 2015 Permalink | Log in to Reply

      My main problem is understanding what real problem does it solve ?

      The proposed syntax is really confusing. Isn’t there a way to simply “improve” the actual syntax instead of changing it like this ?

      Also, wouldn’t it a good idea to abstract the concept in the editor. That would mean displaying a visual representation of the shortcode. I would see that as Facebook highlights someone you tag in a status/comment.

      But, that would mean “forcing” developers to specify expected/accepted attributes.

      Aren’t we ready for something more powerful than writing shortcodes ? For devs, it’s perfect. But for non-tech, it’s hard to understand and use. Changing that would mean a lot of confusion.

    • Justin Busa 1:07 am on September 3, 2015 Permalink | Log in to Reply

      If custom fields aren’t going to be migrated to the new syntax, then it would be nice if there was some sort of filter that would allow plugin developers to migrate fields themselves.

      Also, in terms of sites breaking, it would be nice if there was some sort of constant that would enable the old API. Reason being, lets say a site has shortcodes defined in the theme or is using do_shortcode in theme files. Enabling the old API would instantly fix the site while allowing the developer time to update the theme’s code.

    • Ipstenu (Mika Epstein) 1:18 am on September 3, 2015 Permalink | Log in to Reply

      My major concerns have been raised already but I’ll stress if from a different angle.

      If we learned anything from the shortcode change to secure them, we cannot keep breaking users sites. I know that we’re talking about a long term plan to possibly remove shortcodes as we know them by 4.7, but even with all the notification in the world, we will break sites.

      We have 3 releases of WP a year. 4.7 is 18 months away at the outside. That’s a lot of information to get out there really fast and really clearly, AND a lot of code to fix.

      We have to consider:

      • All the plugins and themes on the planet we will break (because we will, they won’t read or test). We have to degrade them as gracefully as humanly possibly. Continuing to say “Well the developers were notified and should have updated” now that we’re as big as we are is not sustainable.
      • All the very (legitimately) angry end users who are broken because they didn’t upgrade plugins and themes (or the themes/plugins didn’t get updated). People were rightly angry last time. It’s the end users, not the developers, who will be hardest hit by this change.
      • Communicating clearly to the users that it’s now {{gallery}}. That’s going to be very hard. Incredibly hard. Updating their old posts (keeping in mind Justin’s Markdown caveat and those who use them as an aside – I know I know) is easier than making sure everyone knows what to do. At best we can keep tabs on the ones built into WP and perhaps use the logic we have in the visual editor NOW to convert them, but we have to figure out how to make sure everyone knows. This is nothing like the move of Menus to customizer. That was confusing, but the users could see what happened. This is a legit change, your old way is no longer going to work. That is huge.
      • The number of users who have premium themes and plugins that do not get update alerts. These people are simply not going to know they need to update and this is not their fault. We should never be breaking them if there’s possibly any alternative.
      • Users will be upgraded by their hosts vis-a-vis one-click installs and managed hosting so they will have up to date WP and out of date plugins/themes. So yes, many users will be on 4.7 and then a theme from 2014. It sucks, it’s the reality, we know it’s the reality, we cannot stick our heads in the sand.
      • Plugins that are already using {{template}} tags in their code. Yeah, I’ve seen it. Most of them use it for search/replace within their own code, but we’ll want to make sure we check for everyone in the repo who might be doing it on their own.
      • Gabe Shackle 1:55 am on September 3, 2015 Permalink | Log in to Reply

        This sums up my feelings perfectly: “we cannot keep breaking users sites”

        Ending support for the current style of shortcode syntax within 18 months will absolutely break sites and frustrate end-users, site owners, and developers in a huge way.

        The best way to make developers stop using a platform is to force them to repeatedly have to retrain their clients and refactor their code.

    • Jean-Francois Arseneault 1:19 am on September 3, 2015 Permalink | Log in to Reply

      Clients, you know, the small business owers, who we train to use their site, and the 3-5 shortcodes they might need, already have a hard time understanding these “square brackets”.

      The draft I read seems to me like the start of “pleasing the machine, and not the human”

    • Luke Carbis 1:20 am on September 3, 2015 Permalink | Log in to Reply

      I’m concerned about client-brain-backward-compatibility. Any changes to the shortcode syntax should still work with my clients brain.

      For example, I provide my client with a site, and teach them to use [button] to insert a button. We finish our contract, and I am no longer in touch with them.

      First the client updates WordPress to 4.4. Nothing changes. Then 4.5. They’re in a production environment, so they don’t see the warnings. Then 4.6. They don’t happen review old posts / pages, but if they do, they don’t realise that their shortcodes have changed.

      Then the client updates to WordPress 4.7, but unlike me, they don’t read the Make WordPress Core blog. They don’t know about the changes. They don’t know that what they’ve learned has become deprecated and now unsupported.

      The client publishes a new page, and they put the button in the way they’ve been taught, which has always worked. But now, it doesn’t work. It’s broken. They call me.

      The client is now angry because a WordPress update cost them money, and confused because the new syntax is much harder to understand.

      I recognise that there are always changes to WordPress, and that the nature of incremental releases is that a user must learn to deal with change. But as far as I know, these changes have always been easy enough for a reasonable user to intuitively navigate. i.e. changes to the menu design, or updates to the nav menu UI.

      I have three questions:

      1. Has there ever been a change to WordPress which could not be intuitively learned by a reasonable user?

      2. Is it okay to introduce unintuitive changes to WordPress?

      3. How can we make this change intuitive to a reasonable user?

      • Luke Carbis 1:29 am on September 3, 2015 Permalink | Log in to Reply

        Here’s a suggestion to answer my third question.

        • When the user enters a shortcode (with either the [simple] or the [{{new}}] format), check if the shortcode exists.
        • If it does, replace the text shortcode with a GUI placeholder element
        • Also, behind the scenes (i.e. in the HTML editor), replace the [simple] shortcode with the [{{new}}] format

        The user experience doesn’t get worse – it gets better. My client enters a shortcode as they always have. They see a visual indicator to show that it was recognised and accepted. Behind the scenes, the new format is saved.

        • Weston Ruter 5:52 am on September 3, 2015 Permalink | Log in to Reply

          Yeah, if this new syntax goes in then GUI placeholders (TinyMCE views) are going to have to be the answer, which also seems like Shortcake.

    • webaware 1:30 am on September 3, 2015 Permalink | Log in to Reply

      Upon some further thought, I think that really there are two problems that are presented:

      1. brackets are already commonly used elsewhere, e.g. quotations, URLs with array parameters

      I see this as being a problem only when developers register shortcodes for real words. Using a sensible prefix for shortcodes prevents this. Unfortunately, there’s been a push for shortcode portability which directly undermines that, e.g. by recommending shortcodes like [product …] for products. [and of course, that prevents combining plugins with similar intent on the same site, but whatever…]

      Has it actually been a problem thus far? I imagine that anyone writing “blah-de-blah [product name] de-blah” will quickly discover that they should use parentheses instead if they don’t want to trigger the shop plugin they’ve installed. Content editors learn. They already have stuff they need to learn, and this is a very simple one that they learn pretty damned quickly anyhow.

      Is it necessary to strip “unregistered shortcodes” when we can just assume that they are part of normal sentence structure? So some websites will display the odd shortcode when its code [e.g. plugin] isn’t active; so what?

      2. self-closing shortcodes don’t look like they are self-closing until they don’t have a closing shortcode

      … which is easily resolved by demanding that they close with /] similarly to XML and HTML.

      To me, this is THE performance problem, and it is easily resolved by not allowing self-closing shortcodes without a terminating /].

      Now, bear in mind also that cleaning up old code might require changing content in:

      • wp_posts.post_content
      • wp_posts.post_excerpt (some plugins / themes use it for rich text)
      • wp_postmeta.meta_value
      • wp_usermeta.meta_value
      • custom tables
      • code (e.g. directly calling `do_shortcode(‘[product …]’);`

      And it has to take into account all sorts of edge cases.

      There’s only so much auto-upgrading that can be achieved. The changes proposed WILL BREAK WEBSITES. Even simply requiring self-closing shortcodes to have /] WILL BREAK WEBSITES. All I can see coming from this proposal is pain. “There will be a great gnashing of teeth” etc. :(

    • Jean-Francois Arseneault 1:47 am on September 3, 2015 Permalink | Log in to Reply

      Pardon the pink-colored glasses for a second, but why does it seem that our only choice moving forward, to improve the state of shortcodes, is to change *how* shortcodes work, and not *if* there isn’t a better / newer way to accomplish the goal of inserting content into a page ?

      In the spirit of seing the forest from the trees, why are we still trying to desperately manage mixed-source content using text-based shortcodes ?

      Why are we still using a paradigm where the main content area (if talking about posts) is still an area where we can add content, but also perform layout decisions *within* the content? Where’s the separation of concerns in this way of doing things?

      I think Page Builders are the start of a better solution for managing all these different contents within a page, but perhaps forcing plugin authors to expose their functionality into native widgets and ‘page builder elements’, vs letting them add shortcodes anywhere to render content might be an approach that is easier to grasp, from a UI perspective, for *end-users*.

      Sure, developers, integrators… we can handle everything you throw at us, but in the end, the sites are built for end users, for real-life applications and business purposes. End users are the ones that matter.

      Simplicity always wins.

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

        The Shortcake feature plugin covers providing a UI for shortcodes.
        https://wordpress.org/plugins/shortcode-ui/

      • Chris Van Patten 2:30 am on September 3, 2015 Permalink | Log in to Reply

        Although I’m generally in favour of this proposal, I think this merits some consideration too. Is there potentially a way to eliminate shortcodes — as in a manually entered bit of pseudo-tag-like code — altogether? I think Shortcake is an interesting approach, but it still depends on the shortcode API in the backend. What if shortcodes were deprecated, and replaced with an entirely new concept for inserting dynamic “chunks” of content that doesn’t fall back on parsing through plaintext?

        Replacing shortcodes is probably a much-longer term play, but it does mean that instead of patching the old they can be replaced with something newer, more flexible, and more in tune with the direction core has been moving already.

      • John Teague 1:53 pm on September 4, 2015 Permalink | Log in to Reply

        I totally agree. We need to be thinking of an intuitive replacement for shortcodes altogether. That provides incentives for developers and users to make the change.

        I really appreciate the hard work by @Robert Chapman and others putting a lot of effort into solving the increasingly unsustainable shortcode system. Sadly, I think the proposal in its current form, will confuse already error prone users, and likely break a lot of sites.

    • Chris Van Patten 2:36 am on September 3, 2015 Permalink | Log in to Reply

      As a supplement to my other comment (which was a nested reply), I’m generally in favour of this proposal. I think there’s merit in discussing completely new alternatives to shortcodes, but that’s a semi-separate issue.

      Like many others, I’m not sold on the suggested syntax, but it’s obviously still early days.

      One other thought: why not make escaped code the default, and make unescaped the exception with its own special syntax? Are there backcompat reasons that wouldn’t work? Seems like (potentially) an easy win for security.

    • Andrew Nacin 3:03 am on September 3, 2015 Permalink | Log in to Reply

      Thanks for your feedback, everyone. Developers, truly, honestly, really: Thank you for paying attention. I often feel that requests for comments usually fall on deaf ears, and I know I am not the only committer who feels that way. This has been one of the most substantial and productive threads on make/core I’ve seen, and it’s encouraging to see.

      Here are some thoughts on the proposal:

      • This was clearly labeled a “draft”. I am glad many of you noticed that this was not a decree, but a call for feedback. (And thank you again for obliging.)
      • The vision of shortcodes should be something like “it should be easy and intuitive for non-technical authors to embed and enrich their posts” (I have cribbed this from @matt).
      • This vision does not actually mean that shortcodes are the solution. I actually have a strong dislike for shortcodes. I think they are a terrible user experience, and that even something like Shortcake is still only a marginal improvement.
      • Some changes to shortcode parsing is absolutely necessary in order to keep WordPress secure. Yes, this is about security, not just general sanity.
      • The proposed syntax significantly clashes with the proposed vision. And given all of your feedback, we’re clearly going to have to go back to the drawing board. Please note that we still need to do something, but maybe we can think further outside the box.
      • And for goodness sake, PLEASE STOP RELYING ON HTML IN SHORTCODE ATTRIBUTES. This also does not align with the outlined vision, either, and it’s what largely precipitates proposals like these.
      • Thank you @miqrogroove for your incredibly hard work on this. Honestly, folks, many of you simply cannot see how much work Robert has poured into shortcodes over the last year, as it takes place in private security discussions. He’s been a tremendous asset to the project.

      I’m looking forward to future make/core threads getting this much high quality feedback. Now if only it can also carry over to more Trac tickets. 😀

      • Solinx 9:21 am on September 3, 2015 Permalink | Log in to Reply

        Thanks!

        “I’m looking forward to future make/core threads getting this much high quality feedback. Now if only it can also carry over to more Trac tickets.”

        I think this could be helped by making Trac more accessible and by providing a better overview of what is currently going on.

        1. Trac
        When I first heard of Trac I had to get there through google. The “Get Involved” page didn’t help at all. Why not add a link to both the tickets dashboard and the ‘next release’ tickets list at https://make.wordpress.org?

        And why not link to related tickets, github repo’s, slack groups, etc. at the bottom of these blog posts? That makes it a whole lot easier to get to the right places to get involved.

        2. Progress overview
        It is difficult to keep track of all that is going on. The blogs provide updates, but not an overview. Perhaps you could introduce something such as: http://dev.modern.ie/platform/status/adownloadattribute/

        Also here you could link to the related tickets, github, etc.

      • Nick Haskins 12:11 pm on September 3, 2015 Permalink | Log in to Reply

        “Now if only it can also carry over to more Trac tickets.”

        The problem with Trac, for me at least, is that it’s not part of my daily workflow. I’m a bit intimidated by Trac, not to mention making patches. I take part in conversations on Github all day, because that’s how we manage code and issues for my job. I suspect that if these conversations were on Github, with PR’s being allowed there would be a lot more participation. After all, I don’t know any developers outside of WordPress who use SVN in their workflow.

        • NateWr 2:08 pm on September 3, 2015 Permalink | Log in to Reply

          Thanks for outlining this response @nacin. I’d second thinking outside the box. I suspect a lot of the problematic uses of shortcodes stem from people trying to plug gaps in other kinds of functionality (layout, class assignment, conditionals). Maybe solving some of those problems would take a bit of heat off of shortcodes, and make them a smaller attack vector. Or maybe not. Can’t say I really understand the security implications of shortcodes.

        • John Teague 2:33 pm on September 3, 2015 Permalink | Log in to Reply

          Totally agree with you on this Nick. Think how moving to Git would invite solid developers to submit great fixes and features? It’s not that a lot of us can’t use Trac/SVN. It’s just who the hell wants to.

          • Helen Hou-Sandi 4:06 pm on September 3, 2015 Permalink | Log in to Reply

            I imagine that a lot of the workflow folks think of centers around GitHub and pull requests as opposed to Git itself, but just a note that there is a proper Git mirror that many people patch against, including a number of committers. https://make.wordpress.org/core/2014/01/15/git-mirrors-for-wordpress/

            • KalenJohnson 4:49 pm on September 3, 2015 Permalink

              Yes that’s very true, it is Github itself which has become such a boon for developers to be able to quickly and easily find issues, discuss them, and create pull requests. Trac seems very antiquated by comparison, and submitting patch files is not something the rest of the open source web development world does that I’ve seen.

              I can understand how large the move to Github would be for WP, but don’t underestimate that it could really remove WP from the silo it’s in and open up to better quality issues, more issue discussion (as Nacin is looking for), and possibly more patches as people are much more familiar and willing to make pull requests.

            • J.D. Grimes 6:15 pm on September 3, 2015 Permalink

              Yes, the workflow on Trac is needlessly complex. I’d +1 moving to GitHub, or something where we can have PRs instead of patches.

            • John Teague 1:58 pm on September 4, 2015 Permalink

              My bad. I meant github.

      • dlouwe 1:07 am on September 4, 2015 Permalink | Log in to Reply

        “This vision does not actually mean that shortcodes are the solution. I actually have a strong dislike for shortcodes. I think they are a terrible user experience, and that even something like Shortcake is still only a marginal improvement.”

        Very much this. Users shouldn’t have to learn syntax to make use of shortcode-like functionality. They can already use the Visual editor to insert and manipulate HTML without ever knowing what HTML is, and that should be a clear goal for whatever shortcodes end up being in the future. It doesn’t much matter what the new syntax looks like if the only people who are going to be editing it directly are people who have business doing so. As a developer, I don’t mind jumping through some extra hoops to make sure my users have an easy and intuitive experience!

      • raamdev 3:23 am on September 4, 2015 Permalink | Log in to Reply

        > The vision of shortcodes should be something like “it should be easy and intuitive for non-technical authors to embed and enrich their posts”

        I agree. That makes this a good time to redesign shortcodes from scratch, to rethink how we would create something that provides the same flexibility and power of the existing Shortcode API while also more accurately fulfilling the goal of being something that is “easy and intuitive for non-technical authors to embed and enrich their posts”.

        The ideas that came to mind while reading your comment were: Do shortcodes need to be something that is entirely configurable from within the post editor? What if they were instead something that pointed to a configuration, a configuration stored in the database that allowed a plugin or theme to determine what should be returned? (I’m thinking something like `[{{shortcode id=”plugin_slug_123″}}]`, i.e., something like a shortcode with a single attribute.)

        Then a new API could provide plugin and theme developers with a way of building a UI that would allow users to configure ‘shortcodes’ (the configuration being stored in the database, e.g., as `plugin_slug_123`), similar to the way the Plugin API allows plugins to register meta boxes for post types.

        My feeling is that creating something that is both easy and intuitive for non-technical users will require getting rid of syntax as much as possible and replacing that with a UI.

        Building a whole new feature to replace the Shortcode API would also make it easier to transition away from the current Shortcode API: Eventually WordPress Core could disable the old Shortcode API by default (allowing site owners to re-enable it, perhaps using an MU Plugin, with the knowledge that it’s no longer recommended) while plugin and theme developers could update their code to support the new feature (their motivation to do so will be that future versions of WordPress won’t have the old Shortcode API enabled).

    • markkaplun 5:48 am on September 3, 2015 Permalink | Log in to Reply

      [might not be needed after so many comments but…] I want to also voice my opinion against the proposed. I can see how software developer *might* be happy with this kind of syntax but this is very far from freely written text. The need to balance the number of braces is a no go, it is just too easy for my cat to erase one of them and making me waste an hour trying to figure out what is wrong because it will not look obvious. I actually don’t feel too strongly about the syntax of the complex variants, as they require some kind of programming state of mind, but the self closing one should be extremely simple.
      In addition, The use of the $ sign for anything in this context is ridiculous. In free written text it indicates some reference to money or value and the reason it used in regexp is because it is used in free text but rarely in programming.

      Proposals
      1. Whatever is the final syntax, syntax highlighting for shortcodes should be part of both the tinymce and the “text” editors. This will make it easier to identify shortcode and find broken ones.

      2. Since this will be such a big chagne, might as well fix [the lack of] permission checks. On a multi author site everyone can use all shortcodes. There is no reason why a contributor should be able to insert a contact form via a short code. Sure the editor is supposed to review and remove it, but there is no point in giving the ability in the first place.

    • umchal 6:21 am on September 3, 2015 Permalink | Log in to Reply

      The biggest problem of shortcodes from my view is that they remain in the posts even after the plugin which uses the shortcode gets uninstalled.

      I suggest using the HTML comment syntax.

      • HTML

      This way, users do not have to concern about removing them form the post. I suggested this a while back (https://wordpress.org/ideas/topic/commentcode-alternative-to-shortcode).

    • Florian Girardey 7:04 am on September 3, 2015 Permalink | Log in to Reply

      How can you possibly want to break a lot of websites with 4.7 with end of support of the current shortcode syntax and absolutely rejecting the idea of using a recent version of PHP…

      I like the idea of improvement and this roadmap is a good idea but i don’t understand the logic behind the WordPress team right now.

      • BrashRebel 12:43 pm on September 3, 2015 Permalink | Log in to Reply

        If you want to understand, read the whole discussion. In particular @nacin‘s comment https://make.wordpress.org/core/2015/09/02/shortcode-roadmap-draft-one/#comment-27484

        • Florian Girardey 5:51 pm on September 3, 2015 Permalink | Log in to Reply

          I understand why this roadmap is necessary and i absolutely agree.

          But the arguments advanced for such a changement are closely the same that a PHP version update, i don’t understand how the WordPress team can accept this roadmap but also refuse a PHP version update. That’s all

          • Ipstenu (Mika Epstein) 7:18 pm on September 3, 2015 Permalink | Log in to Reply

            While I understand the comparison, it’s a logical fallacy.

            A minimum requirement is just that. A minimum. WP’s minimum is PHP 5.2.4 and MySQL 5.0.15. We still say mod_rewrite is optional. Supporting older versions doesn’t make the codebase insecure in and of itself, and there is no external dependency update that can fix the current security issues with shortcodes.

            The point of this post is to ensure, when we do fix shortcodes, we do it in as graceful and as minimally intrusive a way as humanly possible. To not repeat the shortcode sins of the past. Your concern, while well meaning and valid, has a marked tendency to detract from that.

    • Cristian Antohe 7:10 am on September 3, 2015 Permalink | Log in to Reply

      We’re using Mustache template tags in both our plugins and I can tell you {{tag}} is in no way simpler then [tag]. Once you start adding {{!tag}} or {{^tag}} HTML {{/tag}} things start to go wrong fast. Users simply have a hard time understanding how that works.

      Start to mix up template brakes like [{{tag}}] and that’s just stupid. It’s un-intuitive and will give a lot of headaches to ALL plugin developers who also actively support their plugins.

      • Cristian Antohe 7:19 am on September 3, 2015 Permalink | Log in to Reply

        With these more unique delimeters, we will be able to process registered shortcodes more efficiently because we will not have to search for them by name. Unregistered shortcodes will have more consistency because we can find them more accurately.

        The new syntax is making it harder for users to use shortcodes for the sake of developers who have a hard time working around the constraints that come with using [tag].

    • leemon 7:25 am on September 3, 2015 Permalink | Log in to Reply

      Sorry to say this, but that new syntax is hideous. If this goes forward as it stands, I predict major breakages, lol

    • Mike Schinkel 8:08 am on September 3, 2015 Permalink | Log in to Reply

      Reviewed all the comments and did not see anyone suggest what @cfc suggested on @miqrogroove‘s blog post which just use Custom HTML Elements:

      http://www.miqrogroove.com/blog/2015/shortcode-v44/#comment-515

      They seem perfectly suited for this:

      http://w3c.github.io/webcomponents/spec/custom/#custom-element-lifecycle

      What would they look like?

      Old Shortcode: [foo]bar[/foo]

      New Shortcode: <wp-foo>bar</foo>

      One I saw that idea by @cfc everything else seemed like painful overkill. Besides, shortcodes are very closely aligned with the goal of the custom HTML element proposal with shortcodes being server-side and custom HTML element being client side.

      • Benny 5:56 pm on September 3, 2015 Permalink | Log in to Reply

        I like the idea of custom HTML elements / web components replacing shortcodes. But that still means we can’t phase out the old shortcode syntax because it would break so many sites. How would you suggest to solve that problem? Maybe by adding you’re “You are doing it wrong” notices (for ever)?

      • Michael Davis 10:53 pm on September 3, 2015 Permalink | Log in to Reply

        I hope this gets more discussion. Particularly, what would be potential shortcomings of this method compared to what the new syntax would bring.

      • Knut Sparhell 1:18 am on September 4, 2015 Permalink | Log in to Reply

        I like this idea of custom HTML elements. Registered elements gets executed either server-side or client-side. An advantage is that it’s quite obvious that such elements can’t be used in attribute values, and attributes can’t contain such elements.

        What has to be solved is the slow deprecation of the old shortcode syntax, and if old shortcodes should be replaced upon upgrade, at some point.

        I also look to the more tag and page tags, that are HTML comment tags. When shortcodes was first introduced I was surprised the HTML comment tag was not considered.

        Custom HTML elements seem very future proof, outright elegant, even if the draft never becomes a recommendation or they will never be supported by browsers (for the client side types).

      • webaware 11:09 pm on September 4, 2015 Permalink | Log in to Reply

        Much love. Was thinking about how NextGEN Gallery does its galleries these days (as a decorated image tag it parses out), but this sounds even better.

      • Braad 12:57 am on September 5, 2015 Permalink | Log in to Reply

        +1 for web components. Great idea Mike!

    • chrishoward 8:24 am on September 3, 2015 Permalink | Log in to Reply

      Sorry, I see these new syntax changes as ridiculous.

      The current syntax is untidy and cumbersome enough, and now you want to throw all these braces in it? We should be making shortcodes easier to use, not harder.

      Have you forgotten the user totally?

      These are great for coders. We love “mustaches” and parameters!

      But I pity the user having to key in a multiple-enclosured shortcode.

      Personally, I believe shortcodes should be invisible to the user, just as HTML is. Show the code in text mode, sure, but not in WYSIWYG. In WYSIWYG mode shortcodes should only be entered via a button and form, and then represented in full if possible (like the gallery shortcode) or by a clickable icon.

      For day-to-day users, this new syntax is a big step backwards.

    • asarosenberg 8:45 am on September 3, 2015 Permalink | Log in to Reply

      I agree with previous comments that this suggestion is very bad for users. People can understand shortcodes if they are somewhat familiar with HTML or online forums but the suggested syntax is unreadable to anyone who is not a programmer.

      An easier way to solve the problem with wanting to use brackets for other things is to allow people to escape brackets for example by ignoring brackets prefaced by backslash, star or whatever char that makes sense. If you want WordPress to be a CMS and not just a blog tool, shortcodes are more important than brackets in text.

      As for deprecation and conversion consider that there are shortcodes in meta fields. Many themes use page templates with multiple wp_editors and shortcodes. To avoid massive sudden breakage the old format should work for at least a year or two after the changes have been implemented and announced.

    • Arunas Liuiza 9:07 am on September 3, 2015 Permalink | Log in to Reply

      While I do get the technical reasoning behind this proposal, but I am really worried changes like that will soon make WordPress only usable for people with PhD in Computer Science. Seriously, I think something like 简shortcode简 would be easier to use and understand than the proposed syntax for the average WordPress *user*.

    • andreasnrb 9:27 am on September 3, 2015 Permalink | Log in to Reply

      The first thing I think that should be done before even touching or discussing syntax is to clearly define the purpose of shortcodes and come up with appropriate use cases.
      And just to ignore my first statement. Why not go in other direction and introduce custom HTML tags instead? You register your tag, what attributes it accepts with sanitation callbacks.
      <wp-button href=””>Click me</wp-button>
      register_tag(‘button’,array(‘href’=>’esc_url’))
      Even makes it possible to integrate with HTML5 custom tags later on.

      • andreasnrb 9:31 am on September 3, 2015 Permalink | Log in to Reply

        Yes I know it encodes when written in the HTML window. So it should be combined with a insert button in the menu.

    • HasinHayder 11:56 am on September 3, 2015 Permalink | Log in to Reply

      Now you need a Ph.D in CS to use WordPress :(

    • FolioVision 12:11 pm on September 3, 2015 Permalink | Log in to Reply

      I see that doing this will open new possibilities, but I think the basic shortcodes should stay without change:

      Self-Closing: [shortcode]
      Attributes: [shortcode attr1=”value1″ attr2=’value2′ “value3” ‘value4’ value5]
      Enclosing: [shortcode] HTML [/shortcode]
      Escaped Code: [[shortcode]]

      If you want to add more features (like nested shortcodes here), I think yout can do it without breaking too much stuff:

      Multiple Enclosures (this one should work if they could look for closing tag for [shortcode] – a regex won’t suffice though): [shortcode] HTML [encl2] HTML [encl3] HTML [/shortcode]

      I’m not sure about the rest though, but these special cases could probably use the new syntax:

      Stripped Unregistered Code: [{{randomthing}}]
      Stripped Unregistered Enclosure: [{{randomthing}$] Content also stripped. [${randomthing}}]
      Stripped Empty Code: [{{ }}]
      Ignored Orphan: [{{shortcode}$]
      Ignored Orphan: [${shortcode}}]
      Ignored Orphan: [${encl2}$]
      Ignored Context: [{{shortcode
      }}]
      Ignored Context:

      Do you see any issue with keeping the basic shortcodes unchanged?

    • jakeparis 12:46 pm on September 3, 2015 Permalink | Log in to Reply

      I think that the new syntax is difficult and burdensome to the average user. I would suggest:

      a) Make at least the basic “Self-Closing” shortcode operate without the brackers (just as it does now).
      b) The “Enclosing” style should close with a slash, not a $. There is not precedent for using a $ as a closer in any programming language that I know of — therefore that makes this difficult to remember. The slash it a much better choice.

    • J.D. Grimes 1:26 pm on September 3, 2015 Permalink | Log in to Reply

      I do not know how serious the security implications might be, but perhaps we could avoid removing the old syntax at all, and just disable it on new sites, like we’ve done with other deprecated features.

      I think the real lesson here though, is that shortcodes don’t need to be fixed, they need to be removed. We would still have to figure out how to maintain some amount of backward compatibility for old sites, but it might be more productive to work on a broader roadmap that would actually make shortcodes obsolete. Others, including @nacin, have hinted at this. Is a syntax overhaul really necessary as an intermediate step? Is it even plausible as an intermediate step? What if instead we approached it like this:

      1. Bring Shortcake (or some other “shortcode UI”) into core. This would still use the shortcode API, but would provide a UI for it so the user never has to directly manipulate the shortcode string.
      2. Start using an alternate, secure method of indicating the insertion points of the different content bits when this UI is used.
      3. Disable the shortcode API on new sites.
      4. Let the old sites get slowly broken and hacked over time, or break them ourselves all at once with an update.

    • JakePT 2:28 pm on September 3, 2015 Permalink | Log in to Reply

      I’ve got a couple of things I want to say. Firstly, I really need clarification on what these security issues with Shortcodes are. I read the post on the 4.2.3 change and it didn’t really help. Maybe it’s because it’s happening in an area of WordPress development that I just haven’t stepped into, but I’m having trouble understanding what contexts Shortcodes are a problem in. Isn’t their output defined by the plugin? Why isn’t the security problem with the *plugin*? Aren’t authors the only ones who can use them anyway? What could they do with them that’s so bad? I’m having trouble accepting such a drastic proposal when it doesn’t come with a clear rationale.

      But my biggest problem by *far* is that this would be so so so much easier to swallow if there was *any vision at all* for the future of the content editor. A single TinyMCE field just doesn’t cut it anymore. What happened to the content blocks idea that came up around 3.8/3.9? WordPress needs to address the problem of editing and creating more complex layouts, not breaking functionality that is only being abused because of this lack of vision and progress.

      Shortcodes suck, but don’t make them suck more without something better to replace them.

    • Stefano Aglietti 3:02 pm on September 3, 2015 Permalink | Log in to Reply

      I don’t know if someone already rised the question, but apart that making shortcode delimiter like the ones propose make user in a complicated situation.

      Maybe english people don’ìt know that { and } are not present in alla keyboards directly as the [ and ] are, in Italian keyboard [ and ] are generated using ALT-GR+è or ALT-GR++ and keyboards show ALT-GR basic sign like €@## and [ ].

      To get { and } you net to type ALT-GR+SHIFT+è and ALT-GR+SHIFT++. Most people don’t know about this combination (i think only who write code does) and the parentesys are not written on any key.

      This change would be a a really complication for italian users and i supect a lot of non english keyboard suffer from the same problem. Please when you think to change something like this for end users, use ALWAYS the KISS Method, [{{ is not KISS at alli suggest adding after the square bracket somthig that is awailable on alla keyboards like ! or ? or % or & but for sure nothing is really hide in system and that 99% of people ignore that existes or how to get it leke curly braces

    • Curtiss Grymala 3:04 pm on September 3, 2015 Permalink | Log in to Reply

      First of all, let me say “Thank you” for beginning the process of thinking about this issue.

      As we begin to move forward, has anyone thought about trying to identify where & how shortcodes are currently used, then trying to come up with the best solution for each of those situations? Maybe a shortcode isn’t the best solution for all of the situations in which it’s being used; it’s just the only viable solution we’ve had up until now.

      The bottom-line is, we are still going to need placeholders of some sort within WordPress. There are perfectly reasonable uses of placeholders, regardless of the syntax they use.

      Some are within HTML tags, such as <div class=”[my-custom-class extras=’one-third first’]”> or <img src=”[some-img-url]” alt=”This is my awesome image”/> or <a href=”[my-home-page]” title=”Return to [my-site-name]”>. There are perfectly valid & viable reasons to need to use some sort of placeholder inside of HTML (even if it’s not necessarily inside of the Visual Editor). If we stop allowing these sorts of things, then we’re going to end up with more plugins implementing silly things like [custom-html tag="a" href="{{home-page}}" title="Return to {{site-name}}"]Go Home[/custom-html] which will introduce potentially even bigger security issues and more usability issues for the users.

      Some stand on their own, such as We currently have [number-of-users] users on the site.

      Some output HTML, such as .

      Some are, IMHO, poor attempts to get around security restrictions in the editor, such as [iframe] (there are many plugins that implement this, by basically allowing the editor to enter an HTML tag in normal syntax, but replacing the < and > with square brackets).

      Some need to be nested in order to work properly, such as something like:
      [accordion]
      [accordion-title]My accordion item title[/accordion-title]
      [accordion-content]Some content to appear within the accordion item[/accordion-content]
      [/accordion]

      Some are also completely related to formatting the content, attempting to “fix” the problem of only having one content area, and trying to keep editors from needing to enter HTML on their own, such as the various implementations of column shortcodes (this is a very similar reason that implementations like the accordion shortcodes above exist, as well).

      There are many more perfectly valid & useful implementations of the current shortcode API.

      Each of these may have a completely different and much better solution than the others.

      Finally, as WordPress has evolved very, very far from a simple blogging platform, we need to stop thinking that post titles and post content are the only features that people are using.

      There are plenty of places where shortcodes might appear within the Options table, possibly even inside of serialized data. For instance, shortcodes could, potentially be used within widgets or theme options.

      Shortcodes could absolutely be used, within plain-text or serialized data, within the postmeta table (there are a ton of places that custom fields on a post could include shortcodes) or possibly even the usermeta table.

      The problem I see with the original discussion we had after 4.2.3, and the problem I see with some of the comments on this post, are that there still seem to be people saying “You shouldn’t have used shortcodes to do that; that was stupid, so it doesn’t matter if we break them.”

      The thing I appreciate about this original post, regardless of the fact that the proposed solutions are certainly more complicated than they should be, is that the core team is back to at least trying to solve the issue rather than continuing to feel like it’s okay to break sites just because they disagree with the use-case.

      Again, though, I want to thank @miqrogroove for bringing this to the table and beginning the process of trying to move forward.

    • Stanislav Khromov 5:01 pm on September 3, 2015 Permalink | Log in to Reply

      I’d like to echo the dismay most people feel with this proposed roadmap, and also stress that this can cause a fragmentation in the WP ecosystem.

      Consider that it’s easier than ever to not keep WordPress up to date with the latest version – security patches are backported all the way back to 3.7 and minor security fixes get applied automatically.

      By introducing big, “scary” changes that people feel uneasy about (which the comments prove include even seasoned developers), many will just not update. Consider the kind of fragmentation Python faced after they introduced syntax changes in version 3. Most people just didn’t want or need these changes. I feel the same way about this proposed roadmap.

    • Grant Palin 5:07 pm on September 3, 2015 Permalink | Log in to Reply

      One other gripe I have with the current shortcode syntax is that it sometimes confuses Markdown. Particularly when using within posts authored using WP-Markdown plugin. There’s a workaround, but still.

    • Jacob Santos 8:59 pm on September 3, 2015 Permalink | Log in to Reply

      Why was shortcodes added and what problem did they attempt to solve? What was their original purpose?

      The reason it is a bad idea is that it neglects the reason shortcodes were created and why they have the syntax they do. The history for the most part, I believe, was based in part on BBCode. If Handlebars existed and was more popular, then who knows.

      You will always have a security issue. Tough, but true. Introducing a wholly obtuse syntax will not change that and will make it more difficult for users and developers. Most likely you will just see an influx of plugins that put back the same behavior or those who move away from shortcodes altogether. It will also be a slap in the face once another security flaw is discovered.

      Unless you wish to remove the security issue by pushing people away from using shortcodes completely or creating their own solutions of various quality for security.

      The timeline is far too short. If you go back as far as 3.7, then you must follow that pattern. Deprecate it and update it if you can, but you must support the current until 2018 or 2 years after 4.4 is released.

      • Jacob Santos 9:06 pm on September 3, 2015 Permalink | Log in to Reply

        Lest my argument be misconstrued; I am saying that any syntax change is a bad idea. Solve the security problems with the current or work around them. The bed is made, you have to deal with it.

        Biggest problem I have is that it looks like you are creating a new template engine. There are already those that exist. It would be better if you used them as several have already been audited by security professionals or could be audited by security professionals. They also have a community and those that support it outside of WordPress.

        If you are going to introduce a template engine to WordPress posts, which in and of itself is charge to be warily, you are better off going with something developed by professionals.

        Shortcodes were supposed to be an easy replacement for plugins without a lot of features. When did it become the end all, be all to implement a feature?

        If anything, the RFC should formally suggest where shortcodes should and should not be used, deprecate those usages and at a later date, remove support for them. If advanced templating is required, move to an actual established templating engine. Oh my god, I can’t believe I’m writing this.

        I must be in shock, because the horror of this is just beyond comprehension. I can’t imagine the discussions or the problems that lead to, “hey, why don’t we create a template engine for posts?”

        I have to conclude that this is an early or late April Fool’s joke.

    • chriscct7 2:44 am on September 4, 2015 Permalink | Log in to Reply

      As an update, the team working on the Shortcodes Roadmap, has been working on a new draft proposal which will be posted to make at some point in the near future, which is significantly different than Draft 1. Also, there will be a weekly meeting that will be announced during the same post.

      • John Teague 2:10 pm on September 4, 2015 Permalink | Log in to Reply

        Thank you Chris. And to everyone working to find a solution on this. Hope people realize how much time and effort has to go into this.

  • Simon Wheatley 4:43 pm on June 29, 2015 Permalink |
    Tags: , ,   

    WordCamp Europe 2015 – Multilingual Discussion 

    Discussers:

    Drupal Multilingual Overview

    Christian López Espínola is a Drupal contributor to the multi-language features in that project, and gave us this overview of the multi-language features in Drupal 7 and upcoming in Drupal 8:

    In Drupal we have different modules bundled with core. The language module was added in Drupal 7, which gives support for assigning languages to content. Drupal already had Interface translation support as WordPress does.

    Drupal 8 adds content translation, with a UI.

    At first the problem was that there are two different strategies for doing this. Drupal 7 gave support for translating a node by creating copies; having multiple posts for one piece of content. This made it hard to select the content required for display in case other modules were not aware of or not interested in multilingual support. Moved to translations to the field level, so stored in the equivalent of post meta. One content node now contains all the translations, so fields attached to the node have translations of the title, content, etc, into all languages if those fields are translatable, this way content is not duplicated (i.e. fields are not duplicated between nodes if they are not translatable).

    Q: How does Drupal connect languages into groups of translations of one piece of content.
    A: If one post is a translation of another, there is a field which links it. D7 two nodes. D8 has one node, and translated content is stored in fields (with language attribute).

    Q: What issues did the adding of content language cause?
    A: At some level we had two different posts, one for each language. So if your plugin doesn’t consider internationalisation, then this causes issues because you are considering translations different content, and mix languages in the UI. For example if we want to rate a post from a rating plugin, we may want the rating to be “shared” between all translations of that content.

    Some Approaches to Attributing Language to Content

    We looked at just a few multi-lingual plugins, to see how they addressed the issue of storing language content.

    <caveat>This is by no means an exhaustive list, and only reflects the solutions that the people in the discussion have had experience with :) Please feel free to add other examples or corrections in the comments.</caveat>

    • WPML table structures – to attempt to synthesise this link: each translated content object is stored as a post, and a WPML database table links the content into groups and specifies the language of each content object.
    • Babble puts each the translation for each content object into a custom post type or custom taxonomy, e.g. `post`, `post_fr_fr`, `post_pt_pt`, and uses a taxonomy to group translated content objects together, so you can say “this post is a translation of this other post”. A disadvantage of this approach is that translated content does not have an expected post type, e.g. post, but instead a Babble translation post type, e.g. `post_pt_pt`.
    • Multilingual Press stores content from each language in a separate site in a WordPress multisite. There is a database table which links translated content across sites.
    • Polylang does not create any additional database tables at all. It creates 4 taxonomies: `language`(to hold all the languages you configured), `term_language` (the terms in each language ex. EN: Uncategorized, DE: Allgemein), `term_translations`(connects the translated terms in each languages) `post_translations` (connects translated posts). The plugins seems to be fairly lightweight compared to others and works well with many additional plugins too.

    Proposals

    There are lots of varied issues which multi-language, translation, and/or localisation plugins and projects seek to solve. WordPress core should not provide a translation or localisation UI and/or workflow, we should continue to rely on the plugin space to address different user scenarios.

    We do believe that there are some things which core could provide which would facilitate translation in the ecosystem for this type of plugin.

    Proposal one: core could provide a minimal way to mark content (e.g. posts, terms) as a particular language.

    • In the simplest case, a single language site, all posts would be implicitly assumed to be in the selected front end language for that site.
    • When a translation/localisation plugin is added, the plugin has the duty to set the language for each piece of content (post, term, etc).
    • If this shipped, it would be, by design, “invisible functionality”, and an example plugin would be useful.
    • How would this affect the WordPress exporter and the importer? The translation/localisation plugin would have the duty to add any UI to the importer/exporter, and core would need to provide the necessary hooks, etc.
    • Should we consider special locales like “no language” and “unknown language” (Drupal does this)? Perhaps core specifies these “locales” as a standard, but doesn’t use it.
    • This might be implemented as an additional column on the `wp_posts`and `wp_terms`tables, with associated post and taxonomy API additions and enhancements, which is available for plugins to use.

    Proposal two: core could provide a method or standard for translating strings stored in content objects like widgets

    In some contexts it is hard for a translation or localisation plugin to know what requires translation, e.g. in widgets when the data is stored in a blob in the database. It would be useful if core provided a pattern for others to follow to mark particular strings of text as translatable.

    Taking the example of a plugin providing a text widget, with user editable title and body fields, this plugin could follow the same standard to make these strings available to translation plugins. A possible implementation might be a filter or set of filters to pass the string for translation, and perhaps also the nature of the string to give a hint for the translation UI required, e.g. “rich text” (perhaps the translation plugin would provide a TinyMCE instance), “plain text” (perhaps a simple text area), etc.

    Other things discussed:

    • Setting the admin area language differently to the front end language, including showing the admin bar in the admin area language – being addressed in #26511
    • Supporting variants on locale, e.g. Portuguese informal, as these cannot be defined within the ISO standard currently – being addressed in #28303
     
    • dejudicibus 4:57 pm on June 29, 2015 Permalink | Log in to Reply

      You forgot to mention QTranslate X, one of the best fre plugin for multi-language sites.

      • jennybeaumont 5:01 pm on June 29, 2015 Permalink | Log in to Reply

        As Simon states above, this is not an exhaustive list, but simply the plugins that were discussed by (because used by) those who attended this meeting.

      • Simon Wheatley 5:11 pm on June 29, 2015 Permalink | Log in to Reply

        If you have knowledge of how QTranslate X stores and manages translations, please do add those details here.

        • MSTannu 7:51 am on June 30, 2015 Permalink | Log in to Reply

          The qTranslate family of plugins store multilingual content in the same database field, wrapped in special markup to differentiate each language. While this seems like extra work to pull content in all languages every time, in practise it’s considerably faster than queries with increased complexity to link different fields / tables to language information stored elsewhere.

        • Mike Manger 9:17 am on June 30, 2015 Permalink | Log in to Reply

          It stores all the language content in the post content areas with wrappers for each language (e.g. [:en]Title[:fr]Titre[:]). It has hooks to filter the content and return the requested language. There is no interface for widget support (although you can manually use the tags).

          Not a very clean implementation but I do like the tab interface for changing language.

    • Pascal Birchler 5:12 pm on June 29, 2015 Permalink | Log in to Reply

      As this is a very complex topic where we need to consider lots of details and exceptions, I suggest starting a working group with weekly meetings etc. I’m very willing to help out.

      • Nick Weisser 10:59 am on June 30, 2015 Permalink | Log in to Reply

        +1

      • Simon Wheatley 10:11 am on July 1, 2015 Permalink | Log in to Reply

        @swissspidy This sounds good to me. I am free in the evenings on Monday and Thursday, EU hours, or during the day, EU time, most days. No time is good for all the world, but evening might be better?

        • Silvan Hagen 12:34 pm on July 2, 2015 Permalink | Log in to Reply

          Same here, could do Monday or usually during the day in the afternoon. Would love to put this into a working group.

          • Simon Wheatley 11:48 am on July 8, 2015 Permalink | Log in to Reply

            Sounds like Monday afternoon or evening, EU time, is a good option. I’m going to suggest we start the week after next (20th July), purely because I want to be there but I’m away next Monday. :)

            I’ll see what Slack channel we can find for these weekly conversations, and report back.

    • wycks 5:19 pm on June 29, 2015 Permalink | Log in to Reply

      You should really engage the folks over at WPML and Multilingual Press (Toscho), once you get into the details lots of little problems crop up, for example this has been bounced around for years and is a big pain for multi-lingual sites: https://core.trac.wordpress.org/ticket/18962

      At the end of the day if WP can help define relationships between content (taxonomy, posts, etc) it would go a long way to facilitate the already available plugins and other non translation plugins being able to work with complex content.

      • Francesco Di Candia 5:23 pm on June 29, 2015 Permalink | Log in to Reply

        +1

      • Misamee 6:17 am on June 30, 2015 Permalink | Log in to Reply

        @wycks, WPML is already engaged.
        Unfortunately, due to flight schedules, we couldn’t manage to attend the contributors day, but the day before we did share already some thoughts with Simon.

      • Frank Bueltge 12:22 pm on June 30, 2015 Permalink | Log in to Reply

        We (Inpsyde Company an the MLP team, include @ocean90 ) will help. We discuss the topic very often, also on contributor days. Our MultilingualPress is a result, dev and and maintain since 2007. But always with focus solid, stable, fast, no changes on core or content tables. I’m willing to help.
        Import for me is, that the WP core should provide the foundation/data, plugins should provide the details/UI.

      • Simon Wheatley 10:22 am on July 1, 2015 Permalink | Log in to Reply

        @wycks Thanks for the ticket reference.

        Everyone is welcome to contribute. :) As @bueltge says, Multilingual Press are involved. Robert (@nullbytes), who is a colleague of @toscho, was in the discussions at WCEU. The second proposal builds on a conversation with @amirhelzer and @sciamannikoo from WPML on Saturday at WCEU, and it was good to get their input.

        Regarding relationships and groupings: core already supports grouping posts and terms via taxonomies (e.g. to group all the translations of one post together), and this seems (to me) to be sufficient to the requirement here. Further, the taxonomy roadmap (update post) may offer a different way of linking posts together in the future, providing another route plugins could take advantage of.

        /cc @francescodicandia @paddyullrich

    • Michel - xiligroup dev 6:13 pm on June 29, 2015 Permalink | Log in to Reply

      Just to contribute in this multilingual context (well known and studied since 2009), before I will translate them in english, please find below two links to short recent articles.

      As data-designer, the very first thing to consider is to choose a monosite (standalone) WP install and a multisite (network) install. Secondly the main thing, in each type of install, is to consider standards so each developer can decide what type of plugin (easy to use for newbies or flexible full customizable for developer). In previous WordCamp in Paris and Lyon, I have done some analysis… and solution is not unique…

      http://2015.extend.xiligroup.org/fr/471/mise-en-garde-sur-les-extensions-pour-creer-un-site-web-wordpress-multilingue/

      http://2014.extend.xiligroup.org/fr/1998/wordpress-monosite-multilingue-cahier-des-charges-possible/

    • Matt Mullenweg 7:42 pm on June 29, 2015 Permalink | Log in to Reply

      Both proposals seem to assume that core should do something and this is no longer plugin territory. I haven’t seen anything yet that makes the case definitively for that.

      • nikolov.tmw 10:46 pm on June 29, 2015 Permalink | Log in to Reply

        Well, I guess there’s also the possibility of creating a working group that would be given the task of coming up with a proposal and then standard for how plugins should handle the content to language/locale association. This can be created as a feature plugin and if there’s an obvious benefit it could land in core in the future.
        In any case, having a standard way of creating that would be a great benefit in terms of plugins being compatible with each other and switching from one to the other would be a painless transition.

        It’d definitely be interesting to see if we can figure out how many sites actually use more than one language(although there are also those sites that don’t use a plugin, but instead just create separate sites for each locale).

      • Caspar 4:32 am on June 30, 2015 Permalink | Log in to Reply

        Both proposals do in fact assume this should continue to be plugin territory and core should do something about it in order to provide basic means of production.

        • Frank Klein 1:09 pm on June 30, 2015 Permalink | Log in to Reply

          That’s my understanding from reading the write up as well. It’s about Core being conscious of the existence of multilingual plugins, and accommodating them as much as possible.

      • Pascal Birchler 1:26 pm on July 1, 2015 Permalink | Log in to Reply

        Both proposals do in fact assume this should continue to be plugin territory and core should do something about it in order to provide basic means of production.

        The same was done with the REST API for example, where lots of new functions were introduced in WordPress to better support it. And core definitely needs better support for multilingual content.

      • Silvan Hagen 12:47 pm on July 2, 2015 Permalink | Log in to Reply

        In my opinion core should at least be aware of the language the content is written in and therefore provide some form of support towards storing the language of any type of content within core (all post types, taxonomies, widgets, user meta could be plugin stuff as it’s handled differently with different multilingual solutions).

        The problem with multilingual stuff in general is that not only does it add a huge layer of complexity to the solution, but also to the people using it (editors for example). For example Typo3 has multilingual baked into core and sadly it’s tied to a main language tree, so let’s say you have English as your main language and French as a secondary language, you can’t create content that is only available in French as languages are tied to the tree of pages for the main language.

        So for WordPress it’s clear that if we get some basic support in core, the means for translating the content and how to do it needs to stay plugin territory. For example I know sites where they display comments from all languages on translated posts and use basic machine translation for it. Others have a singular discussion stream per language and post. User meta for example is dealt with differently, if your site has a content team per language, the author bio doesn’t need translation and will be filled in the language the specific author is writing for, but if an author gets translations for their posts, a plugin needs to handle translations for the user meta.

        Here are some thing that could use basic support in core to make it easier:

        • Portability and content migration
        • Best practices and easy transition between multilingual plugins
        • Simple API in core to allow plugins to be aware of multilingual content

        We are far from a solution for this, that’s why I’m in favour of forming a working group for the topic as I think this is something that needs a lot of testing and experiments before a bullet proof minimal solution would be possible at all.

      • Simon Wheatley 3:02 pm on July 3, 2015 Permalink | Log in to Reply

        @matt Neither proposal intends to move the problem out of plugin territory; we are proposing that core provides some additional or enhanced APIs, and that core leads with some new hook standards or patterns. Plugins would still provide the UI and workflow, and would address different use cases. Any additions to core would be designed to make it easier for plugin authors (and ultimately better for users). We would obviously want to ensure that any changes do not break existing solutions, other plugins, or user sites, as is The WordPress Way.

        In relation to the first proposal, for core to provide a way to mark a post as in a particular locale: to my mind, all the approaches used by plugins described so far in this post and the comments have drawbacks. There is work required to integrate with other plugins. There are additional queries or query complexity. For me, ideally, adding multiple languages to a WordPress install should have little performance impact, and should not cause the need for workarounds with other plugins; currently this is not the case.

        • Matt Mullenweg 5:22 pm on July 3, 2015 Permalink | Log in to Reply

          But at least with a pure-plugin (no core changes) approach the added complexity and overhead of queries is only borne by sites running that plugin, not every user regardless of whether they’re multilingual or not.

          • Frank Klein 5:32 pm on July 5, 2015 Permalink | Log in to Reply

            So far I’ve seen no precise architecture proposal, or even code.

            Yet we’re dismissing the proposal outright for some vague fear that this might be too complex or not performant enough?

          • Benny 3:48 am on July 15, 2015 Permalink | Log in to Reply

            I guess for most of us living in a country where it’s natural to have sites with multilingual content it’s a no brainer that the content language should be a core field of any database table that stores content.

            On the other hand I can understand that someone who only has to deal with single language sites is not eager to see core to become multilingual when that means more complexity/overhead for common queries. But that same argument is also true for us who have to deal with the daily fact of sites being naturally multilingual, the sites of our clients, just like non-multilingual sites, should also function with a minimum of complexity/overhead.

            Maybe this difference in point of view can be overcome by introducing an core option or wp-config setting ‘IS_MULTILINGUAL’ and an related API conditional $is_multilingual.

            Core queries would then only execute the somewhat more expensive multilingual variant of a query (i.e. with an added WHERE language = %s clause/clauses) of any core query when the $is_multilingual query is set to true.

            To make these ml queries as fast as possible (i.e. no extra JOINs) we should concider to add a language field to any relevant table. This would bring the fastest possible solutions to both single language sites AND multilingual sites!

            I know you are not keen on db schema changes but I think the language column on relevant tables makes perfect sense.

            The user interfaces side of this could stay in the plug-in territory.

      • FolioVision 1:43 pm on July 9, 2015 Permalink | Log in to Reply

        Matt, may I remind you about the socio-economic phenomenon called Globalisation? I know Americans tend to hang out in monolingual environments but here in Europe almost every website needs to be bilingual at least. A bog-standard example would be a site like Czech computer vendor Alza.com which comes in Slovak, Czech and English. Our European issues with multilingual extend to Canada (French, English), China (Cantonese, Mandarin), much of South America (Spanish, Portugese for sites which traverse more than one territory). English speaking monolingual territories are a tiny minority (USA, England). Among other large nations, Russia is a similar monolingual environment but even Ukraine needs two languages on most websites. France, Germany and Holland most often want their native language with an English option.

        Leaving multilingual in plugin territory means there is no standardised solution to accelerate multilingual development. Every time one takes on a multilingual site one is reinventing the wheel. I’ll grant you Google’s games going back and with with ranking and demoting content on subdomains and Google’s confusion about multilingual articles on the same domain do not help at all with standardisation. Still many of the SEO bonuses and penalties for different languages on one site have been retired now.

        Plugins should be ENHANCING multilingual, not building it from scratch. At the very least, WordPress.org should add all the key building blocks. I would suggest you talk to the three or four top multilingual plugin authors, whether WPML and Polylang and ask them what additional syntax they would like to see in core to make their plugins faster, lighter and more reliable.

        Again just improving core support for multilingual is still a second best solution. Basic, reliable multilingual should really be in core.

    • Alvaro Gois dos Santos 2:40 pm on July 2, 2015 Permalink | Log in to Reply

      First of all, let me congratulate @simonwheatley and all who were involved in the discussions we had in Seville regarding this subject.

      I second the notion that giving core the ability to identify content language could eventually be useful to all multilingual plugins and, hopefully, to make the switch between them easier. In a way, it would give the infrastructure, plugins would do the rest, UI included. It would also account for different approaches and I guess all the work that has been put into this solutions wouldn’t be lost.

      Another discussion is about locales and variations. Several locales have variations that, for now, WordPress doesn’t recognise. This makes it hard (if not impossible) for the common user to change his language variation from the default to a different one, even if it’s included in GlotPress. For instance: in Portugal (pt_PT) we have three versions, default (formal), informal and the Ortographic Reform version (not yet in GlotPress). We’ve tried to make it easy for the user with our PT Variants plugin, but I’m certain there could/should be a more efficient approach.

      • Simon Wheatley 11:03 pm on July 3, 2015 Permalink | Log in to Reply

        @alvarogois I believe the locale variants, e.g. Portuguese formal/informal, is being looked at actively in ticket #28303 :)

        • Alvaro Gois dos Santos 11:07 am on July 6, 2015 Permalink | Log in to Reply

          Thank you @simonwheatley, and thank you @ocean90 for being so active on this. I was not aware that we were so close 😉

        • Alvaro Gois dos Santos 4:27 pm on July 7, 2015 Permalink | Log in to Reply

          Hi again @simonwheatley: I’m having this idea about variants and managing variants translation through GlotPress, I’m not really sure where I should post it or if it has something to do with this discussion.

          Anyway, my idea (regarding GlotPress) is this: some variants are very close to the default language, only some of the strings actually differ, at least in Portuguese. I’m thinking of the formal vs. informal but also the orthographic differences like our own pre and post Orthographic Reform. There should be a way, in GlotPress, to link variants to the default translation. This would allow to have only one translation flow, and changes to be simultaneous in all variants. Now we have different flows, which makes it inefficient.

    • Vadym Volos 3:01 pm on July 7, 2015 Permalink | Log in to Reply

      I did not understand what the problem is?
      See how it is implemented on this engine: opencart.com

      You can take as a basis the plugin Polylang.

      • FolioVision 8:33 pm on July 14, 2015 Permalink | Log in to Reply

        I’m with you Vadym. Polylang would be a very good start. It’s lightweight clean code, the best of the current solutions.

    • Vadym Volos 3:17 pm on July 7, 2015 Permalink | Log in to Reply

      When you do language support.
      Should work plugin “Page Builder by SiteOrigin” (https://wordpress.org/plugins/siteorigin-panels/)
      This ingenious plug! It helps make any page.

      Then I wrote about it: https://wordpress.org/support/topic/page-builder-by-siteorigin-only-works-for-one-language?replies=16

    • Benjamin Lupu 10:28 am on August 10, 2015 Permalink | Log in to Reply

      First thank you for addressing this painful issue. I am still surprised that WordPress doesn’t provide a minimal multilingual support. I am working with since 2008 and at every project, it’s a problem. I also hear complains at every WordCamp (and not only French). There’s a huge need for that! IMO it could be a huge competitive advantage for WordPress providing a way its users to expand their businesses and publish globally. It would be also a selling point for enterprises. This is one of the first question asked when selling WordPress to an enterprises. I totally agree with what have been said earlier in this thread: we have to go further than an API and provide a minimal ready to use UI. It’s also a good idea

      • Benjamin Lupu 10:32 am on August 10, 2015 Permalink | Log in to Reply

        Shot too fast… So it’s also a good idea to be able to activate the multilingual in the wp-config settings. Anyway, correctly addressing the multilingual issue in WordPress would be a huge improvement and a sign that WordPress is really going global.

  • Pascal Birchler 6:28 pm on October 15, 2014 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Hi everyone!

    It’s time for WordPress Core Weekly (formerly known as Last Week in WordPress Core) again! There have been suggestions to change the name of these summary posts to stop confusions about being the last week of WordPress.

    This updates covers all commits since last week up to today, October 15th. There has been much progress this week with lots of improvements to the WP_*_Query classes, fixes in the admin and of course the introduction of the Twenty Fifteen theme! The complete summary:

    Admin

    • Add missing labels to category filter dropdowns. [29870] [29871] #29921
    • Differentiate between invalid and missing admin emails when adding a new site [29877] #17890
    • Multisite: Do not send a welcome notification when noconfirmation has been flagged [29880] #16235
    • Admin menu: [29898] #29806
      • Fix pinning after resizing the window.
      • Merge the two DOM ready callbacks in common.js
      • Fix the submenus position adjustment on focus.

    Editor

    • TinyMCE: fix the ‘wpgallery’ plugin to use a placeholder for galleries when either the ‘wpview’ plugin or wp.mce is not loaded. [29883] #28756
    • Quicktags: move focusing the editor after inserting content to the end of the code blocks. [29884] #29944
    • Editor-expand: reset the editor height after the window is resized. [29886] #29952

    Customizer

    • Change instances of “Theme Customizer” to just “Customizer”, as the Customizer isn’t necessarily theme-specific. [29903] #29947
    • Only POST dirty settings to preview to improve performance. [29905] #29983
    • Don’t trigger a change event if two unchanged object values are equal, second pass. [29907] #26061

    Bundled Themes

    • Add an alt attribute with the site title for header images linked to the home page. [29842] #15926

    Twenty Fifteen

    Comments

    External Scripts

    • Update jQuery UI to 1.11.1. [29847] #29833
      • Rename all files, remove the jquery.ui. prefix. Add old files to $_old_files.
      • Add and use non-minified files in /src.
      • Add grunt task to minify jQuery UI files.
      • (Non-minified files will not be shipped.)

    Language Packs

    • Language packs: Remove translations when deleting a theme or a plugin. [29856] #29860

    Internals

    • Handle deficiencies in PHP’s parse_url in older versions of PHP (<5.4.7) in WP_HTTP::make_absolute_url(). [29851] [29850] [29861] #28001, #29886
      • Correctly handle url’s containing url’s in WP_HTTP::make_absolute_url().
      • Correctly support Schemeless URLs in WP_HTTP::make_absolute_url() by respecting the ‘host’ field if present in the relative url.
    • New remove() method and some unit tests for the WP_Error class. @29854 #28092
    • Return an error when adding a term to a non-existent parent. [29867] #29614

    Queries

    Thanks to @rianrietveld, @tschutter, @netweb, @joedolson, @bramd, @Fab1en, @ocean90, @stephenharris, @boonebgorges, @georgestephanis, @jesin, @afercia, @miqrogroove, @avryl, @mboynes, @transom, @DrewAPicture, @johnrom, @matt, @iandstewart, @iamtakashi, @obenland, @cainm, @kristastevens, @karmatosed, @chellycat, @lancewillett, @kwight, @davidakennedy, @otto42, @jakub.tyrcha, @studionashvegas, @tareq1988, @westonruter for their core contributions!

    Revisions covered: [29842] to [29907]. For the complete list of commits to trunk, check out the log on Trac.

    Interested in joining in? Write or test a patch for 4.1.

     
  • Konstantin Obenland 11:57 pm on September 9, 2014 Permalink
    Tags: , , ,   

    Twenty Fifteen 

    It’s that time of the year again, time to work on a new default theme!
    This year we’re back to creating a brand new design. Like Twenty Fourteen, this is being targeted for December and thus WordPress 4.1.

    @matt asked Takashi Irie to design Twenty Fifteen, and they are both closely collaborating with @iandstewart, who also worked on Twenty Ten and Twenty Eleven. The design is far from finished, but the following screenshots might give you an idea of what direction it is headed this year:

    Twenty Fifteen is a clean, blog-focused theme designed through simplicity. With careful attention to typography, the theme treats text as a major part of the user interface. It features Google’s Noto Serif and Sans – a font family designed to be visually harmonious across many of the world’s languages, and a perfect fit for the internationalization strides being made in WordPress core.

    The theme is also designed to maximize the impact of core’s customization tools – Custom Headers and Custom Backgrounds. These tools will allow any Twenty Fifteen blog to be easily personalized.

    Last but definitely not least, Twenty Fifteen uses a mobile first approach in its design, remaining attractive and focusing on an optimal browsing experience across a wide array of devices from mobile to widescreen desktops.

    All of these things come together to present content cleanly for any of Twenty Fifteen’s users – a simple default theme.

    —Takashi Irie

    Next steps will be to finish the design, create a working theme, commit that to core, and then break it and make sure it adheres to the high standards and expectations we all have for default themes.

    If you are interested in contributing, please subscribe to this blog (if you haven’t already), and leave your name in the comments. As soon as it’s ready for public breaking, testing, and patching, I’ll make sure you get a ping!

    Further reading:

     
    • Amy Hendrix (sabreuse) 11:58 pm on September 9, 2014 Permalink | Log in to Reply

      You had me at “Twenty…”

      • utahman1971 8:23 pm on December 18, 2014 Permalink | Log in to Reply

        They had me at none of the vertical menu themes. They are ugly. That navigation is old or is just set for one sided people. Kind of takes up the pages space too. Never really like the look either. I rather have something you don’t have to spend hours coding to add something to it, then use there default theme that makes you have to do extra coding. You would at least think for a CMS software that was built since 2005 would offer something free that is like a premium paid product. I guess people are right nothing is for free anymore, unless it is do all the work for something you would like on it.

        • Ipstenu (Mika Epstein) 6:11 am on December 19, 2014 Permalink | Log in to Reply

          The default theme is not something that will work for everyone. We know that. It’s an example of what you can do.

          If you want a different theme, we have over a thousand :) https://wordpress.org/themes/ All free.

        • leonp 1:57 pm on December 19, 2014 Permalink | Log in to Reply

          I rather like them. It’s easier to read down the page. “Ugly” is subjective…

          Also, a hamburger menu @ narrow screen that expands to a vertical menu @ widescreen is a pretty “modern” design pattern.

          There’s lots of space on a widescreen these days…

        • thoughtwell 3:30 pm on December 29, 2014 Permalink | Log in to Reply

          +1 for leonp’s comment—was sitting in a client meeting the other day and couldn’t help but notice how awkward large fields of negative space look on large screens and how the content just becomes so isolated looking as this happens… especially when a full-screen background image-cover is used and the photo crops strangely due to letterbox formatting… a vertical side menu would probably help even out the proportions a bit…

          Lager screens are becoming more commonplace as the price drops… and gaming consoles, televisions, htpcs, etc. have folks using browsers on their televisions (probably not a mass demo, but still considerable for some projects, depending on what is being developed… and projection screens are pretty common in company boardrooms… I guess it’s just another case of ‘the right tool for the right job.’

    • Mel Choyce 12:01 am on September 10, 2014 Permalink | Log in to Reply

      <3

    • Carbis 12:03 am on September 10, 2014 Permalink | Log in to Reply

      Very glad to see design inspiration come from twentyeleven and twentyten.

    • codel1417 12:07 am on September 10, 2014 Permalink | Log in to Reply

      Can we have a theme focused around color and design instead of something that matches an ios device. Color is good. white is boring and bland.

      • Robert Dall 12:12 am on September 10, 2014 Permalink | Log in to Reply

        This theme as it is being stated will allow users to completely customize their blog based on their customizer choices. You can see from the screenshots provided that white is just the starting point and the world is your oyster in terms of colour choice…

    • Robert Dall 12:09 am on September 10, 2014 Permalink | Log in to Reply

      Take me to your leader… Actually just direct me to his blog… Oh and seriously: Yes please let me break this theme for you…

    • Reza 12:10 am on September 10, 2014 Permalink | Log in to Reply

      Looks Good to me, at least not left align on bigger screen like 2014 :)

    • ericdaams 12:14 am on September 10, 2014 Permalink | Log in to Reply

      The link to Takashi Irie’s post about Twenty Fourteen is broken 😉

    • Eric 12:14 am on September 10, 2014 Permalink | Log in to Reply

      I’m already a fan. :)

    • bmoredrew 12:14 am on September 10, 2014 Permalink | Log in to Reply

      Awesome. Looks great!

    • Nikhil Vimal (NikV) 12:20 am on September 10, 2014 Permalink | Log in to Reply

      Howdy! I would definitely be interested in working on the next default theme!

    • Ipstenu (Mika Epstein) 12:21 am on September 10, 2014 Permalink | Log in to Reply

      Nice, I like this!

    • Ryan Cowles 12:21 am on September 10, 2014 Permalink | Log in to Reply

      Looking sharp! I’d be happy to help in whatever capacity I can.

    • Ben Lobaugh (blobaugh) 12:22 am on September 10, 2014 Permalink | Log in to Reply

      I have not been this excited about a new default theme in a few years!!!

    • Spencer Hill 12:28 am on September 10, 2014 Permalink | Log in to Reply

      Is this built using Bootstrap?

    • Josh Levinson 12:45 am on September 10, 2014 Permalink | Log in to Reply

      Can’t wait to see it made a reality! I’d love to help out in any way I can.

    • IgniteWoo 12:45 am on September 10, 2014 Permalink | Log in to Reply

      99% of the world reads left to right. Therefore, single sidebar on the left = distraction = poorer visitor experience.

      Lets hope 2015 is avoids the various design fiascos of 2014.

    • marsjaninzmarsa 12:53 am on September 10, 2014 Permalink | Log in to Reply

      Nice and clean and Material-like – I’like it! 😀

    • webdevmattcrom 12:59 am on September 10, 2014 Permalink | Log in to Reply

      Looking forward to taking it for a spin and breaking stuff!

    • Michelle Langston 1:00 am on September 10, 2014 Permalink | Log in to Reply

      Love it! I’m interested in contributing however I can! :)

    • fikrirasyid 1:02 am on September 10, 2014 Permalink | Log in to Reply

      This looks really fantastic. Same here, I’m really interested in contributing 😀

    • derekspringer 1:11 am on September 10, 2014 Permalink | Log in to Reply

      Almost looks like 2012 fancier, side-bar’d younger brother!

    • David A. Kennedy 1:44 am on September 10, 2014 Permalink | Log in to Reply

      Looks awesome! Ping me as well. I’ll contribute whatever code I can as well as coordinating with the Accessibility Team for testing. We’ll test for accessibility from the earliest build possible. I’d love for Twenty Fifteen to carry the accessibility-ready tag, just like Twenty Fourteen. :)

      • Graham Armfield 5:18 am on September 10, 2014 Permalink | Log in to Reply

        +1 David. accessibility-ready should be the default path from now on.

        • Olivier Nourry 9:33 am on September 23, 2014 Permalink | Log in to Reply

          I’d even go further: the default theme should be the top-of-its-class with regards to accessibility. And it should brag about it. It’s a unique and efficient way to spread knowledge about accessibility to people who usually do not care too much about it, and most of time never heard of it.

    • s.r. 1:49 am on September 10, 2014 Permalink | Log in to Reply

      Looks good! Simple and clean.
      However one thought crossed my mind why we always have “blog-focused” themes? WordPress stepped much further than just a blog CMS, so I believe WP could once in awhile make one for proper website to show how to it is done. :) Just saying

      • Graham Armfield 5:15 am on September 10, 2014 Permalink | Log in to Reply

        Totally agree with this. All of the WordPress websites I’ve created for people have been for small
        /medium sized businesses and charities. A good, modern, business-based default theme would be really useful.

      • Xavier Borderie 9:22 am on September 10, 2014 Permalink | Log in to Reply

        You mean, like the current theme, Twenty Fourteen, which is a magazine-like theme? 😉

      • Andrew Nacin 6:45 pm on September 10, 2014 Permalink | Log in to Reply

        And Twenty Twelve, which wasn’t designed to be blog-focused either.

        • Marcel Stephan 11:34 am on November 19, 2014 Permalink | Log in to Reply

          I’ve used Twenty Twelve a lot of times for small business and other, but it’s not responsive enough. So a theme based on a small business would be great.

      • faospark 7:38 am on September 26, 2014 Permalink | Log in to Reply

        I agree @ s.r. and graham. lets call things for what it is and probably do things that is current and useful. i thought sending out wodpress 2014 default theme into the wild was a huge statement from the core the were moving out from this blog type of themes like wordpress 2013 default and yeah maybe 2012 was designed not be blog focused but come’on sir Nacin. look at on how 2012 default theme looks like? it does not require one to be a rocket scientist to figure out that it was meant for a blog. I appreciate the work of the core but for this theme release im little bit not ease with it. i like the look of the theme but the fine print tells me that more likely its gonna downloaded by users but be kept unused.

      • Ian Stewart 8:26 pm on October 1, 2014 Permalink | Log in to Reply

        You should write a blog post about this with some visual examples — or even an example, working theme. It’d be great to see more ideas and discussion around default themes. You can have an impact here. Everyone can. And it doesn’t hurt to start thinking about Twenty Sixteen sooner rather than later.

    • Brent Logan 1:50 am on September 10, 2014 Permalink | Log in to Reply

      Beautiful already. Please ping me.

    • cramdesign 1:53 am on September 10, 2014 Permalink | Log in to Reply

      I’m in. Ping me.

      Where is the appropriate place to discuss the design? Here?

    • Philip Arthur Moore 2:47 am on September 10, 2014 Permalink | Log in to Reply

      > create a working theme

      What’s your game plan for the codebase? You had some awesome food for thought post-2014.

    • Philip Arthur Moore 2:48 am on September 10, 2014 Permalink | Log in to Reply

      Also, ping me. Always happy to help break this stuff. :)

    • Nick Halsey 3:02 am on September 10, 2014 Permalink | Log in to Reply

      I’ll help out again, as time allows with ongoing Customizer work I’m exploring.

      It’s good that Twenty Fifteen will emphasize headers and backgrounds to this extent, right as we re-imagine media in the Customizer (including a new Background Image control) and hopefully officially deprecate and (conditionally) redirect the standalone header/background screens in 4.1.

      Let’s make sure we leverage and showcase some of the new things that the Customizer can do in the code. I already see potential for a conditional-contextual control for header/sidebar color when there is no image, for example. Most importantly, we should show how simply the Customizer can be leveraged by themes by keeping the code side minimal. A versatile theme like this is made even more powerful by giving users the power to achieve a custom design without code (or too many options).

      Given the visual similarities to Twenty Twelve, are we planning on only shipping the three most recent themes with new installs, or will we be keeping Twelve in new installs still? The problem with dropping it is that it’s the only “CMS”-oriented theme of the last four bundled ones, whereas we would now have two blog themes. But given the visual similarities and the clear advantages to the newer one, I think Twelve should be dropped (and it’s easy enough to grab from the repo if wanted).

    • Japh 3:07 am on September 10, 2014 Permalink | Log in to Reply

      <3

    • doughamlin 3:36 am on September 10, 2014 Permalink | Log in to Reply

      Very interested in helping.

    • rilwis 4:08 am on September 10, 2014 Permalink | Log in to Reply

      I love the design, simple and beautiful. It’s very convenient to use for a personal blog.

    • Zulfikar Nore 4:18 am on September 10, 2014 Permalink | Log in to Reply

      Interested in helping and ready to start breaking when you are.

    • Zoe Rooney 4:22 am on September 10, 2014 Permalink | Log in to Reply

      I’d be happy to help as well!

    • Sujay 5:00 am on September 10, 2014 Permalink | Log in to Reply

      Would be happy to contribute!

    • Morten Rand-Hendriksen 6:05 am on September 10, 2014 Permalink | Log in to Reply

      I’m all in. Hit me up.

    • Chris Lema 6:28 am on September 10, 2014 Permalink | Log in to Reply

      Looks great. I’m in.

    • Sakin Shrestha 6:29 am on September 10, 2014 Permalink | Log in to Reply

      Nice and Clean Design. Simply Love it. Thanks and will check in more detail.

    • Slobodan Manic 6:36 am on September 10, 2014 Permalink | Log in to Reply

      Looks really nice. I’d be happy to contribute.

    • Tarık ÇAYIR 6:57 am on September 10, 2014 Permalink | Log in to Reply

      Simple and new modern design.

    • LittleBigThings 7:16 am on September 10, 2014 Permalink | Log in to Reply

      It looks very nice.
      I am happy to follow the development of a default theme for the first time.

    • Caspar 7:20 am on September 10, 2014 Permalink | Log in to Reply

      Looks nice, ping me when you need it broken.

    • blumenberg 7:49 am on September 10, 2014 Permalink | Log in to Reply

      I would be happy to help, count me in. (^_^)

    • Michel - xiligroup dev 8:02 am on September 10, 2014 Permalink | Log in to Reply

      As author of multilingual plugin named xili-language and child themes of bundled themes like twenty fourteen.
      As done previously in tracs, I am ready to contribute – by example – to add some filters at right place : this will avoid un-registering some widget to after clone it with including customisation of query… ( Don’t hesitate to question me.

    • zomidaily 9:34 am on September 10, 2014 Permalink | Log in to Reply

      Wow… can’t wait to see another great default WordPress theme.

    • Nashwan Doaqan 10:00 am on September 10, 2014 Permalink | Log in to Reply

      It looks really Nice!! .. waiting for it :)

    • fritoebola 10:25 am on September 10, 2014 Permalink | Log in to Reply

      December ???!!!!!!! But we want it NOW!!!!! 4.0 is live!!!! :'(

    • Jack Lenox 10:40 am on September 10, 2014 Permalink | Log in to Reply

      Woot!

    • Torsten Landsiedel 11:41 am on September 10, 2014 Permalink | Log in to Reply

      I’m in, too! And this comment section should be read by everyone who is participating. Great thoughts!
      http://konstantin.obenland.it/2013/12/19/twenty-fifteen/

    • Sharon Austin 12:37 pm on September 10, 2014 Permalink | Log in to Reply

      Definitely. Ping me.

    • Jose Castaneda 12:53 pm on September 10, 2014 Permalink | Log in to Reply

      I’m for any direction you choose in order to try and break this. Will this theme be a11y-ready?

    • Tracy Rotton 1:09 pm on September 10, 2014 Permalink | Log in to Reply

      ::hand raised::

      Looking forward to contributing on this!

    • WP Sites - Brad Dalton 1:48 pm on September 10, 2014 Permalink | Log in to Reply

      Ping me please when ready. Thanks

    • Tammie 2:30 pm on September 10, 2014 Permalink | Log in to Reply

      Looks great! I’m excited to see and poke this around. I’d love to help in any way.

    • Yojance 2:53 pm on September 10, 2014 Permalink | Log in to Reply

      This looks amazing. Can’t wait to try it on my site.

    • Tracy Levesque 3:47 pm on September 10, 2014 Permalink | Log in to Reply

      Yeah 😀

    • firewatch 5:46 pm on September 10, 2014 Permalink | Log in to Reply

      Ping me please. :)

    • Dave Clements 5:51 pm on September 10, 2014 Permalink | Log in to Reply

      Looks great guys, though I have to say, I think I was more excited to see a picture of what I believe to be the West Pier in Brighton (my hometown) featured so prominently.

    • Mary 6:07 pm on September 10, 2014 Permalink | Log in to Reply

      I’m really excited to see this! Please count me in for contributing wherever I can be helpful.

    • David Marichal 6:46 pm on September 10, 2014 Permalink | Log in to Reply

      Looking forward to contributing. Ping me.

    • Joan Artés 7:23 pm on September 10, 2014 Permalink | Log in to Reply

      It will be an honor to contribute. Ping me :)

    • Eduardo Reveles 9:40 pm on September 10, 2014 Permalink | Log in to Reply

      o/

    • Alex Vasquez 6:08 am on September 11, 2014 Permalink | Log in to Reply

      I guess it’s okay. If you’re into that kind of thing. =)

    • michaelaterndrup 1:53 pm on September 11, 2014 Permalink | Log in to Reply

      Looking forward to it I try to create my own theme but fail…

    • techjewel 5:32 pm on September 11, 2014 Permalink | Log in to Reply

      Awesome!

    • Jesper Johansen (jayjdk) 10:41 pm on September 11, 2014 Permalink | Log in to Reply

      Looks very nice. Ping me please :)

    • memuller 1:16 am on September 12, 2014 Permalink | Log in to Reply

      Nice and simple – I like it.
      Count/ping me in.

    • menkom 3:29 am on September 12, 2014 Permalink | Log in to Reply

      Hmmmmm… am i the only one that does not like it…. seems extremely bland and limited…. i guess i have to see the final result..

    • Gaurav Tiwari 2:23 pm on September 12, 2014 Permalink | Log in to Reply

      Simple and Trendy theme. And the best, it is ‘really’ readable.

    • Stephen Edgar 10:33 pm on September 12, 2014 Permalink | Log in to Reply

      Impressive, much like :)

    • chrissyrey 2:57 am on September 13, 2014 Permalink | Log in to Reply

      Count me in!

    • Ahmad Awais 4:52 am on September 13, 2014 Permalink | Log in to Reply

      Design is lovely. I am a big fan of Minimal Themes. Looking forward to build & contribute the frontend of this theme. Count me in.

    • Haseeb Ahmad Ayazi 3:19 pm on September 13, 2014 Permalink | Log in to Reply

      Nice theme actually. It will suits the WordPress 4.1 , try to make it more customizable. I am too much tired of using third party themes.

    • abe_charles 3:42 am on September 14, 2014 Permalink | Log in to Reply

      While I think that Twenty Fifteen looks promising, it is light years behind what it should be and I understand it’s still being worked on but it need excerpts as many great themes nowadays employ those features and not just pictures in the same rows as texts but videos as well.

      Twenty Fifteen needs to have more colours. The white thing is too plain as is. If it’s going to have a white background predominantly it needs some flavour to it.

      Plus the menu bar should be interactive with the ability to show images and a mega menu when the cursor hovers over it and if that is not in by default it should be in the theme’s options. All cards should be on the table or at least in the theme’s options.

      Those are my suggestions. Keep the screenshots coming. I am glad that things developed on this theme so quickly.

    • Eric Lewis 3:37 pm on September 14, 2014 Permalink | Log in to Reply

      I think we’re missing out on an opportunity to doing something Javascript-forward here. Aaron Jorbin proposed something similar for Twenty Fifteen, and I’d like to echo his thoughts.

      The WP API would benefit greatly were a default theme built on top of it. We have an API that needs real world usage – what’s more real world than a default theme that ships to 20% of the web?

      We can introduce non-trivial front-end Javascript to theme developers, which would be a great educational service for the community.

    • abe_charles 3:45 pm on September 14, 2014 Permalink | Log in to Reply

      Suggestion: Try to make the excerpts on this theme be set or defined by featured images without having the featured image eclipse the post on the main page like in the default Twenty Fourteen theme.

    • abe_charles 3:53 pm on September 14, 2014 Permalink | Log in to Reply

      Suggestion: Make items in a menu bar be of different colours by default or customizable, similar to the effect the “Fourteen Colors” plugin has on the Twenty Fourteen theme. But this should be a built in feature in the Twenty Fifteen theme and it would be great if when hovered over a menu item the set featured image associated with the posts or some of the traits of the posts or posts themselves be displayed for a particular menu item or category be displayed, like a modern menu.

    • abe_charles 1:12 am on September 15, 2014 Permalink | Log in to Reply

      Suggestion: It would also be great to have a slider with featured posts like the one in Woothemes’ “Headlines” theme and excerpts as i have been saying all this time is key and we need a theme with a decent type of font. No crappy fonts please. it takes away from the greatness of the theme.

    • ajay.khullar2 7:44 pm on September 22, 2014 Permalink | Log in to Reply

      The link to Takashi Irie’s post about Twenty Fourteen is broken again :)

    • Emil Uzelac 9:59 pm on September 22, 2014 Permalink | Log in to Reply

      Look nice on any device! <3

    • Patrick Rauland 2:14 pm on September 23, 2014 Permalink | Log in to Reply

      Always happy to help break things Obenland! :)

    • ThatChris 10:46 pm on September 23, 2014 Permalink | Log in to Reply

      I’m in! :)

    • Paal Joachim Romdahl 11:29 pm on September 23, 2014 Permalink | Log in to Reply

      What features could be added to Core that would also help make the theme even better/easier to use/etc? I am thinking that a subgroup who are working on the theme could also be working on improving aspects of Core at the same time.

    • Ahmad Awais 4:44 am on September 24, 2014 Permalink | Log in to Reply

      @konstantine any further news about how and when we are going to contribute?

    • activedirectory-faq 7:39 am on September 24, 2014 Permalink | Log in to Reply

      Looks nice and is much more my taste than twenty fourteen

    • iluchen 2:40 pm on September 25, 2014 Permalink | Log in to Reply

      wonderful!

    • Justin Kopepasah 12:46 am on September 28, 2014 Permalink | Log in to Reply

      Yet another awesome looking theme for core. Looking forward to digging in to it!

    • aglaonika 10:26 am on September 30, 2014 Permalink | Log in to Reply

      Great design. Would like to join if I didn’t miss the deadline.

    • vishal_chitnis 6:01 pm on October 6, 2014 Permalink | Log in to Reply

      Nice, looking forward to contributing

    • Siobhan Bamber (siobhyb) 10:00 pm on October 6, 2014 Permalink | Log in to Reply

      If you are interested in contributing, please subscribe to this blog (if you haven’t already), and leave your name in the comments. As soon as it’s ready for public breaking, testing, and patching, I’ll make sure you get a ping!

      I’d like to help test when it’s ready too!

    • Tony Ketteringham 3:25 am on October 8, 2014 Permalink | Log in to Reply

      Happy to help as well if you need any more.

    • ianarmstrong 10:50 pm on October 10, 2014 Permalink | Log in to Reply

      I have some concerns that the default layout isn’t keeping up with what we know about user experience. I would love to see a priority placed on purpose -> pitch -> call to action in terms of how the information is presented.

      One of the big trends in design right now is the use of subtle animations to help the user better understand [a] what they just did and [b] what they are supposed to do next. I’d like to see these types of animations callable by class, so that if we create a class called .t15_button it’ll automatically use the appropriate styles.

      While I’m happy to see the theme going back to a cleaner look, there is so much more that it can be. WordPress twentyX series dictates the course of design for all non-premium themes across tens of thousands of sites. I think it would be unfortunate if we stepped back to TwentyTwelve, updated for HTML5 flexbox support and schema.org compatibility.

    • gd6d 7:56 pm on October 11, 2014 Permalink | Log in to Reply

      Would be happy to contribute too!

      • gd6d 7:50 am on October 17, 2014 Permalink | Log in to Reply

        If no menu is activated, the pages title are not visible in the sidebar. If you delete the conditional “if has menu” line 12, sidebar.php, it works fine… Is it going to stay?

    • Maria Antonietta Perna 10:45 am on October 15, 2014 Permalink | Log in to Reply

      Nice clean look for this new theme. I’m always eager to update my knowledge of WP theme development and best practices through the latest default theme, therefore I hope the code is clear to understand and generously commented and that the features that WP offers are made use of, especially the Customizer. I look forward to seeing the proper ways of adding the customization options that most users expect in themes using the Customizer in the default theme, especially after the WP upgrade to v.4. My sincere thanks to this awesome community.

    • dariodev 12:52 am on November 12, 2014 Permalink | Log in to Reply

      Looks great! Ping me, please!

    • Avi_Lambert 10:57 pm on November 14, 2014 Permalink | Log in to Reply

      Woot! Looks like a mobile first theme.

    • Jincheng Shan 11:19 am on November 15, 2014 Permalink | Log in to Reply

      Why Twenty Fifteen didn’t include tag.php and category.php although in archives.php it says Twenty Fifteen has already included them?

    • Fabrizio Pivari 2:11 pm on November 15, 2014 Permalink | Log in to Reply

      Can you add in social menu 500px and tunblr icons?

    • sonisitez 9:34 am on November 16, 2014 Permalink | Log in to Reply

      Im waiting :)

    • divnull 9:17 am on November 17, 2014 Permalink | Log in to Reply

      Wow! Glad to see the spirit of 2011 and 2012 is back! Clear, crisp, simple. I’m happy to skip 2014. :-)
      Good job! :-)

    • wassem mansour 5:29 pm on November 17, 2014 Permalink | Log in to Reply

      Twenty Twelve Rules Forever :)

    • ncjcj 8:56 pm on November 17, 2014 Permalink | Log in to Reply

      I am going to update one the two volunteer sites I keep. It calls for the global nav to be horizontal at the top with drop-down menus.

      Can this be easily achieved with a child-theme (I write my own css) and does the core funtionality easily allow for drop-downs?

      I wanted to use the 2015 just because they get out of date so fast.

      Thanks

      Nancy

    • suzettefranck 11:30 pm on November 19, 2014 Permalink | Log in to Reply

      My blog theme is a child I made of Twenty Thirteen since Twenty Twelve. I think I will have to upgrade to Twenty Fifteen, can’t wait to see how it turns out. I use Twenty Fourteen on all my new blogs, but loved my girlie child theme.

    • David Favor 8:59 pm on November 20, 2014 Permalink | Log in to Reply

      Theme Check reports following (very minor) problems with Twenty Fifteen.

      REQUIRED: The theme needs to have a call to wp_title(), ideally in the header.php file.
      REQUIRED: The theme needs to have tags, ideally in the header.php file.<br /> REQUIRED: The theme doesn’t have post pagination code in it. Use posts_nav_link() or paginate_links() or next_posts_link() and previous_posts_link() to add post pagination.

    • Monika 9:12 am on November 25, 2014 Permalink | Log in to Reply

      hi my first feedback to Twenty Fifteen :-)
      I love the typographie and the elegance of this theme.

      I can’t understand:
      $content_width = 660;
      but the postthumbnail size is set to 825
      set_post_thumbnail_size( 825, 510, true );

      Why is the default thumb bigger than content width?

      This theme has one widget area.
      In source the widget area appears before the main content => this is a really strange design pattern

      If someone would like to have a very good position on search engines I can’t recommend to use this theme because the sidebar appears before the main content in source.

      And is it possible to decrease the http requests for styles and scripts? Everybody is loving a fast website :-)

      I know I can use a child-theme to create a second widget area under the content and use the first sidebar only for navigation, combine scripts and so on.

      Thanks

      Monika

    • Sunnyj 6:51 am on November 28, 2014 Permalink | Log in to Reply

      Noto Sans is a bad choice, very poor quality hinting on the digits 1234567890, especially at 14px or less they will get noticeably blurry. Better off sticking with Open Sans or something else imo.

    • gd6d 5:59 pm on November 30, 2014 Permalink | Log in to Reply

      I use this theme on my website. I have a problem with SEO plugin like Yoast or All in One. I can’t save any change on title or description fields… I had to change the theme, make my corrections, save, and return to Twentyfifteen…

    • Sami Niemi 12:17 pm on December 4, 2014 Permalink | Log in to Reply

      I need to have Twenty Fiveteen for my site :)

    • Edward R. Jenkins 8:47 pm on December 6, 2014 Permalink | Log in to Reply

      Interested in contributing and/or testing!

    • wholroyd 7:30 pm on December 10, 2014 Permalink | Log in to Reply

      Looks like the Flat theme from YoArts, but the article tail looks better and I hope you can put widgets in other places than just in the left menu column.

    • OlalaWeb 9:47 am on December 17, 2014 Permalink | Log in to Reply

      Hi all! Ping me as soon as Twenty Fifteen is released! We’d love to create a Child Theme :)

    • praveenrk 10:10 am on December 18, 2014 Permalink | Log in to Reply

      Great themes …..cool work

  • Helen Hou-Sandi 8:30 pm on May 6, 2014 Permalink
    Tags: ,   

    Summary of last week’s dev chat on 4/30 (IRC log):

    Announcements

    Features as plugins

    • Met on 4/29 (IRC log)
    • Current potential considerations seem to be WP API and media grid.
    • Press This is getting some attention from an early stages working group, which could also be a part of the 4.0 release.
    • Admin Help is poised to shift into more of a continuous testing and advisory group, which is awesome.
    • Front-end editor is making good progress, but has UX issues that are getting worked on, needs iteration and experimentation and probably won’t be ready by 4.0, but should continuously be worked on, as is the goal of features as plugins in the first place. Developers needed.

    Potential ideas and their suggesters:

    Summary: we have good things in mind about more media improvements, more editing experience improvements, more visual media grid and better plugin installer experience (following in the footsteps of themes), and behind the scenes wins in taxonomy, multisite, and post type and comment APIs.

    If you’re interested in any of the above or have other ideas, please sound off in the comments.

    Getting involved

    • We are always looking for more people to be involved with Trac gardening, patch review, patch writing, or some combination thereof.
    • Component pages are running well, and most could still use the caretaking of a component owner or somebody who’d like to become well-versed in a particular area of core. To get started, just sign up for component notifications at https://make.wordpress.org/core/notifications/. No need to be an expert now – learning and persistence is more important.To help with a specific plugin, join their weekly chats and/or follow along wherever they post. See the Features as Plugins page for more information.
    • A reminder from @matt to always be dogfooding the product – use WordPress every day.

    Bonus punnage, to the lead’s chagrin:

    > wonderboymusic will make a t-shirt for anyone who gets all 16 of those Cache tickets closed :)
    > sams: “Cache Master”?
    > wonderboymusic: Johnny Cache
    > jorbin: If you fix the Cache, you’ll get the Credit. That Checks out.
    > MarkJaquith: I’d put in a cache pun, but I don’t want to be sent to purgetory.
    > johnbillion: You would have to be a cache machine to fix all 16

     
  • Andrew Nacin 9:26 pm on December 31, 2013 Permalink
    Tags: ,   

    Commit announcements for 3.9 

    Lots of news to share! First: Helen Hou-Sandí has had guest commit for the past three release cycles. She’s been spending the last year reviewing contributions, mentoring contributors, and working on some of our larger UI projects. I’m proud to announce @helen is now a permanent committer to WordPress!

    We’ve invited John Blackbourn (@johnbillion) to be a committer for the 3.9 cycle. His strong, consistent contributions have been backed by excellent judgment and temperament.

    Matt Thomas, who led the dashboard redesign in 3.8 (and 3.2, and 2.7, etc.), will keep his commit to continue to maintain and improve WordPress UI. He’s been a great mentor to many contributing designers and his long-term impact is indelible.

    For the last few years, we’ve been granting commit access on per-cycle basis, sometimes for a particular component, feature, etc. Generally, after about a year, a guest committer can be considered for permanent commit access. Dominik Schilling, Sergey Biryukov, Drew Jaynes, and Scott Taylor have all had their commit extended for 3.9.

    Drew (@DrewAPicture) was given temporary commit for inline documentation starting with 3.7. He’s been heading up the long-running initiative to document every hook in WordPress. Scott (@wonderboymusic) also started committing during 3.7, and has a particular penchant for digging deep into the query and taxonomy APIs. And Sergey (@SergeyBiryukov) and Dominik (@ocean90), well, they are forces of nature.

    (@aaroncampbell was also given guest commit in 3.7, but he ended up not having much time to use it.)

    Here’s a full list of those with permanent commit: @markjaquith, @ryan, @westi, @matt, @azaozz, @dd32, @koopersmith, @duck_, @helen, and me (@nacin); @lancewillett for bundled themes; @iammattthomas for UI. You might have also seen commits before from @josephscott (XML-RPC), @nbachiyski (internationalization), and @mdawaffe (secret weapon for really tricky problems).

    Next weekly meeting is January 8. Happy new year, everyone. Here’s to a great 2014.

     
  • Matt (Thomas) Miklic 7:33 pm on November 11, 2013 Permalink
    Tags: , fonts, open sans   

    Open Sans, bundling vs. linking 

    In Wednesday’s 3.8 planning meeting we discussed hotlinking vs bundling Open Sans. MP6 followed Twenty Twelve’s example by linking to Google Webfonts, but the consensus from Wednesday’s chat was that bundling would be preferable.

    I began experimenting with this last week; first determining which font formats were necessary to include. I settled on WOFF and SVG as the two formats that would cover every browser we’re aiming to support. I left out TTF and EOT as they add only marginal browser support (IE8), but would add significant weight to the WordPress download. We do include TTF and EOT versions of Dashicons, since loading those icons is essential to usability in a way that loading Open Sans is not.

    The bundled Open Sans webfonts come from FontSquirrel. The Western Latin and Basic Latin subsets are small and include enough characters for English language support. Those subsets do not include a full set of glyphs for other languages, however (they’re available as separate downloads). There is a non-subsetted version of the font available which includes all necessary glyphs, but it’s 2x–2.5x the file size of the subsetted fonts, which add significant overhead to the pageload and can actually crash some mobile browsers. The Western Latin and Basic Latin subsets can cause missing characters (spaces or boxes) to appear in text using accented characters, which is a significant usability concern.

    Google Webfonts solves both the character set and the font format problems by intelligently loading the font format and the character subset that’s needed for a particular browser and a particular website, and nothing more. For us to bundle Open Sans with WordPress, we need a way to accomplish that without adding significant heft to the core WP download. I’m starting this P2 thread to open up the discussion on how we might do that.

     
    • Matt Mullenweg 7:43 pm on November 11, 2013 Permalink | Log in to Reply

      It’s also worth noting if we can solve this in a standalone way (the script not loading any of the rest of WP) we avoid licensing issues and also solve a general problem many people across the web have.

      Also keep in mind if this takes longer than a few days the right answer for 3.8 might be linking in core and releasing a plugin for people that bundles for people that don’t like Google.

      • Piet 4:28 am on November 12, 2013 Permalink | Log in to Reply

        I think it doesn’t have so much to do with liking or not liking Google. There are certain countries where Google is blocked and that includes loading their fonts. For all sites I built (I live in China), I bundle fonts, because only then I can be sure that these fonts load.
        That might be another argument pro-bundling :)

        • krembo99 6:03 am on December 22, 2013 Permalink | Log in to Reply

          I am with Piet – Have the same problems in china ( and elsewhere – granted – all totalitarian regimes, but still .. ). Google services work only sporadically . Fonts , jQuery CDN , Maps etc. Linking those resources makes the page time-out .

    • Doug Wollison 8:41 pm on November 11, 2013 Permalink | Log in to Reply

      Regarding the missing characters, don’t just about all browsers fallback to the next font in the font-family list for those characters?

    • mindctrl 8:46 pm on November 11, 2013 Permalink | Log in to Reply

      Relying on a third party for fonts in core doesn’t make me want to do cartwheels. It’s a backdoor analytics of sorts, and a privacy concern. The increased file size is the lesser of two evils. Neither option is ideal.

      I love Open Sans, but given the two options, I’d rather see Arial. *runs for cover*. I just tested swapping out Open Sans for Arial in trunk, and it’s really not that bad. Theming the WP admin/MP6 via plugins would be a great way for people to opt into hosted font solutions.

      • Doug Wollison 9:21 pm on November 11, 2013 Permalink | Log in to Reply

        Or, the better compromise; Helvetica (Neue if possible), finally falling back to Arial if things get desperate.

        • mindctrl 9:26 pm on November 11, 2013 Permalink | Log in to Reply

          I thought the same thing originally. Helvetica Neue isn’t that bad, but it’s also not standard on a number of platforms. Neither is Helvetica. This was news to me. I don’t know of a definitive list online, but this one from MailChimp is helpful, and the reason I said and tried Arial. http://templates.mailchimp.com/design/typography

          • mindctrl 9:27 pm on November 11, 2013 Permalink | Log in to Reply

            Sorry, actually standard Helvetica is.

            • jwarren 11:09 am on November 13, 2013 Permalink

              If we’re going with system fonts, it should probably just be standard ‘san-serif’, which will be Helvetica on OSX, Arial on Windows, and whatever has been deemed appropriate on the Linux distro of choice. It also allows people and browsers to override that easily for their own purposes – perhaps a different language, perhaps extra visual clarity, perhaps an unusual display technologo… who knows?

    • Robert Dall 9:41 pm on November 11, 2013 Permalink | Log in to Reply

      I have never really like relying on a third party service to do what could be done internally.

      Also what if you are developing locally without access to the internet?

      Regardless of who provides the free service. One day Google (or Adobe who just started there own free font embedding service) “could” turn around and say. “Ya were not going to do that free font thing anymore”

      Now it would be easy to swap it out but why rely on something like that anyways.

      • Matt Thomas 9:50 pm on November 11, 2013 Permalink | Log in to Reply

        To be clear, we’re talking about linking to Google Fonts for Open Sans just until we can solve this in a standalone way, as @matt mentioned above.

        If you’re working locally with no internet connection, the fonts will just fall back to the browser-defined “sans-serif” font (Helvetica on OS X, Arial on Windows by default).

    • Ryan Hellyer 10:04 pm on November 11, 2013 Permalink | Log in to Reply

      I suspect that bundling scripts into WordPress core will create privacy concerns for many people. The ability to perform analytics via them will disturb a small segment of the user-base.

      It may even be illegal in some countries. Germany springs to mind in regards to that. They’re already super ticked off about being spied on at the moment, so I think it might be best if WordPress doesn’t join the party too.

      And yes, you can install a plugin to force them to be self-hosted, but many people will just unwittingly hit the “update” button without ever realising that they’re opening themselves up to privacy issues.

      • Doug Wollison 10:10 pm on November 11, 2013 Permalink | Log in to Reply

        What if we take a progressive enhancement approach? By default, we wouldn’t actually load Open Sans from anywhere, and instead just falls back to whatever font it can. Then we offer plugins (or packaged right in the core) options for self hosted or google hosted.

      • daveshine (David Decker) 11:49 pm on November 11, 2013 Permalink | Log in to Reply

        Almost any modern theme loads Google Fonts already, including some of the default themes, plugins not counted…

        I have absolutely nothing against loading Open Sans from Google, and find it a rather good option to do so.

        Yes, there are lot of issues with privacy that should be done better – in my opinion this topic here falls not amongst them…. just my personal view.

        Thanks, Dave from Germany :)

    • Dion Hulse 11:14 pm on November 11, 2013 Permalink | Log in to Reply

      There is a non-subsetted version of the font available which includes all necessary glyphs, but it’s 2x–2.5x the file size of the subsetted fonts, which add significant overhead to the pageload and can actually crash some mobile browsers.

      If we actually want to use Open Sans for WordPress, this is unfortunately what we have to do.

      • Open Sans (WOFF+SVG for Italic, Regular, SemiBold, and SemIbold+Italic) weighs in at 576K uncompressed (92K WOFF, 484K SVG), 174K compressed.
      • Open Sans (WOFF+SVG for Italic, Regular, SemiBold, and SemIbold+Italic w/ full charset support ) weighs in at 4.5MB uncompressed (345K WOFF, 4.2MB SVG), 826K compressed.

      The SVG’s will compress well as they’re just text, WOFF is already compressed. We could have a light-weight PHP script that served compressed documents intelligently depending upon the client (selectively adding Charsets based on WPLANG / browser UA), but this has caching issues amongst other things.

      If we actually look at what the fonts are for though…

      • WOFF is the primary font, it’s supported by most browsers.
      • SVG is included for iOS 3.2-4.3 support, and for Android Browser 4.0-4.3.

      Given the significant size of SVG fonts, it makes me question if we should be using them at all, it doesn’t add much extra browser support.

      An alternative is shipping with WOFF+TTF fonts – that would add support for iOS 4.2-4.3 (iOS 3.2 misses out), and Android 2.2-4.3 (SVG only works for 4.0-4.3).

      • Open Sans (WOFF+TTF for Italic, Regular, SemiBold, and SemIbold+Italic w/ full charset support ) weighs in at 1,000K uncompressed (345K WOFF, 661KB TTF), 689K compressed.

      or.. just drop Open Sans for those mobile clients.. since it really doesn’t seem worth it.. WOFF supports most desktop browsers and modern mobile devices, and we should have a GOOD font fallback list for unsupported browsers (which we don’t currently have with MP6, but we did previously have in WP 3.6).

      • Dion Hulse 11:22 pm on November 11, 2013 Permalink | Log in to Reply

        I also missed that SVG is also for Mac Safari 3.2-5.0, not just for iOS. TTF is supported in Safari 3.1-5.0 as well.
        TTF/SVG is also needed for older Opera versions (desktop and mobile, and some gaming systems), but WOFF is supported for v11+ so that doesn’t seem like a deal breaker at all (coming from an Opera user..)

      • Matt Thomas 11:48 pm on November 11, 2013 Permalink | Log in to Reply

        I don’t recommend using the un-subsetted font for any solution because of the extra page weight that every user would incur. Intelligently loading the correct subset for the specified language is the best possible user experience, whether it’s linked to from Google fonts or we implement our own solution that accomplishes the same result. Just for comparison, this is the size difference for a single weight and style of Open Sans (we need four: regular, italic, semibold, and semibold italic).

        • English subset, WOFF: 13 KB
        • Czech subset, WOFF: 17 KB
        • Full charset, WOFF: 85 KB
        • English subset, SVG: 32 KB
        • Czech subset, SVG: 70 KB
        • Full charset, SVG: 1.1 MB
        • Dion Hulse 12:01 am on November 12, 2013 Permalink | Log in to Reply

          So yes, I’d never suggest SVG for this.. ever..

          WOFF however, we can get away with including the full set, the extra page load isn’t significant once it’s in the cache.

          Most web services will get away with only loading one subset as they know what the characters on the page are, WordPress doesn’t really know the answer to this, French accented characters can appear in an English post, etc.. so relying upon WPLANG is a rather bad idea for this.

          One method would be to have Javascript detect the characters on the page and load the english by default, and optionally load the larger CSS if it spots any of those characters..

          Even Google Fonts requires you to specify which subsets you want to load, it can’t automatically guess what’s on the page.. so it’ll have the same page load issues (except that you gain benefit from their extra-special browser compression and CDN).

    • davelab6 5:30 am on November 12, 2013 Permalink | Log in to Reply

      Disclaimer: I consult for Google, Adobe and other companies on web fonts and libre fonts issues, but I represent only myself. This is my own personal opinion.

      One day Google (or Adobe who just started there own free font embedding service) “could” turn around and say. “Ya were not going to do that free font thing anymore”

      Anyone can see that Google uses the Fonts API for its own web apps and web pages. Since the fonts are libre licensed, if that day ever comes, switching is possible.

      If you’re working locally with no internet connection, the fonts will just fall back to the browser-defined “sans-serif” font (Helvetica on OS X, Arial on Windows by default).

      If you’re working locally, you can install the fonts, and if the CSS includes them with ‘local’ (as the Google Fonts API css does) then they’ll load :)

      For WordPress to self host the fonts, in a way that matches the fonts served by Google’s Fonts API, you’ll want to subset them by language, and also have versions with the hinting removed to serve to browsers on platforms that don’t use hints, and perhaps also CFF versions for platforms with good CFF rendering. Since WordPress doesn’t have a dynamic font subsetter, you’ll need a set of language subsets and a set of hint subsets.

      WOFF, SVG, TTF, EOT is needed for full browser support, in descending order of importance. If you leave out formats, you will leave out users. Maybe that matters, maybe it doesn’t.

      By using the Google Fonts API you support all users on all platforms. The API doesn’t carry a cookie, so there aren’t the same privacy implications.

      • Matt Thomas 4:15 pm on November 18, 2013 Permalink | Log in to Reply

        Thanks Dave, this is good information to have. Aside from the font format issue — I think we could get by with WOFF and SVG or TTF, based on the browsers we have chosen to support (others would just fall back to browser-standard sans-serif as in 3.7). But hinting and internationalization are big issues that will be thorny to solve with a bundled solution.

    • jwarren 11:14 am on November 13, 2013 Permalink | Log in to Reply

      I would suggest that bundling would be ideal – who know what strange systems WordPress could be running on if/when Google eventually deprecates their fonts service? It also keeps the experience consistent for any isolated environments. Local development away from a consistent internet connection is not an infrequent occurrence, and the fewer 404s, the better.

    • toscho 3:17 am on November 17, 2013 Permalink | Log in to Reply

      MIME types for fonts are not always set up properly on the web server. I just had such a case recently, where the browser showed garbage on first load because of that. The second load took the fonts from cache, and the browser applied the correct glyphs.

    • Louy Alakkad 2:25 pm on November 17, 2013 Permalink | Log in to Reply

      How about using the ‘open-sans’ fonts by default and giving the user three options in theme settings, first is open-sans, second is google fonts and third is downloading a plugin that contains all the fonts needed?

    • Anderton 1:08 am on November 18, 2013 Permalink | Log in to Reply

      Also, Google is blocked in some countries (i could for example not use Google Fonts in China now and then). Now this is no issue with the bundling open san. But for reference: http://www.google.com/transparencyreport/traffic/disruptions/#expand=Y2013

    • Milan Dinić 4:50 pm on November 18, 2013 Permalink | Log in to Reply

      I vote for ditching Open Sans for reasons already mentioned in this thread:

      • Why would we all of sudden rely on external service for essential part of WordPress that is admin area? Then why don’t we also load jQuery from Google, at least that way there would be real benefit since it would save billions of request?
      • Why would we decide which subset to use based just on WPLANG? What with those that use admin in English even though content is in other language? What for multilanguage? Some browsers don’t do proper fallback and we’ll end with squares and other garbage. If Open Sans gets in, all subsets should be included, that’s the price of using nonstandard font.
      • Possible server issues.
    • mor10 7:41 pm on November 19, 2013 Permalink | Log in to Reply

      For the default theme any custom font needs to be bundled for a simple reason: Not every WordPress installation runs on a computer connected to the web. There are many scenarios in which the site is not connected to the web: It could be a standalone application entirely severed from any network, it could be a site hosted on a secure intranet, the list goes on. As an external font library would result in a non-standard experience for these use scenarios I would encourage the inclusion of any custom font in the package itself. And for those same scenarios the inclusion of TTF and EOT might well be necessary since many of these users (European hospital intranets is one example) are stuck behind old system architecture that doesn’t support IE9 and above. Keep in mind that IE9 requires Windows 7, an update not yet undertaken by large parts of government and large industry landscapes.

    • Milan Dinić 5:11 pm on November 28, 2013 Permalink | Log in to Reply

      I have coded a simple plugin that disables loading of Open Sans from Google’s servers. If you have any comments about it (including its name), please share and I’ll submit it to repository in a few days.

    • mighty_mt 7:34 pm on December 10, 2013 Permalink | Log in to Reply

      So what’s the status here? I see in 3.8-RC2 (and also in MP6 2.2.1) that Open Sans is still loaded from Google. And to be honest, I don’t like that.
      I also think that WordPress shouldn’t use web fonts for the admin at all (especially not ones loaded from third party servers). Even though the new admin looks very pretty with Open Sans.

    • Alex Nguyen 1:48 am on December 15, 2013 Permalink | Log in to Reply

      Is there any way to disable Open Sans in the new 3.8 update? My blog is in Vietnamese and Open Sans does not display Vietnamese characters properly.

    • Paul 8:36 pm on December 19, 2013 Permalink | Log in to Reply

      Would love to dequeue open sans, it was a lovely idea but on a unstable african ISP its making editing on a clients site an unbearable experience – and I’m fairly privileged – honestly a standard stack would suit me fine, or just ‘sans-serif as someone suggested above.’. I really don’t thing open sans looks that great to boot.

    • ElectricFeet 12:44 pm on February 19, 2014 Permalink | Log in to Reply

      If it must be linked and not bundled (and I defer to your expertise on that decision), the best option would be to have a simple checkbox in “Edit my profile”: Use Google fonts for admin area?

      Apart from privacy concerns, linking on local dev environments really slows things down.

      (I’m using Milan’s plugin for now. Thatnks Milan!)

    • owcv 4:23 pm on February 24, 2014 Permalink | Log in to Reply

      I’m not happy with this kind of integration of Google on my WordPress Website. I don’t want big brother to watch my site. Open Sans should be included in WordPress but not linked to Google. At least there should be an option to deactivate for users in countries with certain information privacy policies. In the EU for example this could be a violation of actual law!

  • George Stephanis 10:35 pm on November 4, 2013 Permalink
    Tags:   

    Upcoming Global Admin Search (née Omnisearch) Meeting 

    After the feedback in the merge chat today, it looks like we’ve got a bit more work to do on the global search spine.

    Based on a quick survey, it looks like Monday, November 11, 20:00 UTC (3pm EST) is likely to be the best time for the most people.

    As we’ve done before, we’ll meet in #wordpress-core-plugins on Freenode, and I’ll give a shout in advance on #wordpress-dev for anyone that may be lurking in there.

    Putting up the bat-signal:

    Other folks who spoke up during the merge chat that I’d love to have join us:

     
  • Andrew Nacin 7:14 pm on November 1, 2013 Permalink
    Tags: ,   

    @matt will be running a WordPress 3.8 feature planning/decisions meeting on Monday, November 4, 21:00 UTC. Now that Daylight Saving Time has ended for both Europe and the U.S., note that the weekly Wednesday meeting is now moved from 20:00 UTC to 21:00 UTC (4 p.m. EST, 1 p.m. PST). (Americans, change your clocks on Sunday.)

    I’d strongly encourage everyone to study, test, and weigh in on the four 3.8 proposals before the meeting. I believe the goal of the meeting will be to establish what exactly gets merged into 3.8.

    API enhancements, bug fixes, etc. can/will continue as usual — it would be awesome if we had a surge not unlike 3.7. But for now, 3.7.1 is out, so stare at the download counter sip some tea, and relax this the weekend. :)

     
  • Samuel Sidler 11:27 pm on October 22, 2013 Permalink
    Tags: ,   

    Preparing your feature for the 3.8 merge 

    Now that 3.7 RC has shipped – and the final release is coming soon – it’s time to talk a bit more about how merging to core will work for feature plugins. First, let’s talk about decisions.

    Decisions

    I’ve been asked a few times “who decides” what goes in core and variants of that question. There’s actually three decisions that need to get made. In order:

    1. Does the feature belong in core?
    2. Is the feature ready for core?
    3. Should the feature be in this release?

    Core contributors and members of the community are strongly encouraged to help inform and guide each of these decisions. You may even want to offer some of your feedback in the form of answers to these questions. Each question is ultimately answered by a different group.

    1. Project leaders determine if a feature belongs in core.
    2. Contributing developers determine if a feature is ready for core.
    3. The release lead – for 3.8, @matt – determines if a feature belongs in a particular release.

    We’re now at the point where these questions need to get answered. To do that, it’s time to present your feature plugins.

    Present Your Feature

    If you remember back when we first started the feature plugin process, each team had to present its feature idea and answer a few questions. We’re going to do that again, but with a bit more information. If your project thinks it’s ready for core – and specifically for 3.8 – your team lead should make a post to make/core with the following information:

    • A visual and written overview of your feature plugin, along with a link to your plugin.
    • What problem is your feature plugin trying to solve?
    • What brought you to this solution and what other potential solutions did you explore?
    • Have you done user testing of your feature plugin? If so, what were the results? What worked and what didn’t?

    In your post, be sure to include links to previous posts and even specific comments that have helped form your decisions.

    Be ready for feedback from across the WordPress community – especially UX and code quality  – and be ready to defend your decisions or change your mind if a better idea emerges. Everyone will be reviewing the make/core posts and feedback in their discussion threads to determine if the answers to the questions above are all “yes”. If so, the feature can land when the merge window opens.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar