Have you taken the WordPress 2014 Survey yet?

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

  • Mark Jaquith 5:20 pm on September 10, 2014 Permalink | Log in to leave a Comment
    Tags: , meeting   

    9/10 Agenda 

    WordPress 4.0 “Benny” is out the door, warming hearts, flying off shelves, and many other euphemisms besides. After a brief respite to enjoy our success and a job well done, we turn our eyes to the future: 4.0.1, 4.1, and more.

     

    • Ionel Roiban 5:31 pm on September 10, 2014 Permalink | Log in to Reply

      Congratulations, everyone!

    • Stephane Daury (stephdau) 5:43 pm on September 10, 2014 Permalink | Log in to Reply

      4.1 release lead nominations: I’m going to go right in crazy mode and suggest @rmccue.
      Note: I have not discussed that with him, so it’ll catch him by surprise.
      My logic is as so:

      • in May, we had a big IRC convo during our weekly chat about committing to WP API.
      • From what I can tell, said API is quite ripe for 4.1, or could be with the proper effort.
      • Making Ryan a lead (if he can afford to) could be a good way to make WP API the big ticket item for 4.1

      • Stephane Daury (stephdau) 5:46 pm on September 10, 2014 Permalink | Log in to Reply

        That’s also obviously my vote for the focus in 4.1. :)

      • Justin Sainton 6:41 pm on September 10, 2014 Permalink | Log in to Reply

        Really great suggestion! I think @rmccue would make an awesome lead, but I just don’t know about it for the release where he’s the lead on such a major component as the WP-API.

        Just spitballing here, but I wonder if it wouldn’t be a better situation to have someone as a release lead who can shepherd the whole release, not just that specific component? In my imagination, getting the API in the 4.1 release would require someone like Ryan to be more fully devoted to that specific component than to the whole release.

        Just my two cents.

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

        When the API is merged in, we’d probably be best served with Ryan’s focus to be 100% on the API, and not need to worry about anything else also going on. The release lead is as much a project manager as it is a final arbiter, shepherd, and what not. Also, the API is going to be a big ticket item in the release it’s in, no matter what. :)

    • Stephane Daury (stephdau) 5:51 pm on September 10, 2014 Permalink | Log in to Reply

      Call to action on feature plugins for 4.1 and beyond: in the same line as my WP API suggestion, and if it does make it in 4.1, I (we?) would like to resume work on the Press This rewrite, with the twist of building it as a WP API client. It could act as a great bundled example.

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

      Some questions to ask:

      • What have we done in the last few releases that could benefit from a v2, even small things?
      • What have we added in the last few releases that needs to be propagated to other areas?
      • What have we not touched in a very long time and is long overdue for a revisit?
      • What brand new features should we consider working on?
      • What existing features need a complete rethink?
      • What are some bite-sized things that we could do to make a big impact? (3.9 and 4.0 were full of these.)
      • What are big things that are broken and that we feel like we could fix / make better?
      • What might Twenty Fifteen benefit from having in core?

      Also, if you want to help lead a release or want to suggest someone, be sure to read this post from 4.0.

      • Stephane Daury (stephdau) 7:08 pm on September 10, 2014 Permalink | Log in to Reply

        For #1 and #2: we delayed a move to Backbone.js (propagate) for the plugins browser/modal (updated in last release) in 4.0, under my advice, to focus on functionality rather than getting bogged down in a library switch. Should that be tackled that in 4.1, building on the experiences of the Media Grid et al?

      • Nick Halsey 7:30 pm on September 10, 2014 Permalink | Log in to Reply

        To address several of those points, I’d like to continue iterating on the Customizer. Starting to build out better JS APIs in particular, building up to several features that’ve been delayed due to the lack of structure here.

        I’d really like to get media in the Customizer rebuilt (initial patch on #21483), and to officially deprecate and redirect/deep-link the old header and background admin screens. Given Twenty Fifteen’s emphasis on those features, this seems like a good time to finally pull the trigger here.

      • John Blackbourn 7:31 pm on September 10, 2014 Permalink | Log in to Reply

        What have we not touched in a very long time and is long overdue for a revisit?

        I think we need to have a think about all the JavaScript which is landing in WordPress these days, and make sure we are documenting it well enough, whether we need to prioritise an action/filters API for this, whether we are doing enough to educate contributors and other developers on the JavaScript APIs, whether we need a better structure for the .js files, etc etc. See also Eric’s post on wp-hackers.

        What are some bite-sized things that we could do to make a big impact?

        Fix the currently rubbish comment notification settings. See #6286, #14676, #761, Email Alerts plugin.

      • Ihor Vorotnov 2:01 am on September 11, 2014 Permalink | Log in to Reply

        Jumping in here. The feature which is highly anticipated by literally any WP developer outside US and several other english-speaking countries is… some multilingual features in core.

        Here’s my idea in details: http://wordpress.org/ideas/topic/native-multilingual-cms-features-one-more-time#post-27185

        Basically, even making terms slugs non-unique and adding some super-taxonomy `language` will allow major plugin developers (WPML, Polylang) do the rest. WPML currently allows to have posts and pages with same slugs, but not categories, tags and custom taxonomies.

        Right now I’m building a pretty large international website, which will function a s a website and a mobile app platform (backend) – thanks to JSON API. Having urls like `example.com/ru/profile-2/edit` or `example.com/ru/profile-ru/edit/` (just plain simple hierarchical pages) is kind of freaky. Or `example.com/ru/events/country/canada-2/city/toronto-2` and `example.com/ru/events/country/canada-ru/city/toronto-ru`…

        Sooner or later, we need to add solid multilingual features to core to become CMS / Framework, not a blog platform.

    • Zach "The Z Man" Abernathy 7:18 pm on September 10, 2014 Permalink | Log in to Reply

      I personally would love to see a little more work in the area of media with respect to actually managing the media items. For instance, being able to group things in folders would be a huge improvement.

    • John Blackbourn 7:21 pm on September 10, 2014 Permalink | Log in to Reply

      I would like to get the ball rolling on open and closed Multisite networks which didn’t get any traction in 4.0 due to time constraints.

    • Boone Gorges 7:23 pm on September 10, 2014 Permalink | Log in to Reply

      I won’t be able to make this meeting, but I’d like to spend some time during the 4.1 cycle improving WP_*_Query classes. Improved test coverage (see eg #29560), followed by fixing some of the more egregious bugs (such as #19623), and adding what I see as some missing features (#29181, #29181, and a few others I am cooking up). May also look into abstracting some of the common logic into some sort of base class that the others will extend.

    • Robert Dall 8:01 pm on September 10, 2014 Permalink | Log in to Reply

      I’d like to fix the poor UI In the widgets since they were last updated. Specifically #27180 I know we can do better.

    • Aaron Jorbin 8:12 pm on September 10, 2014 Permalink | Log in to Reply

      I’d like to work on getting our JS unit tests running automatically on multiple browsers. I’d also like to look into some automated tests around front end performance of the admin and finding areas that we can speed things up (and also maintain a benchmark of how things are).

    • Xavier Borderie 8:16 pm on September 10, 2014 Permalink | Log in to Reply

      I’d vote for changing the in-editor image update, making like the one in Confluence. I use this wiki tool at my job, and love that, while WP uploads the file and shows the library, letting me inserting the media, when I really want to directly insert it in place. Makes a huge difference.

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

      The Export API was proposed for 4.0 and didn’t make it, would be great for 4.1:
      Export API improvements/overhaul #22435

    • Dan Milward 11:34 pm on September 10, 2014 Permalink | Log in to Reply

      I agree with Nick Halsey. For me it’d be something small and scene setting for more socket.io integration in the future – its hard to argue against the technology on the basis that Automattic acquired it right?

    • Brandon Wamboldt 2:15 am on September 11, 2014 Permalink | Log in to Reply

      The last few releases have made great strides in user experience in the admin, but now I think the team should focus on developers a bit for 4.1. As somebody who works frequently in WordPress, a big pain point is still list tables.

      I frequently create custom tables for data that really don’t fit the mold of post types, and I often have to duplicate large amounts of code to create a list view that mimics the other list views (posts/pages/etc). If you guys could ease that, it would be awesome!

    • Shail 5:00 am on September 11, 2014 Permalink | Log in to Reply

      For me most awaited feature is taxonomy meta. Is this feature in race? I know this is a very big change but I like to see it in core.

    • Ryan Boren 12:50 pm on September 11, 2014 Permalink | Log in to Reply

      I’ll dump my rough notes.

      Mobile and media. Media and mobile.

      Context, Trust, Awareness, Flow

      Press This. With the mobile improvements to the media modal that landed in 4.0, Press This can use the modal without being crippled on phones. The wordpress.com/post/ editor on wordpress.com has worked through some of the same problems that Press This needed to work through, hopefully smoothing the way. The /post/ editor also showed what you can and cannot get away with. Media, preview, and links are important. wpviews and wplinks are must haves. Media must be visual, not raw html, short codes, or even placeholders. Creating galleries should be possible and easy. Press This has a freedom that the /post/ editor does not. PT doesn’t have to worry with existing content edit flows. It can be tailored to a fairly one way creation flow (akin to Tumblr). It also has an advantage in that it can and does allow escaping to the full editor in the admin when the user needs more than PT provides.

      Press This is not just UI. It is bookmarklets, extensions, side-loading, re-blogging, and sharing. It is the sharing mechanism in Android and iOS8. Someday it will be accommodated by the apps. Keep the entire Press This and sharing ecosystem in mind. When dev resumes, prioritize bookmarklets and fleshing out the sharing mechanisms, especially on mobile. Press This the UI is, in part, a trojan horse for getting a decent mobile posting interface on phones, but the sharing big picture should not be lost to new UI fascination.

      Press This the UI should be a marquee user of WP API.

      Large (full screen-ish) images should be a tap/click away in the media modal. Creating and captioning galleries is difficult when provided only thumbnails. Maybe borrow the attachment details modal from grid view.

      Re-think media modal for touch devices. Get rid of tabs, especially in the absence of multi-select. Full images on tap with details below (like the attachment modal) rather than opening the sidebar and presenting another thumbnail sized image. That sidebar is awful on phones.

      Re-think the media modal in general. We know more about how it is used than we did back when. We know what plugins are actually rather than speculatively doing with it. Is having a separate gallery flow still a necessary compromise? Is a sidebar the best way for plugins to integrate? Is there anything blocking VideoPress and Dropbox plugins from integrating? Which plugins integrate well with the media modal?

      Create gallery and image posts from the media library grid view. Give bulk selection a purpose. This will accommodate mobile flows where images are uploaded to the media lib from a mobile device (via Android’s multi-select capable sharing mechanism, for example) and then gallery posts are later created from a desktop. This is a means of working around our lack of mobile multi-select and gallery creation interfaces.

      Phone UX improvements, particularly menus. Is it possible to swipe to open/close side menus on the mobile web? Side menus must have swipe to be usable. Tapping a menu icon in b’ar should dismiss the menu instead of visiting a link. There is often no safe “tap outside” room on a phone, so all menus should dismiss when their icons are tapped. Very aggravating.

      When adding links on mobile, don’t require highlighting text to activate link icons. Buggy on phones.

      Tweak wplinks for phones. It’s already pretty good and keyboard up/down responsive, but mostly by accident.

      Multi-select upload everywhere.

      B’ar consistency. The front page b’ar on touch devices is my favorite. Tablets in landscape show the narrower b’ar in the admin, which always disappoints me.

      Images uploaded to the media library and then added to a post don’t show up in the “Uploaded to this post” filter. Not being able to filter down to images already on the post makes setting featured images tedious. Uploading from mobile to media lib and then posting later is a common mobile flow.

      Fix the image editor on phones.

      Lose media-new.php?

      Oh wouldn’t it be nice…

      Settings that don’t suck.

      An index.php featuring Press This and a reader.

      Reader views for all list table screens.

      Theme switching from the customizer.

      Notifications, Stream.

  • Konstantin Obenland 11:57 pm on September 9, 2014 Permalink | Log in to leave a Comment
    Tags: 4.1, , Twenty Fifteen   

    Twenty Fifteen 

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

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

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

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

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

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

    —Takashi Irie

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

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

    Further reading:

     

  • Jen Mylo 1:17 pm on September 8, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    WCSF Tickets, Meetup Info 

    Anyone planning to attend WCSF this year from the core team, please read the post at http://make.wordpress.org/updates/2014/09/08/wcsf-tickets-and-stuff/ for information about WCSF ticket sales and the contributor days following the main conference. Thanks!

    P.S. If you are planning to attend the core team meetup but I have not been in touch with you regarding hotels, please ping me in IRC (jenmylo) or shoot me an email (same username @wordpress.org) so I can include you in the planning. If we have talked in general but you haven’t actually booked anything, don’t freak out — we have a spot on hold for you and you’ll be able to book it this week when we send out the booking codes.

     

  • Dominik Schilling (ocean90) 12:13 am on September 5, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Language chooser in 4.0 

    As mentioned in previous posts, WordPress 4.0 includes a language chooser. After selecting a language WordPress will download and install the language pack on the fly. The rest of the install process will then be in that language.

    Language Chooser in WordPress 4.0

    Language Chooser in WordPress 4.0

    A summary

    To make this possible we introduced some helper functions or changed existing functions.

    translations_api() is based on plugins_api() / themes_api() and retrieves translations from the WordPress Translation API. The first argument $type must be core, theme or plugin. $args is used for additional arguments. For example $args['version'] should be specified for all types. Types theme and plugin must set slug too.

    wp_get_available_translations() function is a wrapper for translations_api() and returns core translations for the current installed version. The API result is cached for 3 hours.

    As soon as a language is selected and the Continue button is clicked, WordPress will download the language pack in background, wp_download_language_pack() does this with the help of Automatic_Upgrader_Skin and Language_Pack_Upgrader.

    Because translations are installed on the fly we had to enhance the existing load_default_textdomain() function. It now supports an optional $locale parameter to allow to switch the default translation. ([29630])

    The WPLANG option is now set in single sites too and is populated on upgrade, based on the value of the WPLANG constant, which is now deprecated, see [29630]. get_locale() now includes the global $wp_local_package variable (used in localized packages) and an existing but empty WPLANG option can override the WPLANG constant as an empty WPLANG option is equivalent to en_US.

    wp_dropdown_languages() replaces mu_dropdown_languages(), which had many issue like not supporting variants of the same language (like en, en_GB, en_CA and en_AU). The new dropdown is populated by the translation API.

    Asynchronous translation updates

    In WordPress 3.7 we had introduced Language_Pack_Upgrader::async_upgrade(). Asynchronous translation updates will run after a theme or plugin is installed or updated. What’s the purposes of async updates? One, when you install or update a theme or plugin, you’d expect to get the translations updated for that theme or plugin. But all out of date translations are updated here (even when that plugin or theme was already up to date), in order to capitalize on the fact that we have a filesystem connection (which may be via user-submitted FTP credentials).

    In WordPress 4.0 this asynchronous update will no longer run on version-controlled installs. You can also use the async_update_translation filter (which corresponds exactly to the auto_update_translation filter) to disable it, see [29694].

    // Disable asynchronous and automatic background translation updates
add_filter( 'async_update_translation', '__return_false' );
add_filter( 'auto_update_translation', '__return_false' );

    Other notes

    • Localized packages will skip language chooser, see [29705].
    • For BC it’s allowed to choose a language specified by the WPLANG constant (but not installed), see [29691].
    • General Settings includes an option for the Site Language in single sites now too.
    • WPLANG section from wp-config-sample.php is removed, see make/polyglots post.
    • On install, WordPress will skip the language chooser if it has no access to the filesystem without asking for credentials, see [29673].
    • For a peek at what’s to come in 4.1, check out #29395.
     

  • Andrew Nacin 3:56 am on September 4, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    The props list has been updated on the 4.0 credits page. If you haven’t updated your display name yet, you should totally do that on your support forum profile.

     

  • Helen Hou-Sandi 11:39 am on September 3, 2014 Permalink | Log in to leave a Comment
    Tags:   

    4.0 release plan update 

    If you’ve been following along with IRC and Trac activity over the last 24 hours, you’ll have noticed that there’s been a lot of it. We’ve had a number of issues pop up, and thus did not reach the targeted freeze of 16:00 UTC on 2014/09/02. If you haven’t been following along, I highly recommend it :)

    Given that, our new release target is shifted back one day to 16:00 UTC on 2014/09/04. We’ll still kick off two hours beforehand with various pre-launch checks and tasks. This means code freeze by 16:00 UTC on 2014/09/03 – just a few short hours from now. I would also like to run a number of those pre-flight checks in the hour or two before freeze to give us an early chance to squash anything that may come up during those. To that end, an RC2 has been built for final testing.

     

  • Helen Hou-Sandi 3:41 am on September 1, 2014 Permalink | Log in to leave a Comment  

    4.0 release plan and 8/27 meeting summary 

    Per dev chat on 8/27 (summary below), we are targeting a release of 16:00 UTC on 2014/09/03, kicking off at 14:00 UTC on 2014/09/03 in #wordpress-dev. There are a number of steps to go through, including running unit tests, checking build, and testing various update and installation scenarios. We’ll also do a dry run at the same time on Tuesday, 9/2, before we enter a 24 hour code freeze.

    I’d also like to meet at 18:00 UTC on 2014/09/01 in #wordpress-dev to clear out all open tickets for 4.0 and do an RC2. It is a holiday (Labor Day) in the US, but I will be around throughout the day, as will other committers and contributors.

    Summary of 8/27 dev chat (IRC log):

    (More …)

     

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

     

← Older posts

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