Ready to get started?Download WordPress

Make WordPress.org

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Scott Reilly 2:33 am on March 4, 2015 Permalink |

    New Plugin Directory Theme 

    Late last week saw the launch of the reimplemented Theme Directory, complete with a new theme. This week brings with it another improvement to WordPress.org: a new theme for the Plugin Directory.

    Its new appearance should look very familiar; the goal with the theme refresh was to mirror the look and experience of the wp-admin plugin browser.

    The site didn’t just get a facelift; the update includes a few new features not previously available in the directory:

    • Introduction of a “Favorites” section:
      If you are logged in and have favorited plugins, this new section gives you direct access to the list of those plugins. Previously, you could only see a simple listing of them on your profile page.
    • Introduction of a “Beta Testing” section:
      Previously only available in the wp-admin plugin browser on sites running a development copy of WordPress, this new section lists plugins proposed for inclusion in a future version of WordPress.
    • Ability to search for plugins by author:
      In the same fashion as in the wp-admin plugin browser, you can now search for plugins by author (by username).
    • Listings now display a count of active installs instead of downloads:
      Individual plugin pages have just (days ago) seen a switch from displaying the number of downloads to the number of active installs for the plugin. This information is now also shown on all plugin listings, such as search results.

    The individual plugin pages themselves were not changed as the wp-admin plugin browser already largely mirrors their UI. Also note that the effort didn’t include a rewrite or significant change in overall functionality other than what was outlined above. The backend reimplementation of the Plugin Directory will be undertaken at a later time.

    As always, it you encounter a problem or have a suggestion, please submit them at meta.trac using the Plugin Directory component. Be sure to peruse the existing Plugin Directory tickets to avoid submitting a duplicate.

  • Andrew Nacin 2:46 am on March 1, 2015 Permalink |
    Tags: stats   

    Major update to our version stats for PHP, MySQL, and WordPress 

    Today, the stats reflected on wordpress.org/about/stats changed, dramatically. I’d like to explain why.

    First, so they’re documented here, the numbers:

    WordPress versions

    Version Before After
    3.0 16.06% 2.27% −13.80%
    3.1 1.21% 1.25% +0.04%
    3.2 1.38% 1.35% −0.03%
    3.3 4.11% 2.96% −1.15%
    3.4 4.47% 3.24% −1.24%
    3.5 14.60% 7.21% −7.38%
    3.6 6.95% 3.72% −3.23%
    3.7 4.34% 2.51% −1.83%
    3.8 11.66% 8.61% −3.05%
    3.9 13.20% 13.52% +0.31%
    4.0 12.53% 17.40% +4.87%
    4.1 9.48% 35.95% +26.47%

    PHP versions

    Version Before After
    5.2 31.76% 16.60% −15.15%
    5.3 38.56% 38.45% −0.11%
    5.4 25.01% 37.18% +12.17%
    5.5 4.29% 6.52% +2.22%
    5.6 0.39% 1.26% +0.87%

    MySQL versions

    Version Before After
    5.0 17.84% 9.31% −8.53%
    5.1 25.24% 23.80% −1.45%
    5.5 51.87% 59.35% +7.47%
    5.6 4.99% 6.84% +1.85%
    MariaDB 10.0 0.00% 0.68% +0.68%

    What happened?

    Dion Hulse (@dd32) has been working hard to modernize our stats collection and processing. This stats page, which is updated daily, has as of today been switched to this new data.

    Thousands of new WordPress sites come online every day. Some others, though, stop pinging over time. The new data only reflects sites that have pinged api.wordpress.org within the last few months. There were also plenty of other inconsistencies in the data that we’ve been able to resolve, which has resulted in numbers we feel are more consistent and accurate.

    There are three specific trends to note:

    • WordPress 4.1: More than 1/3 of sites are running the latest version, not less than 10% as previously determined. By excluding sites that are no longer online, you can imagine why this percentage would go up.
    • WordPress 3.0 finally looks more in line with what would be expected. This data has been an anomaly for years. (We’ve suggested before that this data was likely invalid — a byproduct of some spammers.)
    • PHP 5.2 is down to 16.6% of sites. We’re in far better shape for 5.2 than previously thought, though 5.3 hasn’t changed.

    As Matt shared at WordCamp San Francisco in October, we’re engaging individual hosting companies to move sites to the latest versions of WordPress, with a secondary focus moving sites to PHP 5.4+. I also expanded on our reasoning and efforts during my php[world] keynote in November. One-sixth of all sites running PHP 5.2 is still many millions of sites. If we move the PHP minimum version too early, we risk stranding millions of installs on older versions of WordPress.

    So, I wish to note that this does not change our calculations for keeping PHP 5.2 as the minimum for WordPress core — we had these numbers available to us when preparing our 2015 plans.

    There are a lot of great things in this new data set. Hope you find it interesting!

    Updated March 2: I shared some more info with WP Tavern here. In particular, I answered Is there anyway we can see PHP/MySQL versions broken down by what WordPress version they are running on?

    We’re still working on ensuring the numbers are stable. They’re pretty predictable: older WP versions have more people on older PHP and MySQL versions. Newer WP versions have less.

    PHP 5.2 is at about 16% for all installs right now. It’s at about 10% for installs running WordPress 4.1, but because 4.1 is such a large part of the pie (36%), it’s the WP version with the most PHP 5.2 installs.

    Our goals remain the same: priority 1 is to update old WordPress installs, priority 2 is to update old PHP and MySQL. Only once the numbers drastically move as a result of our efforts would any minimum requirement change. We cannot risk abandoning so many users on older WordPress and PHP versions.

    • jonradio 2:53 am on March 1, 2015 Permalink | Log in to Reply

      Although this may seem counter-intuitive, I think the charts would be far easier to comprehend upon first glance if the Versions were presented Descending, rather than Ascending. Especially with WordPress Versions, where you have to figure out to click the “page 2″ button to see the two more recent (and popular) versions.

    • Michael Beckwith 4:12 am on March 1, 2015 Permalink | Log in to Reply

      Awesome news all around.

    • Jon (Kenshino) 6:01 am on March 1, 2015 Permalink | Log in to Reply

      It’s pretty good news! Hope the stats will eventually help us shift away from PHP 5.2

    • Josh Pollock 7:56 am on March 1, 2015 Permalink | Log in to Reply

      Thanks for the update. Is there anyway we can see PHP/MySQL versions broken down by what WordPress version they are running on?

      It would be interesting to see what percentage of users running an EOLed version of PHP are choosing to stay on old WordPress versions of their own accord/ lack of action.

  • Samuel Wood (Otto) 2:26 am on February 27, 2015 Permalink |

    After a bit of a longer two-day rollout than planned, the new theme directory is now live and functional.

    If you find bugs (and we’ve already found a few), then please report them on the meta.trac using the Theme Directory component to flag them up. But please, do make sure somebody else hasn’t beaten you to the ticket. Here’s the list of current tickets for the theme directory: Meta Trac

  • Konstantin Obenland 7:19 pm on February 24, 2015 Permalink |
    Tags: ,   

    Theme Directory Launch Checklist 

    Tomorrow we’re going live with the new Directory! We’ll start going through the checklist February 25th 2015 1700 UTC.

    Disable uploads on bbpress themes.
    Replace the uploader page with an “uploads temporarily offline” message.

    Disable themes.trac sync process.

    • Announce launch in WPTRT meeting.
    • Commit an early return to sync-theme-review-results.php.
    • Inform Admins directly: No setting themes live between February 25th 2015 1600 UTC and the new directory is live.
    • Channel notification in #themereview.

    Migrate themes to WP.
    Run migration script in /bin/themes/

    Switch over Directory to not use API.

    Test themesnew API.

    • Switch to use themesnew.php on sandbox.
    • Test /wp-admin/theme-install.php locally.

    Test themesnew downloads.

    • Switch to use themesnew.php on sandbox.
    • Test downloads locally and on /themesnew.

    Up until here, no real damage is done, marks the last chance to postpone the launch.

    Switch over downloads and API scripts.
    mv index.php old-api.php
    mv themesnew.php index.php

    Switch over URLs and redirect.

    • Commit /themes removal.
    • Notify @seanosh about making the switch.
    • Commit mu-plugins commercial change.
    • Test the hell out of /themes.

    Switch over review sync script.
    mv sync-theme-review-results.php sync-theme-review-results-old.php
    mv sync-theme-review-results-themesnew.php sync-theme-review-results.php

    Enable theme uploads in directory plugin.
    Remove custom message and uncomment upload handler.

    • Andrew Nacin 9:19 pm on February 24, 2015 Permalink | Log in to Reply

      Are there actually redirects that need to occur? Are nginx rules already written for this? As far as I know, we should just need to remove bbPress-specific rules and let /themes/ fall through to WordPress.

      This is actually a bit complicated. The order of operations should be to change the DB to reflect /themes not /themesnew, and then remove the rules. But, that’s not quite enough. We also need to remove the /themes bbPress external. This external will *not* be fully removed upon deploy — because it has externals inside of it, it will leave behind directories in the form of e.g. /themes/bb-includes/backpress/includes/pomo.

      So, all of this needs to happen at basically the same time:

      • /themes needs to be deleted from dotorg.svn, and deployed.
      • The remnants of /themes/* needs to be removed manually from production servers.
      • nginx needs to be reloaded (with rules removed).

      I don’t think anyone has tested these steps. :-) @seanosh should be able to remove the /themes-specific nginx rules on your sandbox for you, then you can test the rest. The wporg-plugins-themes nginx conf file would also be a good thing to review as it might illustrate missing features from the new themes directory as well as what existing URLs should be supported, including /rss, /profile, /browse, etc. You can view these files from your sandbox.

      We should probably create a script to do this in one go, as in, you commit to dotorg.svn and do not deploy, then @seanosh runs this as a global command:

      svn up public_html # remove /themes, essentially deploying
      rm -r public_html/themes/ # actually remove /themes
      /etc/init.d/nginx reload # let it fall through to WordPress

      • Konstantin Obenland 11:17 pm on February 24, 2015 Permalink | Log in to Reply

        We also need to remove the /themes bbPress external.

        As far as I can tell, there are only two externals, bbpress and backpress/includes, yes?

    • seanosh 11:23 pm on February 24, 2015 Permalink | Log in to Reply

      I’d prefer if the deploy itself went through the deploy script instead of calling “svn up” everywhere. If need be, we can execute commands immediately after the deploy has taken place. Or is that not possible, @nacin?

  • Konstantin Obenland 12:22 am on February 24, 2015 Permalink |

    Theme Directory Update 2/23 

    Last week I fixed most of the fixable tickets for the Theme Directory, switched to using WP_Query instead of the API for server-side rendering of themes, updated the WordPress-based Themes API with changes from the bbpress-based one, and finished the import script for the new directory. @otto42 committed the new reviews code today, so we should be able to get those integrated today or tomorrow.

    Which means that we’re going to launch on Wednesday or Thursday!

    There is still a lot more work to be done, but everything that’s remaining can be added, changed, or improved with the new directory active. Most importantly we want to make it available to language sites, so that we have an internationalized theme directory, and there will be more to be done around that.

  • Konstantin Obenland 1:57 am on February 13, 2015 Permalink |

    Theme Directory Update 2/12 

    The two major parts of my week were fixing bug reports that came in after my post on make/themes, and getting started with adopting @melchoyce‘s modal design (Modal == modal + single). With the exception of reviews and support, I tried to stick as close as possible to the mockup. While I’m obviously not done yet, a first pass however is live (including some mobile styles).

    @otto42 made progress on the rating integration, working on a solution that lets us use existing ratings/review with limited migration efforts. He projected to be done with that around Wednesday next week.

    Next week I’ll be focussing on switching the server-side rendering of themes from using the API to using WP_Query directly. Towards the end of the week I’d also like to have ratings/reviews integrated and my work on the modal finished.

  • Konstantin Obenland 7:47 pm on February 6, 2015 Permalink |
    Tags: ,   

    Theme Directory Update 2/5 

    A very busy week with lots of improvements! These are some previously mentioned TODOs that I was able to scratch off the list:

    • Rewrote the Theme API’s update endpoint to work with WordPress.
    • Made synchronizing theme review results a cron job.
    • Made sure uploaded theme files are always deleted, no matter the outcome.
    • Added navigational links to Upload and Commercial pages (r1211).

    Additionally, I removed the Admin approval workflow form the Directory plugin, since this is handled entirely on Themes Trac.

    I also opened the floor to bug reports from the community. After doing that at last week’s update here with limited success, I added another call for volunteers on make/themes which resulted in 15 tickets so far.

    Next week I’ll be working though the tickets, as well as @melchoyce‘s Directory mockups, and @otto42 is still working on theme reviews/ratings.

  • Konstantin Obenland 9:41 pm on January 30, 2015 Permalink |

    Theme Directory Update 1/30 

    It’s been two weeks since my last update on the theme directory. I had a chance to get my downloader and Themes API code reviewed by @dd32, but between attending an Automattic meetup, a WordCamp, and taking a couple of days off, it was hard to continue the pace of the weeks prior.

    • @otto42 started working on migrating theme reviews from bbpress to WordPress.
    • Chatted with @samuelsidler and @otto42 about how we want to make the switch from old to new.
    • I tracked down a bug with jumping modal contents on small screens.
    • Added smooth scrolling for iOS devices in the theme modal.
    • Spent a day trying to figure out a way how I can prevent background scrolling on iOS when the theme modal is open.

    If anyone has a fix for the last mentioned bug, please let me know. My CSS and JS foo is failing me on this one, I have not idea how to fix it.

    I think the directory (with the exception of the theme uploader) is to a point where it makes sense to open it up to bug reports. If you find anything wonky and out of the ordinary, please feel free to file a ticket over at meta.trac, and assign it to the Theme Directory component. Thanks so much for your help!

  • Mel Choyce 6:04 pm on January 23, 2015 Permalink |  

    Theme Directory Mockups 

    This week I’ve been working with @obenland to mock up improvements to the new theme directory, focusing primarily on the single theme view.

    (Note: you’ll want to zoom out to 50%)

    Layout-wise, the mockups are pretty similar to this modal — sans-tabs (currently) — but use the overall style of the existing theme browser modal.

    I have to admit that while it’s really slick and nice to quickly browse through, I do have some concerns about displaying the single theme view inside of a modal.

    First of all, I’m worried that linking directly to a modal can be disorienting for users. Often when you load a new page and a modal pops up, your first impulse is to close it because it’s likely some sort of annoying notification or newsletter signup form.

    Secondly, since themes have additional views (most importantly reviews and the support forums), having that kind of forwards/backwards navigation breaks the modal paradigm — modals are generally (though we do break this in core) one-screen views. Additionally, unless we *do* add tabs, it makes quickly navigating to reviews and support more difficult, since now instead of being able to quickly flip over to a new tab, you need to scroll down and locate the button that brings you into the appropriate view. As a theme designer, I check these two tabs pretty frequently to check in on my themes. As a theme user, I often use those tabs when I’m browsing around for good themes to use or play with.

    Lastly, I’m not sure if there’s a good way to open a whole bunch of themes at once to compare, since trying to open up the single theme view in a new tab opens it up in the current tab instead. This might be a technical issue we can overcome, I’m just not knowledgeable enough to know for sure. :)

    If we decided against putting the single theme view in the modal, I think we could still make some good functionality and style improvements to the existing theme pages. The ability to flip back and forth between themes in the repo is particularly helpful. (Though maybe doesn’t work as well as a concept when you’re not coming in from a filter such as popular or new, but instead are being linked directly to the theme itself — something for us to think about.) I think this is worth discussing either way and would be interested to hear what others think.

    I also took some time to check out the theme list and have some thoughts there. Here’s a quick pass at an updated theme card design:


    Instead of having “download” appear when you hover over the theme, I’ve replaced it with a persistent star rating. This is more consistent with comparable services, in which the act of downloading or purchasing is usually obscured behind one click. Since the theme repo is pretty fast, I don’t think this additional click causes much harm, especially since users will often want to preview the theme before downloading.

    Additionally, I’d personally recommend against infinite scroll. In the case of theme searching, I think infinite scroll has the potential to hinder someone’s ability to find and compare themes. My thoughts on the topic are summed up pretty well by this NNG article:

    Endless scrolling is not recommended for goal-oriented finding tasks, such as those requiring people to locate specific content or compare options. …Finding products by feature might be difficult to accomplish quickly if all of the products are presented linearly on a never-ending page, without sorting or other filtering or navigation techniques to help isolate the intended item. …In addition, locating a previously found item on an extremely long page is inefficient, especially if that item is placed many scrolling segments down. It’s much easier for people to remember that the item is on page 3 than it is to gauge where the item is positioned on an extremely long page. [Source]

    I have some additional thoughts on making tweaks to the available filters in the theme directory, but I’ll save those for another time. :)

    • Mickey Kay 6:33 pm on January 23, 2015 Permalink | Log in to Reply

      Looking good! Very clean and nice to see more consistency between the theme and plugin experiences.

      As you mention, I think tabs (or some other solution) are necessary to mitigate the sheer quantity of info that is presented, and the crazy amount of vertical scrolling a user would be required to do just to navigate to the support forum, for example.

      As for the arrows in the top left – are they meant to switch between said tabs, or to the next theme? They look super-clean, I just don’t know what they’re for and it makes me wonder if that they’re to move to the next/previous theme. Thoughts?

      Awesome work, looks great!

      • Mel Choyce 8:46 pm on January 23, 2015 Permalink | Log in to Reply

        As for the arrows in the top left – are they meant to switch between said tabs, or to the next theme? They look super-clean, I just don’t know what they’re for and it makes me wonder if that they’re to move to the next/previous theme. Thoughts?

        They navigate between themes, which is how the current theme browser works in wp-admin: https://cloudup.com/cR7sJEZQlGO

    • Tammie 6:42 pm on January 23, 2015 Permalink | Log in to Reply

      Really awesome work. I really like the layout improvements. I think I have a few concerns with the modal but I think we’re on the right track compared to where we are now. I actually think avoiding tabs would be good, I never like them as a technique myself.

      I do wonder if we could call out the support button a little more. I’m worried it’s a tiny bit hiding due to the treatment and location.

      I’m a little less keen on removing the download button. I get a lot of places use that, but to me that doesn’t mean it’s the best way in this case. I think ratings currently aren’t as used as we’d like to think they are. I also don’t think they are as important in that place as the download. I’m in the against camp for hiding any common action even one click away.

      Apart from a slight preference against something, I would like to say how happy I am to see the improvements going on. Great work everyone involved.

    • Ipstenu (Mika Epstein) 6:56 pm on January 23, 2015 Permalink | Log in to Reply

      This makes the use-flow: Hover -> Click More Info -> Download ? Is that right?

      Couldn’t it be two buttons? More Info and Download?

      • Mel Choyce 10:32 pm on January 23, 2015 Permalink | Log in to Reply

        Two buttons can get tight, and honestly a little weird since the hover-button is styled totally differently.

        (I’m not a huge fan of the hover button anyway, since it performs awkwardly on mobile.)

    • Michael Arestad 6:57 pm on January 23, 2015 Permalink | Log in to Reply

      Already a huge improvement!

      ## On infinite scroll:
      I looooove infinite scroll for searching through themes/photos/whatever. I do think that if we use infinite scroll, it needs to track progress in the URL so if I navigate to and from I don’t lose my place.

      ## On modal:
      I have pretty big concerns about it being a modal. I mirror your above concerns plus a concern about scrolling.

      Scrolling behavior on modals is bizarre. If you scroll to the bottom, the page in the background starts scrolling. Changing this behavior is hacky.

      I also definitely prefer the (open a bunch in tabs to compare) approach when looking for themes. I am not alone in this.

      I strongly believe each theme view should be its own page. It’s not a trivial thing, but I believe it’s necessary.

      ## On tabs:
      I would sure like tabs. It makes sub navigation a bit simpler to grasp and much easier to find on mobile. That said, what Mel mocked up seems pleasant enough to use if not a bit lengthy to scroll through.

    • Samuel Sidler 8:37 pm on January 23, 2015 Permalink | Log in to Reply

      I’d prefer no modal, for the reasons you listed.

      Can you clean up / improve the new review and new forum forms while you’re there? They feel (and have always felt) just tacked on to the end, without even a header.

      • Mel Choyce 9:05 pm on January 23, 2015 Permalink | Log in to Reply

        I cleaned them up a little in my mockups. Aside from adding a header, is there anything else specifically you’d like to see addressed?

        • Samuel Sidler 9:26 pm on January 23, 2015 Permalink | Log in to Reply

          How much nitpicking do you want? :)

          Spacing between the form fields and their titles is large, in a bad way. The text in the HTML buttons are various sizes, instead of being consistent. (Maybe just a visual anomaly?) In general, it just feels cluttered. Could we move some things to inside the textarea? Could we redo the tags box and hint text to be a bit more integrated? The “Post” button is way off and to the right, which makes logical sense, but feels weird and disjointed. Maybe it’d be better in the same column as the inputs?

          I’m sure there are other things that can be improved (I am not a designer), but in general it still feels both spacious (in a bad way) and cluttered, if that makes sense.

          • Mel Choyce 9:50 pm on January 23, 2015 Permalink | Log in to Reply

            All great feedback. I’m not sure what can be done from a technical standpoint, but I could certainly redesign it to work a lot better. :) Thanks.

    • @mercime 8:58 pm on January 23, 2015 Permalink | Log in to Reply

      Very nice!

      Re modals: I agree with your reservations as well. In current single theme pages, I always right click > open to new tab on the “Preview” button to see the theme in better light.

      Re tabs with no modals: +1

      Re comparing themes: Beyond how the theme looks, I compare the tags https://wordpress.org/themes/tag-filter/ under the Theme descriptions i.e., to check which theme is e.g. buddypress, accessible-ready, responsive-layout, and translation-ready

      • Mel Choyce 9:51 pm on January 23, 2015 Permalink | Log in to Reply

        Can you walk me through how you use the tag filter a little more? Do you use the tags to search, or do you scan through the tag list on themes you’re interested in, or something else? I’m really interested in reworking the filtering process, so your input would be super valuable. :)

        • @mercime 11:44 pm on January 23, 2015 Permalink | Log in to Reply

          I think the tags filter page is a hidden gem.

          Prior to joining the WP theme review team some years back, I only clicked on one tag link under the description of the theme I liked e.g. three-columns or one-column, to find similar themes which I could learn from or customize for projects.

          Now that I might submit a theme to the repo, aside from reading the docs relating to the features I want to add, I use the tags filter page to look for accessibility-ready and translation-ready themes, to double-check whether I’m doing it right. I have checked out Twenty Fifteen first because the accessibility team went over the theme pretty well :)

          Thank you for taking on the tags filtering process. I think that while a theme may look good or it’s one the featured themes, if it’s not accessible-ready and translation-ready, then it’s not useful for many who need those features. I can imagine that it would a bummer if someone installed a good-looking theme and found out it’s not translation-ready, then he/she would have to go through the search process again for another theme hoping it’s is.

    • Mel Choyce 10:43 pm on January 24, 2015 Permalink | Log in to Reply

      Tried a version as a page, instead of a modal:

      • Mel Choyce 5:00 pm on January 25, 2015 Permalink | Log in to Reply

        Updated with more mockups.

      • Samuel Sidler 6:15 pm on January 28, 2015 Permalink | Log in to Reply

        I like the form. :D

        I’m not sure how I feel about the tabs, however. The concept is fine, but it seems weird that they’re above the theme name. I also think it’s weird to use the same style of tabs as the regular directory, simply because a user might not notice that the tabs have changed. I hate to recommend “sub tabs” or something along those lines… but we need some way to distinguish the two things. Moving the theme name on top might help a lot.

      • Tom 10:30 pm on March 1, 2015 Permalink | Log in to Reply

        Love these! Really hope to see this in the near future! =)

  • Samuel Sidler 8:51 pm on January 22, 2015 Permalink |

    Meta Team in 2014 

    We’re a few weeks into 2015, but I wanted to take a moment to look back at the meta team in 2014.

    Over the course of 2014, we worked on a number of projects:

    • Trac improvements: A number of improvements to both trac and make/core landed, which make following tickets much easier.
    • Devhub: Working with the docs team, we launched developer.wordpress.org.
    • WordPress Meta Environment: Making it easy to contribute to the meta team was a priority and the WordPress Meta Environment shipped with just that in mind.
    • Open Source: A number of sites were open sourced over the year, including the Rosetta theme, WordPress.tv plugins and theme, and more. (You can find all of our open sourced code here.) Additionally, developer.wordpress.org and apps.wordpress.org launched open source from the start.
    • WordCamp.org: Lots of iteration on current features, many improvements around automation, and the WordCamp Payments plugin launched.
    • SSL: WordPress.org now forces SSL across all of our sites.
    • WordPress.org Profiles: Profiles got a design refresh, including badges for contributing to Make teams, and we’re now automatically pulling in more activity from Trac, WordPress.org posts and comments,WordCamp.org speakers and organizers, and theme and plugin repositories.
    • Slack: Setup Slack and wrote many custom plugins and integrations with WordPress.org.

    Lots of other tickets were fixed over the course of the year and work on a new theme directory began (open source from the start!).

    As always, if you’re interested in getting involved with the meta team, find us on Slack in #meta or dive right into the meta trac, filing or fixing issues.

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