WordPress.org

Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • George Stephanis 2:31 pm on August 31, 2015 Permalink |
    Tags:   

    Two-Factor Auth Update 

    It’s been a couple weeks since our last update, but we’ve had some solid headway in the last couple days!

    Current status of default providers:

    • Email: In and works.
    • FIDO U2F: In and works, but only for PHP 5.3+ (library dependency, non-trivial to revise for 5.2)
    • Backup Codes: In and works.
    • TOTP (Google Authenticator): Pull request open (several, actually), I expect to see it merged in the next couple days.

    For the providers that are in and works, there may be minor issues either via code architecture or enhancements like better ui / ajax or whatnot — it’s just easier to solve those via small pull requests to master, versus endlessly debating in a pull request without actually merging it in. :)

    Application Passwords are also included in the plugin currently, however I’m not sure whether they should be a part of it or not in the end — they are included to allow users who use two-factor authentication to still use xml-rpc functionality, which can’t support two-factor authentication.

    For TOTP, we will need to be able to generate QR codes, and the de facto standard library I’ve found for generating them locally seems to be https://github.com/kazuhikoarase/qrcode-generator — which has both PHP and JS implementations and is MIT licensed. I’m currently leaning towards the JS implementation, but I’d be fine with PHP instead. Either way works just as easily.

    Please, test and report both errors and suggestions either on GitHub or on our Slack channel — #core-passwords.

    As always, our next chat will be on Thursday at 5pm Eastern, in #core-passwords.

     
    • JeanPaulH 2:58 pm on August 31, 2015 Permalink | Log in to Reply

      We’d love to have application password support, so please keep supporting this.

    • Aaron D. Campbell 3:18 pm on August 31, 2015 Permalink | Log in to Reply

      I think app passwords are important. I’m honestly wondering though if they shouldn’t basically be another provider (thus making them something that can be turned off rather than just not used).

      As for QR codes, I can definitely see the merits of both the JS and PHP methods. I still have a hard time breaking myself out of the old school rut of “don’t rely on JS”. It seems like using a PHP library would allow you to still function without JS while still using JS to augment and enhance the functionality (like regenerating the QR code via an httprequest.

      Having said that, the JS library I’ve used for this before was https://github.com/jeromeetienne/jquery-qrcode/ (also MIT). It still works well, but it looks like it hasn’t seen any love in the last year.

      • George Stephanis 3:15 pm on September 2, 2015 Permalink | Log in to Reply

        The jQuery QRCode library you linked actually just uses the one that I linked — https://github.com/jeromeetienne/jquery-qrcode/blob/master/src/qrcode.js — to generate the image itself. (like I said, it seems to be the de facto standard)

        I don’t think application passwords can be just another provider — as they aren’t used in the same way. They’re not used as the second step, and only work on non-interactive logins. That is, if someone has an Application Password, they should only be able to use it for xmlrpc or the like — not actually logging in to the admin panel as you.

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

    Shortcodes roadmap 

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

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

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

    What are shortcodes:

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

    What shortcodes are not:

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

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

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

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

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

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

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

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

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

      Where the output would be

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

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

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

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

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

        http://pastebin.com/1CMN731H

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

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

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

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

        Better would be:

        [my_shortcode class=my_class]

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

        [my_shortcode type=span class=my_span_class]

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

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

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

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

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

          Any thoughts on this?

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

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

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

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

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

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

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

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

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

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

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

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

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

        can simply become:

        <ul>[shortcode]<li>placeholders</li>[/shortcode]</ul>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      [shortcode]<h1>Title</h1>[/shortcode]
    • Dave Navarro, Jr. 4:20 pm on August 31, 2015 Permalink | Log in to Reply

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

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

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

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

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

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

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

  • Tammie 11:42 am on August 29, 2015 Permalink |
    Tags: , ,   

    Twenty Sixteen is now on Github! 

    To try things a bit differently this year, Twenty Sixteen is going to be developed on GitHub, just like a featured plugin, before it makes its way to core SVN and Trac. You can find it right here.

    Want to get involved? It’s as easy as creating an issue or PR on Github. There is a handy guide on how to contribute.

    Weekly meetings will be on Fridays and Mondays at 16:00 UTC in #core-themes. These will start on Friday 4th September.

    Everyone is invited to come and join in bringing Twenty Sixteen to life. Default themes are a great opportunity to get involved in contributing to WordPress!

     
  • Helen Hou-Sandi 12:57 pm on August 28, 2015 Permalink |
    Tags: ,   

    And the other guest committer for 4.4 is… 

    Now that he’s back from holiday, please join me in welcoming @afercia as a guest committer for the 4.4 release cycle! Andrea (pronounced the proper Italian way) has been invaluable with the huge strides the accessibility of WordPress has taken over the past several releases, lending his experience with accessibility methods and software and tenacity in iterating on patches. He’s also contributed many patches outside of accessibility changes as he’s gotten to know various parts of core. We’ve had a hard time keeping up with all of his work in such an important area of web development, so it’s our pleasure to hand him a set of reins to keep it going.

    In core Trac, we have many components and a number of what we’ve come to call focuses. Focus areas include things such as accessibility, UI, and JavaScript, and span multiple components, if not all of them. Building up expertise and trust in a component or focus is critical to maintaining WordPress over time. Commit access is a wonderful thing, but even as committers, we rely heavily on the recommendations of component and focus maintainers to keep tickets and patches moving. Without them, we’d get a lot less done. Andrea is a shining example of how this flow can dramatically improve a specific area of WordPress in a relatively short period of time with continued plans for improvement, and we want to see more and more of this happening. If you’d like to get started with maintainership, please join us in the #core Slack channel and ask about it.

    Congratulations, @afercia!

     
  • Boone Gorges 4:29 pm on August 27, 2015 Permalink |
    Tags: , ,   

    Taxonomy roadmap for 4.4 and beyond 

    In WordPress 4.3, we eliminated shared taxonomy terms once and for all. This means that, by the time WordPress 4.4 is released, just about every WordPress installation will have the same number of rows in the wp_terms and wp_term_taxonomy database tables.

    Why does this matter? When terms in different taxonomies could share the same term_id, terms could only be uniquely identified by a ID-taxonomy pair. This is why every nearly function in our taxonomy API has $term_id and $taxonomy as required arguments. (The decision was made long ago to keep the truly-unique term_taxonomy_id internal for most purposes.) The lack of unique IDs for terms made our API interfaces and internals complicated, and it made it cumbersome to add new features like term metadata.

    Now that term IDs are unique, we can begin the projects of unraveling the now-unneeded complications of the taxonomy API and adding new features that take advantage of the simplified data model. In this post, I’ll outline some of these tasks, and point to areas where interested folks can contribute.

    API simplification and other work on taxonomy internals

    Once each row in the wp_terms table corresponds to a single row in wp_term_taxonomy, there’s no point in having two separate tables (and all the JOINs that two tables require). In 2013, @nacin sketched how this might be done, through a combination of $wpdb tricks and a MySQL view. Here, we need someone to write a patch, and we also need to start a discussion about graceful failures for situations where there are still shared terms in the DB, as well as MySQL version compatibility (view functionality was phased in over the 5.0 series). The tracking ticket for simplification of the taxonomy database schema is #30262.

    With a single term table, we can begin to rewrite our internal SQL queries to remove costly table joins. This kind of refactoring is probably at least one version (and a hundred unit tests) away. In the meantime, we can begin the process of simplifying the API interfaces. For example, functions that accept term IDs, like get_term() no longer need to require an explicit taxonomy parameter.

    Having a unique identifiers for terms means this is also a good time to move toward WP_Term; see #14162. This class can start off being a fairly simple model that takes care of things like basic cache management and data integrity – see WP_Post – but over time, I envision moving business logic to the WP_Term, introducing convenience methods for chaining, and so on.

    Term Meta

    There’s been lots of clamoring for taxonomy term metadata #10142. Unique term IDs make it viable, since WP’s *_metadata() functions assume object IDs as identifiers.

    The technical implementation is not complex. We need wrappers for the CRUD functions, ‘meta_query’ support in get_terms(), an update routine to create the database table, metadata pre-caching (‘update_term_meta_cache’) when fetching terms, and maybe a few other small items.

    The larger challenge is to build a core solution that minimizes conflict with third-party tools. Developers have wanted termmeta for a long time, so there are many public plugins and private libraries that provide it. Many of them use unprefixed function names like update_term_meta(), and many of them use a database table called wp_termmeta. We should do a survey of publicly available plugins to get a sense of usage statistics and schema compatibility. We’ll need to organize outreach to developers of known plugins, so that they can add off-switches to their tools before termmeta appears in core. And we may decide to borrow code from one or more of the existing GPL-licensed tools, ideally with the participation of the original author.

    Let’s share this journey

    Many hands make light work. We need code, but more importantly, we need folks who are nuts about strategy and outreach and backward compatibility.

    There’ll be a meeting for all Taxonomy Heroes, on September 3 2015 20:00 UTC, in the #core channel on Slack. If you’re interested in helping out with any of these taxonomy projects, drop a comment below or come to the meeting. We’ll get a team or two together, and make a plan for 4.4 and beyond.

     
    • Scott Taylor 4:36 pm on August 27, 2015 Permalink | Log in to Reply

      You are an American treasure.

    • Felix Arntz 5:08 pm on August 27, 2015 Permalink | Log in to Reply

      That’s an awesome step, standardizing terms (when compared to posts) will make WordPress development a lot more intuitive. I’m looking forward to help, in any way possible! :)

    • imath 5:12 pm on August 27, 2015 Permalink | Log in to Reply

      Fantastic!

    • prettyboymp 5:42 pm on August 27, 2015 Permalink | Log in to Reply

      I know there are a lot of smart developers leading this and making these decisions, but I don’t think that adding meta to terms is the best path forward. I think it would be better to move towards a sunset of the terms tables altogether and add the ability to create direct relationships between post objects.

      The addition of term meta will introduce a new way for data to be represented and further reduce compatibility between different themes and plugins. The reason many developers want terms to have meta is because they need them to be more than just a word. Developers will now have to determine whether it is best to represent a data structure as a term or as a post object. The limitation right now is that you can only create a many to many relationship within the current schema by using terms. Wouldn’t it make more sense to move towards treating everything as an object and give the ability to create many to many relationships between any of them?

      • Boone Gorges 5:59 pm on August 27, 2015 Permalink | Log in to Reply

        > I think it would be better to move towards a sunset of the terms tables altogether and add the ability to create direct relationships between post objects.

        I would agree with this more if the post schema (and the “post type” API) had been more explicitly designed for general “object” use. One of the virtues of the taxonomy schema as it currently stands is that it’s fast – it doesn’t store a lot of data (like longtext), and the tables can be joined efficiently. wp_term_relationships is, in fact, a relationship table like what you’re suggesting for posts. The post schema, on the other hand, is loaded with fields that are of questionable value for general objects, fields that make queries cumbersome and resource-intensive. (A related concern, which I think is very legitimate, is that introducing term meta – and especially term meta queries – is going to slow down what is currently a fast API. This is something we should definitely discuss as a part of the initiative.)

        As for the question of whether this “further reduces compatibility between different themes and plugins”, I don’t really agree. In theory, a purely node-based system like Drupal means that all data types can work with all other data types. But how this gets fleshed out by developers and within UIs is far from a foregone conclusion.

        Moveover, by introducing greater parity between the Post and Term APIs, an argument could be made that we’re *increasing* compatibility between various WP components, at least as far as the developer experience is concerned. The API interfaces will be similar enough that it’s possible to imagine building tools that will talk to either terms or posts with a minimal layer of abstraction.

        In any case, these are helpful thoughts, and I hope you’ll think about coming and arguing them next Thursday :-)

        • Mike Schinkel 6:54 am on August 28, 2015 Permalink | Log in to Reply

          While I am somewhat on the fence about this, I am leaning towards what @prettyboymp said. Rather than blindly adding term meta, it probably makes good sense to first ask if there is actually not a better way.

          For example, what if the post table were split in two, allowing for a lightweight version with limited fields and a heavy version using a join will full fields? It is possible that could also result in significant performance savings when working with posts in addition to making terms less of a special case.

          Note I am not saying this specific idea makes sense (or that it does not), I’m only saying that it would be good to open the floor for alternate strawmen proposals with subsequent discussion before committing to any one particular direction.

          • Boone Gorges 1:55 pm on August 28, 2015 Permalink | Log in to Reply

            I totally agree that we shouldn’t jump into term meta without discussing whether it’s the right thing to do. I meant to say that in the post, but there were so darn many things to say :)

            That being said, while I think it’s good to brainstorm and think big, I don’t want to be unrealistic. Massive schema and API changes take huge amounts of effort and time. I don’t want to get so sidetracked talking about a complete rearchitecture of WordPress that we lose track of the very real improvements we can make today – improvements that are often compatible with future changes.

            The one larger item I do want to flag for discussion is a general relationships API. Since Taxonomy already contains a relationship table, I want to make sure that any changes we make in that component don’t block the future development of object-object relationship functionality.

    • SanjayaBhai 6:12 pm on August 27, 2015 Permalink | Log in to Reply

      Wosome Fantastic 😀

    • leemon 6:26 pm on August 27, 2015 Permalink | Log in to Reply

      Many many thanks for championing this feature! :)

    • marsjaninzmarsa 6:53 pm on August 27, 2015 Permalink | Log in to Reply

      Count me in of course. :)

    • MatheusGimenez 10:57 pm on August 27, 2015 Permalink | Log in to Reply

      Great! Term meta is a very necessary function. :)

    • natebald 2:18 am on August 31, 2015 Permalink | Log in to Reply

      Hi, can someone explain what this means for sites that different post types uses the same taxonomy? I am unclear what the end result will be if the site is updated. Thank you in advance.

      • Boone Gorges 12:08 pm on August 31, 2015 Permalink | Log in to Reply

        natebald – The scenario you’ve described here is unaffected by any of these changes. The elimination of “shared terms” is about specific *terms* that are shared between multiple taxonomies.

    • texteditor 2:57 pm on August 31, 2015 Permalink | Log in to Reply

      Greetings. Please count me in with this discussion. I built a site for our university that serves e-textbooks in various download formats. I needed to group the download format types together and associate them with their respective posts. I wrote a query joining term relationships, term taxonomy, terms, and post meta among other things. It serves the purpose very well, but I am certain the upcoming 4.4 changes would affect our site. I can show you our site and the queries during the conference. Thank you in advance.

    • masonjames 10:05 pm on August 31, 2015 Permalink | Log in to Reply

      “We need code, but more importantly, we need folks who are nuts about strategy and outreach and backward compatibility.”

      Welp. You had me at “we need folks who are nuts”

    • Marin Atanasov 8:26 pm on September 3, 2015 Permalink | Log in to Reply

      Wow, this is exciting. I’ve been waiting for that since 2.8.

      It would be awesome to get that in 4.4. But too many things to consider. I’d love to help with any patches, testing or opinion here! :)

  • Scott Taylor 7:33 pm on August 26, 2015 Permalink |
    Tags: ,   

    Notes/Agenda – 4.4 Dev Chat, August 26 

    Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

    Time/Date: Wednesday, August 12, 2015 16:00 UTC-4:

    1. New Committers were announced 
    2. Who wants to be the backup lead?
    3. Schedule is still being decided, looking at WordCamp US timetables
    4. Community Feedback

    What’s going to be in 4.4?

    There is still a lot to decide this week, but there are some things I know for sure we want to work on:

    Twenty Sixteen

    Announcement Post: https://make.wordpress.org/core/2015/08/25/introducing-twenty-sixteen/

    Responsive Images

    Update Post: https://make.wordpress.org/core/2015/08/25/responsive-image-support-update/

    ImageFlow

    This will be worked on in a feature plugin, coupled with a healthy dose of user testing and intersecting with Boren’s Flow Patrol initiative. @sheri is going to help me with/teach me user testing, which will drive any new UX/UI media desktop/mobile/responsive initiatives.

    Customizer Performance

    @westonruter and team have some GREAT initiatives:

    HTTP 2.0 Exploration

    @tollmanz has been giving great talks about HTTP/2. He and @ericlewis are going to deep-dive and see how WordPress can prepare itself/the community for taking advantage of HTTPS/TLS/HTTP2 and identify changes that can be made in core and things like VVV to get us there.

    Media Widget

    @sheri and @melchoyce worked on this in 4.3 – we hope to pick this up again

    Mutlisite, the Next Generation

    @jeremyfelt is putting together a plan for WP_Site, WP_Network, WP_Network_Query, WP_Site_Query

    The Taxonomy Roadmap

    A lot of people want Term Meta, it has some pre-reqs. @boone will give us an update of where we are in the Taxonomy Roadmap, what we’ve done, what’s left, etc.

    Things that landed in the past week

    • Images should default to not linking #31467 [33729]
    • WP_Embed::maybe_run_ajax_cache() now runs for pages [33642]
    • Term Splitting: Fix a reversal of parameters to wp_schedule_single_event() introduced in r33621. [33646]
    • Introduce post_name__in parameter for WP_Query. [33653]
    • Comments shouldn’t have more than one _wp_trash_meta_status entry. When deleting _wp_trash_meta_status, also delete _wp_trash_meta_time. [33654]
    • Show count next to “Approved”/fix dynamic counts when moderating comments: [33655][33656][33657][33662][33692]
    • Ensure that feeds are served with the proper Content-Type HTTP header. [33658]
    • Deprecate post_permalink() [33659]
    • Introduce is_post_type_viewable( $post_type_object )/Don’t show certain UI pieces when a post is not viewable on the front end [33666]
    • 'post_edit_category_parent_dropdown_args' filter [33682]
    • new filters: default_hidden_columns and hidden_columns [33689]
    • Add new constant: MONTH_IN_SECONDS [33698]
    • Ensure that attachment_url_to_postid() matches cross-scheme when front-end and back-end schemes are different. [33705]
    • Add a query var, 'title', that allows you to query posts by post_title. [33706]
    • In wp_sanitize_redirect(), don’t eat @ characters. [33707]
    • In wp_insert_user(), add a filter: 'insert_user_meta' [33708]
    • wpdb::get_table_from_query() didn’t find table names with hyphens in them. [33718]
    • oEmbed: Remove blip.tv [33719], add ReverbNation [33745]
    • In WP_Query::parse_tax_query(), allow 'cat' and 'tag' querystrings to be formatted as arrays. [33724]
    • Multisite: Add 'invite_user' action that fires immediately after a user is invited to join a site, but before the notification is sent. [33732]
    • Pass option name to option and transient filters with dynamic names. [33738]
    • Move a lot of classes into their own file, same with functions, load both in the original file: Widgets [33746] HTTP [33748] Users [33749] Comments [33750] Rewrite [33751] Roles [33752] Posts [33759] Tax [33760] Meta [33761]
     
  • Helen Hou-Sandi 7:00 pm on August 26, 2015 Permalink |
    Tags: ,   

    New committers for 4.4! 

    It’s that time again… Please join me in welcoming Tammie Lister (@karmatosed) as a guest committer for WordPress 4.4. There’s another committer to be announced, but we thought we’d wait until he’s back from vacation for a proper welcome.

    You may recognize Tammie from her role as an admin on the theme review team, and she’s also a theme developer extraordinaire at Automattic. Tammie will be heading up development of the new default theme, Twenty Sixteen.

    The lead developers review and appoint new committers to serve each release cycle, often to work on a particular component or feature. This guest commit access comes up for review after each release and can be renewed. Ella Van Dorpe, Konstantin Obenland, and Weston Ruter, all new committers at the beginning of the 4.3 cycle, have been renewed for 4.4.

    Over the last few cycles, both Aaron Jorbin and Jeremy Felt have been working through long-term plans, smashing through tickets, and improving the entire codebase, especially when it comes to tests and multisite. I’m happy to announce that both are now permanent committers. Please join me in congratulating everyone!

     
  • Joe McGill 11:35 pm on August 25, 2015 Permalink |
    Tags: , respimg   

    Update: Responsive Image Support for Core 

    The responsive image team has been meeting regularly for a while. After our meeting earlier this week, we realized that make/core needs an update on what’s been going on with the RICG (Responsive Images Community Group) feature plugin, as well as to request feedback on a few questions.

    Our meetings are in #feature-respimg each Friday at 1900 UTC, so please come and chat to give feedback or if you’re interested in helping out!

    Background

    Several years ago, a ragtag group of web professionals identified a need for new HTML markup which would allow developers to declare multiple sources for an image—allowing devices to select the image source that was most appropriate for its own capabilities. Fast forward to today and all major browsers have either implemented these new tools or currently have them under consideration for development.

    With that as background, the RICG has been working on an Official WordPress Feature Plugin™ to test the viability of adding responsive image support natively into WordPress. Specifically, our aim is to automatically add srcset (using w descriptors) and sizes attributes to the image markup generated by WordPress. According to the WordPress.org plugin directory, there are over 10k active installs, so we’ve definitely seen an interest in this functionality.

    There are two main pieces of functionality included in the plugin, which can be considered separately for inclusion in core:

    1. Logic for producing responsive image markup
    2. Advanced image compression (via ImageMagick)

    Responsive Image Markup

    There is a lot to consider when proposing a change to the way WordPress outputs image markup, so I want to be clear about some of our assumptions going in:

    • Responsive image support should be added ‘invisibly’ without introducing new settings for users to worry about.
    • WordPress, out of the box, should only deal with resolution switching, and not the art direction use case for now. In other words, we would not be adding any API or admin UI for outputting different cropped images at specific breakpoints. (For more information about use cases and all things related to responsive images, I’d recommend reading the terrific Responsive Image 101 series by Jason Grigsby).
    • Provide this functionality using default and available user-defined sizes (via add_image_size()) for source sets rather than creating an additional set of crops. This choice is based on early feedback from Nacin regarding file-count concerns on some shared hosts.
    • Provide filter hooks so theme/plugin authors can extend/override defaults.
    • All sizes of an image (i.e., _wp_attachment_metadata['sizes']) with the same aspect ratio are resized versions of the same image, not custom art directed crops. This assumption has been okay so far, but there may be be plugins that replace the default image sizes with art directed crops that maintain the same aspect ratio. We’ll need to determine how to handle these cases.

    Questions to Consider

    1. How should we handle markup embedded in post content?
      • Currently, we embed the srcset attribute directly into posts with sizes added as a data attribute to make it easier for theme authors to filter the sizes attribute later. It’s tricky to decide when it’s appropriate to add layout relative markup to the database, but WordPress is currently doing this to a certain extent by adding width/height attributes to images, so this may be the best solution for now.
      • Instead, a more elegant solution would be to filter the content on output. This would avoid saving layout markup in the database, and extend support to posts with images that were published before the feature became available. We have a proof of concept but are unsure if adding another filter to the_content is appropriate. Confirmation either way on this question would help us move forward.
    2. Should we support srcset and sizes in older browsers?
      • The plugin includes the picturefill.js polyfill, which provides support for older browsers, but would be a new dependency for core.
      • We could view srcset and sizes as a progressive enhancement and only provide support in WordPress for newer browsers. In that case, we could drop the polyfill and save WordPress an extra JS dependency. Note that this polyfill is written by the same people writing and implementing the spec. We consider it to be very reliable.
    3. Should we turn responsive image support on by default?
      • “Decisions not options.” We propose that responsive images are enabled by default in core, with filters provided for disabling or modifying the feature.
      • If core does not want responsive images enabled by default, they could be enabled through a current_theme_supports() flag. Themes would have to “opt-in” to the feature.

    Advanced Image Compression

    The second potential enhancement introduced through our plugin is an improvement to the default ImageMagick compression settings currently being used in core. RICG contributor Dave Newton has done great research on the best compression settings for ImageMagick, and included them as an opt-in option within the plugin.

    The updated settings are absolutely killer when there are sufficient CPU and memory resources on the host server. In our trials, file sizes have decreased by >50% compared to the default core settings.

    However, on limited servers, these new settings could cause problems. We are iterating on them to find the right balance between the file-size savings and the CPU resources required to process large files.

    Final Notes

    We need your help!

    New features need lots of feedback and testing. Help us test these enhancements by installing the latest version of the plugin from WordPress.org.

    Be sure to enable advanced image compression and tell us how it does with your setup so we can gather more feedback.

    If you know of plugins that heavily modify or interact with custom image sizes or art-directed crops, please leave a comment below so we can test it with this feature.

    Have thoughts on the questions above? Let us know in the comments!

    Want to get involved? We meet each week in #feature-respimg on Friday at 1900 UTC.

     
    • Ahmad Awais 1:08 am on August 26, 2015 Permalink | Log in to Reply

      Will join the next meeting. Let’s do it.

    • bravokeyl 1:58 am on August 26, 2015 Permalink | Log in to Reply

      It’s a good one , but is “ element getting traction from specifications ?

      • wilto 2:49 pm on August 26, 2015 Permalink | Log in to Reply

        Yes indeed! All of the markup patterns used by the plugin are part of the HTML Living Standard:
        https://html.spec.whatwg.org/multipage/embedded-content.html#embedded-content

        While the plugin is using Picturefill for the sake of older browsers, all modern browser support this markup natively to some extent—current versions of Firefox and Chrome support it fully, while Safari and Microsoft Edge have partial support. Picturefill polyfills these features in a granular way, so anything that can work natively will, while anything without native support will be shimmed.

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

      For the HiDPI Gravatars plugin, I’ve been referencing caniuse.com with the “Usage Relative” option selected. We really are at the point now where Internet Explorer 11 is the only significant browser without support for srcset. Decide accordingly. Is it really worth adding core bloat to support IE 11? Would it benefit anyone other than Surface users? Are the accessibility benefits for desktop just as easily acheived in Chrome?

      • Joe McGill 2:00 pm on August 26, 2015 Permalink | Log in to Reply

        This is almost true. As of today, Safari only supports `srcset` with x descriptors so the polyfill is still needed to support w descriptors and `sizes`. There are signs that the next version will include full support, but that is currently not the case.

    • Michael Arestad 2:21 am on August 26, 2015 Permalink | Log in to Reply

      > 2. Should we support srcset and sizes in older browsers?

      No. No need. this can gracefully degrade.

      > 3. Should we turn responsive image support on by default?

      This is definitely the hardest question and might answer itself during larger-scale testing. Going forward, it would make sense to unless it breaks a bunch of themes that do crop the attachment images (or do something else funky).

      • Joe McGill 2:07 pm on August 26, 2015 Permalink | Log in to Reply

        Thanks Michael,

        As a counter argument for supporting srcset and sizes in older browsers: with many older devices being in use around the world, I wonder if the addition of the polyfill—at just over 11kb minified—is worth the potential bandwidth savings that would be gained by potentially loading smaller image sources.

    • padams 6:25 am on August 26, 2015 Permalink | Log in to Reply

      Responsive images are probably not going to be very useful unless the theme itself has a responsive design. Did you guys think about making themes declare support for responsive images instead of making it a global on/off setting?

      • tevko 1:13 am on August 27, 2015 Permalink | Log in to Reply

        Hey padams, since we’re using the srcset attribute with sizes, responsive images will help regardless of fixed width or fluid designs. This is because the srcset / sizes combination works to deliver the best image size based on the users screen resolution and viewport width. This means that two different devices at the same width could get a different image, simply because their screen resolutions are different. This is great for the user because it means that their device will get the best looking image regardless of viewport size.

    • Monika 6:42 am on August 26, 2015 Permalink | Log in to Reply

      >> 3. Should we turn responsive image support on by default?

      >>>If core does not want responsive images enabled by default, they could be enabled through a current_theme_supports() flag. Themes would have to “opt-in” to the feature.

      yes please!

      Why:
      1. RICG This plugin works by including all available image sizes for each image upload.

      Most of the time we don’t need “all” image sizes , thats why I preferr
      https://wordpress.org/plugins/responsify-wp/

      it is easier to use as RICG if I don’t want all image sizes

      Feedback: If I’m using: ‘advanced-image-compression

      my upload failes
      256php memory

    • kuzvac 7:11 am on August 26, 2015 Permalink | Log in to Reply

      Please use “picture” element instead of srcset! Picture element already have backward compatibility to older browsers. https://dev.opera.com/articles/native-responsive-images/
      And use cases https://dev.opera.com/articles/responsive-images/
      And progressive jpg, god, yes.

      • wilto 2:54 pm on August 26, 2015 Permalink | Log in to Reply

        For a “fully automated” situation like this one, we’re apt to get a much better result using `srcset`/`sizes`. `picture` is intended for “art direction” use cases, where there’s a need to set explicit and very specific breakpoints based on the viewport, with the image sources themselves varying slightly. All the `srcset` syntaxes, however, allow the browser to choose the best fit from a list of sources that are identical (apart from their dimensions). `srcset` factor’s in the user’s display density, the size of the image _in the layout_ (rather than based on the viewport), and soon additional factors like a user preference or a bandwidth cap. Since WP will be generating all the different cuts of an image, we end up with something completely seamless: smaller images for the user and no wall of breakpoint decisions for the image uploader.

        And no worries about backwards compatibility—that’s covered with `srcset` as well, either via Picturefill or via the old-fashioned `src` attribute on `img`.

    • Brad Touesnard 11:48 am on August 26, 2015 Permalink | Log in to Reply

      > 2. Should we support srcset and sizes in older browsers?

      I think by default they should not be supported in older browsers, but it should be easy to just install & activate an official plugin to enable them for older browsers.

      > 3. Should we turn responsive image support on by default?

      I suggested the `current_theme_supports()` flag on Slack. I think it should be up to the theme to turn on responsive image support. If the theme is designed for WordPress’ current image resizing it’s not very likely to work well with responsive images.

      I’d like to see the image compression stuff spun off into it’s own independent plugin. Is there a reason it is lumped in with the responsive image stuff?

      • tevko 1:31 am on August 27, 2015 Permalink | Log in to Reply

        Hey Brad, thanks for the feedback.

        Regarding your first point, seeing that RICG Responsive Images is the official plugin, and that plugin provides fallback support, it would seem natural to assume that if integrated into WP Core, fallback support would also be provided.

        Additionally, being an interfaceless plugin that runs behind the scenes, it wouldn’t be readily apparent to users that something else would need to be installed in order to provide fallback support. I think bundling a small polyfill in with the feature would make it easiest on all users. The ability to dequeue the polyfill also exists and has been documented here – https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images#tevkori_get_srcset_string-id-size-

    • John Huebner 12:36 pm on August 26, 2015 Permalink | Log in to Reply

      > In other words, we would not be adding any API or admin UI for outputting different cropped images at specific breakpoints.

      Just my thoughts on this one aspect. While it would be great to have something built into WP automatically handle responsive images, without the ability to specify different images this will not be of much value in the work that I’m required to do. Using the automatically generated images will only be of use to the most generic users. I don’t think I have a single client that would be happy with this model, which is why I don’t use the plugin mentioned.

      • wilto 3:01 pm on August 26, 2015 Permalink | Log in to Reply

        We’re totally agreed that the “art direction” use case covered by the `picture` element—and the accompanying UI changes that would have to go into uploading images—is a valuable one. It’s in the planning stages now.

        However, just like you said, this _is_ a feature of use to the most generic users: anyone putting together a responsive theme that contains large images. If you’ve got visitors to your site using small viewports or low-density displays and you’ve got a theme that contains large or high-resolution images, adding this feature to core ensures that you’re not serving massive images to small viewports or high-density images to low-density displays—situations where the user will see no benefit, but be forced to incur an additional cost.

        It’s better to think of this as a behind-the-scenes enhancement to images, rather than a situation where your client will need to pick and choose breakpoints. Rolling out these features on FT.com resulted in a 66% reduction in image weight*. On my current project we’re looking at an ~80% reduction on 320px, low-density displays, without any changes to the uploader workflow.

    • Nicolas Juen 3:32 pm on August 26, 2015 Permalink | Log in to Reply

      Hi,
      I’m glad this feature is coming to the core, in my agency we are already using a custom solution for this consisting of this plugin (https://github.com/asadowski10/advanced-responsive-images) + WP_Thumb.
      The difference here is that the frontend developper is defining locations on json file, and associate image sizes + breakpoints wich are defined in one other file.
      Then on post_thumbnail function we call with one arg (data-location) with the location defined on json file. This allow us to handle multiple display cases, like in the slider, content, widget area etc.

      Is this conception have been tough ? Is this core functionnality will be hackable so we can do like this ?
      We are using picture fill too but it’s not compatible with lazyload, some libraries do and use the picture element, wich is pretty different from srcset.

    • Ricard Torres 8:18 pm on August 26, 2015 Permalink | Log in to Reply

      One of the top plugins out there that deals with images: https://wordpress.org/plugins/regenerate-thumbnails/

    • Phil Smart 11:57 pm on August 26, 2015 Permalink | Log in to Reply

      I’m just going to weight in quickly and say that I actually like the idea of what the Fusion guys are exploring with their plugin, Image Shortcake (http://fusion.net/story/144755/introducing-image-shortcake-v0-1-0/).

      Their basic approach is to add images to TinyMCE as shortcodes – instead of direct markup – giving them the flexibility to dynamically implement whatever specific markup they need.

      I know it’s a stepping a little deeper than straight up responsive image support, but storing images as shortcodes does seem to be a great starting point for then folding in (and easily updating) necessary markup.

    • Morten Rand-Hendriksen 5:14 pm on August 27, 2015 Permalink | Log in to Reply

      Quick answers:

      1. As you probably know from my blog posts, I am a proponent of the filter-on-output solution. For responsive images to work as effectively as the spec allows, theme and plugin devs have to be able to define the actual display sizes of images through variables. For that to work, the HTML output must be filtered based on current theme and plugins. This will cause some issues with caching services and CDNs, but I think that’s a minor concern. The one thing I hope can be avoided is the blanket approach of sizes=”100w, [original_image_size]”

      2. Backwards compatibility within reason is impoetatn because those that will benefit the most from this development (people on slow / low bandwidth / expensive connections and older devices) often use older browsers.

      3. Yes, turn it on by default. This should be invisible and transparent. We have a major opportunity here to use WordPress to push web standards forward, and that cannonly happen if we make some serious commitments like this.

      Great work to everyone who has been working on this. I am very excited about this plugin and its potential.

  • Scott Taylor 5:15 pm on August 25, 2015 Permalink |
    Tags:   

    Show Me Your WP REST API v2 Apps 

    WordPress 4.4 development hit the ground running last week, only a few hours after the launch of 4.3. We’re already close to 100 commits, and digging through the 385 responses on my “what’s on your wishlist” post. One feature that many of you want is the WP REST API (heard of it?). Lots of work has gone into it, and some people are already using a flavor of it in production – two that I know of:

    Both use version 1.*. I am working on an upgrade path for the NYT to version 2.

    The point of this post is to solicit feedback from the general community:

    • What have you built using v2 of the REST API?
    • Are you running the project in production? If so, please post a link :)
    • Have you upgraded from v1 to v2? If so, how was it?
    • If you believe in the project, would like to see it in core, and haven’t built anything with it: what’s stopping you?

    Let’s take the excitement everyone has for the feature and start stress-testing it. Build something. Anything! And then report your findings back here.

     
    • Scott Bolinger 5:34 pm on August 25, 2015 Permalink | Log in to Reply

      The WP-App Project is using v2. It’s still under development, but making good progress: https://github.com/wp-app/wp-app

      I like v2 better than v1, it’s coming along great. One thing that’s still really difficult is authentication from 3rd party clients (like mobile apps). It won’t be possible to build a widely used mobile app until OAuth is in core, with a simple way to create tokens.

    • prionkor 5:35 pm on August 25, 2015 Permalink | Log in to Reply

      I have built an EmberJS app top of WP REST API. Unfortunately it is not live yet :)

    • JS Morisset 5:43 pm on August 25, 2015 Permalink | Log in to Reply

      WPSSO has support for REST API v2 — it adds a new ‘head’ field that contains two arrays: the ‘html’ array is a list of all social meta tags created by WPSSO for that post/term/user, and the ‘parts’ array provides the same, but with each meta tag exploded into its parts. See http://wpsso.com/codex/plugins/wpsso/notes/modules/wordpress-rest-api-v2/ for an example post REST API response.

      js.

    • Florian Girardey 5:43 pm on August 25, 2015 Permalink | Log in to Reply

      I have built a little Backbone application with the WP REST API v1.
      An iOS and Android app is currently in development.
      They only use my own custom endpoints, so i’m about to try a v1 to v2 update.

      My question is : When the WP REST API will meet the core (maybe in the 4.4?) if my apps are still running on WP REST API v1, did the update will broke my apps ?

      Maybe a way to make the feature plugin take over the core in the first place would be great.

    • Justin Sainton 5:51 pm on August 25, 2015 Permalink | Log in to Reply

      We’re working on v2 integration for WP eCommerce – https://github.com/wp-e-commerce/WP-e-Commerce/tree/feature/rest-api. Basically just barely stubbed out right now, but I’m hoping to be able to devote a few weeks to it next month. Should have a lot more to report back at that point.

    • Adam Silverstein 6:50 pm on August 25, 2015 Permalink | Log in to Reply

      I built a very simple demo Backbone app on top of the v1 api, then updated it to use v2.

      Main pain points were lack of documentation (at the time) and changes in the api between versions.

      https://github.com/adamsilverstein/backbone-demo

    • J.D. Grimes 7:04 pm on August 25, 2015 Permalink | Log in to Reply

      I played around with v1 a while back, but I have yet to build anything with v2. I’m one of those people in your 4th category: I believe in the project and want to see it in core, but I haven’t built anything with it yet. So I’ll try to explain why. It isn’t because I don’t want to, or that I’m waiting for the API to mature. It is because I don’t have time to build something that people can’t use. If the API was in core, I would be building something with it right now. Yes, literally. I’m building a feature in a plugin right now that could use it, but I’m using wp_ajax_* instead, because that is the API that core offers. From the perspective of a plugin developer wanting to extend the API and add their own endpoints, the REST API is a developer feature. And I’m not going to ask users to install a developer tool just so they can use my completely unrelated plugin—even if that tool is itself a plugin. I really don’t think usage of the API by plugins will ever take off unless it is in core. Not because it isn’t nice to use, but because it currently requires duplication of work, and folks just can’t do that. I think that is the biggest pain-point for a lot of people :).

    • martijnn94 7:08 pm on August 25, 2015 Permalink | Log in to Reply

      Working an a vacancy site at the moment on V2, already so satified compared to projects I made with V1. Especially the easy way to manipulate and add data to the response which wasnt easaly possible in V1.

      Had to hack V1 basicly to make it possible to create a multiple tax query with soring on distance based on coordinates. Way easier in V2!

      Using Angular for both of the projects!

    • Mike Nelson 8:20 pm on August 25, 2015 Permalink | Log in to Reply

      We extended the REST API to serve Event Espresso data (lots of it in custom tables) using v1. We looked into v2 but figured we’d stick with whatever’s considered “stable”.
      We built a few code samples to show how to use our integration. One of them is a calendar that shows Event Espresso events and fetches the data from a separate server. Initially, however, we had cross-site scripting issues because it didn’t want to send an ajax request to a different domain (because the demo calendar was hosted on a separate server than where the Event Espresso data was contained), and so we needed to activate the CORS REST API addon which currently only works with v1 (and it’s not even considered stable for v1).
      I would think that it would be a fairly frequent occurence that siteA wants to fetch REST API data from siteB over javascript, no?
      So I guess this is mostly a vote for adding CORS support to v2. Maybe just in an addon for now, but I wouldn’t object to it being added to core either.

    • borekb 9:53 pm on August 25, 2015 Permalink | Log in to Reply

      The admin screens of VersionPress 2.0 are being built in JavaScript / React, talking to the backend using WP REST API v2. http://versionpress.net/

    • Lester Chan 2:07 am on August 26, 2015 Permalink | Log in to Reply

      I am using v1, but since v2 is not backward compatible, I will guess I have to wait.

    • Rouven Hurling 5:48 am on August 26, 2015 Permalink | Log in to Reply

      I’m using v1 in a custom backend.
      I did a trial update to v2 just before the last beta got out (which broke some of my changes).
      For me the update was pretty easy, once I figured out which functions I needed to use, which took a while and some questions in the slack channel, because some of them weren’t in the docs (new register_post_type args for example).

    • brad989 5:53 am on August 26, 2015 Permalink | Log in to Reply

      I’m using v2 in an AngularJS powered theme. http://demo.redeyetheme.com

    • kokarn 9:24 am on August 26, 2015 Permalink | Log in to Reply

      IKEA Sweden’s restaurant pages is built with V1.

      http://www.ikea.com/ms/sv_SE/restaurang/index.html

    • NateWr 3:00 pm on August 26, 2015 Permalink | Log in to Reply

      Not quite production, but getting close to release. Gonna go with the beta and hope for the best. Did not transition from v1 to v2. Outline of a couple projects I’m using it on here:

      https://make.wordpress.org/core/2015/07/23/rest-api-whos-using-this-thing/#comment-26367

      I’d also like to make use of it in some of my free plugin development. But obviously can’t touch it until it’s in core. Not going to bundle it. Seems like a maintenance nightmare.

    • Matthew Haines-Young 3:01 pm on August 26, 2015 Permalink | Log in to Reply

      We’ve just launced a new website for the digital product studio Ustwo ustwo.com. Built on V2.

      The front facing site is built in React and runs on a Node server totally separate from the WP install used to manage all the content.

      As well as using the standard endpoints, we have written quite a few custom ones too, and V2 of the API made this really easy to do.

    • Jake Spurlock 4:30 pm on August 26, 2015 Permalink | Log in to Reply

      In addition the data sync we built, we also use the JSON API for the WIRED liveblog, using React for rendering. Example here: http://www.wired.com/2015/06/apple-wwdc-liveblog/

    • Tanner Moushey 5:58 pm on August 26, 2015 Permalink | Log in to Reply

      I’m using V2 for the StudyChurch study builder along with Backbone js. You can see it in action here

    • Dave Navarro, Jr. 5:58 pm on August 26, 2015 Permalink | Log in to Reply

      I am using v1 to share posts between multiple web sites. I’ve been porting it to v2, but it’s been difficult as there are significant differences.

      I’ve also not been able to get v2 to let me access user data, which is causing delays on a project for syncing users between multiple sites.

    • Mustafa Uysal 11:42 am on August 28, 2015 Permalink | Log in to Reply

      We are using v1 on the nefisyemektarifleri. Here is the video https://www.youtube.com/watch?v=kuErLgmJEbs

    • Huseyin Berberoglu 2:50 pm on August 28, 2015 Permalink | Log in to Reply

      As Mustafa said; we are using v1 on the nefisyemektarifleri.com to communicate with our native applications. We have a lot of custom services.

      Our application downloaded more than 1 million and selected for interview by Google. The interview published yesterday on Google Developers YouTube channel. Here is the video https://www.youtube.com/watch?v=kuErLgmJEbs

      See our application in action (only Turkish recipes); Android: https://play.google.com/store/apps/details?id=com.nefisyemektarifleri.android iOS: https://itunes.apple.com/us/app/nefis-yemek-tarifleri/id947863045

      (same video link with more explanation)

  • Tammie 2:51 pm on August 25, 2015 Permalink |
    Tags: , ,   

    Introducing Twenty Sixteen 

    WordPress 4.4 will see a brand new default theme; that’s right, today is time to meet Twenty Sixteen! The process of selecting the Twenty Sixteen theme was a long one, taking several months. Lots of themes were considered, eventually settling on the one you see below. It’s a perfect fit!

    00.twentysixteen

    Twenty Sixteen features a new, never-released design that has some really unique touches on a traditional blog layout. It adapts well to different devices and is a joy to use.

    Twenty Sixteen is a modernised approach of an ever-popular layout — a horizontal masthead and an optional right sidebar that works well with both blogs and websites. It has custom color options that allow you to make your own Twenty Sixteen. The theme was designed on a harmonious fluid grid with a mobile first approach. This means it looks great on any device.
    – @iamtakashi

    Let’s take a look at more!

    We have the pleasure of welcoming back Takashi Irie as the designer of Twenty Sixteen. This year, the core team developing our new default theme will be myself and @iamtakashi — and you! We hope you can join us in getting Twenty Sixteen out to the world. Along with us, @iandstewart and @samuelsidler will be making sure the ship stays on course and giving us their wisdom as we charter the default theme seas.

    How can you get involved?

    There will be weekly meetings every Monday and Friday 16:00 UTC in #core-themes for half an hour. These weekly meetings will start once the theme has initially landed in core. If you are interested in contributing, subscribe to this blog (if you haven’t already), and leave your name in the comments. Once we’re ready, we will give everyone a ping and we’ll let you know on this blog too.

    Want to know more about default themes?

    There are some great links where you can find out more about past default themes.

    The road to releasing a new default theme is long, but we’re already well on our way! The next step is to commit the initial code to core. From there, we will begin testing and patching. We hope you join in the adventure of releasing Twenty Sixteen.

     
    • Nikhil Vimal 2:54 pm on August 25, 2015 Permalink | Log in to Reply

      I would be interested in helping!

    • Frankie Jarrett 2:57 pm on August 25, 2015 Permalink | Log in to Reply

      Pretty :-)

    • Drew Jaynes 3:05 pm on August 25, 2015 Permalink | Log in to Reply

      Congrats all around!

    • Ciprian 3:11 pm on August 25, 2015 Permalink | Log in to Reply

      I still think it looks a bit outdated. The default themes should be more modern, more 2016ish.

      • Mattias Tengblad 3:38 pm on August 25, 2015 Permalink | Log in to Reply

        +1

      • Paal Joachim Romdahl 4:55 pm on August 25, 2015 Permalink | Log in to Reply

        Agreed.

      • Arnan de Gans 6:21 pm on August 25, 2015 Permalink | Log in to Reply

        Yep, this looks like a 1998 html page :(

      • WTech 6:29 pm on August 25, 2015 Permalink | Log in to Reply

        +2 (imho 2014 is better)

      • Matt Mullenweg 11:52 pm on August 25, 2015 Permalink | Log in to Reply

        For the folks who think it looks old, definitely share some links to themes you think are more modern, it could be a good inspiration for twenty-seventeen (which is just around the corner).

        • waltson 5:37 am on August 26, 2015 Permalink | Log in to Reply

          Hi Matt .Really thanks for giving a chance to interact with you .I like wordpress, and i am working on it from few months .I like the 2016 theme. But please see the below points

          (1)Could you please add some more functions that assist in working with forms.

          (2)Captcha support by default

          (3)Could you please add some more permalink structure tags like %taxonomy%,%sub-taxonomy%,%sub-category% and way to arrange them

          (4) great pain is trying to make WP work with Angular.js or similar for building web apps.

          The most important ting is that please give some importance to https://wordpress.org/ideas/view/latest , because we only have this place to express our ideas . It would be very happy if we get correct reply and concentration from the wordpress team .

          I am looking forward to your reply.

          Thank you .

          • Paal Joachim Romdahl 8:12 am on August 26, 2015 Permalink | Log in to Reply

            Hi Waltson. A better place to post what you wrote would be in the “WordPress 4.4: What’s on your wishlist?” thread further down this page.

            • Sam wc 9:08 am on August 26, 2015 Permalink

              But Paal , these are some good ideas .Why we waiting for implement this in WordPress 4.4 . If these ideas make sense and it is important it can be implemented int he very next WordPress update.

            • Aparna123 9:25 am on August 26, 2015 Permalink

              Waltson is right

            • Sam wc 3:04 pm on August 27, 2015 Permalink

              WordPress team not looking at Frame work such as laravel,Yii,cakephp etc.Please make it very powerful such as this frame work. Because we love wordpress never wan’t to down when compare with these frameworks .

          • Aparna123 9:23 am on August 26, 2015 Permalink | Log in to Reply

            Good things Waltson.Generally there is lack of form handling and validating function in WordPress.Captcha is also important .

        • Adrian Pop 1:08 pm on August 26, 2015 Permalink | Log in to Reply

          I also think is kind of an oldish design – forget about sidebars! I really like Satellite (https://wordpress.org/themes/satellite/) and Ryu (https://wordpress.org/themes/ryu/) is one of my all-time favorite – Thaks Mr. Takashi :)

        • Sam wc 3:03 pm on August 27, 2015 Permalink | Log in to Reply

          WordPress team not looking at Framework such as laravel,Yii,cakephp etc.Please make it very powerful such as this frame work. Because we love wordpress never wan’t to down when compare with these frameworks .

        • transl8or 5:11 pm on August 27, 2015 Permalink | Log in to Reply

          I don’t think it looks old.
          It’s very very classical, kinda puristic und could be quite elegant with good pictures.

          Nevertheless I have two concerns about this theme:

          • The Frame; especially when it’s black, the site could somehow look like a newspaper obiatury.

          So I hope the customizer options will support a checkbox or simular to switch the frame on or off.
          Or maybe even have it only left & right vs. top & bottom.
          Or just choose the frame color individually so that it will be the same as the background color.

          • The Primary Menu; especially in the desktop version.

          I’m often very unhappy with lot’s of menus within WordPress Themes because they seldom look kinda “design consitent” for the whole site nor for bigger websites with lots of pages (not blogs, with mainly posts and infinite scroll).
          The later comes mostly with horizontal menu.

          — —

          As a suggestion for this theme, I could imagine a “sidebar integrated” menu, like you can see it in the Ascetic theme see here:
          http://demo.alienwp.com/ascetica/
          Could be a challenge with a full-width page, or pages with full-width header-image though.

          Or a menu like the Materialist Theme uses, see here:
          https://wordpress.org/themes/materialist/
          But on the upper right side.

          I like simplicity of the menu in the Libre Theme and the Theme in general;
          but it still has the issue of going “white over white, or even over content” when you create a site with a menu that has loads of items and levels.

          — — —

          Talking about the Materialist Theme brings me to the next topic.

          A more modern design approach for Twenty Seventeen?!?

          How about Material Design, Semi Flat Design, more colorful options and/or a “lighter, thinner, more playful & transparent look” for the menu/navigation, input-form elements and fonts.
          Oh, and I’d like to see an option in the Customizer for the primary menu to either be a “fixed navigation bar” or not more often.

          Examples:

          http://www.nuabikes.com/

          http://www.brindisatapaskitchens.com/

          http://revelator.com/

          http://www.wonderfullywild.co.uk/

          https://niice.co/

          http://branding.cards/

          http://simplehonestwork.com/

          http://evandorlot.com/portfolio/naaataa-fashion-branding/

          Google Resources on “Material Design”:

          https://www.google.com/design/spec/material-design/introduction.html

          :)

        • sonofara 2:46 am on August 28, 2015 Permalink | Log in to Reply

          20Sixteen is clean, responsive and is definitely a perfect startup template which can be transformed into an eye catching website.

      • chrishoward 5:50 am on August 26, 2015 Permalink | Log in to Reply

        Yes. Reminds me of 2012.

        I think the main prob is the sidebar. That sort of stuff is all in footers in modern designs.

      • stuk 3:22 pm on August 26, 2015 Permalink | Log in to Reply

        +1

    • Lara Littlefield 3:16 pm on August 25, 2015 Permalink | Log in to Reply

      I’m so excited to have photos displayed in such a unique way like this in a default WordPress theme. 2016 is beautiful!!

    • Helen Hou-Sandi 3:18 pm on August 25, 2015 Permalink | Log in to Reply

      Woohoo! I’ve still got that musician bias – like Twenty Fifteen, this looks like it can serve as a really solid base for portfolio sites, especially with some creative thinking around colors and content.

    • web2033 3:23 pm on August 25, 2015 Permalink | Log in to Reply

      Happy new 2016 ^_^

    • Mel Choyce 3:24 pm on August 25, 2015 Permalink | Log in to Reply

      <3

    • Matthew 3:26 pm on August 25, 2015 Permalink | Log in to Reply

      awesome stuff

    • Philip Arthur Moore 3:27 pm on August 25, 2015 Permalink | Log in to Reply

      Happy to help do some theme breaking. Can’t wait to see this land. Takashi’s designs…are they ever not amazing? Another hit; cannot wait to see this on millions of sites. Great work gang.

    • Ihor Vorotnov 3:35 pm on August 25, 2015 Permalink | Log in to Reply

      One more blog theme with a font that looks ok only with latin characters? Looks nice, but… Come on guys, there’s life outside US. There are other languages out there. WordPress is not only for blogs anymore.

    • Ajay 3:40 pm on August 25, 2015 Permalink | Log in to Reply

      This is definitely looking very clean. Twenty Fifteen was OK look wise, but this definitely looks like a worthy base for any new site.

    • Nick Halsey 3:48 pm on August 25, 2015 Permalink | Log in to Reply

      I’m honestly not a fan based on the screenshots, but that’s okay – even a default theme shouldn’t try to satisfy everyone. Something feels off with it for me.

      Based on the way the colors seem to work, again based on the screenshots, we should probably explore making the text colors auto-generate to light or dark based on the selected background color, for simplicity and to minimize contrast issues. The Fourteen Colors plugin for Twenty Fourteen does something similar.

    • Chrisdc1 3:51 pm on August 25, 2015 Permalink | Log in to Reply

      Looks good, I’d be interested in helping as well,

    • Ahmad Awais 4:02 pm on August 25, 2015 Permalink | Log in to Reply

      I’d love to contribute.

    • Sakin Shrestha 4:03 pm on August 25, 2015 Permalink | Log in to Reply

      Looks really nice and clean. Would love to contribute… Thanks

    • Donna Fontenot 4:18 pm on August 25, 2015 Permalink | Log in to Reply

      This is exactly what WordPress does NOT need. Another boring, snoozefest old-school blog layout. Wake me when WP joins the rest of the world in 2015 and beyond. (BTW, I tried really hard to come up with a nice way to say that, and I just couldn’t, so here is the comment in all its straight-forwardness.)

    • MRWweb 4:25 pm on August 25, 2015 Permalink | Log in to Reply

      Let’s get some alt text in that image gallery! #a11y

      There are some really nice touches in the screenshots. I like the pull quote a lot (though wonder how it will be applied with the editor).

      At some point, I’d love to hear the core team be a little clearer on how the new theme is selected and why there have been two blog themes in a row. (It also might not be too late to add an interesting static front page option to Twenty Sixteen to make it more versatile!) I tend to follow this stuff and had no clue this process was happening. I certainly understand the need for fewer cooks in the kitchen, but at least letting some more people suggest ideas for priorities might be nice. Maybe even a poll or two.

      I’ve heard for years now many people clamoring for a “new Twenty Twelve” and still hope to see another “CMS” theme as a default soon. (It’s remained quite popular: https://docs.google.com/spreadsheets/d/1UV4UGFCdTdNhK8v7l9s6J0uI5Y-QMRocSET63NO3CVc/edit?usp=sharing)

      • Nick Halsey 7:11 pm on August 25, 2015 Permalink | Log in to Reply

        You’re not missing anything – there is a complete lack of transparency in the default theme process prior to the “announcement” posts. Even frequent contributors have heard absolutely nothing about it prior to today.

        My biggest complaint is that we have now had the same designer do the last three default themes. Takashi’s work is amazing, but it’s definitely time to give someone else an opportunity to fill this role as has been done in the past. Since the extremely outside-the-box Twenty Thirteen, we’ve gone back to progressively less and less compelling designs with each default theme.

        • MRWweb 8:59 pm on August 25, 2015 Permalink | Log in to Reply

          > Takashi’s work is amazing, but it’s definitely time to give someone else an opportunity to fill this role as has been done in the past.

          I agree. Even if Twenty Fifteen—which I like quite a bit—were by the objectively best designer in the world (that is not a thing, but for the sake of argument…) the core team should be doing more to promote and diversify the designers who show what WordPress can do and be. The idea that there aren’t other designs who can do this—and wouldn’t drop all sorts of other commitments if given the chance!—just doesn’t make sense.

          I hate being negative in what is an otherwise worthwhile celebratory post and call-to-action, but I really hope this can stop being so untransparent and homogenous.

    • Felix Arntz 4:26 pm on August 25, 2015 Permalink | Log in to Reply

      Plain and simple – and great. Looking forward to replace Twenty Fifteen on my blog :)

    • Emil Uzelac 4:30 pm on August 25, 2015 Permalink | Log in to Reply

      So Fresh, So Clean!

    • Nilambar Sharma 4:31 pm on August 25, 2015 Permalink | Log in to Reply

      Simple and nice. I am willing to contribute… :-)

    • voldemortensen 4:48 pm on August 25, 2015 Permalink | Log in to Reply

      Is there a way to get involved with this *before* it lands in core? I am a frequent core contributor and I have Slack open all day. I’ve heard nothing about this until literally a few minutes ago.

    • Shapeshifter 3 5:12 pm on August 25, 2015 Permalink | Log in to Reply

      “The theme was designed on a harmonious fluid grid with a mobile first approach. This means it looks great on any device.”
      – @iamtakashi

      I like the concept !

      Is there any way to download the current alpha version of this, so I can upload it to my own website to preview it with my own personal content?

      I’m interested to know what the current Theme Customizer currently offers in Content (width) and Layout options.

    • Orangedrop 5:16 pm on August 25, 2015 Permalink | Log in to Reply

      For once purely based on screens I don’t know if I’m down this ! That said you can’t please everybody all of the time :) I would love to get my grubby mitts on it and break it a few times so please count me in ! Thanks guys and as always keep up the awesome work.

    • Brent Jett 5:39 pm on August 25, 2015 Permalink | Log in to Reply

      I’d like to know more about how this theme will be implemented in terms of customizer fields, editor styles, custom widgets/shortcodes etc… I’m a big believer in designing themes for the WP user as much as the reader. Where are these discussions currently being had? Is this project on github somewhere?

    • dannybrown 5:54 pm on August 25, 2015 Permalink | Log in to Reply

      Yawn. Sorry, but this design (as far as looks goes) is so 2012.

    • dshanske 6:15 pm on August 25, 2015 Permalink | Log in to Reply

      I would be interested in ensuring that the theme is microformats compliant.

    • Gaurav Tiwari 6:20 pm on August 25, 2015 Permalink | Log in to Reply

      Make it look like commercial themes. If WP is no longer blogging focused CMS why should the default themes be?

    • LittleBigThings 6:36 pm on August 25, 2015 Permalink | Log in to Reply

      Cool and clean, a bit Twenty Twelve-like. Hope to see some unique features in the Customizer. I would love to follow it up and help out testing.

    • Tomas Mackevicius 6:41 pm on August 25, 2015 Permalink | Log in to Reply

      Looks great! Can we see live demo?

    • Karthikeyan KC 6:44 pm on August 25, 2015 Permalink | Log in to Reply

      To be honest, twentyfourteen looks better than twentysixteen. Anyways, it’s good for the default one. :)

    • Tomas Mackevicius 6:52 pm on August 25, 2015 Permalink | Log in to Reply

      But 2014 was not built on _s, I hope 2016 is.

    • WebMan Design | Oliver Juhas 7:07 pm on August 25, 2015 Permalink | Log in to Reply

      Looks great, very clean! I’d like to contribute too :)

    • SanjayaBhai 7:10 pm on August 25, 2015 Permalink | Log in to Reply

      Twenty sixteen.. Hope it will be great…. But please make this themes more modern/Beautiful … It’s seems classic .

    • Alex Mills (Viper007Bond) 7:25 pm on August 25, 2015 Permalink | Log in to Reply

      It’s been a long time since I’ve run a default theme but I’ll be switching for this one!

    • George Stephanis 7:28 pm on August 25, 2015 Permalink | Log in to Reply

      I’m pulling for twentyseventeen to be Kubrick redone responsively. :)

      • Ryan Hellyer 9:42 am on August 26, 2015 Permalink | Log in to Reply

        I’ve been toying with forking Kubrick like that for many years now, but never gotten around to it.

      • Drew Jaynes 8:41 pm on August 26, 2015 Permalink | Log in to Reply

        FWIW, I already did it. I created a child theme for Twenty Twelve called Nubrick, that created a responsive version of Kubrick. The header used CSS gradients and everything else was matched to a tee with some obvious improvements. Might have it laying around here somewhere, have to look.

    • Tarik Cayir 7:59 pm on August 25, 2015 Permalink | Log in to Reply

      That’s sweet and incredible!

    • Morten Rand-Hendriksen 8:14 pm on August 25, 2015 Permalink | Log in to Reply

      Sign me up. I’ve done a lot of work with pull-images of the kind proposed here and know some of the pitfalls. I’ll contribute what I can and where it helps.

    • Valeriu Tihai 12:14 am on August 26, 2015 Permalink | Log in to Reply

      Happy to help

    • WP Sites - Brad Dalton 1:37 am on August 26, 2015 Permalink | Log in to Reply

      How about a widgetized page template which can be used as the front page. Widgets in columns are popular and so are full width sections. The genesis sample child theme is hugely popular because you can easily add custom functionality unlike any of the default themes.

    • Matt (Thomas) Miklic 2:03 am on August 26, 2015 Permalink | Log in to Reply

      This is a beautiful theme and I can’t wait to use it myself.

    • Aaron Brazell 2:13 am on August 26, 2015 Permalink | Log in to Reply

      I like the image offset a lot and I want a one-column option, so glad to see that in there. Agree with previous commenters saying it looks a bit dated, but I also don’t think that’s twntysixteen per se… I think the “blog layout”, which is a guiding principal, is a bit dated. I’d love to see twentyseventeen place less emphasis on text content, top down, left-right, sidebar, header and more of a focus on rich media. Photographs, videos, etc… with natural integrations (no external APIs) with social content (and not just FB and Twitter)… it’s such a rich internet, but the blog approach to the project might be influencing the frontend a bit much and not keeping up. :)

    • nick6352683 2:38 am on August 26, 2015 Permalink | Log in to Reply

      Anything, and I mean anything would be better than 2013, 2014, and 2015. I prefer 2012 over those, and 2016 seems more or less in line with 2012. The whole discussion is pretty much mute for me, as I always opt to use “premium” type themes, with tons of bells and whistles, but I’m very biased as I develop my own themes, with extra functions and shortcodes.

    • webdevmattcrom 3:33 am on August 26, 2015 Permalink | Log in to Reply

      Definitely interested in contributing, sign me up!

      I love that this does feel like it’s heading back toward a cleaner Twenty Twelve feeling. I like that the sidebar is on the right by default, but especially considering RTL it would be nice to have a Customizer option to put the sidebar on either side. In that vein, since the Customizer is getting more and more prominence it would be great to see this theme really flaunt some great aspects of the Customizer as a strong example of “Decisions not Options” while still providing flexibility in look and feel.

      Looking forward to seeing this come to life.

    • Amit Kvint 6:32 am on August 26, 2015 Permalink | Log in to Reply

      Definitely interested in contributing, sign me up too!

    • Brian Krogsgard 7:12 am on August 26, 2015 Permalink | Log in to Reply

      Is Ian Stewart the default theme lead?

      There is obviously a lot of decision making going on in regard to default theme design that nobody really knows about, and it is really confusing. It is so different than the rest of WordPress development.

      So, how would someone go about getting involved earlier in the process (at the design level!), short of going to Matt Mullenweg? I might add that going to Matt on how to get involved (though he appears the primary gatekeeper on default theme design) is likely quite intimidating for most folks.

      A lot of talented designers would probably like to get involved in this process but don’t know it’s possible or how to start. Some information and light on the process itself would be most welcome, I’m sure.

    • Philip Arthur Moore 8:55 am on August 26, 2015 Permalink | Log in to Reply

      The fact that there are so many passionate responses here is pretty cool.

      History time:

      Default themes won’t be for everyone, and ultimately I share Brian’s thoughts above. I think it’d be GREAT for 10000% transparency around the default theme making, designing, and proposal stages before posts like this are made. (Honestly it makes no difference to me personally but the community seems to benefit quite well from feeling like we have a chance to contribute to such a public and front-facing piece of WordPress.)

      But that aside, however the theme came to be, I think the first drafts shared are quite nice and absolutely cannot wait to help break things once it lands into Core. I’ve no doubt that there are some pretty serious design and development challenges that will come out of these drafts, and it’s going to be exciting to take part in that.

    • Subharanjan 9:04 am on August 26, 2015 Permalink | Log in to Reply

      Clean and Simple !! Looks awesome :)

    • Fotis 9:20 am on August 26, 2015 Permalink | Log in to Reply

      Perfect.

    • Ryan Hellyer 9:46 am on August 26, 2015 Permalink | Log in to Reply

      I like this new design. Simple, yet elegant.

    • stuk 10:24 am on August 26, 2015 Permalink | Log in to Reply

      To me it seems quite outdated and useless as any default theme, is it not?
      Quite clear that their intention is not to add extra features to WordPress, and indeed the basic theme can support only a maximum basic options.

      But also simply bad design. If it’s the preview we let people install with the system, so it seems bad.
      Nothing to do with new design trends.
      Despite the WordPress developers insist that the system is already more than a blogging system infrastructure, they continue to release static templates without AJAX and without REST, and yet the basic theme is a theme of a blog, not a website.

      In one word: shame.

    • David Bennett 11:42 am on August 26, 2015 Permalink | Log in to Reply

      It reminds me of Linen from TheThemeFoundry, and it has the open, airy look of themes from ElmaStudio. I like it. The only thing I wonder about are the horizontal dividers in the sidebar. The Daily Dish theme from StudioPress has black sidebar dividers overpower the theme somewhat. The dividers in The Daily Dish are thicker but if a blogger has a lot of widgets it can start to look like the i Ching.

    • Elisa 12:19 pm on August 26, 2015 Permalink | Log in to Reply

      I like it :)

    • CYBERsprout 1:28 pm on August 26, 2015 Permalink | Log in to Reply

      Looks great! A very modern design.

    • ldbaldwin 2:43 pm on August 26, 2015 Permalink | Log in to Reply

      I would be interested in contributing on some leve, (testing, documentation, etc.). Thanks!

    • cramdesign 2:47 pm on August 26, 2015 Permalink | Log in to Reply

      I think it looks great. The structure is a traditional setup but I think that the overall design, typography and image handling is very current. I agree that the dividers in the sidebar might be a little too heavy but, then again, that is easily changed with css and let’s be bold every now and again.

    • firewatch 3:34 pm on August 26, 2015 Permalink | Log in to Reply

      I’m interested in contributing, thanks!

    • djsteveb 9:20 pm on August 26, 2015 Permalink | Log in to Reply

      Wish all the like and dislike comments could be removed here. Give specifics or save the screen space.

      Sorry ya’ll but the default theme does not need to be any one person’s idea of pretty or modern, it’s default and certainly not the only option for anyone running wp.

      What the default themes have been lacking since 2012(?) is documentation, transparency, and support.

      All that fancy responsiveness is fine if you like things as is. Simply trying to move the left sidebar to the right with 2015 is a nightmare – I miss the days of simply change float left to float right.

      Yes I know, “modern design” is beyond that – I have learned how to move things around with bootstrap, and foundation… moving things with 2014 / 15 is a joke. No documentation, no support – no transparency with updates.

      Either given backend option for the most common changes, or make it easier for people to change things with code. Having to make edits and then change screen sizes and search for ways to change rules for each media query is a joke, with no docs, and no warnings about updates.

      Given that the default theme is the only thing we can count on that will get any kind of support from buddypress, rtmedia and other plugins – many are indeed stuck with the default theme base – pretty or not – those things can be adjusted if the options are understood, documented, supported.

      My comment on takshi’s site still waiting moderation (August 25, 2015 at 12:37 am ) – maybe it’s akismet limbo. Support on the wp repo is total confusion – even other professional sites that created right sidebar child theme break with basic background color change – is it them? Is it the theme? Was it working then an update fixed something and broke others?

      I am happy to contribute what I can (20% through my php course!) – I was planning to make a video tutorial from the text how-to for making themes at themeshaper.com – however it states it’s outdated. I stumbled across a trello that has documentation for theming in the works – but that may be finished in 2017?

      Given that the default theme has total power over so many things WP – I prefer no java, nothing complex, basic – make it easy to mod it so people can make it prettier and modern on their own. Not left in limbo choosing no support, no docs with wp plugins that work (and look basic) – or get a theme that looks better is modifiable – but then does not work with plugins and gets no love or support from plugin systems.

      Frankly the older default themes were much easier to make better. Anything default that is complex is just going to shrink the amount of WP users that can actually mod something on their own without a degree in javascript and php. You might as well force us to use sass and less and bower. Really shrink the amount of people that can enhance a basic default theme.

      Maybe pull all the extra stuff out and make it an option plugin like some do with “jetpack features” – I just want BP to work with something that can be modded – either with lots of backend theme options (colors, sidebar on, sidebar off, move to footer – basic stuff really, or easy css that the average person can figure out or get basic support from the community to figure out. (please take out all third party bloat, eg- google fonts, gravatar, emoji and put them as optional plugins, pretty please!)

      Or convince BP and rtmedia (and others) to work with / provide support themes based on bootstrap and or foundation – then the default theme can be whatever it wants to be and we can peruse the documentation for those frameworks, and make adjustments easily.

      Sorry to long rant, (and I started with ‘save the screen space – seriously sorry, very frustrated with all this!) I want to see WP, and things associated with it continue to succeed, however I concur that many of the past two years’ not-so-transparent decisions have not made this easy for most of the average users IMHO.

      • rahul286 5:40 pm on August 28, 2015 Permalink | Log in to Reply

        I am from rtMedia team.

        I like your idea of themes using a base js/css framework like bootstrap and or foundation. But our reason for supporting default themes is they work nicely with BuddyPress as well as other plugins. Mainly because many plugin developers also check test plugins with default themes.

        That being said, our inability to support most themes is mainly because most themes are not tested with BuddyPress. In fact wordpress.org only shows 28 themes that claim to support BuddyPress – https://wordpress.org/themes/tags/buddypress/ and 1 of them is default theme and 1 other (rtPanel) is our theme.

        • djsteveb 9:52 am on August 29, 2015 Permalink | Log in to Reply

          @rahul286 – Thank you for chiming in on this issue. I don’t expect your team or any other to have the ability to support every edge case theme created for wp, and I am glad you guys at least make an effort to keep rtmedia working with whatever updates get pushed by automattic at least. Your media plugin is the only reliable way for buddypress users to get picture and other media uploads, so it’s continuing functionality is imperative.

          It is sad there are so few themes tagged to work with BP – of course there are many that do work with bp and yet they are not tagged that way in the repo – and there are several that are available outside the wp org system – however my experience has been that we can not count on other themes to work with bp and rtmedia properly no matter where they are from. I have tried 24 of those you mentioned 😉

          This is exactly why I feel a new default theme must be carefully considered, and it should be easier to modify than the past two – as we are indeed basically stuck using 2014 / 2015 /2016 for bp sites or gamble with lots of things not working – and no support or docs to fix things. This is not an rtmedia fault – it’s just where things have gone with bp in general I guess.

          There are some who think my thoughts on this are 100% wrong, at least one person replying to a similar comment I made in regards to these issues at wp-tavern – ( http://wptavern.com/first-look-at-the-twenty-sixteen-default-wordpress-theme#comment-72326 ) – however I think people have not seen the amount of support that has been needed to keep self hosted wordpress sites with plugins working properly with major updates and the basic issues that revolve around the default theme, and those that vary from it, is the starting point for almost every issue bp / rtmedia and many others plugins breaking with users sites.

    • Marcus Tibesar 11:26 pm on August 26, 2015 Permalink | Log in to Reply

      IMO there is too much white horizontal space between the gravatars and the content.

    • Marcus 9:44 am on August 27, 2015 Permalink | Log in to Reply

      I would love to help out

    • weblizar 11:38 am on August 27, 2015 Permalink | Log in to Reply

      Hi,Like to contribute.

    • abe_charles 12:43 pm on August 27, 2015 Permalink | Log in to Reply

      Have to say that Twenty Sixteen default theme is very weak. It deserves to be placed on life support because it looks like something created in 2010. It’s plain black and white by default with options for different colour options but still quite stale.

      I thought Twenty Fifteen was poor but looking at Twenty Sixteen it’s as if WordPress is taking two steps backward by presenting this piece of crap. You have a disgruntled blogger in me and this theme ain’t gonna fly. At least you have a few more months before the year 2016 so get back to the drawing board and change the direction of this theme. It’s too late for April Fools.

      Repeal, repeal and stop making the images fall off the page. That’s frustrating. Come with a better theme.

    • Mel Choyce 8:22 pm on August 27, 2015 Permalink | Log in to Reply

      I think it’s important for people to remember that this theme was made by a real, live person. Disparaging contributors and their work is inappropriate and not welcome in this community.

      You are welcome to your opinion, but if you want to give feedback, please keep that feedback respectful and constructive. Critiquing the design and the default theme building process is fine. Calling this theme “crap” or “useless,” however, is not constructive feedback and not appropriate for these contributor blogs. As Matt Miklic mentioned, that kind of feedback is abusive and unhelpful.

      Here’s how to structure good design feedback:

      • Empathize. Remember that behind every design is a person. If you wouldn’t say it to this person’s face, don’t say it here.
      • Start with “I think…” and finish with “because…”
      • Comment on particular elements that don’t work in the design, like the typography, colors, hierarchy, and composition. Try to be as specific as possible.
      • Stick to goal-oriented feedback: “This theme can become a better default theme for more users if it did [x], [y], and [z].”
      • Frame feedback as suggestions, not mandates. “What if you…” and “How about if you tried…” are great ways to present alternate ideas to a designer.

      Thanks for helping us keep WordPress a positive place to contribute.

    • abe_charles 12:44 pm on August 28, 2015 Permalink | Log in to Reply

      Apologies for the insensitive remark. I never meant to cause offense, I thought that the opinion was valid but it went too far. It’s just that I have been waiting for Twenty Sixteen theme for a few months and to see what it will look like or what it looks like I am disappointed. It does need work for real. It’s too plain and looks like not much thought was put into it. It’s rather plain and basic. I was expecting Twenty Fourteen 2.0 or Twenty Fifteen 4.0

    • modparlor 2:01 pm on August 29, 2015 Permalink | Log in to Reply

      Neat. Looking forward to this new minimalist theme. One request though: Could you please add in a font-switcher into the customizer. A thing desperately lacking in the 2015 theme IMHO. I can add in my own fonts, I know, but a dropdown with a set of 30+ Googlefonts would be easyer for quick tryouts.

      That aside, thanks for the neat themes and the ongoing work on WP.

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