WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Andrew Nacin Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 1:40 pm on April 16, 2014 Permalink | Log in to leave a Comment
    Tags: , , , external libraries   

    jQuery UI and wpdialogs in WordPress 3.9 

    WordPress 3.9 does not use the “wpdialogs” TinyMCE plugin as part of the TinyMCE 4.0 update ( #16284, #24067), which comes with a new dialog manager. (For more, see this post and their migration guide.) This was a jQuery UI wrapper we had introduced back in WP 3.1. If you were using this in your own scripts, please be sure you are setting “wpdialogs” as a script dependency.

    If you were using jQuery UI for anything on the post screen, please be sure you are setting this as a script dependency.

    In both cases you may need to enqueue the “wp-jquery-ui-dialog” stylesheet, if you are using the WP UI dialog design.

     
  • Andrew Nacin 12:14 pm on April 15, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Let’s have a meeting today, Tuesday April 15, 2014, 18:00 UTC, to make sure we have everything in place for a release. (#wordpress-dev)

     
  • Andrew Nacin 6:00 pm on April 2, 2014 Permalink | Log in to leave a Comment  

    Today’s meeting is at 20:00 UTC, or exactly two hours from now. This is one hour earlier than last week, to coincide with the UK’s switch to Daylight Saving Time. Agenda here.

     
  • Andrew Nacin 11:57 am on April 1, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Agenda for the April 2 meeting 

    Please suggest items for the April 2 developer meeting. So far:

    • The wpdialog TinyMCE plugin and the enqueuing of jQuery UI Dialog ( #16284)
    • Transient/cache suspensions during widget previews ( #27538)
    • Any other show-stoppers or critical issues
    • Timing of Release Candidate 1
    • April 16 is our target release date of 3.9
     
  • Andrew Nacin 5:24 am on March 27, 2014 Permalink | Log in to leave a Comment
    Tags: , , ,   

    TinyMCE 4.0 requires text/css for editor style files 

    As of TinyMCE 4.0, the visual editor iframe now has an HTML5 document type (<!DOCTYPE html>). In this scenario, CSS files must be served with the text/css content type. A server will serve a *.css file with the proper content type, but if you’re using a PHP file for an editor style file, you need to be the one to do it. It’s as simple as leading with:

    <?php
    header( 'Content-Type: text/css; charset=UTF-8' );
    

    So if you’re doing something particularly crazy with the editor and your styles aren’t loading in WordPress 3.9, you may just need a content type. Also, Chrome (and probably other browsers) throw a console warning when this happens.

    (via #27288)

     
  • Andrew Nacin 5:08 pm on March 12, 2014 Permalink | Log in to leave a Comment
    Tags:   

    As a reminder, the weekly meeting continues to be at 21:00 UTC.

    Daylight Saving Time has started in the U.S., which means the meeting is at 5 p.m. Eastern time, 2 p.m. Pacific. We will revert to 20:00 UTC on April 2, after Europe enters Daylight Saving Time.

    Our agenda for today will be to go over all 3.9 tasks and get an idea where we need the most resources, to ensure we are in a good position to close out the beta period in less than three weeks.

     
    • Robert Chapin 6:06 pm on March 12, 2014 Permalink | Log in to Reply

      It looks like I can join at least the first half of the meeting. There have been several iterations of the patch for #22692. It should be a comprehensive fix at this point. It will adjust quotes, smilies, and shortcodes so that their behaviors are normal in the presence of NBSP chars and entities. It also paves the way for refreshing patches in #26842, #8775, #20342, #23185, and many others. We could potentially clear out half of the wptexturize tickets if this gets the attention it deserves.

  • Andrew Nacin 6:00 pm on March 3, 2014 Permalink | Log in to leave a Comment  

    Daily ticket triage meetings at 1900 UTC this week 

    To help realize the goal of a WordPress 3.9 Beta 1 by week’s end, let’s have daily ticket triage sessions in IRC at 1900 UTC, or 2 p.m. U.S. Eastern time. (This is two hours before our usual weekly meeting.) If you’re able to join, see you in #wordpress-dev in one hour.

    We have 99 enhancement tickets open. They either need to be closed or moved out of 3.9 by the end of the week. Just 20 per day will empty that report.

    Of course, a number of us will be in IRC outside of these times as well, working on the same goal.

     
    • Robert Chapin 3:43 pm on March 4, 2014 Permalink | Log in to Reply

      Can we expect some attention on the early tickets?

    • KirkM 4:28 pm on March 6, 2014 Permalink | Log in to Reply

      Andrew – There appears to be a rather serious problem for theme authors who use the “mce-css”filter” to style TinyMCE using a .php file instead of a .css file. This filter was present in WordPress 3.8.1 as well as previous versions. Unfortunately, the “mce_css” filter has gone missing in builds of WordPress 3.9.

      A ticket has been submitted about this:

      https://core.trac.wordpress.org/ticket/27288

      Just FYI

  • Andrew Nacin 11:29 pm on February 20, 2014 Permalink | Log in to leave a Comment  

    Friday Trac Sprint 

    I mentioned this in the dev chat on Wednesday: Join us tomorrow (Friday, February 21) for a sprint through Trac tickets that need a reply!

    A few weeks ago I said one goal of mine for the 3.9 cycle was to make contributing easier and more accessible. That’s why so much work has gone into improving our tools in the last few months. One task is to empty one particular report of tickets: tickets that need a response. After that, I’d like to keep it empty.

    As of this writing, there are 386 tickets on this report. (The report shows 441, as that includes another 55 opened by a committer.) Help us empty this report!

    To best coordinate a few dozen people all trying to comment on a few hundred tickets, please join us in #wordpress-dev in IRC. We’ll break these tickets into chunks, such as by age, component, or focus.

    We’ll have people in IRC all day to help you out if you haven’t triaged tickets or given feedback before. There is a whole set of guidelines in the comments below@SergeyBiryukov and @ocean90 will be around for morning in Europe, and I’ll be around starting at around 9 a.m. U.S. Eastern.

     
    • Andrew Nacin 7:53 am on February 21, 2014 Permalink | Log in to Reply

      The main goals here are to make sure that tickets and patches have received some form of initial feedback. That’s just the first step in a long process, of course, but it’s an important one. If you’re new to this, here’s some tips on how you might approach and handle a ticket:

      When giving feedback for a ticket:

      • Thank the individual for the report. Some of these tickets are quite old; for those, a simple “Thanks for the report nacin. Sorry you never got a response.” is fine.
      • If this was one of the reporter’s first tickets, it will tell you above the comment box. Be nice. :-)
      • If it’s a support request, you can refer them to the WordPress.org support forums and close the ticket as “invalid”.
      • If it’s a bug report that sounds like an enhancement, then change the ticket to an enhancement. Enhancements are a bit more difficult to triage (as the feedback is more subjective), so it’s much easier to start with bugs.
      • Consider a quick search to see if it is a duplicate of another ticket that may be farther along.
      • If there’s a component that is more appropriate for the ticket, feel free to move it.

      If it’s a bug report:

      • See if you can still reproduce it in trunk. (And/or try 3.8.1.) Some bug reports may have been invalid to begin with; others might have been fixed already.
      • If when reproducing it, you feel you can elaborate on the issue, or write clearer steps to reproduce, please do so.
      • If you can’t reproduce it, ask the reporter for more information and add the “reporter-feedback” keyword. If you think the ticket should be closed, you can mark it with the “close” keyword. (There doesn’t need to be a rush to close the ticket.)

      If it has a patch:

      • Test it out — does it fix the problem? How did you test it? Did you notice any side effects?
      • If the patch doesn’t apply cleanly (as in, it fails when you try), add the “needs-refresh” keyword.
      • If you’re a developer, consider doing even just a cursory code review.
      • If the “has-patch” workflow keyword is missing, add it. Or, if after review you don’t find the patch to be sufficient, you can set it to “needs-patch” instead.
      • If you feel the patch is ready to be reviewed by a core developer to be considered for inclusion in WordPress, simply say so.

      It might take only a few minutes to triage some of the more straightforward tickets, especially once you get the hang of it. You could easily spend twenty or thirty minutes on others, or even longer if there’s a lot to test or if you have a lot of feedback to give. Take your time; the post calls this a “sprint” but it’s not a race!

      If you come across a ticket you like and want to write a patch for it, that’s great! Feel free to leave feedback on the ticket and start working on a patch. If you end up working on just that for today, that’s totally fine — there are a lot of others working through this list of tickets, too. Triaging can be a great way to find tickets that interest you.

      A number of us will be in #wordpress-dev to help you out. So people don’t overlap, we’ll try to point you to a particular collection of tickets, based on your interests. If you’re unsure what to do for a particular ticket, feel free to move on. Or even better: Ask in IRC and we can talk through it.

      (If you are craving even more detail on triaging tickets, the contributor handbook has a whole page on bug gardening.)

  • Andrew Nacin 8:15 am on February 12, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Please suggest agenda items for the February 12 developer meeting.

    Aside from usual 3.9 stuff, we’re going to be using part of this meeting for brainstorming for GSoC.

    Here’s the agenda thread and meeting notes from last week, as a point of reference.

     
    • Jen Mylo 8:21 am on February 12, 2014 Permalink | Log in to Reply

      If people want to write up their ideas for GSoC projects in advance, that would be great in terms of keeping things going. I’ll be submitting our GSoC application immediately following the dev chat, so if anyone has ideas but won’t be at the meeting, go ahead and post them at http://codex.wordpress.org/GSoC2014. Thanks!

    • Rami Yushuvaev 12:20 pm on February 12, 2014 Permalink | Log in to Reply

      How about a “Road Map” for upgrading the minimum requirements to PHP 5.4 and MySQL 5.5 (or any other version you choose). The purpose of the roadmap is to set a time frame, not choosing technology.

      The roadmap should be spread over a long period of time (let’s say 2 years from now), enough time for web hosts to make the proper adjustments. WordPress has three major version per year, this means WordPress 4.4 will require the new minimum requirements.

      The road map will not be a binding, meaning that if core developers will decide to upgrade the minimum requirements in wp4.6 or wp4.8 the road map can be changed. BUT, setting a time table is important, for plugin developers, web hosts, and core developers. It allows everyone the get ready for the upcoming change.

      • Bryan Petty 7:34 pm on February 12, 2014 Permalink | Log in to Reply

        It’s been mentioned many times that we should not become “a protest piece at the expense of our users”, and this is specifically mentioned in regards to setting hard deadlines for bumping minimum server requirements. We cater to our users, not dictate what they need by abandoning millions of users at arbitrary points, especially if they still account for more than 10% of WP installations.

        We still haven’t dropped PHP 5.2 support, and given the rate of use shown in the stats, that still isn’t happening for another couple years. Dropping 5.3 is probably more than 5 or 6 years down the road, and isn’t even worth thinking about right now.

        When the time comes, you can be assured there will be plenty of notice, but it won’t even be necessary for most since it will only apply to less than 10% of users.

    • Dominik Schilling (ocean90) 3:11 pm on February 12, 2014 Permalink | Log in to Reply

      State of #27078 (Autoprefixer), #26669 (wp-admin.css split) and #26799 (Backbone update).

    • Daniel Bachhuber 3:29 pm on February 12, 2014 Permalink | Log in to Reply

      I’d like to discuss #316 if it’s not too big of a conversation.

    • Tom Auger 4:47 pm on February 12, 2014 Permalink | Log in to Reply

      Let’s talk about all the great things that are happening with the Image Editor and Media Modal. I’m seeing the following tickets which are all tangential to each other: #24409 (which is awesome), #26672, #24567, #18947, #26870 (thank the gods), #21811 (which has turned into a much bigger deal than I thought) and #21810 (which seems to be a refresh of #19889).

      This all seems like “a thing”. @wonderboymusic, @gcorne and others seem to have things well in hand, but I’d like to see a little more sharing around all the great things that are going on, and where help / discussion / review is needed.

    • Aaron Jorbin 8:54 pm on February 12, 2014 Permalink | Log in to Reply

      I’d love to find out if anyone else has comments on #27023 and if people think grunt-patch is ready for me to tag it in npm and for us to add it.

    • Andrew Nacin 8:56 pm on February 12, 2014 Permalink | Log in to Reply

      Agenda:

      • CSS/JS: Autoprefixer #27078, wp-admin.css #26669, Backbone update #26799
      • 3.9 status reports for teams/projects/tasks
      • Widgets Customizer merge: old style widgets + options API issue (details in the meeting)
      • Any other logjams or stuck situations we need to address
      • GSoC brainstorming

      We can hopefully get through all but the last point pretty quickly.

  • Andrew Nacin 3:06 pm on February 6, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Here’s a quick summary of yesterday’s meeting (IRC log), as a status report on WordPress 3.9:

    Beta 1 will now be the week of March 3, a week later. The rest of the schedule is unchanged. I felt the extra week of alpha would be helpful given all of forward momentum right now, and others seemed to agree.

    It was decided to green-light the widget customizer plugin for merge. If all goes well, it’ll be in 3.9 final. There’s still a lot to do: some UI polishing, deeper code review, etc. — and surely it will get a lot of testing.

    Quick hits raised in the meeting:

    • Settings review is in the ideas/sketch/wireframe stage. They have a meeting today. (@jenmylo, @melchoyce)
    • Lots of audio/video changes landed. Needs review on #27026 and UI feedback on #26631. (@wonderboymusic)
    • Work continues bringing the image editor into the media manager. #21811. (@gcorne, @tomauger)
    • TinyMCE/editor: modals are getting redesigned. #26952. (@melchoyce, @avryl) QUnit tests are being added. #27014. (@azaozz) @gcorne also sunk some time into MCE views, for gallery rendering.
    • THX plugin is being revived to take a crack at the theme install screen. If it works out, these patches could land in 3.9. (@matveb)
    • A Grunt patch tool needs testing. #27023. (@jorbin)
    • Some refactoring of the multisite bootstrap will begin this week. #27003. (@jeremyfelt)
    • Volunteer(s) wanted: If anyone wants to work on expanding autocomplete in core, there is some work in that area to be done. @helen will help shepherd.

    We have a few more weeks of alpha, so it’s a great time to help with writing or testing a patch for WordPress 3.9. We’ll be keeping the tempo quick. Expect lots of changes.

     
    • helgatheviking 2:58 pm on February 8, 2014 Permalink | Log in to Reply

      Is there any chance 3.9 will tackle the issues with nav-menus.php saving a lot of data? Apparently this is the reason for the hold up on adding action hooks to the admin menu UI (for adding additional meta to the menu items), which is a feature that has been requested (at least 4 duplicates that I can find) a few times. Plugins and themes that are replacing the custom Walker with their own would finally be able to work together.

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