Have you taken the WordPress 2015 Survey yet?

WordPress.org

Make WordPress Core

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

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

We’d love for you to help out.

Looking to file a bug?

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

Want to contribute?

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

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

Weekly meetings

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

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

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

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Morgan Estes 1:45 am on October 13, 2015 Permalink |
    Tags: ,   

    Week in Core: Sept. 28 – Oct. 11, 2015 

    Welcome back to the latest issue of Week in Core, covering changes from Sept. 28 – Oct. 11, 2015, changesets [34659]–[35029]. Here are the highlights:

    See that ↑ right there? That’s an oEmbed. And it’s loaded from inside this site.

    Feature Plugins Merged

    The Responsive Images, oEmbed Provider, and the “baby” REST API feature plugins have been merged into core. Grab the latest version of trunk and test them out.

    WordPress logo with wordmark below

    Responsive images in your posts. Just upload and insert!

    Potent Notables

    These changes were big enough to merit their own blog posts:

    Deeper Reading

    Some commits pack in a lot of info, from detailed background to best practices in using hooks. Here are a few worth reading the entire commit message:

    (More …)

     

  • John Blackbourn 11:00 am on October 12, 2015 Permalink |
    Tags: ,   

    Tweaks to user searching and management 

    A few improvements have been made to user searching and user management in WordPress 4.3 and the upcoming 4.4. Here’s an overview:

    • 4.3: Performing a search on the Users screen now searches the user’s username, email address, display name, nicename, and URL, instead of just their username and nicename. See #27304
    • 4.4: Performing a search on the Network Admin -> Users screen previously required the use of a * wildcard character at the beginning and/or end of the search term, otherwise the search required an exact match. This is no longer the case, so finding users on Multisite is no longer frustrating and inexplicably dysfunctional. This, combined with the changes in 4.3, means searching for a phrase such as “@gmail.com” now works as you would expect. See #32913
    • 4.4: It’s now possible to filter the Users screen by users who have no role (in addition to being able to filter the screen by individual roles), if there are such users. See #22993
    • 4.4: Users with multiple roles (it’s possible to programatically give a user multiple roles, although this isn’t possible via the UI) are now shown as having multiple roles on the Users screen. This helps avoid obfuscation of a user’s roles. If your plugin facilitates the assignment of multiple roles to an individual user, you should test it against trunk and look at using the new get_role_list filter introduced in [34963] if necessary. See #22959

    Any other improvements you think could be made? Leave a comment.

     

    • JakePT 11:36 am on October 12, 2015 Permalink | Log in to Reply

      Does this new search also search first and last name fields individually? Be nice if it did.

      I also really want the option to not send users their passwords back. When building a site for a client, we’ll set up their account well before handing it over, to make sure permissions, white-labelling etc. are all working fine. Even then we have our own handover method and don’t need to send the WP Mail. I’m kind of shocked that this change was made, honestly. I’m sure a lot of people do the same thing.

    • sirjonathan 12:39 pm on October 12, 2015 Permalink | Log in to Reply

      How about the ability to search by meta values stored in usermeta? I’ve got a case where I’ve added a column to display a custom value but don’t currently have a way to search by that value.

    • deltafactory 1:52 pm on October 12, 2015 Permalink | Log in to Reply

      On the User list table, would it be possible to (optionally?) store per-role user counts in a transient or other cache? For large user-bases with a wide variety of roles, the slow LIKE query that drives this isn’t necessary on every page load while paging through or searching users.

    • Laurens Offereins 3:26 pm on October 12, 2015 Permalink | Log in to Reply

      Great! Any chance #32956 would make it next?

    • Justin Tadlock 9:45 pm on October 12, 2015 Permalink | Log in to Reply

      I’m just stopping by to formally say thank you for the improvements in 4.3 to user searching. You don’t know how many headaches you’ve saved me in just a short time. So, thanks.

      And, keep up the great work!

  • Scott Kingsley Clark 7:29 am on October 8, 2015 Permalink |
    Tags: , , , ,   

    Fields API chat summary – October 5th, 2015 

    Present: @sc0ttkclark, @nicholas_io, @tomharrigan, @ericlewis, @potatomaster

    Logs: https://wordpress.slack.com/archives/core-fields/s1444021200000000

    • I just got 100 hours from 10up to work on Fields API!
    • I will be working on getting the WP 4.3 Customizer changes put into the Fields API, my first pass doesn’t have unit tests passing yet
    • We’ll be fleshing out Control classes, based on Customizer control classes and expand the main control class into individual classes as opposed to a ‘switch’
    • We laid out a few implementations we’d like to get into prototyping
      • User profile fields (piggy backing existing UI of section heading + fields) @sc0ttkclark
      • Settings API (cue the oooh’s and aaah’s sound effect) @sc0ttkclark
      • Post editor (meta boxes + fields) @tomharrigan
      • Widget forms @nicholas_io
      • Future: Term editor (sections + fields)
      • Future: Comment forms?
    • We want to improve the main Fields API readme to better explain the project, offer more links to information about the Customizer API since it’s what we based the Fields API on, and flesh out more examples
    • We need more examples, so any use-cases we can put together for any object type, would be handy to start putting that code together (structures, not custom implementations or overrides)

    We certainly could use additional contributors involved with the project, especially as we seek to start more implementation prototypes of how things could work. Just hop into Slack #core-fields or check out our Github repo. Over the next 5 weeks my involvement in the project will be greatly increased, so if you are going to get involved — now would be the right timing!

    Next chat: Monday 20:00 UTC 2015 (every Monday)

     

  • Robert Chapin 12:42 am on October 8, 2015 Permalink |
    Tags: , ,   

    Shortcode Roadmap Draft Three 

    This is the third draft of the Shortcode API Roadmap. It describes in broad terms the changes that might take place across versions 4.4 through 4.6. This roadmap gives notice to plugin developers that significant changes in plugin design may be needed for compatibility with future versions of the Shortcode API. This roadmap also identifies steps taken to minimize the impact on plugin developers to allow most plugins to continue working with only small changes.

    This roadmap is based on decisions made at meetings, feedback received on previous posts, and consultation with the core developers.

    Our need for a roadmap arose from specific problems in the old code.  There are performance problems in parsing shortcodes, and we need to fix those problems with backward compatibility in mind.  Recent security patches illustrated the problem of not being proactive about security hardening.  Bloat in content filters is another big problem that complicates efforts to correct problems.

    Please comment on this new draft.  We will have another meeting Wednesday at 17Z, which is 2015-10-14 1700.

    4.4 – New Restriction on Shortcode Names

    There is only one item on the 4.4 Milestone. It helps us move toward our goal of security hardening without breaking websites.  Names of registered shortcodes will be slightly restricted by disallowing angle braces.  It should be possible to implement this change immediately with no impact on existing content or plugins.

    The < and > characters will be no longer allowed in the $tag parameter of add_shortcode(). Starting in 4.4, attempting to register an invalid shortcode name will result in a helpful error message.

    These characters will be forbidden in shortcode names: [ ] < > / &

    Also forbidden are the “non-printing characters” including spaces, tabs, new lines, and other control sequences.

    (More …)

     

    • Scott Fennell 1:43 am on October 8, 2015 Permalink | Log in to Reply

      Excellent progress here. Thank you very much for your work and for considering community feedback on this!

      Very relieved to see the bit about allowing an opt-in for shortcodes in html attributes.

      One question. You mentioned,

      “continued core support for HTML in shortcode attributes is likely to evolve through the automatic update system when unplanned future patches are released”

      As the owner of many many instances of HTML in shortcode attributes, I’m not quite sure what to make of this. Are you proposing that my HTML in shortcode atts might break on an automatic update?

      • Robert Chapin 1:53 am on October 8, 2015 Permalink | Log in to Reply

        Yes, some sites were already affected in the 4.2.3 and 4.3.1 updates. There is some concern that this could happen again. It would have been ideal to get more HTML separation but I think we are running out of ideas for that.

        • J.D. Grimes 12:40 pm on October 8, 2015 Permalink | Log in to Reply

          What was wrong with the enclosures syntax? Too complex?

          P.S.—Thank you for your continued work on this!

          • J.D. Grimes 12:56 pm on October 8, 2015 Permalink | Log in to Reply

            Or, why wasn’t HTML in shortcode atts a per-shortcode opt-in feature? But maybe nothing would really be gained by that…

            (Sorry, I didn’t attend the meeting, so I don’t know if this was discussed, and I don’t see a link to the chat in the post.)

          • Robert Chapin 1:38 pm on October 8, 2015 Permalink | Log in to Reply

            https://wordpress.slack.com/archives/core/p1444251538001280

            There was no traction at the core meeting. Mostly negative feedback and no alternatives were proposed. One suggestion was to add closing tags for enclosures, but if I write out an example of that it looks much worse than the original idea. The shortcode would become two or three times longer, and I can’t imagine that would get traction either. So without a syntax that has a chance to see beta, the enclosures idea is out of the roadmap.

            • J.D. Grimes 2:27 pm on October 8, 2015 Permalink

              OK. It sounds like what we really need is an alternative to shortcodes. I don’t mean syntax, I mean the whole concept. I don’t think anyone is going to be happy with the proposal that we just keep breaking things without notice. What we need here is not a shortcode roadmap. Not even Shortcode UI. What we need here is a make-shortcodes-obsolete roadmap.

              Here’s a really wild idea. Now that we have the oEmbed plugin in core, what if in future we replaced shortcodes with the embed feature—except we’d be embedding content from within the site. So we create our content for the shortcode and it is identified by some URL. Then we just paste that URL into our post where we want that content to appear, and viola.

              Of course, that may be completely crazy. But I think we need to begin looking beyond shortcodes for the ultimate solution.

    • Ipstenu (Mika Epstein) 3:29 pm on October 8, 2015 Permalink | Log in to Reply

      > continued core support for HTML in shortcode attributes is likely to evolve through the automatic update system when unplanned future patches are released

      To paraphrase what Helen said in the meeting, the issues with our enclosures of [shortcode:foo=bar] is that we were now actually encouraging people to do the thing we didn’t want them to do in the first place.

      Summarizing what I know we all know, but it’s best sometimes to put this plainly… Using HTML within shortcodes is something WordPress never intended to be a thing, it causes issues, and trying to support it has gotten us into this nightmare we’re at now.

      The options we have boil down to this:

      1) Stop supporting it and break it willy nilly – This sucks because now users, who may have no idea WHY this broke, are stuck with dead sites.

      2) Find a janky workaround to support something we don’t want to support – This sucks because there’s just no way to find and contact and force every developer to update their plugins and core is left holding a bag they don’t want.

      I can argue both cases. Neither is tenable. In both cases, though, communication seems like what we need to do. As much as I don’t want to break users’ sites, no matter what we choose we will be doing this to some extent, and it may be best to do option 1.

      By WordPress 5.0 (I’m throwing a dart at the wall here, this isn’t gospel!), you can’t use HTML in shortcode attributes. Any time between now and then, it might break due to security updates.

      • Scott Fennell 8:43 pm on October 8, 2015 Permalink | Log in to Reply

        “This sucks because there’s just no way to find and contact and force every developer to update their plugins”

        I really appreciate your voice on this @Ipstenu, but there’s a point I’ve been trying to make that I feel like is getting lost. Updating a plugin is pretty easy. What’s hard is updating the post/page content that uses that plugin. That’s the real headache. I know you mentioned the idea of doing a regex search. My database is many gigabytes in size, so this would be a very cumbersome operation. What if I had clients on many databases?

        I’m confused and disappointed that the momentum on this thread seems to be to stop supporting HTML in shortcode atts (HISA) on a security update. Good morning, many, many broken sites. I’ve never known WordPress to do that on such a scale. There has to be something we can do to ease this transition. What if…

        4.5 – Core keeps supporting HISA when rendering content on the front end, but when a field is saved (any text field that might contain a shortcode, to include text widgets and user bio), angle brackets in the shortcode atts are escaped. As a plugin author, I’ll have had time to update my plugins to handle escaped angle brackets however I so choose.

        4.6 – Core ships with an API to execute the update_post(), update_user(), update_option() actions on all fields on all blogs in the network. Agency people like me would be expected to test and execute this step.

        4.7 – Stop supporting HISA.

        • Ipstenu (Mika Epstein) 8:53 pm on October 8, 2015 Permalink | Log in to Reply

          Good morning, many, many broken sites. I’ve never known WordPress to do that on such a scale.

          Sure you do. 4.2.3 – We’re trying to avoid that as much as possible.

          Updating the plugin is easy. In a perfect world, sure that’s true. But getting it updated is not.

          1) Developers have to KNOW you need to. And frankly, the developers who will be most impacted by this change will not. Yes, that’s their fault for not keeping up with things. But the people who get nailed by the break is the users. We need to avoid that if humanly possibly.

          2) Users have to update. And lets be frank, they won’t.

          So what’s worse? Telling everyone “You will be broken by 5.0” or “You might be broken at any time in the future, if we have to edit the shortcode parser, because your plugin was letting you do things wrong” or “You have to edit all your posts in order to match the new parser we’re going to use, which we don’t want to support anyway and we think it’s a bad idea”

          No matter how we look at this, we’re going to be asking users to make a major change.

          If we change shortcode structure, they have to edit all their posts. If we stop supporting it, they have to edit all their posts.

          The only way to ‘not’ break anyone or require anyone to make a change is to never change the shortcodes as we know them today.

          And the thing is, that’s literally where my brilliance fails me. I don’t want to impact the user, but I don’t see a way around it except keeping things as they are, which we shouldn’t for a variety of reasons.

          We dug ourselves into a hole years ago :(

          • Scott Fennell 9:04 pm on October 8, 2015 Permalink | Log in to Reply

            “Sure you do. 4.2.3 – We’re trying to avoid that as much as possible.”
            I disagree. Even I think the use cases broken in 4.2.3 were wacky 😀 . In all seriousness, I think the the use cases being threatened in this thread are far, far more popular (though I don’t have data to back that up).

            “Developers have to KNOW you need to. And frankly, the developers who will be most impacted by this change will not.”
            But instead of just impacting developers, this thread threatens to harm end users who would have to be trained to update their shortcodes.

            “So what’s worse? … [ three rough options ] …”
            I’m a bit of a child at the grown-up table here, but I dunno, what about the roadmap I outlined in my previous comment?

            • Ipstenu (Mika Epstein) 10:56 pm on October 8, 2015 Permalink

              I think people using HTML in shortcodes and some of the crazy things they do with layouts is wacky :) It’s a perception thing. But what happened in 4.2.3 is a smaller scale of things. It’s the canary in the mine for me. I look at that and I know how bad this can get as we scale up.

              Now… This part is where we’re arguing the same thing :)

              Core keeps supporting HISA when rendering content on the front end, but when a field is saved (any text field that might contain a shortcode, to include text widgets and user bio), angle brackets in the shortcode atts are escaped. As a plugin author, I’ll have had time to update my plugins to handle escaped angle brackets however I so choose.

              What happens to every existing HISA I have? Do they still work?

              What happens when I go into an old post with an HISA and edit it and save? Does it retain what I had before or change it do the new?

              How can we ensure that we’re not just moving the problem? I have a feeling we’d actually just be trading one set of problems for another by allowing them to render the HTML on the front end though I’d have to deep dive more into the API to be sure… And part of the issue there is in what people have their shortcodes doing when they process :/

              The issue is that we don’t want the old code to work. Or rather we cannot give anyone assurance it will continue to work due to ongoing security revelations. We pretty much know we’re going to break things. Badly.

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

        To paraphrase what Helen said in the meeting, the issues with our enclosures of [shortcode:foo=bar] is that we were now actually encouraging people to do the thing we didn’t want them to do in the first place.

        I just need to point out that’s not correct. The value was never placed inside a delimiter like that, which would not make sense in the first place.

    • bobbingwide 5:56 pm on October 8, 2015 Permalink | Log in to Reply

      My comments:
      4.4 – restriction on shortcode names is absolutely fine by me
      4.5 – filter priority changing also goes a long way to satisfying my requirements
      4.6 – also acceptable

      but not having the HTML in shortcode attributes, because you don’t like the new syntax and/or haven’t worked through the requirements, shouldn’t exclude it from the roadmap.

      If WordPress doesn’t deliver the goods then I imagine that some developers will just deliver the replacement functionality that’s required. Therefore, IMHO, the requirements should be documented as an enhancement, and then developed as a feature plugin.

      • Ipstenu (Mika Epstein) 6:15 pm on October 8, 2015 Permalink | Log in to Reply

        The issue is WHY we needed to sort out a new syntax in the first place. We’re attempting to support something that was a bad idea to start with, is potentially dangerous, and messes with rendering posts. Building any alternative means we’re condoning something we believe aren’t best practices, and that’s a terrible idea for supportability.

      • Scott Fennell 11:12 pm on October 8, 2015 Permalink | Log in to Reply

        “What happens to every existing HISA I have? Do they still work?”
        I’m proposing that they still render on the front end until 4.7, yes.

        “What happens when I go into an old post with an HISA and edit it and save?”
        I’m proposing that on 4.5, your HISA angle brackets would be escaped upon save. What happens to that on the front end depends on how diligent your plugin author is. I know you have some qualms about that, but it’s better than passing the burden to the end user to edit their shortcodes.

        “Does it retain what I had before or change it do the new?”
        On 4.5, it escapes angle brackets in your HISA, that’s all.

        “How can we ensure that we’re not just moving the problem?”
        Well, at the risk of being tongue-in-cheek, I know I’m solving the problem if core doesn’t break my shortcodes! I’m in an agency context where there are not malicious or even adventurous post editors. I know not everyone is in that position, but I think it’s under-voiced here on the make blog (I digress).

        More to your point, how do we know we’re not just moving the problem? I don’t know — I thought the problem was angle brackets in shortcode atts. Is that not the problem?

  • John Blackbourn 6:52 pm on October 7, 2015 Permalink |
    Tags:   

    add_rewrite_rule() accepts an array of query vars in WordPress 4.4 

    A small change to add_rewrite_rule() in [34708] means that in the upcoming WordPress 4.4 an array can be passed as the second parameter instead of a query string.

    Previously:

    add_rewrite_rule( 'foo/([^/]+)/bar/([^/]+)/?$', 'index.php?post_type=foo&name=$matches[1]&taxonomy=bar&term=$matches[2]' );

    Now:

    add_rewrite_rule( 'foo/([^/]+)/bar/([^/]+)/?$', array(
	'post_type' => 'foo',
	'name'      => '$matches[1]',
	'taxonomy'  => 'bar',
	'term'      => '$matches[2]',
) );

    While this isn’t the biggest change in the world, it makes this parameter much easier on the eyes.

    (Note that your $matches variables need to remain in single quotes!)

     

  • Scott Taylor 6:27 pm on October 7, 2015 Permalink |
    Tags: ,   

    4.4 Dev Chat, October 7: Suggest items for today’s agenda 

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

    Time/Date: Wednesday, October 7, 2015 16:00 UTC-4:

    • Feature Plugin Merge Window CLOSES
    • Already Committed!
      • Responsive Images
      • oEmbed
    • Twenty Sixteen
    • Components
      • Customizer
      • Multisite
      • Shortcodes
      • Post By Email
    • Gardening
      • 7 weeks, 1186 commits Since 4.3
      • 207 in the past 7 days Timeline
      • We’ve closed 573 tickets on the milestone since 4.4 started
      • Always fun to look at Ticket Graph
      • Can we get below 3000 tickets (getting closer…)?
        • We have moved some .org tickets to Meta
        • We need to close 63 non-.org, non-4.4, non-4.3.2 tickets AND every new ticket that is submitted
    • 2 weeks til Beta

    Please suggest any other agenda items for today’s chat. The band’s taking requests.

     

    • Aaron Jorbin 6:40 pm on October 7, 2015 Permalink | Log in to Reply

      Since we didn’t talk about it last week due to the length of the meeting, I would like to start coming up with the plan for dev-notes posts that still need to be written this week.

    • chriscct7 8:13 pm on October 7, 2015 Permalink | Log in to Reply

      Re: Gardening:
      Last week: “We need to close 274 non-.org, non-4.4, non-4.3.2 tickets AND every new ticket that is submitted”
      This week: “We need to close 63 non-.org, non-4.4, non-4.3.2 tickets AND every new ticket that is submitted”

      At that rate, could happen really easily

  • Jeremy Felt 5:49 pm on October 7, 2015 Permalink |
    Tags:   

    Multisite Office Hours Recap (October 6, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite. The next will be 2015-10-13 2000.

    Today’s chat log
    Overall 4.4 Release Objectives

    This was our first structured office hours in a bit after a lag, but here’s to being back in action. :)

    A rough agenda posted before the meeting:

    • #28290 – We’ve added _network_option() and need to converse some more about parameter order. After some thoughts shared in Slack yesterday, it seems that having $network_id first makes sense. This would have the side effect of a seamless transition for those already using the functions in WP Multi Network. We should also add global options with a network ID of 0. This may belong in another ticket.
    • #18292 – Opinions on whether we should temporarily fix the network upgrade process by halting on a failed site rather than using wp_die() and killing the entire thing. A long term solution via #11869 is to revamp the process entirely so that we don’t have to worry about silly things like this.
    • #34145 – Does anyone have a problem with removing Lucida Grande from wp-activate.php?
    • #31240 – Patch needed, I haven’t had time to work on it yet, though I think we still have time in this cycle.
    • #32450 – More testing, iterations on the current patch needed. This one is likely tougher than WP_Network as it touches more parts of core once implemented.
    • Open floor, other things, tickets, etc…

    Conclusions:

    • #28290 – Go with a new parameter order and accept $network_id first in _network_option(). Revert the change to use _network_option() in core. Open a new ticket to talk about storing network ID 0 as a global option. Initial revert in [34912].
    • #18292 – Let’s wait on the halt behavior and stick with what we know. We should tackle #11869 as a way to resolve all of this. Ticket closed.
    • #34145 – Get rid of it. Committed in [34882].
    • #31240 – Postpone this until we’ve had a chance to really decide what we want from the Add New site screen. Not all networks are created equal in their configuration of domain and path. We need to start doing some more unit testing around what we actually do and do not support. Ticket moved to future release.
    • #32450 – We didn’t have a chance to cover this one, more testing and iterations needed. :)

    Thanks all!

     

  • John Blackbourn 3:15 pm on October 7, 2015 Permalink |
    Tags: , ,   

    single-{post_type}-{post_name}.php: New theme template in WordPress 4.4 

    A new theme template has been added to the theme hierarchy as of r34800: single-{post_type}-{post_name}.php.  This template follows the rules of is_single() and is used for a single post or custom post type. It’s most useful for targeting a specific post in a custom post type, and brings consistency to the templates available for pages and taxonomies. It comes in the hierarchy before single.php and single-{post_type}.php.

    Don’t forget, too, that in WordPress 4.3 singular.php was introduced and the hierarchy of attachment templates was fixed.

     

    • petermolnar 3:22 pm on October 7, 2015 Permalink | Log in to Reply

      wp-config should have an option that sets the max allowed depth for template searches. As in:
      1 -> single depth, eg. single.php, {taxonomy}.php
      2 -> 2 level depth, eg. single-{post_type}.php
      3 -> unlimited depth, eg. single-{post_type}-{post_name}.php

      I wouldn’t be surprised it’d result in a measurable speed gain.

      • John Blackbourn 3:36 pm on October 7, 2015 Permalink | Log in to Reply

        That would save a maximum of about five file_exists() calls, depending on whether you’re using a child theme or not. I doubt it would have any measurable impact at all. file_exists() checks are very fast when absolute file paths are used.

        Additionally, it would introduce inconsistency to the template hierarchy, and consistency is a huge benefit of the theming system in WordPress.

    • kjbenk 4:07 pm on October 7, 2015 Permalink | Log in to Reply

      This is really cool and I can see an immediate use case for this.

    • Ravinder Kumar 5:05 pm on October 7, 2015 Permalink | Log in to Reply

      Nice addition to WordPress.
      Thanks.

    • Dinesh Kesarwani 5:28 am on October 8, 2015 Permalink | Log in to Reply

      Yes! nice addition. I also suggested similar template before some time ago. But, it was rejected.
      https://core.trac.wordpress.org/ticket/29700

    • BenRacicot 12:10 am on October 10, 2015 Permalink | Log in to Reply

      Golf clap

  • Gary Pendergast 12:38 pm on October 7, 2015 Permalink |
    Tags: ,   

    🎉 One more committer for 4.4! 

    Please join me in welcoming a new guest committer for WordPress 4.4 — Ryan McCue (@rmccue)!

    Ryan has been contributing to the WordPress world for many years, through various patches, as well as being one of the maintainers of the SimplePie RSS library that WordPress uses.

    More recently, he started the WordPress REST API feature plugin, and has been leading the development of it for the past two years, nine months and five days (not that anyone is counting!). As the REST API comes closer to being ready for merge, Ryan having commit access is a natural progression: he can bring his expertise in the REST API directly across to WordPress Core.

    Congratulations, Ryan! 🎆💯⭐️⭐️⭐️⭐️⭐️

     

  • Simon Wheatley 10:15 am on October 6, 2015 Permalink |
    Tags:   

    We’re looking for assistance in the multilingual project, which is investigating ways to enhance the multilingual support provided by WordPress core. The discussion is over here.

     

    • Paal Joachim Romdahl 1:01 am on October 7, 2015 Permalink | Log in to Reply

      Thanks for posting here about the discussion Simon! There are a lot of people that want to help out from seeing the replies in the discussion. It just needs a clear direction as to how people can help with the project.
      Creating a clear direction and on goals then people can set out to work on them.

← 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
Skip to toolbar