WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from December, 2012 Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 7:33 pm on April 9, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Last Week in WordPress Core 

    Howdy everyone! This is Last Week in WordPress Core for the week of March 31-April 7. I’m including all of the commits up to RC1 this week, which was released yesterday. Things are looking good, with very few remaining tickets open.

    3.8.2 and 3.7.2 were also released with security fixes, and automatic updates are rolling out.

    Developers, please test with your plugins and themes and let us know if you find issues.

    TinyMCE: As a quick note, since I’ve seen this brought up in the forums — in this release, TinyMCE no longer uses wpdialogs. This means it now needs to be enqueued by any plugin that wants to use it. As of [28024], there is a clarified warning that will appear in the JavaScript console if you attempt to use it, and it’s not enqueued.

    IE8 & wpview: Due to IE7/8 compat being necessary in TinyMCE (to resolve caret issues), IE8 and wpview are not currently the best of friends. Post RC1, fixes landed for #27546 that make wpviews degrade more gracefully.

    Media:

    • Playlists: Make elements in playlists responsive and fix playlist advancement on mobile. [27894] [27895] #27625
    • Playlists: Set preload='none' for the empty <audio|video> tag. [27974] #26779
    • Playlists: Make tracks keyboard-accessible. [28023] #27644
    • A/V Shortcodes: Remove support for a caption in audio and video shortcodes. This was part of a UX iteration for the related MCE views, but these captions have since been excluded. See [27640]. [27979] #27320
    • Edit Image Modal: Make the calculation of the aspect ratio more robust. [27942] [27948] #27366
    • Do not show featured images for image attachments; remove post_supports_thumbnails() and theme_supports_thumbnails() for now. [28051] #27673

    HTML5 Galleries:

    • Remove <br> elements for HTML5 galleries; see #26697. [27914] #27637
    • Twenty Thirteen and Fourteen: Update styles to support the new HTML5 line-break-less galleries. [27926] #27637

    Admin:

    Theme Installer:

    Widgets

    • Trigger jQuery events for widget updates. widget-added when a widget is added to a sidebar and widget-updated/widget-synced for widget soft/hard updates. [27909] [27969] #19675; #27491
    • In WP_Widget, introduce is_preview() method to allow widgets to check to see if they’re currently being previewed via the customizer. [27966] #27538
    • Widget Customizer: Improve compatibility with plugin custom scripts and styles for widgets. [27907] #27619
    • Widget Customizer: Rename inject_preview_css to print_preview_css. [27968] #27534
    • Widget Customizer: Use postMessage to highlight widgets in preview or sections/controls in Customizer. [27892] [27893] #27622
    • Widget Customizer: Refactor and clean up WidgetCustomizer as wp.customize.Widgets, and make available widgets panel a Backbone view. [27985] [27986] [27988] [27995] [28034] #27690

    TinyMCE

    • Update TinyMCE to 4.0.21. [27897] #24067
    • Image Details Modal Improve look-and-feel, and add a Custom Size option to the size drop-down that reveals fields for soft-resizing the inserted image. [27918] #27366
    • Image Details Modal: Move all advanced options under a single toggle, bring back the field for CSS Class, and optimize CSS for responsive layout. [27898] #27366
    • Drag and Drop Uploading: Add new argument to wp_editor() to enable. [27901] #27465
    • Gallery Views: Avoid JS errors when image attachments lack metadata. [28008] #27691
    • Return to loading /langs/[locale].js and /langs/[locale]_dlg.js from PHP to prevent errors with missing translation files when requireLangPack() is used without its second argument. Back to using ISO 639-1 (two letter) locales. #24067; [27922] #27610
    • Clarify error when wpdialogs is not enqueued. Add wp_enqueue_editor action fired when scripts and styles for the editor are being enqueued. [28024] #16284
    • Update translatable strings. [27927] #27453, #24067
    • Tighten up toolbar and tab styles. [27978] [27983] #27279
    • Expose toolbar keyboard shortcut in Help documentation for TinyMCE, and clean up TinyMCE help dialog, removing duplicated text and leaving only Keyboard Shortcuts. [28029] #27024; [28032] #27100

    Database:

    • Fall back from ext/mysqli to ext/mysql if the connection fails. This allows us to avoid breaking a site that works under ext/mysql but is misconfigured for ext/mysqli. [27935] #21663
    • Add $allow_bail argument to wpdb::check_connection() to match the connect method. [27925] #27240
    • Don’t pass a second argument to mysqli_fetch_field(). [28002] #27693
    • Rename USE_EXT_MYSQL to WP_USE_EXT_MYSQL. [28022] #21663

    Internals:

    • Updates: Record Plugin & Theme update statistics like we do for Core updates. [27905] [27906] #27633
    • Pingbacks: Forward pingback IP during verification. [27872] #27613
    • Dashicons: [27989] [28005] [28013] #26936
      • New icons: .dashicons-external, .dashicons-editor-contract and .dashicons-universal-access-alt.
      • Updated icons: .dashicons-code, .dashicons-universal-access, .dashicons-arrow-x-alt and .dashicons-arrow-x-alt2.
      • Restores .dashicons-post-trash as an alias for .dashicons-trash, which is the new one.
      • Use new icons in Widget Customizer.
    • Don’t try to resolve symlinks for single-file plugins. plugins_url() should not be used in this context anyway. [27999] #16953
    • Remove old links_recently_updated_* DB options that never had a UI. [27916] #27649
    • Deprecate wpmu_current_site(). [28009] #27702

    Many thanks to @adamsilverstein, @andykeith, @avryl, @azaozz, @bramd, @chiragswadia, @davidmarichal, @dd32, @dpe415, @duck_, @DrewAPicture, @DrProtocols, @ehg, @eightface, @empireoflight, @gcorne, @helen, @jackreichert, @jdgrimes, @jeremyfelt, @jesin, @joedolson, @johnbillion, @jorbin, @jond3r, @kovshenin, @kpdesign, @leewillis77, @markjaquith, @matveb, @mcsf, @melchoyce, @michael-arestad, @nacin, @Nessworthy, @norcross, @obenland, @ocean90, @pento, @plocha, @rachelbaker, @rmccue, @sdasse, @SergeyBiryukov, @siobhan, @sonjanyc, @tellyworth, Tom Adams, @vancoder, @westonruter, and @wonderboymusic for their help this week!

    For the complete list of commits to trunk, check out the log on Trac. Since we’re getting very close to release, the best way to help is to test! Let us know if you run into problems in the Alpha/Beta forums or on trac.

     
  • Andrew Nacin 9:01 pm on January 27, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Proposed Trac component reorganization 

    Warning, this long. tl;dr: I propose a reorganization of our Trac components. 34 top-level components with two dozen subcomponents. New tree at the bottom. First, an overview of some of our problems.
    (More …)

     
    • Helen Hou-Sandi 9:22 pm on January 27, 2014 Permalink | Log in to Reply

      I am particularly excited about how groups and maintainers will (hopefully) form around components and focuses. Anybody can comment on a Trac ticket or pitch an idea or create a potential roadmap, but there’s a real sense of empowerment when you really feel like you’ve got your head and hands wrapped around a specific area, and are perhaps even recognized for doing so.

      I know for me personally it’s been really gratifying to be entrusted to run with a particular area (what we can now define as the UI focus) and has made me feel more comfortable with interacting and pushing core forward. And not just when it comes to UI development and conception, but in other areas as well. I also might just dare hope that we can stop the worst of the ticket rot, with having both more bodies as well as a clearer idea for hopeful contributors as to where to go for more feedback or help.

    • nofearinc 9:23 pm on January 27, 2014 Permalink | Log in to Reply

      I’m curious about the Query branches of Comments and Users – too many tickets for these types of Queries or plans to extend a lot furthermore?

      Great list though, and the “hall of fame” with notes is awesome.

      • Andrew Nacin 9:28 pm on January 27, 2014 Permalink | Log in to Reply

        I don’t think either is necessarily the case. The idea was to create a specific subcomponent under Users that those focused on Query (in general) could also specifically follow. Same for Comments. So in this case, it’s about granularity, not necessarily roadmap or ticket counts. Query is goofy, as I mentioned in the post — it’s a cross-section that would normally be good as a focus, but it actually covers functional areas of core (there just happen to be a lot of areas).

    • StyledThemes 9:24 pm on January 27, 2014 Permalink | Log in to Reply

      Give me a BIG Pot of coffee and I will ready this shortly…however, I saw the part of Bootstrap which caught my eye as I build my themes with it (well, parts of it). But from what I see in the list, looks interesting overall.

      • Andrew Nacin 9:25 pm on January 27, 2014 Permalink | Log in to Reply

        Bootstrap is not Twitter Bootstrap, it’s the “loading” process of WordPress. I may rename this to Bootstrapping if it’s a problem.

        • StyledThemes 9:34 pm on January 27, 2014 Permalink | Log in to Reply

          ah… how about WordStrap :)

        • nofearinc 9:37 pm on January 27, 2014 Permalink | Log in to Reply

          That’s the initial association of many folks btw, even knowing what Bootstrapping is, the recent popularity of the Twitter’s thing is overlapping actively, just my 2¢

        • jack96161 10:26 pm on January 27, 2014 Permalink | Log in to Reply

          Agreed, Twitter commandeered “Bootstrap” for too many in the community these days — greybeards like me know what a real bootstrap is, but renaming it will eliminate more questions like this in the future. I always liked the “Progenitor Process”, we used in an early operating system at HP, but it will probably end up as something like “startup”, “init”, or other bland 2-syllable invention …

          • jack96161 10:34 pm on January 27, 2014 Permalink | Log in to Reply

            Just noticed on the 3.9 Trac pages that “Bootstrap/Load” is used as a component name — I’ll vote for that one and the Twitterites can just deal with it!

    • Aaron Jorbin 9:52 pm on January 27, 2014 Permalink | Log in to Reply

      One additional focus that may make sense is Unit-Tests. The use case I’m thinking of is a patch that just adds unit tests. It would go in the component that it most directly deals with as I think the test tools component is more focused on the tools of testing rather than the actual tests and receive the focus of Unit-Tests (and optionally the JavaScript focus if it is a javascript unit test)

      • Andrew Nacin 10:07 pm on January 27, 2014 Permalink | Log in to Reply

        Ah, yeah, I forgot to mention this. This is also on my list. I’m still trying to figure out how it overlaps with keywords (needs-unit-tests and has-unit-tests), so I saved it for later. Does needs-unit-tests and has-unit-tests simply trigger the unit-tests focus automatically? If a ticket is opened specifically to provide unit tests for something, is that more of a has-patch situation? etc.

        • Aaron Jorbin 11:27 pm on January 27, 2014 Permalink | Log in to Reply

          I think needs-unit-tests and has-unit-tests should trigger the unit tests focus.

          Has-patch makes sense in the just adding unit tests case since it is fixing the reported issue (not having unit tests) while I think needs-unit-tests and has-unit-tests is more workflow oriented.

    • Jon Brown 12:15 am on January 28, 2014 Permalink | Log in to Reply

      This looks great. You’ve done a great job of making the parents obvious (fwiw, I’d keep bootstrap as bootstrap).

      Two things seemed non-obvious to me, and maybe that’s just unfamiliarity on my part, but worth mentioning.
      First – Formatting-Shortcodes/Charset. This seems non-obvious to me but I’m guessing this is processing raw content, essentially wpautop, it’s brethren and associated filters. Formatting sounds more like CSS to me than filtering/processing content.
      Second – There are separate top level categories for HTTP API & XML-RPC. It seems to me this could be a single top level “Remote/External APIs” component with sub-components for HTTP, XML-RPC, JSON, etc… Maybe that’s makes no sense though though since code wise they’re entirely separate.

      Again, great work sifting all this into these components, these are just comments as I read through and understand what’s group where, why and what each component covers.

      • Andrew Nacin 7:01 pm on January 28, 2014 Permalink | Log in to Reply

        Formatting has been called Formatting, well, for as long as I’ve been around. It also centers around formatting.php. It might not be the best name, but yeah, it’s for processing raw content. We’ll make sure the description and search keywords for it are solid.

        For right now, HTTP and XML-RPC have pretty much zero overlap in form or function. We’ll need to revisit everything here anyway when the REST API comes into core. (Gut reaction would be a component for the server, and a focus to handle APIs specific to another component.)

    • Robert Dall 12:30 am on January 28, 2014 Permalink | Log in to Reply

      I am not sure if we want to confuse the themes & bundled theme anymore then they already are. When I gave a talk on trac and I explained why it is called bundled themes a couple light bulbs went off in the crowd. But yet they knew what default themes meant. It’s all semantics, but now that understand why themes and bundled themes are different.

      What I *REALLY* like is having a subcomponent for each theme in development. We could still use use the title to differentiate between Twenty-Thirteen and Twenty-Fourteen as is the current standard but having this and the easy of use sounds whole lot better and easier for query’s of trac etc…

      • Andrew Nacin 1:12 am on January 28, 2014 Permalink | Log in to Reply

        I’ve got no issue renaming Bundled Theme to Default Themes, and we can definitely nest individual components underneath it for each theme. The issue I see would be that if we added subcomponents for each default theme directly under the Themes component, where would a ticket go that affects more than one theme? (This isn’t entirely uncommon.)

        • Sam Sidler 4:19 pm on January 28, 2014 Permalink | Log in to Reply

          In the main Bundled/Default Theme component? I assume the components are still usable even when subcomponents exist.

          • Andrew Nacin 6:47 pm on January 28, 2014 Permalink | Log in to Reply

            Sorry, I should have been more specific. Option 1, which is totally fine;

            Default Themes

            • Twenty Ten
            • Twenty Eleven

            Option 2, which I’d prefer (and which I thought RDall was hinting at):

            Themes

            • Appearance
            • Widgets
            • Nav Menus
            • Twenty Ten
            • Twenty Eleven

            My point was I’d like to merge “Bundled Theme” (or “Default Themes” or whatever) with “Themes” to make it even less confusing. But then I’m not sure where general default theme tickets (affecting multiple themes) would go — getting dumped in “Themes” means they may get lost.

        • Robert Dall 6:20 pm on January 28, 2014 Permalink | Log in to Reply

          Does it need a subcomponent if it effects all themes? Or are subcomponents required when they exist?

  • Andrew Nacin 7:47 pm on January 6, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Lots of improvements to Core Trac 

    Over the holidays, I was sick for two weeks (boo). While resting and recovering, I took to working on our tools (yay). Specifically, Trac. Here’s an overview of the added features, enhancements, and bug fixes. There’s a lot (and more on the way), so I’ll try to keep each point brief. If you have any questions I’d be happy to elaborate in the comments.
    (More …)

     
  • Andrew Nacin 9:26 pm on December 31, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Commit announcements for 3.9 

    Lots of news to share! First: Helen Hou-Sandí has had guest commit for the past three release cycles. She’s been spending the last year reviewing contributions, mentoring contributors, and working on some of our larger UI projects. I’m proud to announce @helen is now a permanent committer to WordPress!

    We’ve invited John Blackbourn (@johnbillion) to be a committer for the 3.9 cycle. His strong, consistent contributions have been backed by excellent judgment and temperament.

    Matt Thomas, who led the dashboard redesign in 3.8 (and 3.2, and 2.7, etc.), will keep his commit to continue to maintain and improve WordPress UI. He’s been a great mentor to many contributing designers and his long-term impact is indelible.

    For the last few years, we’ve been granting commit access on per-cycle basis, sometimes for a particular component, feature, etc. Generally, after about a year, a guest committer can be considered for permanent commit access. Dominik Schilling, Sergey Biryukov, Drew Jaynes, and Scott Taylor have all had their commit extended for 3.9.

    Drew (@DrewAPicture) was given temporary commit for inline documentation starting with 3.7. He’s been heading up the long-running initiative to document every hook in WordPress. Scott (@wonderboymusic) also started committing during 3.7, and has a particular penchant for digging deep into the query and taxonomy APIs. And Sergey (@SergeyBiryukov) and Dominik (@ocean90), well, they are forces of nature.

    (@aaroncampbell was also given guest commit in 3.7, but he ended up not having much time to use it.)

    Here’s a full list of those with permanent commit: @markjaquith, @ryan, @westi, @matt, @azaozz, @dd32, @koopersmith, @duck_, @helen, and me (@nacin); @lancewillett for bundled themes; @iammattthomas for UI. You might have also seen commits before from @josephscott (XML-RPC), @nbachiyski (internationalization), and @mdawaffe (secret weapon for really tricky problems).

    Next weekly meeting is January 8. Happy new year, everyone. Here’s to a great 2014.

     
  • Andrew Nacin 6:50 pm on August 21, 2013 Permalink
    Tags: ,   

    Agenda for today’s dev meeting:

    • Review why/how we’re doing features-as-plugins for post-3.7 releases (@samuelsidler)
    • Start cranking on tickets, discuss any major tickets we need to discuss, check if anyone is stuck or wants something to work on (@duck_)
    • A number of people are working on make/core posts to kick off some 3.7 initiatives (updates, language packs, inline docs, develop.svn ideas list) or jumpstart conversations for future dev meetings (CSS preprocessor pros/cons) — let’s aim to get these done this week.
    • This meeting will be followed by 3.8 office hours at 21:00 UTC. There is no 3.8 meeting tomorrow — postponed for this week.

    Also, the JavaScript meeting (IRC logs) went great:

    • @kadamwhite and @carldanley will be enumerating JS style preferences and working on a jshintrc
    • @jorbin and @kadamwhite are working on JS unit tests (#24870, #25096, #25088)
    • We’ll be formally adopting JSDoc for inline documentation (same basic style as PHPDoc)
    • Also discussed include JS actions/filters (#21170)
     
    • Andrew Nacin 6:52 pm on August 21, 2013 Permalink | Log in to Reply

      Suggest any items for the dev chat in the comments.

    • Carl Danley 6:55 pm on August 21, 2013 Permalink | Log in to Reply

      Also – i’m putting together a formal approach on design patterns to further enhance our consistency in JS. I’m hoping this will help to introduce a standard that developers can conform to; something that promotes both ease of use and a clear definition for how we should be approaching implementations. Will have this content ready a little later in the week.

    • Unsal Korkmaz 7:11 pm on August 21, 2013 Permalink | Log in to Reply

      Sorry if i miss, what happened to post formats?

    • WraithKenny 7:34 pm on August 21, 2013 Permalink | Log in to Reply

      I’m totally down for the pro’s side of css preprocessors. Grunt supports lesscss.org

  • Andrew Nacin 7:35 pm on August 14, 2013 Permalink
    Tags:   

    WordPress 3.7 organization 

    With WordPress 3.7 and 3.8, we’re a project in major transition. Version 3.7 aims to solve for a lot of things that are weighing us down. (See the initial kickoff post.) What do you want to do? In terms of process, here is what is being worked on for 3.7:

    Processes, Tools, Workflows

    • New development tools — develop.svn.wordpress.org — run by @koop. If you are interested in Grunt, unit testing (including JS testing), and how we can streamline and modernize our workflows, this is for you.
    • Code reference — inline documentation efforts — run by @rzen, @ericlewis, and @drewapicture. If you are interested in inline documentation, this is for you. See this post to get started.
    • Process changes (including improvements to Trac and how we organize around components). If you want to write some Python for Trac, this is for you. If you’re just interested in helping with component reorganization, stay tuned here — there will be a post soon outlining a new component tree.

    Security, Stability, and Updates

    We have a few other focuses that all deal with a general theme of security and stability.

    • Passwords. We are aiming to improve the adoption of best security practices by assisting with password generation. #24633@duck_ is also working on some changes to strengthen cookies. #20276. If you are interested in security, this is for you.
    • Updates. @dd32 and @pento will be heading up automatic updates for minor releases, as well as improving the trustworthiness of our upgrader. If you love updates and stability, this is for you.
    • Language packs. We need to separate language files from plugins, themes, and core, allowing them to be maintained and updated independently (and, ideally, automatically). #18200. If you want to help WordPress’ global reach, hook up with me, @dd32, and @markoheijnen.

    General Triage

    Finally, we have 3,800 (already only 3,600) open tickets on Trac. There are dozens of components with many, many tickets. Already, there have been a few components with a strong base of contributors working on them, including:

    • Multisite, currently being smashed by @jeremyfelt and others. If you like multisite and want to make it better and more stable, this is for you. There are currently 122 open tickets.
    • JavaScript. A number of you have expressed interest on working on JavaScript in core. Whether that is shoring up the stability of existing features, improving existing JS, or working on a JS testing framework, this should be a great working group. @carldanley, @adamsilverstein, @nbachiyski, @kadamwhite, and others expressed interest.
    • Query and Taxonomy. These two advanced areas of core kind of go hand-in-hand, not in the least because @wonderboymusic smashes query tickets with his left hand and taxonomy tickets with his right. If you’re interested in bringing down these tickets (68 and 93 open), this is for you.
    • General triage. Folks like @c3mdigital and @avryl have been already going through old tickets either closing them out or finding diamonds in the rough. Or maybe you find that one of the many open components catches your interest. (Go here and choose any component from the drop-down to see all open tickets.) We’ll be coordinating efforts to work together both in IRC (especially during the weekly meetings) and here on make/core.
    • Components with a lot of open tickets: General (376 tickets), Administration (302 tickets), Media (221 tickets), Template (161 tickets), Comments (135 tickets), Users (107 tickets), Themes (105 tickets), Formatting (98 tickets), Menus (96 tickets), Widgets (90 tickets), Plugins (90 tickets), Editor (85 tickets), Upgrade/Install (84 tickets), Import (70 tickets). If you want to do general triage, General and Administration in particular need a lot of work!

    Today during the weekly meeting, we’ll be talking about ongoing efforts, rallying the troops and helping to assemble working groups, and setting up some times for regular triage meetings.

    So, what do you want to work on? Let’s start coordinating in the comments.

     
    • WraithKenny 7:49 pm on August 14, 2013 Permalink | Log in to Reply

      I’m interested in “New Development Tools” and JavaScript Triage. I’ll help as much as time permits and see if I can get a coworker to help out too.

    • MartyThornley 7:51 pm on August 14, 2013 Permalink | Log in to Reply

      I’m always up for multisite. Just submitted a revised patch for http://core.trac.wordpress.org/ticket/20774, based on feedback and taking a look now to see what else I might be able to jump on.

    • George Stephanis 8:00 pm on August 14, 2013 Permalink | Log in to Reply

      I take it core won’t be getting two-factor authentication in 3.7, then?

    • nofearinc 8:07 pm on August 14, 2013 Permalink | Log in to Reply

      I would like to work in “Updates” and help in General and Administration.

    • Konstantin Obenland 8:10 pm on August 14, 2013 Permalink | Log in to Reply

      I’d like to help clean up the themes component. I started with pushing some tickets to the 3.7 milestone and I think there are some quick wins there.

    • K.Adam White 8:30 pm on August 14, 2013 Permalink | Log in to Reply

      I’m guilty as charged: JavaScript! I’d love to have a conversation in #wordpress-dev to discuss the JavaScript changes. I know @carldanley has begun to work on some proposals; it should be a lively conversation!

    • Mike Schroder 10:01 pm on August 14, 2013 Permalink | Log in to Reply

      I’d like to help with “Updates”!

      Otherwise, I’m likely just to spend some time triaging tickets, likely mostly in the ‘media’ component. Another project needs assistance? Let me know!

    • lucasstark 10:16 pm on August 14, 2013 Permalink | Log in to Reply

      Regarding Process. Is there any way we could flag and filter tickets that are “plugin territory”.

      • Andrew Nacin 3:00 am on August 15, 2013 Permalink | Log in to Reply

        Good question. I think we’d hesitate to add yet another resolution. We have pretty much always used “wontfix” for this — as in, we are acknowledging the ticket is valid, but we’re declining to address it.

        By all means, feel free to close ‘plugin territory’ tickets with a comment stating such!

    • Ryan McCue 3:57 am on August 15, 2013 Permalink | Log in to Reply

      Development tools, process, passwords and updates sound good to me (and of course, background work on the code reference as needed). Process and tooling will probably be the main ones for me given time constraints (Python’s always fun).

    • Travis Northcutt 12:47 pm on August 15, 2013 Permalink | Log in to Reply

      Is there any reason to think that a plugin that prevents WP from sending passwords in plaintext, and instead requires a new user to set their own password, would be a good idea?

      I don’t know enough to know the specifics of how that would work internally, but it’s something that interests me.

    • Nashwan Doaqan 5:31 pm on August 15, 2013 Permalink | Log in to Reply

      I am really want to help with Language packs, this will save my life !

    • Mustafa Uysal 12:45 pm on August 16, 2013 Permalink | Log in to Reply

      I’d like to help language packs.

    • doughamlin 4:00 pm on August 19, 2013 Permalink | Log in to Reply

      Are the two items listed above for passwords the only things being worked on? I think it’d be smart to see both limited login attempts (probably not technically password-related) and strong password enforcement built into core.

  • Andrew Nacin 7:17 pm on August 6, 2013 Permalink
    Tags: ,   

    WordPress 3.7 meeting tomorrow, August 7 

    If you haven’t caught @matt‘s State of the Word keynote at WordCamp San Francisco last weekend, you should. It contains a lot of great insight into how WordPress is used (using data from the 2013 user survey) and what should be expected for WordPress 3.7 and 3.8. (Talk about 3.7 starts at around 33 minutes in.)

    Here’s what was announced: WordPress 3.7 will be released in two months — early October. (Wat.) Jon Cave (@duck_) and I will be leading the release. It will be a quick “platform-focused” release, with a focus on stability and security.

    There are three main things we’d like to get done — language packs, auto-updates for minor releases, and some enhancements to help strengthen user’s passwords. Beyond that, though, the major goal of 3.7 is to offer a bit of a “reset” — which includes a huge cleanup of Trac. We’re currently at 3,800 open tickets, and we’d like to whittle that down as well as make things more manageable for the future. That includes reorganizing our Trac components, making it easier to contribute to certain areas of core (rather than, say, drinking from a single Trac firehose), and trying to organize teams around these components.

    Outside of core, there will also be work on developer.wordpress.org, which will include a hosted code reference and developer handbooks. As part of this, there will be a lot of inline documentation cleanup in 3.7 — potentially including an inline documentation standard for actions and filters.

    Better development tools will also be a goal in 3.7 — see also the post on develop.svn.wordpress.org from earlier.

    This is just the beginning. Please join me on Wednesday, August 7, 20:00 UTC for our weekly developer meeting in #wordpress-dev on freenode.net. I expect 3.7 to be a bit crazy, with a high volume of commits (oh, the days of WordPress 3.0), but also with increasing organization that can help set the stage for future releases. Daily bug scrubs! Rapid development! High tempo! Yay! Who is with me? See you tomorrow.

     
  • Andrew Nacin 2:26 am on July 28, 2013 Permalink
    Tags: post types, ,   

    Potential roadmap for taxonomy meta and post relationships 

    In the days before the WordPress Community Summit in October, a number of contributing developers huddled together to discuss a number of long-term architecture ideas. Among them were taxonomy meta and post relationships. (Ah, I see I now have your attention!) This post is more or less a proposed roadmap. It’s an ambitious plan that is designed to take place over perhaps five or more releases.

    (During WordCamp San Francisco’s keynote, @matt talked a little about a new aim to build teams of contributors and reviewers around individual core components. There will be a lot more on that in the coming days and weeks. For now, here’s a post that covers two components, post types and taxonomy.)

    The discussion included all core committers at the time — @ryan, @markjaquith, @westi, @azaozz, @nacin, @dd32, @koopersmith, and @duck_ — and a number of contributing developers, including @aaroncampbell, @dh-shredder, @helen, and @scribu.

    At the moment, terms are represented in WordPress using two different IDs: a term ID, and a term taxonomy ID. A term ID (and name and slug) can actually appear in multiple taxonomies, so to identify a particular term, you must have either the term ID and the corresponding taxonomy, or just the term taxonomy ID. This dates back to the original taxonomy schema in WordPress 2.3. At the time, the concept of “shared terms” seemed like it could be an important abstraction. Hindsight is 20/20, and shared terms are the bane of taxonomies in WordPress.

    So when we talk about term meta, we’re actually talking about term taxonomy meta – meta associated with a term taxonomy ID, not a term ID. The problem is, the public ID used in the API and elsewhere is the term ID (and, by necessity, a taxonomy is also passed). This confusion — and the need for there to be only one object identifier in our metadata API (term taxonomy ID, not two, as in term ID and taxonomy) — has long forced us to table the discussion of term metadata.

    (There are separate conceptual issues here — at what point does a term with metadata simply become a post-like object that can relate to other posts? And given post relationships, could terms and posts actually converge in their underlying schema? I’m not actually going to answer those questions in this post. Purely talking schema and architecture at this point.)

    At WordCamp San Francisco last year, four of us — me, Gary Pendergast (@pento), @scribu, and @koopersmith — came up with a rather crazy way to make major changes to our table schema while still being backwards compatible. In fact, we came up with two ways to do it. This was the plan everyone heard and discussed at the summit.

    It was clear that shared terms had to go. The first step is removing a UNIQUE index on the slug field in the wp_terms table. (This is dependent on #17689.) Then, we stop creating new shared terms. Step three, on an upgrade routine, we actively look for any existing shared terms and split them.

    These three initial steps must happen over two to three major releases, as we’re talking about a bug fix, a schema change, an API change, and an upgrade routine — in that order.

    Then comes the fun part, in yet another major release. With shared terms split, term ID and term taxonomy ID will be identical  on every install.  If we moved the slug and name fields from wp_terms to wp_term_taxonomy, we could actually drop wp_terms.

    How can we remove an entire table but still be backwards compatible? We came up with two solutions:

    1. Because all fields in wp_terms will exist in wp_term_taxonomy, wp_terms can be recreated as a MySQL view to be a read-only mirror of term data, thus being compatible with all existing queries.
    2. Because all fields in wp_terms will exist in wp_term_taxonomy, and because table aliases like `t`and `tt` are always used when joining these two tables, $wpdb->terms can simply be set to $wpdb->term_taxonomy. A query that previously joined wp_terms with wp_term_taxonomy would just join itself.

    In all: Using the second approach (yes, it works), it took about 20 lines of code to make WordPress run without a wp_terms table. Wow, right?

    So by this point, we would finally have a sane taxonomy schema. Less joins, a cleaner API (probably helped by a new WP_Term object to model WP_Post and WP_User), no more shared terms headaches, and a single, sane ID for a single taxonomy’s term.

    Once that is all finished, we can finally have term meta. Maybe. (Kidding. (Kind of.))

    Where do post relationships come in? The existing Posts 2 Posts plugin by @scribu is fantastic and serves the niche well. But we’re not really comfortable making any architecture or API changes along these lines while our taxonomy schema is still in a far from ideal state.

    The post relationships plugin supports posts to posts, and posts to users. Core taxonomy relationships supports posts to terms, but it can also be rigged to relate users to terms. (It also supported links to terms, yet another object type.) We didn’t fully iron out this idea yet, but one idea is to convert the current wp_term_relationships table to a more generic object relationships table, which can support posts to posts, posts to users, terms to users, and of course posts to terms (and, really, any arbitrary relationship).

    A disclaimer: This post doesn’t promise anything. Do not rely on the contents of this post for future projects.  It will take us some time to lay out the proper groundwork and make sure we get this right. Do not expect this to happen in WordPress 3.7, or even 3.8. (Actually, do not expect this to happen at all.)

    That said, I’m really glad to get this information out there and I’m excited to hear any feedback you may have. We are always thinking toward the future, and a lot of contributing developers have mile-long roadmaps in their heads — it’s long past time to get those on paper.

     
    • Scott Taylor 2:39 am on July 28, 2013 Permalink | Log in to Reply

      `WP_Term` should happen as soon as possible. Proper modeling, fix caching, etc

      • Andrew Nacin 6:26 am on July 29, 2013 Permalink | Log in to Reply

        Yes, but ideally we wait until we have a single ID to pass around. It really needs to be term_taxonomy_id, but we don’t pass it around anywhere else in the UI.

    • Jon Brown 2:44 am on July 28, 2013 Permalink | Log in to Reply

      Will this happen for 3.7? j/king… I read every beautiful word of this post including the disclaimer. This all sounds brilliant. TaxID/TermID confused the heck out of me for a LONG time as a new to WP developer.

    • Scott Kingsley Clark 4:06 am on July 28, 2013 Permalink | Log in to Reply

      Excited about all the above, will watch like a hawk at how things go and be available to test and implement changes in my own projects!

    • Manny Fleurmond 4:52 am on July 28, 2013 Permalink | Log in to Reply

      Keeping an eye out for developments. The things that could be possible with connecting posts, terms, users, etc in all types of relationships (one to one, one to many, many to many) is mind boggling. This would definitely help plugins like bbPress and cause an awesome boom of innovation in the WP plugin development community. I wait and watch with baited breath.

    • Grant Palin 5:14 am on July 28, 2013 Permalink | Log in to Reply

      The two terms tables have puzzled me for a while. Now I see it is due to the way core is set up. So it’s interesting that you are looking at correcting the core setup and simplifying things a bit. WP_Terms sounds good, and will help improve the image that WordPress has among some coders as being poorly coded. And not least, the possibility of having content type or term relationships in core would be excellent, and further the ability of WP to be a CMS out of the box.

    • Mike Schinkel 5:22 am on July 28, 2013 Permalink | Log in to Reply

      Finally.

    • Shane Pearlman 5:51 am on July 28, 2013 Permalink | Log in to Reply

      + yay

    • rfair404 7:01 am on July 28, 2013 Permalink | Log in to Reply

      Both are great ideas. I want to play.

    • Avryl 8:29 am on July 28, 2013 Permalink | Log in to Reply

      Awesome! :D

    • Hassan 9:42 am on July 28, 2013 Permalink | Log in to Reply

      For the past two weeks or so I was always thinking about taxonomy meta, whether WordPress will ever support it or should I just go with workarounds (e.g. wp_options). Then all of a sudden @nacin wrote this post! Yay!

      Even though it’s not here yet (hey come soon already!), I’m already planning for some projects! (Yeah, I read the disclaimer :))

    • Julien 10:13 am on July 28, 2013 Permalink | Log in to Reply

      Great news! The future is bright with WordPress. This will open up everything and Worpress will be seriously taken as à tool for web application! Can’t wait to see this released for Wp 3.9 (kidding;))

    • Mike Little 11:24 am on July 28, 2013 Permalink | Log in to Reply

      For those who need to work now with the idea of Term/Taxonomy metadata, there are some plugins already out there. I have successfully used “Taxonomy Metadata” (http://wordpress.org/plugins/taxonomy-metadata/) in a project; also “Meta for taxonomies” (http://wordpress.org/plugins/meta-for-taxonomies/) looks interesting.

      A question: the current system (sort of) supports synonyms/aliases for terms, which can be very useful: are there plans to retain this functionality?

      • Rahe 8:03 am on July 29, 2013 Permalink | Log in to Reply

        Meta for taxonomies is perfect, it uses the WordPress meta API and is only an API ( like the WordPress post_meta ).
        I use it very often, the only problem is there is no easy way like the posts meta box to display/edit the meta in the admin.

      • Andrew Nacin 8:13 am on July 29, 2013 Permalink | Log in to Reply

        I’ve almost never seen it used, but no plans to remove that functionality. This should continue to work just fine. Worth pointing out that any shared terms will be split which could possibly break aliases. Something to keep in mind.

    • aristath 12:30 pm on July 28, 2013 Permalink | Log in to Reply

      This conversation brings in mind what happened on Drupal 6 when it became Drupal 7. I know Drupal and WordPress are 2 completely different things, but bare with me.

      On Drupal 6, there were taxonomies and nodes. Something similar to out terms and posts… And the database structure was also similar to what we have now.
      On Drupal 7 however, they decided to make some radical changes. There were no longer nodes and taxonomies, everything was an “entity”. The database structure was significantly simplified and allowed it to move forward as a CMS.
      Ideally this is the direction I would love to see on WordPress… and this sounds like a first step to that direction.

      The proposed solutions are both viable, though I find the 2nd one more compelling.

      • Andrew Nacin 8:15 am on July 29, 2013 Permalink | Log in to Reply

        Yeah, we’re aware of this. It’s certainly something to at least think about. But I don’t think a generic “entity” makes sense for us.

        I’ll share that, according to folklore, the current taxonomy schema was actually inspired by Drupal’s own schema. And we know how that went. :-)

    • Charles Frees-Melvin 2:25 pm on July 28, 2013 Permalink | Log in to Reply

      What if there was a single meta table and a meta_type filed that has “posts”, “comments”, “users” in it. It would make meta more versatile to extend to taxonomies once taxonomies are ready for it. Kind of like we did to categories and link categories when we came up with the terms/taxonomies system.

    • Mike 2:47 pm on July 28, 2013 Permalink | Log in to Reply

      Does this mean I won’t be able to use one taxonomy term with two different taxonomies?
      Because I thought that was the perfect bug –>>feature scenario.

      • Matt Van Andel 11:57 pm on July 28, 2013 Permalink | Log in to Reply

        This wouldn’t affect that at all. Currently, taxonomy terms are an overly-normalized nightmare. If you create a Category called “Foo” and a Tag called “Foo”, only one term is added to wp_terms and then it is associated with the taxonomy in wp_term_taxonomy. The weird thing about this is that there is only entry in wp_term_taxonomy for each term, even though the normalized terms are listed in wp_terms. It is, frankly, really stupid… but as @Nacin said, hindsight is 20/20.

        What is being proposed is that those two tables are merged. You could still have identical terms in multiple taxonomies – but how they are identified in the database and by the API would change to something a little more sane.

        • Mike Schinkel 5:39 pm on July 29, 2013 Permalink | Log in to Reply

          taxonomy terms are an overly-normalized nightmare.

          Actually, if it had been normalized it would likely be much less of a nightmare. As-is the current schema causes E. F. Codd to turn over in his grave.

    • Robert Chapin 4:29 pm on July 28, 2013 Permalink | Log in to Reply

      Excellent direction.

    • Stephanie Leary 8:09 pm on July 28, 2013 Permalink | Log in to Reply

      I will now find @nacin and give him a hug.

      (+1)

    • portfola 8:43 pm on July 28, 2013 Permalink | Log in to Reply

      This is a welcome development, thank you!

    • Matt Van Andel 11:33 pm on July 28, 2013 Permalink | Log in to Reply

      Finally! These are all things that have driven me crazy for as long as I’ve been developing for WordPress.

      But over at *least* 5 major versions? Ugh. Post 2 Post is a decent bandaid, but that’s functionality that we need in core as of yesterday. What is the reasoning for spacing out the rollout that much? Is it just to minimize potentially breaking changes? Are there ways we can accelerate the process?

      • Japh 11:36 pm on July 28, 2013 Permalink | Log in to Reply

        If you have a listen to Matt’s State of the Word talk, you’ll note that the plan is to speed up update and release cycles generally. So this could happen over a shorter period of time than you might think, despite being over a number of cycles.

        In fact, I imagine it’s this type of thing that’s part of the reasoning behind speeding up the cycles: bigger changes can happen faster.

      • Andrew Nacin 10:43 am on July 29, 2013 Permalink | Log in to Reply

        As the post tried to carefully outline, this requires a significant number of schema, API, and architecture changes. Database upgrades can be very painful, especially with the very real potential of significant amounts of data to modify and migrate here — we need to make sure that we don’t try to bite off too much each release.

        There’s nothing wrong with Posts 2 Posts being in a plugin. You’ll note this post doesn’t actually promise post relationships — it’s entirely possible we leave it out of core for the long term. I’m not saying it’s likely, but my point is that not only is there not a way to accelerate this process, but that there isn’t a need for it either.

        • Taras Mankovski 5:28 pm on July 29, 2013 Permalink | Log in to Reply

          > There’s nothing wrong with Posts 2 Posts being in a plugin.

          This reads like a Jedi mind trick: “You don’t need this… Go back to work.”

          “I don’t need this… I’ll go back to work”

    • sboisvert 4:14 am on July 29, 2013 Permalink | Log in to Reply

      I’ve thought about this. And I’m happy smarter people have also thought about it and now have a good plan to fix it :)

    • Frank Bültge 10:04 am on July 29, 2013 Permalink | Log in to Reply

      @Nacin Thanks for the status. This are very nice news.

    • Michael Dance 5:00 pm on July 29, 2013 Permalink | Log in to Reply

      This sounds like a really, really sharp approach. Great job so far.

      As a heavy Posts 2 Posts user, I just want to mention that post relationships have pretty much eliminated my need for term meta.

      As a simple example: say you have a Journal Article post type and a Journal Issue taxonomy. Each term is a different journal issue, but for each one you’d want an image, a masthead — more than a term can provide. So that’s where term meta could help.

      But: with post relationships, you can just make Journals a post type and relate each journal to a bunch of articles that way. Suddenly journals have access to post meta, featured images, the works.

      I’m not saying I don’t want term meta at all, but there is a danger that it could open the door to terms and taxonomies being used way beyond the scope of what they’re meant to do and muddy the lines between term and post. And while post relationships can cover most of the use cases of term meta (if I’m wrong on this, I’d love to see some examples), the opposite is definitely not true, so to me, post relationships are the bigger priority.

      (All that said, I know that this is a long way off, and in the meantime I’m just as excited about getting rid of the shared term abstraction and creating WP_Term.)

    • Ben Huson 7:11 pm on July 29, 2013 Permalink | Log in to Reply

      Nice to see this on the roadmap – even if we should “not expect this to happen at all” :)

    • Marcus 12:46 pm on July 30, 2013 Permalink | Log in to Reply

      this will be awesome!

    • Allstar 9:14 pm on July 30, 2013 Permalink | Log in to Reply

      I’m all for progress…

      What about internationalisation?

      I’ve wanted for ages for the term_taxonomy tables description field to be moved into the terms table. Therefore all the language would be in one place and the data in another.
      So, you would only use the term_taxonomy_id as a primary for getting stuff BUT you could have multiple terms (in different languages) associated with it. You would not go to the terms table first to find something unless it was by text lookup.

      A WP_Term object is a big *like* from me but I’d l’d also like WP to be easier on the international side of things and my above comment on how to do international user entered terms would be a good step.

      Of course I’m no Core Developer big wig so I might’ve overlooked something but it’s at least worth mentioning in case the idea had been overlooked or I overlooked a way of doing it.

    • shawfactor 7:18 am on July 31, 2013 Permalink | Log in to Reply

      @nacin the speed and modelling improvements would be nice but the can you elaborate further on how you would extend the current taxonomies which are doubles into triples without having a redundant field on the doubles?

      Also I think Posts 2 Posts plugin by @scribu is nice but as I’ve argued: http://shawfactor.com/b/gaA

      post relationships need to be in the core and they nheed to be semantic.

    • Chris Lema 2:53 pm on July 31, 2013 Permalink | Log in to Reply

      +1 for doing it over several releases (even if it’s slow). Quick DB changes have tons of unintended consequences. Great write up.

    • AzzX 12:10 am on August 2, 2013 Permalink | Log in to Reply

      I have used CPTonomies and Posts to Posts to achieve more functionality though they are hacks and susceptible to being discontinued and breaking. This is where Drupal excels. If I want to have ratings and comments on a specific Taxonomy I can – without hacking the core.

    • grindcode 12:10 pm on August 2, 2013 Permalink | Log in to Reply

      This is the last milestone WP needs to approach any needs. Good stuff!

    • Chuck Reynolds 10:43 am on August 3, 2013 Permalink | Log in to Reply

      needs to happen.. might as well start the move and roll it out slow.

  • Andrew Nacin 10:09 pm on December 7, 2012 Permalink
    Tags: ,   

    The new target for WordPress 3.5′s release is Monday, December 10, at 11 a.m. Eastern time.

    I badly wanted to release today, just as I did yesterday, and the day before. I want this thing kicked out to the curb as much as you want it running on your sites. But the entire core team is exhausted, and we’ve made too many changes this week on too little sleep to risk dropping 3.5 without an adequate code freeze and a few days of quiet. #22803 was downright frightening to see, while #22790 was just absurd on a number of levels. I wanted to go to bed at 11 p.m. last night and instead four of us worked until 7 a.m. The responsible voice in my head says without a doubt, that code needs to soak longer (and should probably sit in a corner with a dunce hat on).

    Plus, let’s face it, it’s late Friday afternoon on the east coast of the United States. I don’t want to do that to support teams, hosting companies, or translators. In the end, the extra few days can only help.

    So: we’re going to branch 3.5 now. I’m currently aiming for a code freeze that lasts 65 hours and fifty-five minutes in length. We will reconvene on Monday at 10 AM Eastern time (1500 UTC) and start working our way through the release checklist.

    Tomorrow evening, a few of us will touch base to see if anything has come up we need to deal with. By Sunday morning, we will know whether anything needs to change. Until then, we rest. I know, it’s lame we’re not shipping 3.5 yet. But a few more days will be forgotten sooner than potential egg on our face if we ship it without clear heads.

    In the meantime: Go update your WordPress.org profile with your full name so it can make it on the credits page. And enjoy the weekend!

    I’ll leave you with this:

     
    • Mike Schroder 10:12 pm on December 7, 2012 Permalink | Log in to Reply

      Heavy hearts is indeed the proper tag for this. Thanks for being willing to make the decision, but even more for your (and the rest of everyone who has been up for nights) sleepless effort.

    • Alex King 10:15 pm on December 7, 2012 Permalink | Log in to Reply

      A wise (and I’m sure, hard and frustrating) choice.

    • Amy Hendrix (sabreuse) 10:15 pm on December 7, 2012 Permalink | Log in to Reply

      Mad props to you and the whole 7am crew — take care of both yourselvesa and the release.

    • Matthew Richmond 10:20 pm on December 7, 2012 Permalink | Log in to Reply

      Sounds like a wise move. Props to you and all the contributors on the incredible work so far!

    • Alex Mills (Viper007Bond) 10:20 pm on December 7, 2012 Permalink | Log in to Reply

      But a few more days will be forgotten sooner than potential egg on our face if we ship it without clear heads.

      Hear hear. Users aren’t going to care if 3.5 is a few days late compared to serious bugs.

    • Matt Wiebe 10:20 pm on December 7, 2012 Permalink | Log in to Reply

      /me salutes the lead developers and wishes them dreams of, well, just dreams. Because sleep.

    • Shane Pearlman 10:21 pm on December 7, 2012 Permalink | Log in to Reply

      Dude, thank you for applying common sense. No one will actually remember if it is really today or monday in the scheme of things, but they will always remember when bad things happen.

    • Jeremy Felt 10:22 pm on December 7, 2012 Permalink | Log in to Reply

      Fantastic job getting it here. Smart call to wait. Thanks to all the 7am-ers!

    • quicoto 10:25 pm on December 7, 2012 Permalink | Log in to Reply

      Good choice, thanks for all the hard work guys!

    • Luis Rull 10:27 pm on December 7, 2012 Permalink | Log in to Reply

      Good choice. We need good code, not early one. Keep up with the good work.

    • Syed Balkhi 10:30 pm on December 7, 2012 Permalink | Log in to Reply

      Can’t wait for it :) Keep up the good work.

    • Joey Kudish 10:32 pm on December 7, 2012 Permalink | Log in to Reply

      Great rational and responsible choice. Kudos and mad props for all the long nights!

    • BobDunn-Trainer 10:34 pm on December 7, 2012 Permalink | Log in to Reply

      Makes total sense… and all I can say is thank you and everyone else for all this hard work!

    • Birgit Olzem 10:37 pm on December 7, 2012 Permalink | Log in to Reply

      Thank you, for your announcement, Andrew. I know, it was a critial decision for you, but really reasonable! Have a good rest at weekend.

    • jcastaneda 10:39 pm on December 7, 2012 Permalink | Log in to Reply

      Completely reasonable. It would be like serving uncooked food.

    • Michael Beckwith 10:40 pm on December 7, 2012 Permalink | Log in to Reply

      Go enjoy the weekend everyone, business can resume Monday.

    • joelwills 10:49 pm on December 7, 2012 Permalink | Log in to Reply

      Thanks for all your hard wok everyone, much appreciated!

    • Jerry Bates (JerrySarcastic) 10:55 pm on December 7, 2012 Permalink | Log in to Reply

      Spock would say that this is “…the only logical conclusion.”

    • Richard Tape 11:18 pm on December 7, 2012 Permalink | Log in to Reply

      “I know, it’s lame we’re not shipping 3.5 yet.”

      No. Just no.

      It’s not lame. It’s the right choice. It’s the only choice. Thank you, Andrew and everyone else for the ridiculous hours of work you’ve put in to this and all releases. Enjoy your weekend. You’ve deserved it.

    • cjc1867 11:34 pm on December 7, 2012 Permalink | Log in to Reply

      no pressure but make it perfect as can be but release it when you are ready guys

    • Tony Scott 11:36 pm on December 7, 2012 Permalink | Log in to Reply

      Better late and right, rather than ontime and wrong (not my phrase, can’t remember from whom)!

    • Philip Arthur Moore 12:12 am on December 8, 2012 Permalink | Log in to Reply

      Echoing the sentiments of everyone who has commented before me. Watching #wordpress-dev the last several days has made me realize the sheer amount of work that you guys are putting into getting this out the door. It’s impressive, to say the least.

      When it’s all said and done no one will remember a few missed days or deadlines. What they will remember is how much of yourself you’ve given to this release and everyone will applaud you for it and be thankful.

      Get some sleep.

    • Jason Spatola 12:18 am on December 8, 2012 Permalink | Log in to Reply

      Looks like I’m the lone voice of dissent here. Horrible decision, guys. (Just kidding. Can’t wait until Monday!)

    • marcopako 12:37 am on December 8, 2012 Permalink | Log in to Reply

      Thank you guys!

    • Jon Brown 1:14 am on December 8, 2012 Permalink | Log in to Reply

      I’ve been keeping track of irc and trac… and my god you guys have been gone HARD for a LONG time. Take a few minutes this weekend to breathe and enjoy… you deserve that and WAY more. Thanks for all the hard work.

    • FAT Media 1:33 am on December 8, 2012 Permalink | Log in to Reply

      This was definitely the right call. Anyone who is upset by this decision needs to have their heads examined. Keep up the great work guys and get some freakin sleep!

    • jasontucker 2:40 am on December 8, 2012 Permalink | Log in to Reply

      Just remember, beer fixes most things! :) HAve a drink and a relaxing weekend all.

    • Samuel Wood (Otto) 3:03 am on December 8, 2012 Permalink | Log in to Reply

      Too much niceness here.

      THIS IS BAD AND YOU SHOULD FEEL BAD.

      Also, have a good weekend, and if you happen to mention where you’re going, I may call in a shot for you. Be careful out there folks! :)

    • Ryan McCue 3:28 am on December 8, 2012 Permalink | Log in to Reply

      Heard they punched a duck?

      Poor @duck_, he never stood a chance.

    • Dan 3:32 am on December 8, 2012 Permalink | Log in to Reply

      A wise decision. High-five to all the core devs, thanks for all your hard work.

    • George Stephanis 3:49 am on December 8, 2012 Permalink | Log in to Reply

      I fully support this decision. Unless Keri is reading, in which case OH GOD DON’T BLAME ME, BLAME JORBIN, IT’S ALL HIS FAULT.

      And RE: duck punching, no mallards were harmed in the making of WordPress 3.5

    • Konstantin Kovshenin 8:28 am on December 8, 2012 Permalink | Log in to Reply

      Good move! Besides, whoever really needs 3.5 are running RC4 anyway.

    • Frank Bültge 10:47 am on December 8, 2012 Permalink | Log in to Reply

      Good decision! The people need to test early and the RC is available, who wants to use 3.5.

    • Jonas Bolinder (jond3r) 1:49 pm on December 8, 2012 Permalink | Log in to Reply

      Anybody else pondering about duck punching and monkey patching? Here’s what Wikipedia has to say.

    • cdils 3:36 pm on December 8, 2012 Permalink | Log in to Reply

      I am beyond impressed with you guys and the efforts you’re taking to release solid code to the community. Take a big nap and thanks for your hard work.

    • Maor Chasen 7:45 pm on December 8, 2012 Permalink | Log in to Reply

      Great call. Better be a stable version rather than a buggy one.

    • markroth 8:43 pm on December 8, 2012 Permalink | Log in to Reply

      This was a very good call. I commend you for that. And I thank you immensely for all the work you’ve done and are doing on WordPress!

    • Abhishek Ghosh 8:47 pm on December 8, 2012 Permalink | Log in to Reply

      Great move.

      `I know, it’s lame we’re not shipping 3.5 yet. But a few more days will be forgotten sooner than potential egg on our face if we ship it without clear heads.’

      It is carefulness to make the perfect.

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