WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Andrew Nacin Toggle Comment Threads | Keyboard Shortcuts

  • 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.

  • Andrew Nacin 8:44 pm on February 5, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Fine-grained Trac notifications 

    Some housekeeping items to share so I don’t need to cover it in the meeting today:

    New notification preferences are live. On the notifications page, you’ll be able to subscribe to activity from all tickets in a particular milestone, component, or focus. You can also subscribe to only new tickets, in case you want to then selectively watch tickets as they come in.

    New greeting on make/core. Look up. Or if you’re viewing this post directly, check out the homepage. Right now the “Get Involved” menu item leads you to there, but it’d been tough to know where to go from there. This serves to introduce new people and get them information quickly: what this blog is, where to file a bug, how to start contributing; and provides some info about IRC and our meetings.

    New, simpler new ticket form: I simplified the new ticket form, cleaning up the warnings, text, and chrome (it had a lot of borders and fieldsets and such). It looks much less intimidating now.

    New ticket reports and component pages. These went live late last week — here and here.

    Create a new ticket This was also helpful because we shifted around where you can go to create a new ticket. You can now do it from search results, all ticket reports and the main reports screen, component pages, the icon in the navigation, and now from the make/core homepage. The new reports screen is a new entry point for Trac. You’ll note it actually duplicates the content of Trac’s home page (new ticket button there too), which you’ll have trouble finding a direct link to anywhere.

    Focuses/components: Component and focus triaging is pretty much done. (More than one thousand open tickets — 30% — have been modified in the last two weeks alone.) Still have some decisions to make about the Administration component, but I’m not worried.

    And with that, I actually have no more changes planned for core trac. Except for ticket smashing. It’s now time to start clearing these two reports: Tickets without a response and Tickets that are ancient and inactive. Who is with me?!

    Thanks also @ocean90 for replacing every last icon in Trac with a Dashicon. Love it.

     
  • Andrew Nacin 3:26 am on February 5, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Please suggest agenda items for the weekly developer meeting, Wednesday, February 5, 21:00 UTC.

    If there’s a task or ticket we need to work through, or need volunteers for, let’s get those spelled out now. Maybe we can even work through some of them pre-meeting.

    I’ll again be asking for a sentence or two (or more, if necessary of course) from each person/team working on a 3.9 task. You can also post those here if you’d like — please cross-reference any relevant tickets or discussions. Worked out great last week. For the state of things as of last week, see Mike’s weekly roundup.

     
    • Pippin Williamson 4:05 am on February 5, 2014 Permalink | Log in to Reply

      Not sure if there’s much discussion needed on them, but I’d love to see the remove/has_image_size() tickets shored up:

      https://core.trac.wordpress.org/ticket/26768
      https://core.trac.wordpress.org/ticket/26951

    • Jeremy Felt 4:19 am on February 5, 2014 Permalink | Log in to Reply

      I’d like to chat a bit about the direction of domain routing. I’ll be around pre-meeting as well.

      I opened #27003 last night with a patch that introduces `wp_get_network()` as a way to retrieve a network by it’s domain and path. This isn’t an absolutely necessary abstraction from `wpmu_current_site()`, but it does remove the functionality away from the `$current_site` global and focuses on retrieving just the requested information. In the process, `wpmu_current_site()` gets cleaned up quite a bit. It should be pretty straight forward to write unit tests that cover `wp_get_network()`.

      IMO, this is a first step toward cleaning up a bit of the load process. If we’re good with this direction, the next step will be to do the same thing for site discovery ($wpdb->blogs). I have more notes written up here on the multisite load process in general for anyone that wants an overview of how things are working.

    • Pippin Williamson 5:17 am on February 5, 2014 Permalink | Log in to Reply

      I’ll throw out another one. I’d LOVE to see further discussion on better custom comment types, per https://core.trac.wordpress.org/ticket/12668

    • Weston Ruter 8:14 am on February 5, 2014 Permalink | Log in to Reply

      There was a really good discussion today on #wordpress-dev regarding feedback for Widget Customizer. So I think we have a path forward for important issues to address. I’ve created a milestone on GitHub to track these issues: https://github.com/x-team/wp-widget-customizer/issues?milestone=4&state=open

    • Robert Chapin 11:27 am on February 5, 2014 Permalink | Log in to Reply

      3.9-early tickets, please

    • Manuel Schmalstieg 12:49 pm on February 5, 2014 Permalink | Log in to Reply

      For international users, improving the handling of accents/diacritics in file attachments would be a big win: https://core.trac.wordpress.org/ticket/22363 – the ticket has patches, and @markoheijnen has proposed it for 3.9 …

    • Tom Auger 7:59 pm on February 5, 2014 Permalink | Log in to Reply

      I’d like to discuss https://core.trac.wordpress.org/ticket/21811 and see if my patch / suggestions are salvageable, given the much bigger development effort around the entire Media Modal. The feature I was working on (prior to the whole Media Modal overhaul) was a very small, targeted, incremental enhancement that was kinda “shoehorned” in under that trac ticket, but really addresses something different and much smaller in scope.

    • Tom Auger 8:37 pm on February 5, 2014 Permalink | Log in to Reply

      Update: I see @gcorne has done some great work demonstrating how this could get integrated into Media Modal. I’ll continue this week and see if I can bring these things together. As for today’s meeting – we just got massively dumped on in Toronto, so I’ma head out of the office now and may not get back online in time to catch this week’s meeting.

  • Andrew Nacin 12:13 pm on January 29, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Please propose agenda items for the development meeting today at 21:00 UTC. Let’s try to keep it to under an hour, like last week’s.

    Some to start us off:

    • Consider the Widgets Customizer plugin for 3.9 merge. If you haven’t looked at it yet, please spend some time today before the meeting. Obviously, we all like the idea, but we need to study the implementation and provide feedback. Please comment on that post if you haven’t already.
    • I’d like to propose an initiative for cleaning up a group of 556 tickets during the 3.9 cycle. (It has details, will explain in the meeting.)
    • Quick situation reports for various 3.9 tasks. If you’re working on something, please come armed with a sentence so we can do these rapid-fire — or post it in the comments thread. Some things are moving forward quickly, some aren’t. Where can we help? Here’s a list of what was proposed for 3.9 (see also the comments, which were updated after the last meeting). We need to take the “proposed” label off soon…
    • I’d like to get moving on the Trac component re-organization; I’ll see if there are any questions. We will need some help to move around tickets (ideally adding feedback to them along the way), so I’ll be looking for volunteers and talking about what is needed.

    Aren’t familiar with how these meetings work? They’re especially good for breaking logjams — whether that means talking through a major sticking point, finding volunteers to help with something. We also use them to plan out schedules and tasks, make sure everyone is on the same page, and do release post-mortems to see how things went. (As 3.8.1 was released on Thursday, could be good to discuss this and 3.8.2, for example.)

    The meeting takes place in IRC on chat.freenode.net in the #wordpress-dev channel. See you then!

     
    • William Bowles 12:27 pm on January 29, 2014 Permalink | Log in to Reply

      I like it! One of the problems with WP has always been the amount of time spent moving between the various components that make up the site. I’d like to see a lot of the backend stuff move to the Customize sidebar and the popout access to other widget tools seems to work perfectly.

    • Tom Auger 2:06 pm on January 29, 2014 Permalink | Log in to Reply

      I have moved forward with https://core.trac.wordpress.org/ticket/21811. Still trying the time to upload an actual patch, but could use some eyes on the last two plugin ZIPs that were uploaded to see whether there’s any buy-in on my proof-of-concept approach to modularizing the Image Editor.

    • Tom Lynch 2:43 pm on January 29, 2014 Permalink | Log in to Reply

      I’d suggest considering talk around some of the older parts of wp-admin that have static coded HTML tables that don’t have any hooks or filters, nor use the Settings API to actually make it possible for people to develop management plugins.

    • John Blackbourn 3:11 pm on January 29, 2014 Permalink | Log in to Reply

      We should have a think about how we can start to build this new “easy first bug” report on Trac.

    • Jen Mylo 3:28 pm on January 29, 2014 Permalink | Log in to Reply

      GSoC 2014. I’ll post about it on this blog before the meeting, but would like to take a few minutes during the chat to discuss areas of interest for projects and people who’d be interested in mentoring/co-mentoring so I can get the application started.

    • Andrew Ozz 4:16 pm on January 29, 2014 Permalink | Log in to Reply

      Decide on JavaScript actions and filters, https://core.trac.wordpress.org/ticket/21170. We need JS hooks in core, either our own implementation or standardize on jQuery( document ).trigger( 'event-name' ). I know @koop had more thoughts on this but he hasn’t been around for a while.

    • tomdryan 4:17 pm on January 29, 2014 Permalink | Log in to Reply

      I may not be able to make it today, but I would like to propose creating a new task force that can look at existing plugins that would be good candidates to get moved into core. Most of the core efforts appear to be in developing new functionality, which is critical, but there are existing plugins that also fix gaps in the core feature set. The goal would be to identify those plugins and approach the authors to see what there interest level is in contributing their code to core. This approach unitizes WP excellent plug in architecture and plug in community to move WP core forward more rapidly.

      I love to hear comments about this idea (post here). I’ll try to make it to today’s meeting, but if not, I love to talk about this subject in the near future.

    • Bryan Petty 6:07 pm on January 29, 2014 Permalink | Log in to Reply

      I have an upstream update to PHPMailer in #25560. There are a couple decisions that still need to be made: include the full library, or strip it down without docs, tests, and examples (both patches are there), and a quick review of the approach on back-compat. This does need to in early in the cycle though, so about now is a good time, and hence why I bring it up now.

  • 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 6:54 pm on January 24, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Continuing the Trac component re-organization with "focuses" 

    Based on triaging a few hundred tickets in the General and Multisite components, we’ve added five components:

    • Bootstrap/Load — applies to wp-settings.php, ms-load.php, load.php, ms-settings.php, etc.
    • Login and Registration — useful for multisite, but applies to single-site too
    • Options and Meta — option.php, meta.php, etc.
    • Script Loader — WP_Scripts, WP_Styles, and script-loader.php
    • Networks and Sites — multisite only

    We also removed two components that (poorly) described the problem rather than the affected area of core. “Validation” ranged from from validation tickets to XHTML issues. HTML validation issues now belong in the affected component, like “Template” or “Administration.” “Warnings/Notices” contained tickets ranging from PHP warnings to providing feedback to users. The open tickets were moved to more appropriate components. Additionally, the remaining tickets in “AtomPub” were wontfixed and the component was removed.

    A new concept: Focuses

    We’ve also added seven new “focuses”ui, accessibility, javascript, docs, multisite, performance, and rtl. Focuses are about broad concepts and help break tickets down by specialties and skills, rather than functional areas of core. Multisite and RTL are widely general “modes” for WordPress, and each have contributors who focus strongly on those areas, but they are not well-contained “components” of core. Accessibility isn’t an area of core — it permates the entire user experience. A ticket about inline documentation should still receive the attention of developers for that area of core (say, comment.php), while those who focus on inline documentation should still be able to do so.

    “Focuses” is a new field in Trac. They’re like tags, and more than one can be assigned to a ticket. It can be queried using custom queries. And they have their own reports which we hope to properly expose and make better really soon — https://core.trac.wordpress.org/focus/accessibility.

    Guidelines to help with the transition

    The corresponding components for the new focuses have been removed. The “ui-focus” keyword has also been converted over. Overall, we gained five components but lost eight.

    This has the potential to be confusing at first and we’ll surely need to make some adjustments. Also, the component cleanup is not done yet — this is just the beginning. Here are some guidelines for how to use the new focuses.

    • The old RTL component — use the rtl focus and assign a relevant component. If it’s RTL issues with the media library, use the “Media” component. If it’s about the RTL build tools, then use the “Build Tools” component. If it’s more general, then use the “I18n” component.

    • The old Accessibility component — use the accessibility focus and assign a relevant component. For issues with the media library, use “Media.” For issues with activating a theme, use “Themes.”

    • The old Inline Docs component — use the docs focus and assign a relevant component. Hook documentation for user.php belongs in the “Users” component.

    • The old Multisite component — use the multisite focus and assign a relevant component. If it’s related to users, use “Users.” If it’s related to the loading process of multisite (choosing a site based on domain and path, etc.), use “Bootstrap/Load.” If it’s related to the installation process, use “Upgrade/Install.” network_admin_url() goes into the “Permalinks” component. get_site_option() is “Options and Meta.” The Network Admin still has its own component. (Choosing that component or “Networks and Sites” automatically assign the “multisite” focus for you.) @jeremyfelt recategorized about 110 tickets into about 15 different components.

    • The old Performance component — use the performance focus and assign a relevant component. Improving the performance of WP_Query belongs in “Query,” improving the performance of get_option() belongs in “Options and Meta,” etc.

    • The old Graphic Design component — use the ui focus and assign a relevant component. (This is probably going to be “Administration”, at least for now.)

    • The old ui-focus keyword — This has been removed. Simply use the ui focus.

    • The old JavaScript and UI components — these have not existed for some time. Use the corresponding focus and assign a relevant component.

    We may add more focuses over time. For example, the “Text Changes” component would probably make a better focus, for our wordsmiths.

    Any questions, suggestions, or comments?

    This is a summary and addendum of one section of this Wednesday’s weekly developer meeting. Logs.

     
    • Helen Hou-Sandi 7:06 pm on January 24, 2014 Permalink | Log in to Reply

      Really excited to see this happening. I think focuses will give us a really solid place to point new contributors, as not all of them (or perhaps not even many of them) have any idea what components of WordPress they might want to work on, but they do know they’re into UI making or JavaScript. I think it also conceptually just makes more sense – there are functional components of core, and there are concepts that apply to all areas of core and are not fundamentally separate, like accessibility and documentation.

    • Jeremy Felt 7:49 pm on January 24, 2014 Permalink | Log in to Reply

      Many +1s, this is great. Two things come to mind.

      1 – Is it clear (or is it true) that UI focus covers UX as well or should that still be handled via keyword? I assigned a couple to UI focus last night thinking that it would generally cover that.
      2 – We should try to distinguish what belongs in ‘Network and Sites’ vs ‘Network Admin’. I left a bunch that dealt with adding new sites in ‘Network and Sites’, but because it deals with `wp-admin/network/site-edit.php`, it may be better in Network Admin.

      • Jeremy Felt 10:48 pm on January 25, 2014 Permalink | Log in to Reply

        Another thought.

        If a cache issue is oriented around cron, should it be assigned the ‘Cache’ component with no focus, or the ‘Cron’ component with ‘Performance’ focus.

        It seems that many caching issues could be considered performance issues, but not all of them. They are closely related almost always though.

    • Xavier Borderie 12:36 pm on January 25, 2014 Permalink | Log in to Reply

      Piggybacking on a Trac-related post (sorry, and couldn’t figure if it was better suited for make/core or make/meta — since it’s WP-related, I feel it’s best posted here)…

      While talking about background updates and 3.8/3.9 being the only versions to receive any further updates, I’ve been pointed to the Trac roadmap, which still features milestones for 3.5.3 (one open ticket, for backporting reasons), 3.6.2 (one closed ticket) and 3.7.2 (13 tickets total).

      So, what should it be? Would a cleanup be needed in those tickets, or are there really remaining plans for branches 3.5, 3.6 and 3.7?

    • Umesh Kumar 6:34 am on April 17, 2014 Permalink | Log in to Reply

      Is there anyway in Tickets section to show my previous contributions? I can see the current open tickets but not the closed one.

  • Andrew Nacin 12:39 am on January 24, 2014 Permalink
    Tags: ,   

    3.8.1 auto update rollout 

    I’ll be using this thread to track the rollout of automatic background updates for 3.8.1, released earlier.

    The WP.org API is now sending update instructions to about 1 in every 128 sites. This is for all locales (not just English). 3.8.1 was released about four hours ago and I’d like to have the rollout complete in the next six hours or so. Sites check WP.org every 12 hours, but this timetable means all sites should be updating within one day of the initial release.

    So, why a slow rollout? Well, we’re monitoring a number of things that would cause us to put a pause on auto-updates, such as whether there were any critical issues in 3.8.1, whether update failure rates are higher than usual, how WP.org is handling the load, etc. The rollout is happening much faster this time than last time (3.7.1), and yes, the goal will be to eventually push out auto-update instructions immediately.

    So far, we’ve seen a 100% success rate for about a thousand auto-updates to 3.8.1, and north of 99% for one-click updates. (A reminder: a failure only means the site couldn’t update, not that it broke.) I’ll comment to this thread with more numbers as the rollout continues.

     
    • Andrew Nacin 12:45 am on January 24, 2014 Permalink

      In case you’re curious as to how this 1-in-128 is calculated, we take the first three characters of the md5 of the site’s URL and convert it to base 10. md5 is hexadecimal (base 16), so the three characters mean 4096 possibilities. It’s now serving sites where this base 10 number is 0 to 31.

      Just randomly serving an instruction every 128 requests wouldn’t work. We do it this way to ensure a site receives a consistent response with repeated API calls.

    • Jeff Rose 12:46 am on January 24, 2014 Permalink

      I’ll cop to being one of those one-button failures. My Digital Ocean test install had bad permissions. Not WordPress’s fault.

      • Andrew Nacin 12:50 am on January 24, 2014 Permalink

        What’s cool is we are actually able to break it down by error code. Bad permissions is what we’d consider a non-critical failure. The only time a “critical” failure occurs is if WordPress started to copy files over, but couldn’t verify we copied them all successfully. It’s still probable everything is fine with the site, and quite possible the update completed anyway.

        If an error occurs at any point before we start to copy files (such as a permissions error, which is a pre-flight check now), WordPress simply declines to continue. The vast majority of the less than 1% of errors we’re seeing from one-click updates are these kinds of errors.

    • Ipstenu (Mika Epstein) 12:47 am on January 24, 2014 Permalink

      Mine had a bad timing for an auto-update (yes, auto update WHILE I’m messing with files, that’s smart ;) ). Stopped messing with files. It re-ran later and worked.

    • Andrew Nacin 12:59 am on January 24, 2014 Permalink

      Bumped to one out of every 64 sites.

    • Andrew Nacin 2:36 am on January 24, 2014 Permalink

      Now at one in every two sites. Will be holding steady here for possibly a few hours.

    • Andrew Nacin 4:11 am on January 24, 2014 Permalink

      Things are looking great, so all sites are now receiving auto-update instructions. The rollout is complete. We’ve seen about 100,000 successful updates in the last few hours.

    • Andrew Nacin 8:11 am on January 24, 2014 Permalink

      We briefly dialed it back to about 75% of sites after seeing hundreds of updates a second from installs set to UTC. We’ll bump it back up soon.

    • marvila 10:24 am on January 24, 2014 Permalink

      One quick doubt. I have a monitor on my system that alerts me whenever a file is changed on wordpress and, of course, it started to show me lots of file changes.

      Is there a place to see whether the auto-update is still happening? Just to be sure the alerts are really for the auto-update (although everything seems to indicate so).

      Thanks,

      • Andrew Nacin 10:10 pm on January 24, 2014 Permalink

        Once you get a success email, the update is complete.

    • Knut Sparhell 11:39 am on January 24, 2014 Permalink

      All but one of the 35 sites I manage are localized (nb_NO), and they all have the “Advanced Automatic Updates” plugin with at least minor updates turned ON (most have ALL options ON). Some sites now has been background updated to 3.8.1 (no available updates indicated), but some has been updated to 3.8.1, but still waits for 3.8.1-nb_NO (says such update is available in the admin).

      May I expect all sites to update to 3.8.1-nb_NO, or do I have to “update” from 3.8.1 to 3.8.1-nb_NO by clicking the Update button on each site? For 3.7 to 3.7.1 no localized sites was fully updated and I had to do the last part, to nb_NO, myself.

      BTW: Tomorrow is WordCamp Norway!

      • Andrew Nacin 10:10 pm on January 24, 2014 Permalink

        If the site is running the 3.8 English package, it’ll update to 3.8.1 in English, even if the locale is set to nb_NO. It requires A) for an nb_NO package to exist, and B) for your version.php file to have $wp_locale_package = ‘nb_NO’, for it to update to the Norwegian package. I hope to make this better in the future.

        Have fun at WordCamp Norway. :-)

    • driveroll 12:53 pm on January 24, 2014 Permalink

      Hello!
      I’ve noticed these auto-updates on several of my sites, this is the first time it happens like that, automatically. I usually would prefer to update wordpress manually to take care of any possible conflicts with themes or plugins that aren’t ready for the update… I actually haven’t checked if any of these actually occurred on some of those sites. Is there a way for the auto-updates to notice if the site breaks for incompatibility reasons? Is there a way to choose not to run the auto-updates?

      Best,
      David

    • Gary Jones 2:50 pm on January 24, 2014 Permalink

      I had an interesting issue, which I can only put down to the 3.8.1 auto-update, as I’ve not edited code or content on my site for a few days.

      Others said that my site had lost its style. When I cleared my cache, yes, the style sheet link reference was broken:

      ‘/wp-content/themes//style.css?ver=2.0.2′

      That’s the child theme name missing, and the version has reverted to the parent theme (Genesis Framework).

      I cleared the Varnish Static, Varnish Dynamic and Memcache caches in SiteGround User Area, and it’s all back up fine.

      My other sites on the same SG account, with different WP installs, all running child themes of Genesis 2.0.2, all look to have gone through perfectly fine. The affected site *only* has Genesis and the child theme installed (no Twenty* themes), but then that’s the same for the other installs as well.

      I can’t explain it.

      • Gary Jones 2:53 pm on January 24, 2014 Permalink

        The full link was:

        The ID there indicates that Genesis thought the child theme was still active (as it should have been), but somehow, the name and version number couldn’t be retrieved from it (file read issue?)

      • Ipstenu (Mika Epstein) 5:36 pm on January 24, 2014 Permalink

        Is the child theme still installed on the site?

        The upgrade should NOT delete any theme files. Actually … it can’t delete theme files, unless you named the child theme ‘twentyten’ or something.

        • Gary Jones 8:06 pm on January 24, 2014 Permalink

          The child theme was still installed, and apparently not touched (correct). A clearing of the host caches brought everything back up correctly.

      • Samuel Wood (Otto) 5:46 pm on January 24, 2014 Permalink

        Could be an issue with the files for the theme being temporarily unavailable. I’d check the filesystem on that particular server (or ask the host to do so). Also make sure you have an up-to-date backup of the site.

        There is a function called “validate_current_theme” that runs on the wp-admin/themes.php page. It checks that the relevant theme files exist. If they don’t, then it tries to switch the theme back to the default theme, which is currently twentyfourteen.

        In that switch process, if the default theme isn’t there either, then a quick read of the code seems to me that it could set the theme to a blank value, which would give the results you’re seeing.

        We’ve seen this in the past on some hosting setups where the filesystem was having intermittent failures. Users would say that it “randomly” switched back to the default theme. The theme validation check isn’t nearly as aggressive as it used to be, I think, but this is one possible way that it could happen.

        • Gary Jones 8:26 pm on January 24, 2014 Permalink

          That consequential explanation sounds viable.

          Lots of the files (in wp-includes, theme files, etc.) of the affected site are now 0755. As most files weren’t touched, that is likely from the initial install via Softaculous in cPanel, but it presumably rules out any file permissions issue.

          I’ve just checked the version.php of the other installs (the affected site was the root site, while others are add-on domains), and they still say 3.8, so they actually haven’t been touched.

          What’s more fun, is that version.php of the affected site says 3.8.1, yet I’m still getting an update notification in the WP admin.

          I’ve got one 3.8.0 install where the theme files are 0644 and folders are 0755, with twentyfourteen also present, another the same but without twentyfourteen present, and a third where the theme files are 0755. I’ll keep track and see if any break.

          I’ve commented out define( ‘WP_AUTO_UPDATE_CORE’, false ); which was added to wp-config.php by SiteGround Autoupdate, so that WordPress handles things itself.

          • Andrew Nacin 10:08 pm on January 24, 2014 Permalink

            validate_current_theme() won’t do anything unless you visit wp-admin/themes.php. This appears to be a hosting problem.

    • Gary Jones 2:54 pm on January 24, 2014 Permalink

      link rel=’stylesheet’ id=’child-theme-css’ href=’/wp-content/themes//style.css?ver=2.0.2′ type=’text/css’ media=’all’

    • KirkM 3:59 pm on January 24, 2014 Permalink

      I’m running 2 WordPress powered sites, the first being a rather ancient (going on 8 years on original install) but still viable personal blog and a newer (4 years) test site. The old personal blog updated automatically updated to 3.8.1 from 3.8 without a problem but I had to manually update the test site. The test site via the admin Update page. It did show that the 3.8.1 update was available though. Perhaps the auto-updates hadn’t gotten around to the test site yet or maybe the security plugin is keeping the auto-update from happening (see list of plugins for the test site). I have no way to be sure. No big deal though.

      Just for information purposes, the old personal blog site has the following plugins activated:

      Akismet
      All In One SEO Pack
      Artiss Transient Cleaner
      Better WP Security
      BruteProtect
      Clean Options
      Google Analytics for WordPress
      Lightbox Plus ColorBox
      P3 (Plugin Performance Profiler)
      Spam Free WordPress
      Subscribe to Comments Reloaded
      WP Revisions Control
      WP Robots Txt
      WP Super Cache

      And I’m running Weaver II Pro as a theme.

      The test site has the following plugins activated:

      Acunetix WP Security
      Akismet
      Clean Options
      Lightbox Plus ColorBox
      WP-DBManager

      This site also runs the Weaver II Pro theme.

      So, no problems here really. No errors seen in any of the error logs for personal blog in regards to the auto-update. Considering how old the WordPress install is and what I’ve put the site through over the years, I’m glad to see the auto-update work so well. I do keep the site in good repair but still…great job to all!

    • Debbie Doglady 4:05 pm on January 24, 2014 Permalink

      I couldn’t do the one-click update. Got at “500 Internal Server Error”.

    • Xavier Borderie 4:41 pm on January 24, 2014 Permalink

      Automatic background updates is still not quite well-known among regular users: we (WPFR) received one e-mail from the owner of the (unknown to us) owner of a permanent makeup website running WP, about having received “quite a strange message”, with a copy of the “Congratulations on your auto update!” e-mail, and a question: “How come WordPress feels the right to update my site without my knowledge?”

      I told him everything about the feature, plugins to disable it and links to the Codex, and he answered with:

      Well let me thank you for showing to us that you can remotely control our site without our permission and without having been personally given access to the administration.

      Free software does not rhyme with abuse of rights.

      One final e-mail from me reassuring that no one ever touched his site, that it was all automatic and everything. No answer since then.

      But still. If one guy takes the time to complain about it, that means heaps of others are confused about it. It might be warranted to put more informational text in the e-mail sent on successful and failed updates.

      • Xavier Borderie 5:05 pm on January 24, 2014 Permalink

        Aside 1: his website is not even live yet, it’s apparently a test version for a forthcoming new version of their previously full-HTML site. I can understand the fury.

        Aside 2: a commenter on the FR announcement says he hopes his 3.6-using site (kept this way because it uses a 3.7+-incompatible plugin) will not be “brutally” updated to 3.8.1, and fears about update failures when the webmaster is unavailable for days (holidays).

        It’s all about education and good copy.

      • Ipstenu (Mika Epstein) 5:43 pm on January 24, 2014 Permalink

        Sadly this is an application of Zeno’s dichotomy paradox in action. We cannot ever alert 100% of the world.

        I would suggest you do a blast email (or a post on your site) explaining this to your customers. We did that at DreamHost and had a crazy small number of people who even blinked when they were upgraded. We told them it was coming beforehand, pointed out they COULD opt out, but we suggested they would not, and provided directions. The majority of people were fine with it (though I admit we already do upgrades for anyone who used our one-click upgrader), and the few who were not were glad to have the information on how to opt out.

        • Xavier Borderie 7:53 pm on January 24, 2014 Permalink

          Ah, but they’re not customers of ours :) I’m the fr_FR translator, and WPFR is the non-profit entity for that hosts the FR support forum and organizes the Paris WordCamp, so there’s no way we can e-mail everyone. That being said, we could tweet and write a blogpost about this beforehand, true, true… Thanks for the tip!

    • rossagrant 4:44 pm on January 24, 2014 Permalink

      Hey Andrew!

      Just a quick question.

      I woke up to an email this morning from my staging site saying that it had been updated to 3.8.1 automatically.

      My production site which is on the same server and is basically a duplicate of staging didn’t auto-update.

      I was already logged into my dashboard, hit refresh and then saw the manual update flyout. I hit it and it updated no problem.

      Another WP install on a sub-directory of my production site DID update automatically, so 2 out of the 3 sites on the same server basically.

      Is there anything I should look out for as to why the main production site didn’t auto-update?

      What are the triggers for the update? Did it matter that I was logged in as admin at the time?

      Would love to understand what triggers this.

      Thanks :)

    • ElleJG 7:09 pm on January 24, 2014 Permalink

      Holy komoly. Call me a control freak but I don’t like arbitrary updates. An auto update from 3.8 to 3.8.1 came as a complete surprise!

      Can someone confirm that this can only happen within versions? As in I won’t someday find that all of my sites have jumped from 3.8 to 3.9 without me deciding it was safe to do so? And should I decide that I would like to update all by my little self when I know it won’t break anything – how do I do that?

      Until every WP plugin developer is forced to update along with WP core – which can’t and won’t happen – I personally think auto updates are a bad idea. But hey, that’s just my opinion. :)

      Thanks guys. Would appreciate the info. I’m already trying to figure out a site problem today, and having this happen at the same time did not make me happy.

    • stevenhong 8:28 pm on January 24, 2014 Permalink

      Ok. My website broke based on this automatic update. I was on my site before lunch, and came back and when I hit my site again, it was in maintenance mode. Looked at the timestamp of the file and it was 8 minutes ago. Deleted .maintenance, and the site is broken.

      Fatal error: Class ‘WP_Query’ not found in /home/steveho/public_html/wp-settings.php on line 251

      is all I get, both on the front end, and when I try to log in via wp-admin.

      I thought it might be a conflict in plugins, so I went and removed all active plugins (via phpmyadmin) and it still doesn’t work.

      What did work was for me to copy all the 3.8.1 files onto my server, and follow the install instructions. Entire site is back and running with all the data intact.

    • keeperbay 9:44 pm on January 24, 2014 Permalink

      UPDATE. Have installed the “Disable Auto Update Patch” on 45 WordPress blogs today.
      Have 120 more to go.
      More orders rolling in.
      THANK YOU WP CORE!!! Once again you have kept me gainfully employed. I’ve never received so many orders in one day.

    • Andrew Nacin 10:03 pm on January 24, 2014 Permalink

      IF YOU NEED ASSISTANCE, USE THE SUPPORT FORUMS. I’m closing comments on this thread.

      http://wordpress.org/support/

    • keeperbay 10:20 pm on January 24, 2014 Permalink

      Here are the problems:
      Problem #1. WP Core thinks that posting a link to Codex will help, but Most Bloggers Know Nothing About Code!

      Problem #2. Auto Updating assumes that all plugins are going to automatically work with the new version of WP – When has that EVER Happened?

      Problem #3. When Problem #2 occurs, those bloggers who fall into the category of Problem #1 are stuck paying to have their sites restored, fixed or rebuilt.

      • Andrew Nacin 10:51 pm on January 24, 2014 Permalink

        1. Bloggers shouldn’t need to rush to update their site to keep it secure and stable. If WordPress can take care of that, we should take care of that. They shouldn’t need to even go to the Codex for this. It “Just works.”

        2. We don’t break plugins in minor versions. Auto updates are for minor versions. We take a lot of precautionary steps. All we’re doing is fixing a few bugs and any security issues.

        3. I’ve yet to see a site break due to an auto update.

    • rossagrant 10:55 pm on January 24, 2014 Permalink

      @nacin used the update tester on production and all is well – thanks! :)

  • Andrew Nacin 11:58 pm on January 22, 2014 Permalink | Log in to leave a Comment  

    WordPress 3.8.1 Release Candidate 

    Greetings! WordPress 3.8.1 RC1 is now available for final testing. Here’s a zip, or you can set the WordPress Beta Tester plugin to “point release nightlies.” (Trunk, which is 3.9-alpha, also has all of these fixes.)

    We hope to get this released to you as early as tomorrow, January 23. Once 3.8.1 is released, we’ll wait a few hours before turning on automatic background updates, which will then be gradually rolled out over about a day.

    It’s been nearly six weeks since 3.8, which has seen more than 9 million downloads. It’s now time to kick 3.8.1 out the door, especially since we’re now ramping up WordPress 3.9 development.

    Feel free to leave here any questions or comments about 3.8.1 in general, though if you have found a bug in WordPress, please report them on Trac.

    Below is a complete changelog. Each section is roughly ordered by priority. Also on Trac, you can also find the full changelog, a diff of the changes, and the list of 3.8.1 tickets.

    Embedding tweets:

    • Switch Twitter oEmbed to SSL due to a Twitter API change that broke embedding across all WordPress sites. [26969], #26844.

    WP_Query fixes:

    • Fix category handling in pre_get_posts when pretty permalinks are in use; fix handling of taxonomy queries in get_queried_object(). [26946], #26627, #26634.
    • Avoid a fatal error in wp_reset_postdata() if $wp_query global is not set. (Also affected 3.7.) [26951], #26775.

    Themes screen fixes and improvements:

    Fixes for the new dashboard design:

    • Fix the “dead zone” on submit buttons, so they actually click. [26998], #26700Chrome bug.
    • Prevent the admin color scheme from previewing when editing another user. [26937], #26607.
    • Update the styles for the media modal when used on the frontend. [26992], #26677.
    • Add a contrasting border to admin feature pointers. [26970], #26689.
    • Update Dashicons to latest. (The Updates icon now points in the right direction.) [26965], #26518.
    • OCD alignment updates on the Updates screen. [26938], #26699.

    Responsive admin fixes:

    • Prevent widget controls from going off the screen when editing extra-wide widgets on small devices. [26964], #26701.
    • When moderating comments, make sure the comment author is always visible. [26961], #26618.
    • Responsive improvements to submenus in the toolbar. [27009], #26720.
    • Improve keyboard accessibility for the admin menu when in responsive mode. [27010], #26639.
    • Prevent the toolbar from wrapping to a second line on narrow screen (multisite only). [26949], #26537.

    The new dashboard widgets:

    • Quick Draft widget: Don’t ignore default comment status and ping status. [26960], #26722.
    • At a Glance widget: Don’t link to Pages or Posts for Authors or Contributors (respectively). [27001], #26574.
    • Quick Draft widget: Break long words in Quick Draft content to prevent overflow. [26948], #26658.

    Miscellaneous:

    • Media: Fix directory permissions for new media upload directories. [26927], #26781.
    • RTL: Force LTR direction for code inputs. [26954], #26666.
    • RTL: Make sure half-stars in star ratings are filled on the correct side. [26953], #26814.
     
  • Andrew Nacin 9:03 pm on January 22, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Possible tasks for WP 3.9 

    During last week’s dev chat, we decided on a schedule. We also chatted about a major focus in 3.9 on improving workflow for new and current contributors alike. If there are further suggestions on changes we can make to workflow to make core easier to contribute to, let us know.

    Below is a rundown of what features/enhancements/ideas were discussed as possible for 3.9, including potential volunteers to take point on different tasks. This is all tentative. Thanks @DH-Shredder for compiling this.

    In today’s chat, let’s continue to build this out. If you have something you’d love to work on during the release, join us!

    Widgets

    There are two widget-related feature plugins to review: Better Widgets and Widget Customizer. Decisions on what we’re merging should come by next week, per the schedule. Expect a post from @shaunandrews soon explaining both and requesting help reviewing them.

    TinyMCE improvements (@azaozz, @gcorne, @lgladdy)

    • TinyMCE 4 inclusion and troubleshooting
    • Improving editing/positioning images after insertion into the editor

    Editor-related media improvements

    • Bringing the image editor into the media manager (@melchoyce, @johnbillion)
    • Allow a user to drop an item for upload on the post screen. This would then open the media modal (as an initial first step).

    A better themes experience, part 2 (@matveb)

    • Taking our new experience to the theme installer (this may be started as a plugin)
    • Supporting multiple screenshots, left out of 3.8
    • Backbone routing and subview backend improvements

    Improved audio/video support (@wonderboymusic) (see this post)

    • Playlists, subtitles, metadata generation
    • Media manager documentation

    JavaScript and CSS

    Miscellaneous

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

      RE: Grunt tool for patches

      It now is working for:

      patches you have in your local repository
      when you enter a ticket number
      when you enter a ticket url
      when you enter an attachment url
      when you enter a raw attachment url

      My next step is to add some more tests and write up documentation. Once that is in place, I would love to have some extra help testing. I most likely have some error messaging to improve and the like. I’ll post on make/core within the next week with info on how to help test/get involved.

      development is happening at https://github.com/aaronjorbin/grunt-patch-wordpress

    • Andrew Nacin 3:04 am on January 23, 2014 Permalink | Log in to Reply

      Some more things to add, from the meeting today:

      • @drewapicture is doing a mockup of a potential new tools screen he’s been talking about.
      • @gcorne is looking into syncing caret positions between the visual and text editors.
      • @obenland and @helen discussed including markup changes as part of the admin settings audit proposed by @jenmylo and @melchoyce. @Ipstenu and @ryelle are additionally interested in the UX side of things.
      • @helen proposed looking into better insert from URL handling in the media modal. This also ties into oEmbed insertion, and oEmbed previews / MCE views, which @gcorne has mentioned before.
      • @adamsilverstein brought up a post meta revisioning API. It happened in 3.6 but it was baked into post format UI stuff, and got pulled. It should be attempted again.
      • @TomAuger will be helping with image editing UIs, and posted work he’s been doing on #21811.
      • Manuel Schmalstieg 3:12 pm on January 23, 2014 Permalink | Log in to Reply

        > @gcorne is looking into syncing caret positions between the visual and text editors.
        Wow, that’s a wonderful idea! Improved preservation of whitespace when switching between visual/text modes would also be a major editing help.

      • Jen Mylo 5:46 pm on January 27, 2014 Permalink | Log in to Reply

        As I hear it, @ryelle is actually interested in the dev & API side of things.

    • RicaNeaga 10:25 am on January 23, 2014 Permalink | Log in to Reply

      So no plans in 3.9 for mysqli via #21663? Or hopefully full and official MariaDB support? Please reconsider, many are not happy (right now) to see only MySQL mentioned in the wordpress requirements page.

    • StyledThemes 12:54 am on January 24, 2014 Permalink | Log in to Reply

      Speaking of widgets, and something I am really amazed this is not part of the core…the ability to disable widget titles with each widget. There are many times where the title is needed for reference in the admin, but needs to be removed from the front-end. That’s one thing…the other would be a method to publish widgets to select pages/posts without having to install a plugin for this. Cheers!

    • Pippin Williamson 4:05 pm on January 24, 2014 Permalink | Log in to Reply

      I’d love to see the password generator enhancements get considered again, https://core.trac.wordpress.org/ticket/24633 – It’s mostly waiting on additional feedback. It was originally slated for 3.8 but then got pulled due to lack of feedback.

    • RENAUT 10:56 am on February 4, 2014 Permalink | Log in to Reply

      for TinyMCE improvements ability to deactivate fullpage icons and shortkeys for plugins using tinymce (in the simplest way) thank you

  • Andrew Nacin 8:05 pm on January 15, 2014 Permalink | Log in to leave a Comment
    Tags:   

    WordPress 3.9 planning 

    We were supposed to discuss WordPress 3.9 during the weekly meeting last week, but in the absence of a decision on a release lead, and with a lot of 3.8.1 things to get through, it got pushed to today. 2100 UTC, #wordpress-dev (so, in an hour).

    I’ll be the release lead for WordPress 3.9. Expect some familiar faces helping me out, including Andrew Ozz, who will be overseeing all of the TinyMCE work already underway this cycle; Helen Hou-Sandí, who will be spending most of her time working on and advising ongoing feature plugins efforts; Sam Sidler, who will be helping with project management; and Mike Schroder, who will be backing me up for this release.

    Today we’ll be:

    • Setting a schedule. The tentative 2014 roadmap decided in December slated 3.9 for April 15. That’s 90 days from now, and sounds good to me.
    • Reviewing feature plugins. Lots of things in progress — let’s take a quick look.
    • Brainstorming on what this release should be focusing on. There are plenty of possibilities when it comes to iterating on existing features (especially those added in the last five releases — the customizer, media, audio/video, theme browser, admin UI), general bug-fixing, long-standing architecture and API improvements, and such.
    • Discussing changes to workflows. Changes to Trac, ticket reporting, re-doing our components tree, a new Git mirror, and such make this release look a lot like 3.7, when we kicked off the new core development repository. We could use continual help to identify how we can make it easier to contribute, break through bottlenecks, etc. We also need to tag some tickets as good-first-bug!

    Hope to see you today. Have any idea, thought, or suggestion about 3.9 or for today’s meeting in particular? Please leave a comment so I can prepare for it. Talk soon.

     
    • sbruner 8:12 pm on January 15, 2014 Permalink | Log in to Reply

      Good to have you leading 3.9. Here’s a small patch that would make a big impact. Expanding on the custom template for database failures: https://core.trac.wordpress.org/ticket/25703

    • Jen Mylo 8:24 pm on January 15, 2014 Permalink | Log in to Reply

      Settings! Discussion Settings as a starting point. We didn’t touch them in 2.7, or 2.8, or 2.9, or ever since before I was even around core. They are super-confusing and seemingly contradictory with the checkboxes for options that appear mutually exclusive. I’d like to take point on redesigning that settings screen so that choosing your comment options are as easy as leaving a comment. As part of this project, we’d take a look at other settings screens and clean up any untidy bits/make them consistent. In the absence of the long-awaited settings API, I’d like this release to be the one where don’t let the perfect be the enemy of the better re settings and we switch from tables to css. If there’s a dev or two that wants to hit this with me (no codename, just “Improve Settings”), that’d be great.

      • Helen Hou-Sandi 8:31 pm on January 15, 2014 Permalink | Log in to Reply

        I’ve been thinking about this a fair bit recently, from two sides:

        1. Creating reusable form CSS, and then using that to switch off of tables on the settings screens.
        2. What are “Settings” vs. “Preferences” vs. “Options”? Can we do a sorting activity or something similar?

        As far as the comment moderations settings go, I think there’s a good starting point here, just needs somebody to weigh in on the option naming and upgrade routine: #23233

      • Ipstenu (Mika Epstein) 8:42 pm on January 15, 2014 Permalink | Log in to Reply

        Network Settings: The unholy cluster of “Shove everything on one screen and pray” would be nice to fix.

        • Jen Mylo 9:32 pm on January 15, 2014 Permalink | Log in to Reply

          Yep, that would fall under making other settings screens consistent and better. I started with Discussion as the pitch because it was driving me crazy the other day.

      • Manuel Schmalstieg 9:10 pm on January 15, 2014 Permalink | Log in to Reply

        Talking of Discussion Settings – I remember reading a ticket that proposed an easy function for disabling entirely all commenting functionality on a site (and thus removing all reference to comments from the admin UI). But that proposal disappeared from my radar and didn’t re-surface, can’t find the Trac entry anymore. Was I dreaming?

      • Konstantin Obenland 10:41 pm on January 15, 2014 Permalink | Log in to Reply

        I’d be happy to help out with creating patches!
        Would this project also include the custom header/background settings pages?

        • Nick Halsey 1:10 am on January 16, 2014 Permalink | Log in to Reply

          My guess would be no, but I’d love to separately get #25569 and #25571 (and their many media-related prerequisites) done in 3.9 so that we could streamline and eventually expand those features. I think leveraging the customizer would be a good way to cut down on the need for settings pages in general.

      • Nick Halsey 1:05 am on January 16, 2014 Permalink | Log in to Reply

        I’d love to help with this as well. I’ve been looking through the different settings pages, and realized that we could conceivably remove Reading by merging the rest of those controls to the customizer, removing them, and/or moving a couple to a different page. Looking more closely, there isn’t much in Writing either once post by email is finally removed. Permalinks could take up much less space too. Evaluating which options we really need and also addressing their organization could help reduce both the number of options and the number of pages, which seems like a solid/tangible goal. At the moment, though, Discussion is most certainly the worst.

      • Stefano Aglietti 8:31 am on January 16, 2014 Permalink | Log in to Reply

        On Settings removing the WordPress address and the site address leaving them just as wp-config option. This 2 settings are totally misunderstanded by tons of user and in italian forum there is question about what happened cause someone changed them “by mistake” or cause he/she was thinking to make something different

    • Andrew Nacin 8:26 pm on January 15, 2014 Permalink | Log in to Reply

      With 3.5, 3.7, and 3.9, I seem to have a propensity for leading odd-numbered releases. However, this pattern also requires the initial number to be odd. :-) Already promised my wife 4.1 is out of the picture. Just saying.

    • Mike Schroder 8:27 pm on January 15, 2014 Permalink | Log in to Reply

      Excited to help out! Looking forward to the brainstorm session today, to get us on the way.

    • Gregory Cornelius 8:36 pm on January 15, 2014 Permalink | Log in to Reply

      Excited to be able to help out full-time this cycle.

      While not formally a feature-as-a-plugin, I created a little plugin to play around with rendering the gallery shortcode output inside the Visual editor. There is some overlap with the Front-End Editor plugin. I also want to experiment with wp.mce.view and see if we can create some sort of abstraction for bringing more inline editing of shortcode blocks into the Visual editor or at least some sort of easy to create preview mechanism.

    • Ozh 8:56 pm on January 15, 2014 Permalink | Log in to Reply

      Dudes, I already planned everything for you a couple months ago: http://planetozh.com/projects/wp-core-team-agenda/

    • Ansel Taft 10:27 pm on January 15, 2014 Permalink | Log in to Reply

      As someone who’s learning PHP, I’m excited by the good-first-bug! trac ticket designation, so maybe I can contribute to the CMS I love… though the core team will need to heavily scrutinize the code we first-timers push up, and feedback welcomed.

    • scotthack 11:21 pm on January 15, 2014 Permalink | Log in to Reply

      Guessing there is already a plugin that could be evaluated and promoted to look at. But I’d like to see a CPT and taxonomy manager ( with an import feature ) that will help keep that functionality OUT OF THEMES. That way if someone purchases a theme from a theme shop, they can import the CPTs and taxonomies and get the functionality that the theme is expecting. But if they change the theme, that data won’t go away.

    • markpack 11:41 pm on January 15, 2014 Permalink | Log in to Reply

      One tiny suggestion: it would be great to restore the option there used to be when adding a photo to a post to also make it the featured photo with just one tick box on the same add photo screen. It adds an annoyingly large number of extra clicks and a delay to have to add the photo to the post and then make it a featured image separately.

    • leemon 3:00 pm on January 16, 2014 Permalink | Log in to Reply

    • Dave Navarro, Jr. 1:31 am on February 18, 2014 Permalink | Log in to Reply

      I’d love to see links fixed so that jQuery Mobile can be used without going through hoops.

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