WordPress.org

Make WordPress Core

Welcome to the official blog of the core development team for the WordPress open source project.

Here, we make WordPress core. Follow our progress with general updates, status reports, and the occasional code debate.

We’d love for you to help out.

Looking to file a bug?

It’s easy to create a ticket on our bug tracker.

Want to contribute?

Get started quickly. We have some tickets marked as good first bugs for new contributors. There’s more on our reports page, like patches needing testing.

We also have a detailed handbook for contributors, complete with tutorials.

Weekly meetings

We use Slack for real-time communication. As contributors live all over the world, there are discussions happening at all hours of the day.

We have a project meeting every Wednesday at 20:00 UTC in the #core channel on Slack. (Find out more about Slack.)

You can find meeting agendas on this blog. You’re welcome to join us or listen in.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • 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. :)

  • 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

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

    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.

    • 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

  • Daniel Bachhuber 8:11 pm on August 24, 2015 Permalink |
    Tags: , ,   

    Shortcake (Shortcode UI) chat summary – August 24th, 2015 

    Present: @danielbachhuber, @goldenapples, @miqrogroove, @azaozz

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1440442841000013

    • We triaged the remaining issues for v0.5.0. Daniel will be picking them up over the next day.
    • A big project for v0.6.0 will be to go through core’s feature plugin guidelines and identify what we need to change to be valid.
    • Spent time discussing @miqrogroove summary of shortcode problems, and proposed solutions

    Next chat: same time and place

    Next release: v0.5.0 – this week (a bit overdue)

     
  • Konstantin Obenland 5:30 pm on August 20, 2015 Permalink |
    Tags: , post-mortem   

    WordPress 4.3 Post Mortem 

    I’d like to do a review of the WordPress 4.3 release cycle, talk about what went well, what didn’t, and ideally derive specific items that we can improve on.

    Let’s do that in the #core channel on Slack on August 24 2015 20:00 UTC, the usual dev chat time.

     
  • Helen Hou-Sandi 1:35 pm on August 20, 2015 Permalink |
    Tags: ,   

    8/20 UI Chat Agenda: 4.4 

    After a few weeks off from regular meetings while the final touches were put on 4.3, let’s have our weekly UI chat, today at 17:00 UTC. Inspired by @wonderboymusic‘s call for 4.4 wishlist items, let’s talk today about what our bigger projects are in the world of UI and UX, what our wishlist items are, and what we can reasonably target for 4.4.

     
    • chriscct7 5:47 pm on August 20, 2015 Permalink | Log in to Reply

      I think it’d be interesting to look at https://core.trac.wordpress.org/ticket/22959#comment:29 if someone’s interested in working on it

    • David Lingren 7:42 pm on August 20, 2015 Permalink | Log in to Reply

      I’d like to know the status of Ryan Boren’s “Retiring media-new.php” proposal (https://make.wordpress.org/flow/2015/01/29/retiring-media-new-php/).

      In addition to the browser uploader, media-new.php offers a number of hooks that allow plugin developers a way to extend its functions.

      My plugin, Media Library Assistant (https://wordpress.org/plugins/media-library-assistant/), adds a form below the drag-and-drop area on the Media/Upload New Media screen. The form allows users to set defaults for standard fields, taxonomy terms and custom fields that are applied to items as they are uploaded. It uses the ‘upload_post_params’ and ‘post-upload-ui’ hooks provided in media-new.php.

      I have not developed an alternative approach to this feature that works in the grid view or Media Manager Modal Window (MMMW). I have found it very difficult to extend grid view and MMMW, and I am concerned that a media-new.php replacement will have similar issues.

      I hope you will think through and meet the needs of plugin and theme developers in any media-new.php replacement effort. Thank you for your consideration.

      • Ryan Boren 5:05 pm on August 21, 2015 Permalink | Log in to Reply

        I replied over here. I updated that post with screenshots of media-new.php + MLA. At the moment, this is just a proposal I’ve been shopping around. It has some interest, but I don’t know if it will get developer time during 4.4

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