Make WordPress Core

Tagged: updates Toggle Comment Threads | Keyboard Shortcuts

  • Daniel Bachhuber 9:30 pm on November 2, 2015 Permalink |
    Tags: , updates, , , ,   

    Shortcake (Shortcode UI) chat summary – November 2nd, 2015 

    Present: @danielbachhuber, @goldenapples, @matth_eu

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

    • We released Shortcake v0.6.0. Read through the full release notes.
    • Weekly meetings are on hold until January. Between now and then, we’ll be thinking about what we need to do to put forth a core proposal. @matth_eu might put together sketches.
    • We missed the boat on getting a Shortcake representative to the community summit, and are researching ways to helicopter @goldenapples to said community summit boat.

    Next chat: sometime in January 2016

  • Daniel Bachhuber 7:42 pm on October 5, 2015 Permalink |
    Tags: , , , , , updates   

    Shortcake (Shortcode UI) chat summary – October 5th, 2015 

    Present: @danielbachhuber, @goldenapples, @matth_eu

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

    • Matt’s making process on support for encoding HTML in attributes. Gallery functionality is also almost done, but there’s one small bug.
    • Than started work on trying to add some filters that can be used to handle floated/non-block previews. It still some work to go, as it’ll involve overriding some methods deep in mce.view.
    • Daniel will hit up the backlog when he has a moment, as there are a number of unanswered open issues.
    • We discussed inline editing and agreed upon an ideal abstraction .

    Next chat: same time and place

    Next release: v0.6.0 – Tuesday, November 3rd

  • Joe McGill 10:21 pm on September 5, 2015 Permalink |
    Tags: , , , updates   

    Responsive Images Feature Plugin Update 

    Following up on our first official project update, here’s a brief status update to keep everyone informed about the progress we’ve made.


    • Released v2.4.0 early last week, fixing several bugs and adding a few filters (changelog). Please test on your sites and leave us feedback!
    • Created placeholder tickets for adding srcset and sizes support ( #33641 ) and improving the compression settings of Imagick ( #33642 ).
    • @jaspermdegroot is digging into the content filter approach to support responsive images for old posts. Performance tests and details on GitHub. Feedback appreciated!

    Next Steps

    We’re ready to create an initial patch candidate for core. We’ll be working on that over the next week, with a more detailed update at that time.

    Check out the logs from our last meeting and join us for the next one on Friday at 19:00 UTC in #feature-respimg.

    Questions? Please leave feedback below, or ask anytime in #feature-respimg.

  • Pascal Birchler 6:31 am on September 2, 2015 Permalink |
    Tags: , , , updates   

    oEmbed Feature Plugin Update 

    After kicking off the oEmbed feature plugin a couple of weeks ago, it’s high time for another status update.

    In case you have missed it, the oEmbed API plugin makes WordPress an oEmbed provider, allowing you to embed blog posts just like YouTube videos or tweets. Of course everything happens with security and ease-of-use in mind.

    oEmbed Feature Plugin

    Embedding a post is super simple!

    We made some great progress over the last few weeks. The highlights are:

    • Improved test coverage, which led to many fixed bugs
    • Auto-resizing of the embedded iframe so it looks great on every screen
    • It seamlessly integrates with the REST API, but also works perfectly without it

    The plugin is very stable so far. We’re looking into bringing it to WordPress.com for testing, but of course we also need your help to bring this further! Download the plugin from the repository — play with it, break it, and help us fixing all bugs that may appear. We’re always looking for areas to improve.

    We’re now mainly working on getting it into shape for an eventual core merge proposal and implementing the different oEmbed response types. This means supporting embedding attachment posts and posts with different post formats.

    Please, test and report both errors and suggestions either on GitHub or our #feature-oembed Slack channel. Anyone is welcome to join us!

    Next chat: September 7 2015 9pm UTC

  • Daniel Bachhuber 8:16 pm on August 31, 2015 Permalink |
    Tags: , , , , , updates   

    Shortcake (Shortcode UI) chat summary – August 31st, 2015 

    Present: @danielbachhuber, @matth_eu

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

    Next chat: same time and place

    Next release: v0.6.0 – Tuesday, November 3rd

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

    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.

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

    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!


    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:

        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!

      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

      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

      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.

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

    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)

  • Ryan McCue 7:29 am on August 14, 2015 Permalink |
    Tags: , , , , updates   

    WP REST API: Versions 1.2.3 (Security Release) and 2.0 Beta 4 

    First and foremost: version 1.2.3 of the REST API is now available. Download it from the plugin repository or from GitHub. This is a security release affecting sites running version 1.2 or a 2.0 beta releases.

    Security Release

    Recently, we were alerted to a potential XSS vulnerability introduced in version 1.2 of the API related to the JSONP support. This vulnerability also existed in version 2.0. Thanks to Alex Concha (@xknown) for reporting this issue to the team responsibly.

    This release was coordinated by the REST API team and the WordPress core security team. The security team is pushing automatic updates for version 1.2.3, but do not wait or rely on the automatic update process. We recommend sites or plugins that are using either v1.2.x or 2.0 beta releases update the plugin immediately.

    If you’d prefer not to upgrade, you can instead disable JSONP support through a filter. For version 1:

    add_filter( 'json_jsonp_enabled', '__return_false' );

    To disable JSONP on version 2:

    add_filter( 'rest_jsonp_enabled', '__return_false' );

    If you have a question about the security release, you can find the team in #core-restapi on WordPress.org Slack, or you can privately message @rachelbaker, @rmccue, @danielbachhuber, or @joehoyle.

    Version 2.0 Beta 4

    Alongside the security release for version 1.2, we’re also releasing the latest beta for version 2.0: 2.0 Beta 4 “See My Vest”. You can download this from the plugin repository or from GitHub.

    This beta release includes the security fix from version 1.2.3, so we recommend everyone running a version 2 beta update immediately to fix the issue.

    As well as the security release, this beta also includes a bunch of other changes. Here’s some highlights:

    • Show public user information through the user controller.

      In WordPress as of r32683 (scheduled for 4.3), WP_User_Query now has support for getting users with published posts. To match current behaviour in WordPress themes and feeds, we now expose this public user information. This includes the avatar, description, user ID, custom URL, display name, and URL, for users who have published at least one post on the site. This information is available to all clients; other fields and data for all users are still only available when authenticated.

    • Send schema in OPTIONS requests and index.

      Rather than using separate /schema endpoints, the schema for items is now available through an OPTIONS request to the route. This means that full documentation is now available for endpoints through an OPTIONS request; this includes available methods, what data you can pass to the endpoint, and the data you’ll get back.

      ⚠️ This breaks backwards compatibility for clients relying on schemas being at their own routes. These clients should instead send OPTIONS requests.

    • Update JavaScript API for version 2.

      Our fantastic JavaScript API from version 1 is now available for version 2, refreshed with the latest and greatest changes. Thanks to Taylor Lovett (@tlovett1), K. Adam White (@kadamwhite) and Nathan Rice (@nathanrice).

    • Embed links inside items in a collection.

      Previously when fetching a collection of items, you only received the items themselves. No longer! You can now request a collection with embeds enabled (try /wp/v2/posts?_embed).

    • Move /posts WP_Query vars back to filter param.

      In version 1, we had internal WP_Query vars available via filter (e.g. filter[s]=search+term). For our first betas of version 2, we tried something different and exposed these directly on the endpoint. The experiment has now concluded; we didn’t like this that much, so filter is back.

      ⚠️ This breaks backwards compatibility for users using WP Query vars. Simply change your x=y parameter to filter[x]=y.

    • Respect rest_base for taxonomies.

      ⚠️ This breaks backwards compatibility by changing the /wp/v2/posts/{id}/terms/post_tag endpoint to /wp/v2/posts/{id}/tag.

    As always, we have a detailed changelog as well as the full set of changes if you’re interested.

    (Note that while this version 2 beta breaks backwards compatibility, the 1.2.3 security release does not break compatibility with the 1.2 branch.)

    This release had 11 contributors, and we’d like to thank each and every one of them:

    $ git shortlog 2.0-beta3...2.0-beta4 --summary
         1   Daniel Bachhuber
        11   Daniel Jalkut
         1   Fredrik Forsmo
         1   Jared Cobb
         3   Jay Dolan
        26   Joe Hoyle
        10   Josh Pollock
        25   Rachel Baker
        50   Ryan McCue
        24   Stephen Edgar
         8   Taylor Lovett

    Thank you again to all of our beta testers, and thanks to everyone who let us know how you’re using the API. We’re taking note of all of your feedback, and you might see some further changes related to that in coming releases.

    • Ahmad Awais 8:18 am on August 14, 2015 Permalink | Log in to Reply

      Hey, Ryan!
      Did you change the folder name or main file name in WP REST API 1.2.3 since I am using 1.2.2 and I didn’t get any update notification, which is weird.

      • Ryan McCue 10:10 pm on August 14, 2015 Permalink | Log in to Reply

        The patch in 1.2.3 is minimal and didn’t change the filename. If you’re using the API from GitHub, your folder might accidentally be called WP-API, whereas it should be json-rest-api to match the repo.

    • CotswoldPhoto 9:40 am on August 14, 2015 Permalink | Log in to Reply

      Great work team REST API. I really hope that this makes it into core for 4.4.

    • Rachel Baker 12:56 pm on August 14, 2015 Permalink | Log in to Reply

      Oh, please won’t you see my vest! 🎶

  • George Stephanis 12:10 pm on August 3, 2015 Permalink |
    Tags: , , updates   

    Two-Factor Authentication Weekly Update! 

    We met on Thursday and discussed the providers in progress — TOTP, FIDO U2F, and Backup Codes.


    In Attendance:

    Last week we merged in the functionality to support fallback methods and have a great pull from @valendesigns to better automate the workflows and systems, as well as adding in some unit tests — https://github.com/georgestephanis/two-factor/pull/8

    We also need some Design help with some flows and options screens, so if any designers are interested in pitching in, let me know! :)

    Next meeting will be Thursday, August 6th at 21:00 UTC

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