WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

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

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

We’d love for you to help out.

Looking to file a bug?

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

Want to contribute?

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

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

Weekly meetings

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

We have a project meeting every Wednesday at 20:00 UTC in the #wordpress-dev channel on chat.freenode.net. (Quick start: There’s a web interface.)

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

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 7:48 pm on July 2, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Here’s where we are on the five goals for internationalization outlined previously:

    1. The first step installing WordPress should be to choose a language. The rest of the install process would then be in that language.

    First pass done in #28577. There is a list of things to do in the ticket, which includes:

    • Improved error handling when the API or filesystem isn’t accessible. Working on this.
    • Bring this to setup-config.php. Working on this.
    • Place browser-based language suggestions at the top. Working on this.
    • Use better markup rather than simple select/option HTML, currently being worked on by @jorbin.

    2. You should be able to choose/switch a language from the general settings screen, after which the language pack should be downloaded.

    This simply requires replacing mu_dropdown_languages() with a new method that handles uninstalled languages gracefully. This is easy to implement and relies on much of the same code as the install process, so it’s simply on hold until that’s done. I’ve also worked out a UX flow with @sonjanyc.

    3. You should be able to search from the dashboard for plugins and themes that are available in your language.

    This is handled on the WordPress.org side. The updated plugins screen will need to pass a new argument to filter by language, and then remove that argument if the user requests showing plugins in any language. We’ll need to hack in readme/description translation support but that’s a small API change and otherwise WordPress.org work, not core work.

    4. All localized packages should be able to be automatically generated and made available immediately as part of the core release process.

    A script for this is written. While it needs more work, it was used as a test to build 3.9.1 packages, which are doubling as 4.0-alpha testing packages. This does not require changes in core.

    5. Localized packages should only be used for initial downloads from WordPress.org. Instead, language packs should be transparently used for updates.

    This is ready. A flag needs to simply be flipped in the API.

    Ongoing problems to solve:

    • I have a proposal to type up for how to handle readmes, license files, etc., in both core and plugins. Requires no core changes.
    • No one has picked up the plan to limit the code modifications still done in some locales. This may end up being a July project for me.
    • The relevant APIs we need in core were deployed to WordPress.org. Also, the plugin and theme directories are fully internationalized; we need to get those strings to translators and shoehorn them onto existing international sites.
     
  • Helen Hou-Sandi 5:57 pm on July 2, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Proposed agenda for today:

    • A look at the assignments from last week – next steps, any stucks, any needs. (@azaozz,
    • #27423: Improve Media Modal UI at small-screen sizes
    • #14759: Improve the way oEmbed deals with caching (@markjaquith)
    • #20564: Framework for storing revisions of Post Meta (@adamsilverstein)
    • How are we feeling about beta?

    Please add any items you have in the comments below.

     
  • Nick Halsey 2:44 am on June 28, 2014 Permalink | Log in to leave a Comment
    Tags: , menu-customizer   

    GSoC Menu Customizer Update 

    Since this is my first post here, a quick introduction. I’m a student at the University of Southern California studying Civil Engineering, Architecture, and Music Composition. I’ve been contributing to WordPress Core for just over a year and this summer I’m pleased to be working on WordPress full-time for my Google Summer of Code project.

    Overview

    The goal of the Menu Customizer project is to add Custom Menu management to the Customizer. Ideally, the project should be able to replace the existing Menus screen, with full feature parity, but that’s obviously a bigger discussion that would take place later. For more details, check out my initial proposal.

    Current Status

    I started six weeks ago and have built out most of the plugin’s UI and structure. However, I still need to build the menu-item previewing and saving components of the project. The UI closely resembles the Widgets-in-customizer UI, with sections for each menu and controls for each item. New menu items are added via a slide-out panel, where they’re currently grouped by post type/taxonomy, custom links, and a global search feature. The existing “Navigation” Customizer section has been re-branded to “Theme Locations,” and emphasizes the ability to add menus to widgets. Development is being done on the plugin repo, and you can download and play with it from there, but note that adding items creates orphaned draft menu items that are never published currently. Here’s a demo of the current plugin:

    (If the embedded video doesn’t play for you, try this link: https://cloudup.com/cVJbk3u32QV)

    The add-menu-item UI and implementation will be getting a lot of attention throughout the rest of my project. Items are added immediately, rather than the existing two-step checkboxes and adding several at once process, and menu items can now be deleted without having to open their settings, making deletion and addition more streamlined.

    When editing menu items, changing the navigation label of an item instantly updates its drag-and-drop handle, and updating a menu name updates the corresponding Customizer section. Items can be reordered or moved into sub-menus via either drag-and-drop or a reordering mode similar to that of the Widget Customizer.

    To minimalize the UI, given the limited space in the customizer, the “Title Attribute” field has been turned off by default, and all of the existing menu-item-field screen options are available, syncing with the existing Menus screen. I might look into building a core API for customizer screen options now that #27406 is in trunk, time permitting.

    A good amount of my time in the past couple weeks has been dedicated to #27406, which is a prerequisite for the Menu Customizer to be realistic given the need to allow users to create new menus (and in turn, new Customizer sections). Committed to trunk yesterday, it introduces a “Panels” API to the Customizer. Panels are a way to group sections, adding a new layer of hierarchy to the Customizer. In the Widget Customizer, all widget areas are added to the Widgets panel, allowing widgets to take over the entire Customizer as needed. The Menu Customizer plugin does the same thing with Menus, and requires trunk accordingly.

    Upcoming Work

    My next steps are to implement menu-adding and deleting, to implement reorderability/sortability, and then to spend quite a bit of time developing a saving/previewing system that scales well (see #14134  and related). This will most likely involve creating clones of changed menu items (posts) and menus (taxonomy terms). Once all of that’s finished, the plugin should be feature-complete, and ready for iteration.

    Core Patches

    I’ve also taken the opportunity to spend a fair amount of time working on core patches related to either Menus or the Customizer, as this project is widely expanding my knowledge of both areas. A couple of examples that have made it into core include #27406 – Customizer Panels, and #23076 – which adds live menu-item label-updating to the existing Menu screen. I’m planning on continuing to work on Menus and the Customizer via tickets/patches throughout my project as time allows.

     
    • helgatheviking 3:00 am on June 28, 2014 Permalink | Log in to Reply

      The video is pretty sweet!, great work! I’m definitely interested in seeing #14134 get fixed because it has been holding up the addition of an [18584: action hook for custom menu item meta](https://core.trac.wordpress.org/ticket/18584), which is causing all menu modifying plugins (and themes) to not be compatible with each other.

      • Nick Halsey 3:21 am on June 28, 2014 Permalink | Log in to Reply

        Thanks! I’m hoping to both fix the scaling issues and add some hooks in the new interface. The addition of a hook would really open up the possibilities for what menus can do, as your plugin and others already demonstrate.

        That being said I’m thinking that an API for custom menu fields might be even better than a hook, as that would make it easier to work with and match other core patterns for this type of structure. We’re essentially looking at custom post fields here given the way menus work. I’ll definitely look into this more once I get to the initial feature-completion stage. The ongoing Metadata UI API project might be able to be integrated here in some form, too.

    • nikeo 8:28 am on June 28, 2014 Permalink | Log in to Reply

      Great work! The plugin’s code is really clean and well commented.
      Thanks for sharing

    • Rami Yushuvaev 5:05 pm on June 28, 2014 Permalink | Log in to Reply

      Have you tested this in RTL mode?

      • Nick Halsey 5:54 pm on June 29, 2014 Permalink | Log in to Reply

        Not yet, that’ll come once we’re ready to test on different devices & environments after the basic functionality is complete. That being said, I’m guessing that the core build process will handle most of it automatically.

  • Alex Shiels 2:24 am on June 28, 2014 Permalink | Log in to leave a Comment  

    Update on the Plugins page work 

    A quick update on the Plugins page (previously: here and here). The three major areas of work are the Detail modal view; the plugin-install.php landing page; and the plugin list views. Some progress so far:

    #22599 has a minimal patch for displaying plugin reviews and ratings in the Detail modal. More work is needed.

    #27440 now has API support for image banners in the Detail modal.

    @stephdau is working on the next steps for the modal, which will probably include experimenting with removing or replacing the Thickbox code, and iterating on the UI.

    I’m working on the plugin-install.php page. There’s no specific ticket for it yet, but step 1 will be a basic overhaul incorporating some of the ideas in @melchoyce‘s thread in a rudimentary fashion.

    The plan is to get these minimally functional with API support very soon, and then experiment from there with the UI and incremental improvements.

    Some closely related tickets and posts:

    #28646 and #17902 suggest some improvements to the list views, both related to unifying the search list and the installed plugins list.

    #20002 suggests API improvements related to querying multiple plugins.

    This post includes screenshots of many web/app stores, which suggest some design cues. If you’d like to help out, we could use feedback and incremental patches on those tickets; and of course the Plugins component has many other tickets in need of attention.

     

     

     
    • Pippin Williamson 2:59 am on June 28, 2014 Permalink | Log in to Reply

      I love see these kind of updates. They make me so happy :)

    • Gustavo Bordoni 11:03 am on June 30, 2014 Permalink | Log in to Reply

      +1 for these, there is a lot of love for the Plugins!

    • Paal Joachim Romdahl 7:16 pm on July 1, 2014 Permalink | Log in to Reply

      Clicking the details of a plugin opens a modal box. If one wants to check the next plugin in the search list one has to first close the existing modal box and then click the next plugin details. What about including arrows to signal a forward and backward through the detail list of plugins one made a search for? (Similar to the themes screen.)

  • Eric Andrew Lewis 1:39 am on June 28, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Media Grid Update 

    Media Grid started as a standalone plugin by Shaun Andrews, which was a reimagining of the UI as an alternative to the traditional post list view in the Media Library. The argument was that images are the ubiquitous media type in most users’ libraries, so we should provide an interface to browse media visually.

    I joined the project in late April, attempting to integrate existing Media modal code. This work was merged into the standalone plugin, and into trunk(see #24716) in early June. In the process, I created documentation for the Media code, which is the most comprehensive resource for untangling the Backbone wires in media.

    Questions were raised about what problem the grid was solving, so in order to get a more hands-on understanding of user engagement with the Media Library, Jerry Bates performed user interviews. These confirmed our assumption that images are the pervasive media type, but also surfaced the fact that users identify media in different ways – some by the thumbnail, some by what post a media item is uploaded to, some by title.

    After a good amount of UX/UI chatter in weekly meetings, we decided we could serve users better by making a few changes to the original implementation merged into trunk. We’ve landed on mock-ups for a quick pivot, which I’m working on implementing . I’ll be dropping diffs for y’all Javascript Jedis to peruse on #24716, feedback welcome and appreciated. I hope to have merge-ables by Monday morning, and then to progress to user testing.

     
  • Helen Hou-Sandi 2:42 am on June 27, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of 6/25 dev chat (IRC log):

    General

    • Beta 1 is being pushed back to July 9 from July 2, with each successive beta and RC 1 also pushing back a week. The schedule has been updated.
    • oEmbed (@azaozz), i18n / language packs (@nacin), media grid (@ericlewis), and plugin installer (@tellyworth) should each have an update post published here before the weekend, outlining what has been done thus far, next steps, points needing discussion, and relevant tickets.
    • Each of the above should have a new patch ready by Monday. Across the board, it would be nice to see more work-in-progress patches — props @ericandrewlewis for recent patches on the media grid ticket
    • Daily scrubs in #wordpress-dev happening at 15:00 UTC.
    • @johnbillion would like to help coordinate people who are given time by their employers to work on WP; Make/Core post forthcoming.

    oEmbed

    • Recent updates to oEmbed: previews in the editor, media modal, added a bunch of providers
    • Todos: SSL, script sandboxing, caching improvements, UI/UX tweaks
    • Two thirds of our supported providers don’t support SSL: #28507
    • @sams suggested SSL should be a requirement for oEmbed providers going forward (have since revised to an important consideration for the time being).
    • Insecure iframes and/or insecure contained content will be blocked by newer Chrome and Firefox.
    • Two options: placeholder or a nonced, authed, proxied iframe.
    • For Monday: Placeholder fallback for SSL admin and non-SSL oEmbeds.

    i18n

    Media Grid

    • A quick phase 2 of the media grid is going forward
    • Media Grid needs a fair amount of work, not user testable yet.
    • Reminder: watch out for strings like “Edit Media” (#) won’t work well for long translations, i.e. ru_RU.
    • @ericandrewlewis asked for feedback on the JavaScript application structural decisions around Media Grid. This is likely worth a separate discussion.
    • For Monday: A user-testable patch.

    Plugin Installer

    • Screenshots for possibly comparable things.
    • @tellyworth is working on plugin-install.php and @stephdau is working on the details modal / page.
    • Next: Need to discuss what kind of data is most helpful to display for users when they are trying to figure out which plugin it is they want.
    • For Monday: @tellyworth and @stephdau will post patches in progress.

    Other

    With thanks (again) to @designsimply for note collation.

     
  • Helen Hou-Sandi 3:30 pm on June 26, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Daily scrubs for 4.0 

    Let’s do daily scrubs / ticket triage for the duration of the 4.0 release cycle at 15:00 UTC in #wordpress-dev. Fellow committers and component maintainers, please comment below if you can pledge to be there at least once or twice a week, and potentially help drive that particular scrub.

    For those who aren’t as familiar with scrubs / scheduled ticket triage sessions, they aim to provide some structure and a known time to focus on existing Trac tickets. At least one committer should be around for each one for rapid feedback. If you are unable to make the time, that’s okay – there are often contributors at various hours in the #wordpress-dev IRC channel who can give feedback and look at tickets, and ad hoc scrubs are very much encouraged. Those who are interested in reviewing patches and triaging tickets are especially welcome, and anybody is welcome to bring a ticket for eyes. If no specific tickets come up, we’ll move to reports, such as that for the next major release or ancient tickets.

     
    • Konstantin Obenland 8:28 pm on June 26, 2014 Permalink | Log in to Reply

      please comment below if you can pledge to be there at least once or twice a week

      I should be available at least once or twice a week.

    • Weston Ruter 8:36 pm on June 26, 2014 Permalink | Log in to Reply

      I have standing client meetings during this time every weekday, except for Monday and Tuesday (thanks to Canada Day :-) ). So I can be there next week. #widgets #customize

  • Helen Hou-Sandi 7:12 pm on June 25, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Agenda for today’s dev chat:

    • Beta timing – on schedule for next week, 7/2.
    • Organize and rally around pushes on features: oEmbed, i18n, plugin install experience, media grid.
    • #22023: Remove UNIQUE for slug in wp_terms.
    • Texturize/formatting.

    Please propose other items in the comments below.

     
    • Robert Chapin 7:32 pm on June 25, 2014 Permalink | Log in to Reply

      Texturize is going well. #28564 started a bit of a debate about exotic forms of shortcode and HTML nesting. I’ve ensured that most HTML can still go inside of shortcodes. Several old issues about inline comments, escaped shortcodes, and [ and ] in hyperlinks have been resolved and unit tested. A few performance issues were fixed.

    • John Blackbourn 8:04 pm on June 25, 2014 Permalink | Log in to Reply

      Let’s talk about whether the findings of #28507 is going to be a problem sandboxed oEmbeds

    • helgatheviking 9:28 pm on June 25, 2014 Permalink | Log in to Reply

      Is this ticket Menu Item limits: https://core.trac.wordpress.org/ticket/14134 getting any love for 4.0 or is it relying on the results of the GSOC? If I ever wanted to take a crack at it, is it safe to rely on javascript for things? The entire admin requires it right?

  • Ryan McCue 2:01 am on June 23, 2014 Permalink | Log in to leave a Comment
    Tags:   

    JSON REST API: Version 1.1 

    I’m happy to announce the availability of version 1.1 of the JSON REST API.

    This release is a bit of a smaller, more focussed release as we work on increasing test coverage and squashing bugs. Here’s the juicy details:

    • Add new routes for taxonomies and terms.

      Taxonomies and terms have now been moved from the /posts/types/<type>
      namespace to global routes: /taxonomies, /taxonomies/<tax>,
      /taxonomies/<tax>/terms and /taxonomies/<tax>/terms/<term>

      Test coverage for taxonomy endpoints has also been increased to 100%.

      Deprecation warning: The /posts/types/<type>/taxonomies endpoint (and
      sub-endpoints with the same prefix) have been deprecated in favour of the new
      endpoints. These deprecated endpoints will now return a
      X-WP-DeprecatedFunction header indicating that the endpoint should not be
      used for new development, but will continue to work in the future.

      (props @kadamwhite, @rachelbaker, @rmccue, #198, #211)

    • Allow customizing the API resources prefix

      The API base (typically wp-json/) can now be customized to a different
      prefix using the json_url_prefix filter. Note that rewrites will need to be
      flushed manually after changing this.

      (props @ericandrewlewis, @rmccue, #104, #244, #278)

    • Give null as date for draft posts.

      Draft posts would previously return “0000-00-00 00:00:00″ or
      “1970-01-01T00:00:00″, as draft posts are not assigned a publish date. The API
      now returns null where a date is not available.

      Compatibility warning: Clients should be prepared to accept null as a
      value for date/time fields, and treat it as if no value is set.

      (props @rmccue, #229, #230)

    • Fix errors with excerpt.

      Posts without excerpts could previously return nonsense strings, excerpts from
      other posts, or cause internal PHP errors. Posts without excerpts will now
      always return an excerpt, typically automatically generated from the post
      content.

      The excerpt_raw field was added to the edit context on posts. This field
      contains the raw excerpt data saved for the post, including empty
      string values.

      (props @rmccue, #222, #226)

    • Only expose email for edit context.

      User email addresses are now only exposed for context=edit, which requires
      the edit_users permission (not required for the current user).

      The email address field will now return false instead of a string if the
      field is not exposed.

      (props @pkevan, @rmccue, #290, #296)

    • Correct password-protected post handling.

      Password-protected posts could previously be exposed to all users, however
      could also have broken behaviour with excerpts. Password-protected posts are
      now hidden to unauthenticated users, while content and excerpts are shown
      correctly for the edit context.

      (Note that hiding password-protected posts is intended to be a temporary
      measure, and will likely change in the future.)

      (props @rmccue, #286, #313)

    • Add documentation on authentication methods.

      Full documentation on authentication
      is now available. This documentation explains the difference between the
      various available authentication methods, and notes which should be used.

      (props @rmccue, #242)

    • Include new client JS from github.io

      The WP-API Javascript library is now loaded dynamically from
      wp-api.github.io to ensure it is always up-to-date.

      (props @tlovett1, #179, #240)

    • Don’t allow setting the modification date on post creation/update.

      As it turns out, WP core doesn’t allow us to set this, so this was previously
      a no-op anyway. Discovered during test coverage phase.

      (props @rachelbaker, @rmccue, #285, #288)

    • Check post parent correctly on insertion.

      Posts could previously be added with an invalid parent ID. These IDs are now
      checked to ensure the post exists.

      (props @rmccue, #228, #231)

    • Make sure the type is actually evaluated for json_prepare_${type} filter.

      This value was previously not interpolated correctly, due to the use of the
      single-quoted string type.

      (props @danielbachhuber, #266)

    • Return WP_Error instead of array of empty objects for a revisions
      permissions error.

      Previously, when trying to access post revisions without correct permissions,
      a JSON list of internal error objects would be returned. This has been
      corrected to return a standard API error instead.

      (props @rachelbaker, @tlovett1, #251, #276)

    • Flip user parameters check for insert/update.

      Previously, you could add a user without specifying username/password/email,
      but couldn’t update a user without those parameters. The logic has been
      inverted here instead.

      (props @rmccue, #221, #289)

    • Add revision endpoints tests

      (props @danielbachhuber, @rachelbaker, @rmccue, #275, #277, #284, #279)

    • Add post endpoint testing

      Now at >54% coverage for the whole class, and >80% for the main methods. This
      figure will continue to rise over the next few releases.

      (props @rachelbaker, @rmccue, #99)

    • Separate helper functions into global namespace.

      WP_JSON_Server::get_timezone(), WP_JSON_Server::get_date_with_gmt(),
      WP_JSON_Server::get_avatar_url() and `WP_JSON_Server::parse_date() have
      all been moved into the global namespace to decouple them from the server
      class.

      Deprecation warning: These methods have been deprecated. The new
      json_get_timezone(), json_get_date_with_gmt(), json_get_avatar_url() and
      json_parse_date() methods should now be used instead.

      (props @rmccue, #185, #298)

    As always, we’ve got a full list of all the changes and a longer changelog. Here’s who contributed to this release:

    $ git shortlog 1.0...1.1 --summary
         8  Daniel Bachhuber
        12  DrewAPicture
         3  Eric Lewis
         2  JDGrimes
         9  K.Adam White
        54  Rachel Baker
       128  Ryan McCue
         4  Taylor Lovett
         1  jeremyfelt
         1  pkevan

    Version 1.2

    We’ve already started work on 1.2, and as always, we’re looking for help!

    With version 1.2 and onwards, we’ll be tackling a bunch of extra testing for our endpoints, with the aim of eventually reaching >90% coverage. As always, we’ll also be adding new features and fixing bugs.

    We’re also working on improving the new documentation site, and expect to see the majority of documentation migrated over there. Thanks to Sarah Gooding for helping out on the documentation side.

    Core Integration

    In case you missed it, the API is now slated for integration in WordPress 4.1. WP Tavern has a great writeup on the details.

    As always, we look forward to seeing you at the team o2 and on GitHub. Now’s also a great time to remind you that you can get support for the plugin on WP.org, or by tweeting at me. Thanks to everyone who made this release great, and thanks to everyone using the plugin!

     
    • Ian Dunn 4:14 pm on June 23, 2014 Permalink | Log in to Reply

      Include new client JS from github.io

      Is this intended to be a permanent change? I could be wrong, but I think Core’s policy (and also the wporg plugin directory’s) is that assets should be local.

      (Open Sans is an exception, because it’s very difficult to reproduce everything that Google’s API does locally.)

    • Stephane Daury (stephdau) 6:20 pm on June 25, 2014 Permalink | Log in to Reply

      Awesome work, gang.

  • Scott Kingsley Clark 6:06 pm on June 22, 2014 Permalink | Log in to leave a Comment
    Tags:   

    WP Metadata API / UI office hours this Friday 

    We will continue our weekly meetings this Friday. As no other suggestions have been made, it will remain at 18:00 UTC on Fridays in #wordpress-core-plugins on Freenode IRC.

    We may be transitioning from meeting into office hours as we haven’t had as many contributors joining us at the meetings as we had hoped. We will continue developing some awesomeness over at https://github.com/wordpress-metadata/metadata-ui-api

    Feel free to hop into the issues and take ownership of new field types or documentation. We’re also looking for help with styling of the form fields and JS in relation to support for repeatable fields.

     
    • Slobodan Manic 7:47 pm on June 22, 2014 Permalink | Log in to Reply

      Fridays work for me. I can continue working on field types, submitted a PR with four new input fields (email, range, number, color).

    • nofearinc 7:56 pm on June 22, 2014 Permalink | Log in to Reply

      9pm EEST on Fridays is not really the best timing for some of us either, which is 8pm for CEST (Central Europe) folks too (sorry for not being available, but that timing is a bit off here).

    • Ryan McCue 1:21 am on June 23, 2014 Permalink | Log in to Reply

      We may be transitioning from meeting into office hours as we haven’t had as many contributors joining us at the meetings as we had hoped.

      I think that’s just a common thing with feature-as-a-plugin teams; don’t be disheartened! :)

    • deltafactory 2:06 pm on June 23, 2014 Permalink | Log in to Reply

      Was last week’s cancelled? I was there and tried to get the conversation started but no one answered.

      • Scott Kingsley Clark 2:11 pm on June 23, 2014 Permalink | Log in to Reply

        Saw you and someone else were there, unfortunately Mike couldn’t make it and I was stuck in traffic trying to get home. We are all currently planning to be there this Friday, I won’t be cutting it so close with my plans on Friday either :)

    • Scott Kingsley Clark 8:32 pm on June 27, 2014 Permalink | Log in to Reply

      It turned out that Mike Schinkel couldn’t make it this week and I once again was stuck in traffic trying to get back from a WP lunch meetup.

      I think we’re going to try and push the ‘office hours’ a little earlier in the day so we can get some of our european contributors more involved.

      But going forward, I think in general, Fridays in #wordpress-core-plugins, I’ll be in there, and if you want to chat, we can chat, not sure if an hour long meeting slot is best while we’re in the current stage, until we have more movement and planning to be done as a group. Right now we’re just executing plans as we’ve laid them out.

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