WordPress.org

Ready to get started?Download WordPress

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 IRC 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 #wordpress-dev channel on chat.freenode.net. (Quick start: There’s a web interface.)

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

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Scott Taylor 2:07 am on August 29, 2014 Permalink | Log in to leave a Comment
    Tags:   

    A more powerful ORDER BY in WordPress 4.0 

    orderby is the argument passed to WP_Query to tell it what column to sort on when it is creating the ORDER BY clause for its generated SQL. The default value for orderby is post_date.

    The default sort order for a column in MySQL is ASC (ascending), with smallest values first. For the reverse, DESC is used. You can sort on multiple columns, and each column can have its own sort order.

    The default value for the order argument inside WP_Query is DESC. ~23% of the internet automatically queries posts in reverse chronological order because of this. order can only be one of 2 values: DESC or ASC.

    orderby accepts a string, representing a column on which to sort:

    $q = new WP_Query( array( 'orderby' => 'post_title' ) );
    
    // or an alias
    $q = new WP_Query( array( 'orderby' => 'title' ) );
    

    Both will produce an ORDER BY clause like:

    ORDER BY post_title DESC
    

    orderby will also parse a space-delimited set of columns:

    $q = new WP_Query( array( 'orderby' => 'title author' ) );
    

    Prior to 4.0, there was a problem: the value for order would only be applied to the last value that you passed in that space-delimited list, producing an ORDER BY clause like:

    ORDER BY post_title, post_author DESC
    

    Remember that the default sort order for a column in MySQL is ASC, so queries like that can get weird real fast and produce unexpected/unpredictable results. If no value is passed for order for a column in the generated SQL, the column will be sorted in ASC order. This was not so clear to all developers. #26042 was a joy to debug.

    In 4.0, when you pass a space-delimited set of values, your sole value for order will be applied to all of your values that are parsed for orderby. This was fixed in [28541].

    So that’s pretty good, but it doesn’t allow you granular control over the sort order for each column. The syntax doesn’t allow itself much room for extending.

    Enter [29027].

    In 4.0, you can now pass an array to WP_Query as the value for orderby. The syntax looks like:

    $q = new WP_Query( array( 'orderby' => array( 'title' => 'DESC', 'menu_order' => 'ASC' ) ) );
    

    This allows you to control the generation of the ORDER BY clause with more specificity:

    ORDER BY post_title DESC, menu_order ASC
    

    Pre-4.0, you would have had to use some gnarly filters on the SQL statement or a specific clause. No bueno.

    To see the internals, check out the new protected methods in WP_Query: ->parse_order() and ->parse_orderby.

    Happy WP_Querying!

     
  • Helen Hou-Sandi 8:04 pm on August 27, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    RC1 is here! Proposed agenda for today’s meeting:

    • What’s come up in the hours since RC1 was released?
    • Keep an eye on support forums and bugs reported against trunk. Great time for triage of non-4.0 tickets as well.
    • Plugin developers: update your readmes and add an icon!
    • Interesting post on wp-hackers. Feedback welcome.
    • Codex page.
    • Any blog posts we need to write for developers?
    • Are there any plugins we need to ship to show off or extend 4.0 features?
    • Release plan.
     
  • Helen Hou-Sandi 7:07 pm on August 25, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    I’d like to hold an impromptu scrub of remaining 4.0 tickets in about an hour at 20:00 UTC. @nacin and I triaged most tickets earlier today and feel confident that we can finish everything out and get to RC.

     
  • Scott Kingsley Clark 5:20 pm on August 22, 2014 Permalink | Log in to leave a Comment
    Tags:   

    WP Metadata UI / API project update and new meeting time/place 

    It’s been a few weeks since we’ve posted an update, @mikeschinkel has been working hard on some new commits to give us some shortcuts for option arrays and things have stabilized there finally. We’re now focused on documenting field type development so we can get some contributors in there fleshing out the remaining field types.

    We are also moving our “Office Hours” time and place, to Mondays @ 1800 UTC , but instead of IRC where people can’t sync up and collaborate, we’re moving it to our public Gitter room. Some other WP projects are using it and we’ve found it incredibly helpful to keep up with GitHub activity along with chat that can happen at all times of the day and it sticks around for you to read anytime you want to.

    Our Gitter chat can be found here: https://gitter.im/wordpress-metadata/metadata-ui-api

    Anyone can see the chat messages, and if you want to participate it’s just a GitHub login away. They have iOS / Mac apps too, so that’s helpful to some people as well.

    If you’re interested in contributing, or if you want to check out what we’ve got and need some insight, just ping us — anytime — in Gitter :)

     
  • Andrew Nacin 7:11 pm on August 21, 2014 Permalink | Log in to leave a Comment
    Tags: , upgrade install   

    Introducing plugin icons in the plugin installer 

    WordPress 4.0 comes with a redesigned plugin installer. Just now we’ve added one of the finishing touches to this project — plugin icons.

    Plugin authors, If your plugin is compatible with WordPress 4.0, it only takes a few moments to change a readme “Tested up to:” value to 4.0. Compatibility information is prominently shown in the new plugin installer, so you’ll definitely want to update this value. For your plugin to stand out, you’ll also want to give your plugin an icon. Read on…

    Akismet

    Beautiful, auto-generated icons

    Default icons are generated using the GeoPattern library by Jason Long of GitHub. If you have a banner image, it is automatically sampled to determine the primary color for the pattern, using Tonesque from @matveb. (Cool, huh?)

    mosiac-2

    Making your own icon

    Plugin icons are 128 pixels square. HiDPI (retina) icons are supported at 256 pixels square. Like banners, these go into your /assets directory and can be either a PNG or JPG. So just create assets/icon-128x128.(png|jpg) and/or assets/icon-256x256.(png|jpg) and you have an icon.

    You also have another option: SVG. Vectors are perfect for icons like this, as they can be scaled to any size and the file itself is small. For an SVG file, you simply need an assets/icon.svg file.

    We may implement SVG-to-images fallbacks in core for browsers that don’t support them, so if you go the SVG route, I’d suggest also turning your SVG into a PNG. (SVG takes precedence.)

    Jetpack uses an SVG icon:

    Some tips when designing an icon

    • Keep it simple! The Android and iOS Human Interface Guidelines both have some fantastic design tips.
    • Avoid text, especially since these may be seen at smaller sizes in other contexts (and in languages other than English). And because this is an icon, not an ad.
    • Use the right image format for what you’re doing. Don’t use JPGs for simple designs; don’t use PNGs for photos.
    • Optimize your images! Use something like ImageOptim or your favorite web app, CLI tool, etc.
    • Please no WordPress logos. Come up with your own brand. (If you already have a banner image, you likely already have a head start here.)
    • If you haven’t worked with SVGs before, they’re pretty cool. Here’s a tutorial from Chris Coyier.
    • Keep in mind this is an icon for your plugin, not a display ad.

    Some examples

    Akismet, Jetpack, and Hello Dolly already have icons. You can see their assets directories herehere, and here.

    Thanks to the hard work of Alex Shiels (@tellyworth) for implementing this!

     
  • Janneke Van Dorpe 8:45 pm on August 20, 2014 Permalink | Log in to leave a Comment  

    GSoC update 

    Monday was the “pencils down” date for GSoC, and here’s a post about what I have done so far. It’s all related to the editor, but it can be divided into three parts: work on core for the editor “views” and scrolling, work on the Editor Experiments plugin, which contains further enhancements and work on a complete rewrite of the Front-end Editor, which includes both work on core and the other plugin.

    Note that everything requires at least WordPress 4.0 beta 4 to try.

    Core

    View related tickets (#28595, #28195, #28788#28913#27971#28458 and other minor tickets), better thumbnail resizing for a responsive modal (#27423), editors scrolling (#28328) and other minor things added to core the past few months.

    Editor Experiments

    The goal of this project was to make it easier for plugins to add views in the editor, for example for their shortcodes. It’s been very difficult, however, to figure out the needs and support all different scenarios. Technically it’s also not easy, since we’re working in an iframe, all the changes are tracked by TinyMCE and the DOM can get rebuild.

    As for a UI, there are lots of options for an editing interface. WordPress should provide some options, but the experience should be customisable. Ideally it should be possible to edit views straight inside the editor. E.g. for a gallery view, it should be possible to edit captions inline and rearrange images. I decided to pick a popular shortcode and see what I can do. I picked a shortcode that can display a Google Map, and it ended up like this in the editor:

    Screen Shot 2014-08-20 at 13.04.06

    You search by address, or just drag and zoom the map, change the map type etc., and it will update the shortcode for you.

    I realise the is just one case, and there are a few more necessary to figure out an API. There are also a lot of improvements needed to the view plugin in TinyMCE. Currently it is not possible to have editable text fields inside the view. It is also not possible to drag views around, let alone drag and drop items inside a view, which would be a huge deal for shortcodes that let you add form elements for example. With the “Editor Experiments” it is possible to add an “inline” toolbar to manipulate the view. Of course, you still have the option to display your own modal and update the view after it closes.

    Another goal was to experiment with the concept of content blocks and inline editing. I made a TinyMCE plugin that adds a toolbar with formatting tools when you select something in the editor and that is extendible in the same way the default toolbar is. You can create your own buttons (like you did before) and add them to the toolbar, or just any existing one. In the future, we can change the buttons based on the selection.

    Screen Shot 2014-08-20 at 13.11.01

    Screen Shot 2014-08-20 at 13.12.14

    To add a block, you have to put your cursor in an empty paragraph and the following will show up:

    Screen Shot 2014-08-20 at 13.14.42

    Clicking on it renders the block toolbar:

    Screen Shot 2014-08-20 at 13.15.22

    And this toolbar too is extendible. You can add any TinyMCE button to it, but of course only buttons that insert something will be useful here.

    Front-end editor

    The original project was called “Front-end content blocks”, but we’ve changed the goals a bit at the start to focus on the back-end editor first instead, and it kind of felt like development on the FEE has stopped in the last few months. But that’s not entirely true. All these improvements can be implemented in the FEE too. That’s why I’ve also completely rewritten the FEE from scratch and added all this stuff. The improvements include:

    • An inline toolbar for text, images and views. The fixed and always-visible toolbar is gone.
    • The “add block” toolbar to insert content. Similarly you can add a featured image.
    • The kind of buggy “view” implementation is now completely replaced with the view implementation in core form 3.9 and all the improvements I did for 4.0.
    • The editor now loads instantly on the page. No page refresh anymore. Also no page refresh on save/publish. You can simply toggle the editor on and off. It was mainly this change that required most of the rewrite…
    • Fixed and improved lots of other stuff. It’s just better if you try it yourself… Go to GitHub and clone the plugin. :)

    Something else I’ve been working on, and that is currently in the FEE, is automatic markdown conversion as you type. Not that it would be useful in the current implementation for all the syntax, but for some things it is really useful. Typing *  or -  converts automatically to a list, 1.  to a numbered list and *word* or **word** to italic and bold. :)

    I’ll publish another post soon with more information about the Front-end Editor. I’d like to do a 1.0 release soon after the release of WordPress 4.0, and any help is really welcome.

     
    • Stephane Daury (stephdau) 8:53 pm on August 20, 2014 Permalink | Log in to Reply

      I, for one, have to mention how valuable your contribs were, and thank you profusely for them.
      Awesome work, J. :)

    • Gregory Cornelius 9:22 pm on August 20, 2014 Permalink | Log in to Reply

      Thanks for all your hard work! I hope that you learned a few things along the way and are able to continue contributing to WordPress.

    • Matt van Andel 10:29 pm on August 20, 2014 Permalink | Log in to Reply

      One use-case that I’d like to see addressed is the concept of content separation… or having “blocks” of content that are handled separately by the theme… either by loop or by loading specific named blocks.

      The reason for this would be to make highly structured template pages easily maintainable in the admin from a single edit screen. Here’s a quick-and-dirty experiment that demonstrates the concept… https://github.com/Veraxus/nv-plugins-content-blocks

      You can create new blocks in the editor wherever you like – similar to adding a “more” tag – and give them a name for reference. Those tags are then parsed out in the post object. The entire content can still be rendered out with the_content() but you can render specific blocks in the current loop with the_content_block($block_id) instead. This lets you create a structure-heavy page template and load specific chunks of content from the editor without exposing the admins to any complex, easily-broken underlying HTML.

      In other words, it helps keep the HTML in the theme templates and the raw content in the editor.

      Now my current approach may not be the best, but it addresses a problem that is becoming more and more common as WordPress gets ever more popular as a full CMS.

      • Janneke Van Dorpe 10:50 pm on August 20, 2014 Permalink | Log in to Reply

        Do you have a use case for that? Just not sure what the benefit would be.

        • camu 3:20 am on August 21, 2014 Permalink | Log in to Reply

          There’s already a very powerful plugin that does this. I use it all the time: Visual Composer. You can find it on CodeCanyon.

          • Matt van Andel 3:44 pm on August 21, 2014 Permalink | Log in to Reply

            Thanks for the heads up, but that’s nuclear-grade overkill what I’m asking.

            Example A:
            You are building a website for a business that makes and sells a specialized piece of computer hardware. As you scroll down the homepage, you give the visitor a tour of what makes this hardware special, from the inside out. As you scroll down the page, the entire system assembles itself on the left of the screen, with new hardware coming up from the bottom and being “stickied” to what is already there… motherboard, CPU, chipsets, case… with information appearing to the right of the hardware at each step.

            Example B:
            You have a page that is a detailed Timeline of an organization’s history. Each date is a full-width fluid box with a background image. Floating above that background image is a lightly transparent white box with the date and descriptive text. The admin should be able to adjust dates (post title) and copy, and change the image at any point… or add new points in the timeline.

            • * *

            Traditionally, anything with that amount of structure, animation, or other complex technical requirements would have to be entirely hand-coded in a theme template as TinyMCE is horrific at handling complex HTML, particularly when you want a client to be able to easily edit things in the visual editor, without worrying about any important HTML breaking.

            But how do we expose those individual blocks of copy to admins in an elegant, highly usable way… so that they can be easily updated at any time (without anyone needing to futz with template files)? Ideally, the admin user would be able to edit anything on the homepage simply by editing the Homepage and being presented with all the blocks, neatly separated, that can be edited… but this is not something that WordPress currently supports at all.

            One old hacky solution I’ve used for years is to set up each “block” as a sub-page of Home, and then load those posts on a case-by-case basis. I’m not a fan of this approach as it’s a usability nightmare (one page is built out of many sub-pages), although the specific mechanics (blocks become a special kind of child post) may work well as a technical solution if a plugin provides the right kind of admin UI to support it (including hiding child pages from list tables that are technically blocks and not standalone pages).

            Another hacky solution (the one I linked to earlier) uses the HTML comment <!–block–> to split content in the same editor into blocks, just like &lt!–more–> – but those can be loaded in the template individually or looped. The current version is inelegant and ugly as hell, and currently only identifies blocks by array index instead of a more flexible title or tag… but it keeps all of a pages content neatly in one place… the editor for that specific page, where it belongs. Then the theme can control how and where those blocks are displayed on the page.

            Hopefully that makes that more clear.

            • Janneke Van Dorpe 3:54 pm on August 21, 2014 Permalink

              I get the idea, but these seem to be very specific use cases. There is actually already a similar concept to what you’re describing with and that’s . You can access the array of blocks with the global $pages. It sounds like your plugin is doing exactly this, and nextpage is build in core. You just tell the user to separate the content with page breaks and add the button to the editor, since it’s not there by default.
              Other option is to add more instances of TinyMCE under each other, but that might be a bit of an overkill.

    • Fab1en 7:53 am on August 21, 2014 Permalink | Log in to Reply

      Thanks a lot Janneke for your great work !
      The possibility for plugin to add views to the TinyMce editor looks very promising. I can provide you some use case examples where a custom view is needed.

      The first use case is exposed is the following WPSE question : Adding more options to the instance of an image. The user wants to modify the markup inserted for an image without switching to Text view. So that requires to extend the default image view with more options.

      The second use case is for a shortcode provided by Aesop Story Engine. The need is to position an element with the mouse, so jquery ui draggable widget is needed. I managed to achieve this, but jQuery ui needs to be loaded inside TinyMCE iframe to make this work.

      • Janneke Van Dorpe 3:40 pm on August 21, 2014 Permalink | Log in to Reply

        Thanks for the feedback!

        For the first case, you should take a look at this plugin: https://wordpress.org/plugins/advanced-image-styles/
        There is already a “view” for images, and the image details modal gives you options to change it. It’s not really a view though. It has its own TinyMCE plugin to handle everything, since at the moment views can only block elements in the editor and can’t be aligned. It’s also no possible yet to edit text in a view (which would be required for the caption).

        Yes, jQuery UI draggable is tricky to use in iframes. It shouldn’t be necessary to enqueue it inside the iframe. I wonder how hard is would be for jQuery to fix this. Anyway, this is why views in the front-end editor or so much easier to handle. No iframes!

        I’ve tried to use Aesop Story Engine several times, but I could never figure out how it works. It just inserts a bunch of shortcodes?

    • Ryan McCue 4:22 am on August 22, 2014 Permalink | Log in to Reply

      This is hugely exciting. :) The inline buttons especially are awesome, but all the other parts rock too.

      • Janneke Van Dorpe 5:57 am on August 22, 2014 Permalink | Log in to Reply

        Thanks!

        You asked me about using your JSON Rest API for the Front-end Editor a while ago, and I’m interested in using it. But I’m a bit hesitant to require another plugin. I also want to release the new editor soon after WP 4.0 is released, so there might not be enough time to switch over, but it would be cool to try it out. :) How is the project going, and do you still need other projects to try it?

    • Nick Halsey 1:39 am on August 24, 2014 Permalink | Log in to Reply

      Wow, great job Janneke!

      I think we should start looking into integrating FEE and the Customizer. Both are front-end-contextual, and I see the Customizer as the place to handle non-content whereas the FEE does content. At least initially, that helps to preserve the way WordPress separates content from layout & design for the UX.

      Interestingly enough, the FEE currently works within the Customizer preview. You’ve got a much smoother experience going with your plugin right now, without the need for a pageload, and that’s something we’d like the Customizer to also be able to do eventually.

      I envision a “post” panel in the Customizer, contextual to single views. If the panel is opened in the Customizer, the front-end editor would load in the preview. If the front-end editor is triggered from the front-end, it would load the editor and open the Customizer, to the post panel/context. This allows users to quickly access other customization tools such as widgets and menus while editing content, but keeps content separated from everything else by making it editable in the preview rather than alongside it. And with panels, the visible UI context is limited to post-related things.

      The “post” panel would essentially contain all of the metaboxes from post.php for a given post type, as accordion/customizer sections. While experimenting with making post metadata directly editable is intriguing, I think we really need to have a more obvious mechanism for adding and managing taxonomies, featured images (the current implementation just isn’t compatible with everything themes do), things in the publish metabox, etc. Putting that into the Customizer would keep things visually consistent with our other front-end-contextual UI, and implementing it as a Customizer panel rather than a Customizer look-alike integrates direct access to other site Customization tools while editing content. We could also pull in the metadata UI API if/when it’s merged into core and/or implement post meta into the Customizer API (maybe with a postmeta setting type).

      I know @westonruter has been experimenting with editing posts with the Customizer and two-way communication between the Customizer controls and preview lately too, so I imagine we’d be able to get something like this working from a technical perspective. It would definitely be a lot of work to build a fully-integrated solution, though.

      • Janneke Van Dorpe 3:29 pm on August 26, 2014 Permalink | Log in to Reply

        Yes, definitely. I don’t see why we shouldn’t experiment with this. That’s also one of the reasons I made the change to “instant” on/off, and I’m aware the editor works in the customizer. Shhht! :) I will add an item there to turn the editor on, and maybe some of the UI can move there when uncollapsed. We can experiment with both at the same time, there’s no need to make any decisions about that direction now. Personally, I prefer to use the editor when there’s no panel making the screen smaller and with access to all buttons etc.

    • danieliser 5:27 am on August 25, 2014 Permalink | Log in to Reply

      Just tested the new editor, love love love the block concept. What are the plans to incorporate this into core? Any thoughts on what milestone this may be included?

  • Helen Hou-Sandi 4:13 pm on August 13, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    All hands on deck for 4.0 Beta 4 and RC 1 

    We’ve been pushing really hard to get to a place where a final beta and then RC phase are appropriate for the 4.0 development cycle.

    This impacts a few things:

    • The release date (currently scheduled for August 27, in just two short weeks).
    • Finalizing help and about page text, and thus string freeze (and, therefore, translators).

    With the help of everybody who’s contributed to this release thus far, we’ve done a really great job with the features we’ve been working on and the overall ticket queue for this milestone. All of that said, we need your help to get the following done:

    Needed to reach the final beta

    • #28328: Focus on editing, while editing (editor scrolling improvements). There is a comment that outlines a few things we feel need at least consideration before we consider this release-worthy. @stephdau has been working through patching – testing of patches is greatly appreciated, as are bug reports (as always).
    • #28842: Media Grid: Bulk selection mode. User testing and further feedback have led us to give a separate selection mode another try. @ericlewis has been doing very heavy lifting throughout the cycle on the feature. There is a patch for testing (not for commit) along with some observations on ticket. Once again, testing and UI/UX observations are very welcome. If you would like to help with patching, please let us know and we can coordinate to avoid duplicate efforts.

    Needed before RC1

    • Commit or punt all tickets currently slated for the 4.0 milestone. Anybody can help by testing/writing patches or marking tickets for commit or punt using keywords. If you’re not sure, feel free to ask in IRC, on ticket, or just move to the next one.
    • Triage all tickets reported against trunk. This is especially important in the RC phase, as we need to monitor things reported against trunk for bugs introduced in the cycle, particularly regressions. Many tickets opened against trunk will apply to earlier versions – please change the version field as appropriate to reflect that. It may help to filter out anything already milestoned for 4.0 or Future Release.
    • QA sweeps across browsers and devices, particularly on new features and checking CSS for anything introduced that may not work in IE8 or in some cases IE7. For instance, any usages of CSS calc() need to have a fallback for IE8 and older.

    If you’d like to tackle something you see here and would like a little more direction to get started, please leave a comment below or head over to #wordpress-dev in IRC. One or more core developers is likely to be around at most hours.

    Finally, for today’s dev chat at 2014-08-13 20:00 UTC, let’s take a quick look at the above, note any other blockers we see, and get people assigned to tasks/tickets as we can.

     
    • Robert Chapin 5:54 pm on August 13, 2014 Permalink | Log in to Reply

      I can’t make the meeting but I am subscribed to the Formatting component in case anything comes up. Have a good one. :)

    • Mattias Tengblad 1:01 am on August 14, 2014 Permalink | Log in to Reply

      One HUGE blocker for RC1 is that the translators have ZERO strings to translate yet. String freeze anyone? What so freaking hard with communication between groups? Will look really good to have an all new language packs installer with no up to date languages.

  • Nick Halsey 12:20 am on August 8, 2014 Permalink | Log in to leave a Comment
    Tags: , ,   

    GSoC Menu Customizer Update: Live-previewing Menus 

    I’ve finished implementing menu-previewing in the Menu Customizer plugin, building on the scalable approach to saving menus that I discussed in my last update. The entire Menus experience is now consolidated into a Menus panel in the Customizer, where you can preview your menus as you make changes. It’s really nice to have Menus easily accessible alongside the rest of the site-appearance-management tools in the Customizer.

    I only have about a week and a half left in my GSoC project, and I’m hoping to focus on improving the add-new-menu-item panel in my remaining time, making it scale and implementing the search functionality. I’m also planning on cleaning up the codebase and implementing the ability to manage menu hierarchy (submenus).

    If you’re interested in testing the Menu Customizer, and live-previewing changes to your menus, you can get the plugin here. Please note that it currently requires PHP 5.3+, but it’s getting less and less alpha by the day.

    Post-GSoC Plans

    After the GSoC coding period is over, I’m planning on transitioning Menu Customizer development to the feature-plugin format, gathering a group of interested contributors and holding weekly meetings to coordinate our efforts. While it won’t be ready for core consideration by 4.1, and requires some more core Customizer infrastructure to really work well, we’ll continue working on the plugin until menus in the Customizer really shine, and are ready for core.

     
  • Helen Hou-Sandi 7:42 pm on August 6, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Proposed agenda for today’s dev chat:

    Please propose any other items you might have in the comments.

     
    • Stephane Daury (stephdau) 7:48 pm on August 6, 2014 Permalink | Log in to Reply

      #27440 only has one issue left (as of .3 patch, .4 to be discussed), and I could use some help with it: UI for section tabs in small screens: they wrap, and mess the layout up.

      Making that a menu was discussed in last week’s chat, but I found it to be meh (extra clicks, etc) in my tries.
      I had in mind to try what an horizontal scrolling bar (as some native apps do), with a visual cue that there’s stuff to the right/left to scroll to, but the CSS is giving me trouble, and I’m empty handed right now.

    • Nick Halsey 7:51 pm on August 6, 2014 Permalink | Log in to Reply

      #28979 should be finalized one way or another before RC as mixed priorities would require a lot of churn (probably introducing a new section-panel parent class, renaming a file, etc.).

    • quangn 9:36 pm on August 6, 2014 Permalink | Log in to Reply

      I have question how about adding “shuffle” and auto play in the player for audio music? I really miss this feature and I wrote several posts about this and it seems no one replied to me :(

    • Mattias Tengblad 12:20 pm on August 7, 2014 Permalink | Log in to Reply

      For the love of god, think of the children…ehm…I mean the translators. Two ~ weeks left to release? We need information, and strings to translate!

    • rajlaksh 5:38 pm on August 9, 2014 Permalink | Log in to Reply

      Is Categories will become like TAGS System? Easy to browse?

  • Ryan McCue 1:02 pm on July 26, 2014 Permalink | Log in to leave a Comment
    Tags:   

    JSON REST API: Version 1.1.1 (Security Release) 

    I’d like to announce the availability of version 1.1.1 of the JSON REST API. This is a security release for a minor security issue, however we recommend all users running 1.1 upgrade as soon as possible.

    This release only affects users running WP API on a domain with other (non-WordPress) software running. Using the JSONP support built-in to the API, it is possible to serve up arbitrary Flash SWF files from the API, allowing these Flash files to bypass browser cross-origin domain policies. While WordPress includes built-in CSRF protection, other software running on the same domain may not include similar protections.

    As a workaround, JSONP support can be disabled on your site with:

    add_filter( 'json_jsonp_enabled', '__return_false' );

    Thanks to @iandunn for reporting this issue to the team responsibly.

    We’d also like to announce that WP-API is now available on HackerOne. We invite security researchers and developers to report any potential security issues to us via HackerOne, allowing us to triage and fix issues privately, and also award bounties for valid security reports.

     
    • Leo Baiano 2:07 pm on July 26, 2014 Permalink | Log in to Reply

      Congratulations, very good this work. Começcando am exploring this plugin and am having good results, then I will be more intimate and who knows the code can not work: D

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