Make WordPress Core

Tagged: dev chat Toggle Comment Threads | Keyboard Shortcuts

  • Ryan Boren 7:36 pm on November 3, 2014 Permalink
    Tags: dev chat,   

    Dev Chat Summary, October 29th 



    • Beta 1
    • Feature plugin merge window



    Links Mentioned


    Focus 2

    I think Focus v2 is ready to be turned into a core patch and be merged in. Over the last few days we have been working on making it less “twitchy” and narrowing the circumstances under which focus mode is triggered, so we are sure the user is focused on composition when it happens, instead of transiently moving through the editor or absentmindedly clicking.

    Session Manager

    I think the session manager is ready with some minor UI tweaks (simplifications, really) and use of the geo IP API.

    Yes the session management UI is in a similar position

    I’m hoping to get that in patch form and ready to merge before the weekend

    Select 2

    @helen @ericlewis Do you have time to look into the touch problems before Friday? I am very tempted to punt this if we can’t get this merged by early next week, and highly visible touch support problems will prevent it being merged

    I think we can circle back Friday during the bug scrub and make a decision

    i am having bad gut feelings myself.

    I think the work @helen and @ericlewis have done is great, but there are too many unknowns (edited)

    I side with withholding it for just one release. The benefits of waiting (potentially better codebase, more room to test accessibility, etc) far outweigh the benefits of including now (almost certain rewrites in the very near future, for one)

    I’d say cut it. It’s a minor improvement, not a make-or-break feature.

    And with so many other things about to come in, it’s pulling resources in different directions a bit.

    “just one release” – i’ve been tinkering with this since february.

    Fair point, very fair point

    but i am not worried about cutting it for 4.1. it is frustrating, but not worrisome.

    Ok unless the situation with touch support changes in the next few days, we should consider this punted. I have also just been informed that there is a licensing issue which I was unaware of

    Twenty Fifteen

    Twenty Fifteen is steaming ahead

    @obenland @lancewillett @iamtakashi Anything of particular note you’d like to mention?

    It’s looking good

    @celloexpressions just did a great review

    and doubled our ticket numbers :simple_smile:

    Well, that was just as much as I could do in an hour :simple_smile: but it’s pretty good overall, no huge issues. I’m still thinking about the color schemes implementation

    Not much to report on beyond the update here https://make.wordpress.org/core/2014/10/28/twenty-fifteen-chat-summary-october-28/
    Make WordPress Core
    Twenty Fifteen Chat Summary October 28
    Notes for our weekly chat about Twenty Fifteen: Twenty Fifteen continues to feel pretty robust — thanks to everyone who’s been testing the theme, reporting bugs, and contributing to patches with co…

    We had some new template tags land yesterday, I started a ticket for the new `title-tag` support and will publish a post on that later today

    Also working on adding support for the navigational template tags

    Plugin and Theme Install

    Lastly from me, the proposed updates to the plugin and theme install and update process haven’t had much traction lately, as I’ve already noted, due to @nacin @melchoyce @pento @avryl being busy on other things, but we have mockups and that group are going to plow through it starting this afternoon

    So that is still scheduled for 4.1

    Feature Plugins

    Feature plugins need to be in the beta list. Only one of those discussed here is listed, Focus. /wp-admin/plugin-install.php?tab=beta

    @boren: Roger.

    Does that page have a .org analog?


  • Helen Hou-Sandi 9:44 pm on June 1, 2014 Permalink
    Tags: , dev chat   

    Summary of 5/28 dev chat (IRC log):

    • @nacin and @tellyworth have been working on the .org API side for i18n and plugins page improvements respectively and should be ready for work on the core side soon. Be on the lookout for tickets and discussions.
    • @ericlewis has been working through the Media component in Trac and will be holding weekly scrub in #wordpress-dev alongside media grid chats, Fridays at 17:00 UTC.
    • @wonderboymusic has been evaluating various oEmbed endpoints as we add and remove them. Some services need some more evaluation: #28379.
    • Embed representations in wpview need an iframe sandboxing solution investigated to avoid script conflicts inside TinyMCE and the admin: #28249
    • The JSON REST API came a long way in the past week, especially on the documentation front, and is being placed onto the roadmap for the 4.1 release. From @nacin:

    1.0 is a great step in the right direction; let’s push it hard; let’s put it squarely, loudly, and officially on the 4.1 roadmap (I’m comfortable doing that); let’s get a lot of core contributors focusing on it for the final mile, especially when it comes to internals

    let’s get a lot of people to build things on it, including inside automattic, mobile apps, even wordpress.org stuff; let’s branch off 1.0 so we can decide paint and carpet colors on the master branch

    •  And finally, several people were added to various Trac components as component maintainers. You can be added at any time, or get on the road to becoming one by signing up for granular notifications on the components page.
    • Eric Andrew Lewis 10:35 pm on June 1, 2014 Permalink | Log in to Reply

      I think component maintainer gravatars should be surfaced to the components page, so we can see the core community at a glance rather than clickering into each.

  • Helen Hou-Sandi 7:16 pm on May 28, 2014 Permalink
    Tags: , , dev chat   

    Summary for 5/21, Agenda for 5/28 

    Summary of 5/21 dev chat (IRC log):


    • Posts like the i18n goals one serve as a great model for anybody who has ideas for a feature or component roadmap, whether that’s within one cycle or longer term: a list of concrete goals that can be divided up into specific tasks.
    • The make/* blogs should be used as much as possible for discussions and progress updates. Teams that have been using separate P2s but should consider using the make.wordpress.org instead for wider reach and more active participation from the community.
    • Keep in mind that plugins are supposed to encourage rapid and possibly wild experimentation – please do not discourage that.
    • Think of meetings as blocked out times where you can more reliably get a group together and get unstuck as needed, but we should take advantage of async (Trac, P2) and adhoc (IRC outside of meeting) discussion as much as possible.

    Team Updates

    • i18n goals for 4.0 have been posted, @nacin is seeking people to help with a lot of it. @yoavf, @kovshenin, @iandunn, @coffee2code, and @otto42 have done or will do some of the i18n tasks.
    • JSON REST API was given another week to collate a detailed compare-and-contrast with the other available APIs, including the JSON API plugin and Jetpack/.com’s API, and proven client implementations.
    • Media Grid has a narrowed scope for 4.0 inclusion: something more visually driven than the standard list table, much like theme browser brought to themes and is being investigated for plugins in 4.0. Will also fix some long-standing issues that were brought in with 3.5.
    • Editor improvement ideas: @markjaquith and @avryl have put together a proof-of-concept plugin that we should smooth out and make a decision on.

    Agenda for 5/28:

    • Make final decision on JSON REST API.
    • One sentence updates from various groups – i18n, media grid, plugins, oEmbed, etc. Come prepared.

    Please propose any other agenda items in the comments below.

  • John Blackbourn 8:22 pm on May 13, 2014 Permalink
    Tags: , dev chat,   

    Agenda for tomorrow’s Multisite chat 

    We’re having a dev chat about Multisite in #wordpress-dev tomorrow (May 14, 2014 18:00 UTC). I’d like to split the chat into two main areas:

    1. Open vs. closed networks
    2. Everything else

    The concept of an open network where users can create their own sites was the popular impetus for WordPress MU, but is decidedly not the primary use case for multisite anymore. Most operate closed, trusted networks, where site signups are disabled (and often user signups are disabled as well).

    Back in October, Andrew Nacin published a collection of thoughts on potential changes to Multisite, one of which was the idea of open vs. closed networks. I’d like to discuss this concept and whether now is the right time to tackle it. Here are some relevant paragraphs from that post:

    When a network is not designed for “open registration”, there are a number of undue burdens that should be lifted for administrators. Uploadable file types are severely restricted, and the amount they can upload is capped. They cannot activate installed plugins, though there is an option for this. They cannot add users to their sites without knowing their email address (ostensibly to prevent spam), and the user must still go through a “confirmation” process. New sites must go through an “activation” process. They cannot create new users.

    I don’t think WordPress needs to decide that the multisite feature is only geared for closed networks. Rather, a single option — set on install, and controllable via network settings — can control this entire paradigm very effectively.

    Essentially, I am proposing we trust single-site administrators in a closed network to not be spammy, and to be given wide-ranging control of their own sites; but that we do not extend that trust to important areas of security.

    So, let’s discuss whether now is the time to introduce the concept of open vs. closed networks, what form it takes, and to which functionality it extends.

    • What differences should we see between an open network and a closed network?
      • Open user registration
      • Open site registration
      • Capabilities for regular Administrators (plugins, themes, users)
      • Email notifications (amount of, and wording in)
      • User listing and user editing UI differences
      • Site listing and site editing UI differences
      • Network admin dashboard UI differences
    • What form should the open vs. closed network option take? A UI option when installing multisite? Changeable after the fact or set in stone like subdir/subdomain option?
    • What changes need to be considered for existing multisite installs?

    Secondly, let’s discuss all other multisite improvements that we would like to see. Several may well be related to the idea of open vs. closed networks, and that’s ok. Here’s a list to get us started:

    • Reign Rein in notification emails when adding sites, users
    • Improve user searching – #27304
    • Improve user management
    • Better explanations for what archive/spam/delete does to a site
    • Merge in the Hyper Admins plugin
    • Merge in the User Management Tools plugin

    If anyone has particular issues they’d like addressed (bonus points for existing tickets on Trac), leave a comment and we’ll see what we can cover.

    Two other items worth mentioning are:

    • Domain mapping
    • SSL improvements

    I don’t think we’re yet at the stage where we could consider implementing domain mapping in core. It has a prerequisite of removing the subdirectory vs. subdomain paradigm, and we’re not near approaching that (unless someone wants to step up).

    Regarding SSL improvements, I’m planning on arranging a separate working group to tackle a whole raft of SSL improvements in core that aren’t just related to multisite. I’ll be publishing a separate post in the next couple of days to get us started.

    • Robert Dall 8:47 pm on May 13, 2014 Permalink | Log in to Reply

      I couldn’t agree more on adding the Hyper Admins and the User Management Tools into core. That makes a lot of sense.

      I could also see real benefit to the Domain Mapping and SSL Improvements.

      Here is why:

      I am actually in the middle of a project where I am using a multi-site for company that has 5 different websites that offer 5 different areas of the products and or services offered.

      So while we could use 5 different installs of WordPress were using the power of multisite to keep the admin to a minimum.

      Domain Mapping will be of great use to this and many other types of multisite usage.

      SSL and wildcard SSL is someone confusing to the uninitiated any improvement to WordPress multisite and SSL would be of great benefit.

    • Sallie Goetsch 8:49 pm on May 13, 2014 Permalink | Log in to Reply

      That’s “rein in.”

      However, I’m really glad to see Multisite getting some attention. I’m not qualified to help develop it, but I’ve noticed the lack of developments in the last several WordPress versions. What IS the status of domain mapping? Do you still need a plugin for it or not?

      Are there any plans to institute network-wide widget areas? Right now network-wide menus are possible with a plugin, but there’s no way to add network-wide widget areas at all.

      How about default theme settings that the network admin can control? I’ve got a project coming up where we’re actually leaning toward NOT using Multisite in part because the network admins would have to go in and configure theme options for each sub-site separately (even though they will be the SAME for each site, with the only difference being a different logo image). We could hack the theme up so it doesn’t have any other options, but that’s not really a good alternative, either.

      I realize these things are too much to ask for 4.0, but wanted to at least add them to the wishlist.


      • John Blackbourn 3:07 pm on May 14, 2014 Permalink | Log in to Reply

        What IS the status of domain mapping? Do you still need a plugin for it or not?

        Yep, there’s no support in core for domain mapping currently.

        Are there any plans to institute network-wide widget areas? How about default theme settings that the network admin can control?

        Network-wide widgets, menus, and settings are an interesting idea and certainly something I’ve seen requested before. The complication comes when those widgets, menus, and settings need to be present on the main site, which may not be desirable. I’ll add it to the agenda!

    • Rouven Hurling 9:27 pm on May 13, 2014 Permalink | Log in to Reply

      i would love to see #15800 fixed, so that network wide plugins can add a tab the site edit where there can display their options (or in my case, data and options for that client and so on)

    • Knut Sparhell 1:29 pm on May 14, 2014 Permalink | Log in to Reply

      As long as the mulitisite setup can only be done from wp-config.php this should also be where to set a WP_IS_TRUSTED_NETWORK constant. You don’t specifically install a multisite, you install WordPress and transform it to mulitsite by editing wp-config.php.

      The spam site option may be removed unless some sites actually have it set already. The way links was deprecated is the way to go.

      Users should be registered through a signup process to avoid sending passwords over email. Single sites could also gain from a better signup process. For trusted networks this should be unified.

      There is a plugin for dealing with user activation keys, removing unused and unnecessary signups. This could be part of core.

      Shared media could also be something for the future, and have in mind.

      The important thing now is where to start, how to simplify things and not doing things that may block further evolution and flixibility.

      • John Blackbourn 3:10 pm on May 14, 2014 Permalink | Log in to Reply

        As long as the mulitisite setup can only be done from wp-config.php this should also be where to set a WP_IS_TRUSTED_NETWORK constant. You don’t specifically install a multisite, you install WordPress and transform it to mulitsite by editing wp-config.php.

        That’s not quite correct. You add the `WP_ALLOW_MULTISITE` constant but then you still need to go through the setup process in the admin area. This is where I imagine the open/closed network option will go.

        I agree with all your other points!

      • Boone Gorges 4:58 pm on May 14, 2014 Permalink | Log in to Reply

        > There is a plugin for dealing with user activation keys, removing unused and unnecessary signups. This could be part of core.

        Agreed that this is a problem. See also the new “Pending Users” feature in BuddyPress (http://wptavern.com/buddypress-2-0-to-add-signups-administration-screen – BP now creates the wp_signups table for non-multisite as well, to centralize signup management) and this plugin: https://wordpress.org/plugins/unconfirmed

    • Paal Joachim Romdahl 4:50 pm on May 19, 2014 Permalink | Log in to Reply

      An idea… brainstorming….
      What about having a Network page similar to a All Pages/All posts screen. Only here we can create connections. Create a new sub site or link with existing site.

      Create a new sub site options:

      • title, description and perhaps URL.
      • Optional check box for Domain.
      • Check boxes for Shared media, share posts, etc.
      • And probably other options.

      Link with existing site.

      • URL of site
      • Username and password.
      • Check boxes for shared media, share post etc.

      and more.

      This would really make it into a Network page that one can connect existing or new site.

  • Helen Hou-Sandi 2:48 am on May 9, 2014 Permalink
    Tags: , dev chat   

    Summary of 5/7 dev chat (IRC log):

    Proposed 4.0 ideas

    • Multisite enhancements: SSL, get site creation/editing UIs in line with the arbitrary domain/path support. Planning on weekly office hours.
    • Mobile experience: media modal and upload flow, Press This feature plugin.
    • oEmbed discoverability, usability, and caching improvements.
    • Widgets: JS API (#28093)
    • Taxonomy roadmap, part one.
    • Background images in the customizer.
    • Plugin installer improvements: better search and more information (needs .org API support), upgrading a plugin or theme via zip upload (#19641)
    • Export API improvements/overhaul (#22435)
    • Post meta: support for revisions (#20564)
    • APIs for posts/comment types/statuses. Ping @nacin if interested in collaborating (#12706).
    • Continuous a11y enhancements, particularly in the media modal.
    • Texturize patches, continuing on performance enhancements and bugfixes in 3.9.

    If you are interested in any of the above, sound off in the comments below.

    Potential themes for the release:

    • More visual cues in the admin for user tasks, as has been done for themes.
    • Continuing to improve the editing and media experiences.
    • Lots of under the hood things and API attention to make devs happy.

    Feature Plugins

    • Front-end Editor looks like it’ll continue past 4.0, as enabled by being a feature as a plugin, but we should continuously keep an eye on it and see what improvements can be brought into core sooner.
    • Media Grid View and Press This are under way.
    • WP API continues to move forward.

    Patches needing early dev attention

    • #17689: Terms should not be sanitized inside term_exists(). This is the first step in moving along with the taxonomy roadmap, so please look here if this has been of interest to you. Potentially needs more unit tests. Thanks to @aaroncampbell for the latest patch.
    • #14759: Improve the way oEmbed deals with caching (patch from @markjaquith).

    And finally, 3.9.1 is out now, if you haven’t already updated or been updated.

    • Schwarttzy 5:21 am on May 9, 2014 Permalink | Log in to Reply

      How about featured background images?

    • Florian Girardey 7:51 am on May 9, 2014 Permalink | Log in to Reply

      How about better UI for Header images ?

    • helgatheviking 7:55 am on May 9, 2014 Permalink | Log in to Reply

      More admin filter/hooks everywhere! And love for the quick edit.

    • RicaNeaga 9:49 am on May 9, 2014 Permalink | Log in to Reply

      Here’s what the roadmap looks like for Cpanel, from here… http://features.cpanel.net/responses/as-a-server-administrator-i-want-mariadb-support-so-that-i-can-accomodate-both-innodb-and-noninnodb-users

      ”1. We introduce MariaDB 10 with cPanel & WHM version 11.50

      2. In version 11.50 both MariaDB and MySQL are provided, and wholly supported, by cPanel

      3. With version 11.52 we announce that MySQL is considered deprecated, and will be removed in version 11.54

      4. With version 11.54 we no longer provide the MySQL RPMs.”

      So in ~ a year from now a major web hosting control panel is going to ship without any trace of MySQL. Then why not fully supporting MariaDB (10) in the next major release, 4.0, and include MariaDB (10) as an alternative for MySQL in the requirements page? https://wordpress.org/about/requirements/

      • Andrew Nacin 3:03 pm on May 9, 2014 Permalink | Log in to Reply

        WordPress already supports MariaDB, and has for a long time, since MariaDB is a compatible replacement for MySQL. We could put it in the requirements somewhere but it’s still pretty esoteric at this time.

        • RicaNeaga 5:33 pm on May 9, 2014 Permalink | Log in to Reply

          Thanks for the answer and info. MariaDB 10 however is a combination of MySQL 5.5 and 5.6, and with features of its own, it won’t be a 100% drop-in replacement for either of them (MySQL 5.5 or 5.6).

          So maybe it’s a good idea to make sure everything it’s ok, and put it in the requiremets after that. The sooner the better I think, it would make a statement that the wordpress project is also supporting MariaDB in the long run, alongside Google, CPanel, Plesk, RHEL and other major Linux distros.

          Right now I’m annoyed since I’d like to buy a managed server from Germany, and their control panel supports by default only MySQL and PostgreSQL. ”Spreading the word” about MariaDB hopefully would make others ”embrace the future” sooner :)

    • Jon Brown 4:55 am on May 10, 2014 Permalink | Log in to Reply

      I’m assuming the Metadata API/UI is still too far out to be considered for 4.0, but I’m going to cross my fingers and hope for it anyway: https://github.com/wordpress-metadata/metadata-ui-api/

      • Helen Hou-Sandi 6:39 pm on May 10, 2014 Permalink | Log in to Reply

        I would think of this as more of a working group that also happens to have a particular end goal in mind, and improvements can (and should be) ongoing. That end goal does not seem likely for 4.0 though, no.

    • Robert Chapin 4:03 pm on May 10, 2014 Permalink | Log in to Reply

      #10041 needs early dev attention. Come on guys. If we don’t do this now, the patch will go stale.

    • rajlaksh 7:25 am on May 13, 2014 Permalink | Log in to Reply

      what about categories like tags in new post page? so u have to enter category name then auto complete search :)

      Easy then scrolling 500+ categories.

  • Helen Hou-Sandi 8:30 pm on May 6, 2014 Permalink
    Tags: , dev chat   

    Summary of last week’s dev chat on 4/30 (IRC log):


    Features as plugins

    • Met on 4/29 (IRC log)
    • Current potential considerations seem to be WP API and media grid.
    • Press This is getting some attention from an early stages working group, which could also be a part of the 4.0 release.
    • Admin Help is poised to shift into more of a continuous testing and advisory group, which is awesome.
    • Front-end editor is making good progress, but has UX issues that are getting worked on, needs iteration and experimentation and probably won’t be ready by 4.0, but should continuously be worked on, as is the goal of features as plugins in the first place. Developers needed.

    Potential ideas and their suggesters:

    Summary: we have good things in mind about more media improvements, more editing experience improvements, more visual media grid and better plugin installer experience (following in the footsteps of themes), and behind the scenes wins in taxonomy, multisite, and post type and comment APIs.

    If you’re interested in any of the above or have other ideas, please sound off in the comments.

    Getting involved

    • We are always looking for more people to be involved with Trac gardening, patch review, patch writing, or some combination thereof.
    • Component pages are running well, and most could still use the caretaking of a component owner or somebody who’d like to become well-versed in a particular area of core. To get started, just sign up for component notifications at https://make.wordpress.org/core/notifications/. No need to be an expert now – learning and persistence is more important.To help with a specific plugin, join their weekly chats and/or follow along wherever they post. See the Features as Plugins page for more information.
    • A reminder from @matt to always be dogfooding the product – use WordPress every day.

    Bonus punnage, to the lead’s chagrin:

    > wonderboymusic will make a t-shirt for anyone who gets all 16 of those Cache tickets closed :)
    > sams: “Cache Master”?
    > wonderboymusic: Johnny Cache
    > jorbin: If you fix the Cache, you’ll get the Credit. That Checks out.
    > MarkJaquith: I’d put in a cache pun, but I don’t want to be sent to purgetory.
    > johnbillion: You would have to be a cache machine to fix all 16

  • Mark Jaquith 8:49 pm on January 16, 2013 Permalink
    Tags: dev chat   

    Agenda for the weekly dev chat:

    1. Feature team updates
    2. Set up schedule for more frequent feature team updates
    3. Unstick anyone who is stuck
    4. Rallying call for Ryan’s code maint ticket list

    • Schwarttzy 8:55 pm on January 16, 2013 Permalink | Log in to Reply

      Hi, I’m new to this whole WordPress Core thing and would like to add to the core with an idea I have to help responsive web designers with featured images. Basically, add an option for setting an aspect ratio, instead of defining some fixed width and height. How do I get started?

      • Amy Hendrix (sabreuse) 11:51 pm on January 16, 2013 Permalink | Log in to Reply

        Hi Schwarttzy, and welcome! If you’re interested in contributing, you should start with the Core Contributor Handbook, which has a lot of information about the process and the tools we use:


        It’s also incredibly useful to drop in on a few of the weekly dev chats in IRC — even though a lot of what happens there is updates on what different teams are doing, it’ll give you a good idea of what’s going on as well as the whole workflow. You’re also welcome to ask in #wordpress-dev if you need more help getting started; there’s usually someone around outside of meeting times.

        As for responsive images, there’s an existing ticket to make heights and widths filterable, although it hasn’t seen any action in a few months: you might want to start with getting familiar with the discussion and patches that have already happened in that effort. Check out #14110

  • Andrew Nacin 7:08 pm on November 14, 2012 Permalink
    Tags: , dev chat   

    Today’s dev chat, starting in two hours:

    • Triage https://core.trac.wordpress.org/report/5. No ticket should be without an owner, a path forward, and a timeline.
    • Discuss timeline for RC1 and how we are all feeling.
    • Things we need to do (or start thinking about) to prepare for a final release:
      • We need an About page of features. So, what are our wins?
      • Full sweeps for RTL, help text, IE, no JS, the blue color scheme, performance regressions, and 100% passing unit tests.
      • Continue to scan the support forums and awaiting review tickets reported against trunk to ensure we don’t miss anything.
      • Brainstorm what features and API changes need written tutorials (the “field guide”), and get people on board to research and write them.
      • Figure out what changes might need “3.5 compat” posts. The wpdb::prepare() argument change comes to mind, and obviously parts of media.

    All tickets should have people responsible for them, but also, so should all of these release preparation tasks. There’s something in there for everyone — bug gardeners, documentation, research, testing, etc.

  • Andrew Nacin 5:14 pm on November 7, 2012 Permalink
    Tags: , dev chat   

    Dev chat is moving from 2000 UTC to 2100 UTC, as daylight saving time has gone into affect in both the US and UK. This keeps the meeting at 4 PM U.S. Eastern (a little under 4 hours from now).

    Agenda for today is to shore up https://core.trac.wordpress.org/report/6 and ready another beta to be kicked out the door.

  • Andrew Nacin 5:12 pm on September 20, 2012 Permalink
    Tags: , , dev chat,   

    Timeline for Twenty Twelve 1.0 — final testing window 

    During the dev chat yesterday (logs), it was determined that the timeline for Twenty Twelve’s release to the WordPress.org theme directory will be next week.

    That means if you have any bugs to report against Twenty Twelve, please do so now! It’s time for final reviews. Once 1.0 is released, it will be very tough for us to make style or code changes, as we will then need to avoid breaking child themes (both code wise, and stylistically).

    So, if you haven’t looked at Twenty Twelve yet, now’s the time. Here’s the demo site: http://twentytwelvedemo.wordpress.com. Also, if you’re using the Beta Tester plugin instead of a checkout from Subversion, you may not have Twenty Twelve installed and up to date. In that case, here’s a direct link to download a ZIP.

    (@westi, @dd32, we should adjust how beta theme installs are handled…)

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