Make WordPress Core

Tagged: agenda Toggle Comment Threads | Keyboard Shortcuts

  • John Blackbourn 7:48 pm on October 15, 2014 Permalink
    Tags: , agenda   

    Agenda for October 15th dev chat 

    According to the 4.1 release schedule, we should be merging in our planned feature plugins today. Strictly the only feature plugin we have scheduled for 4.1 is the user session management UI though, so I’m not too worried.

    Today’s meeting we’ll cover:

    • Twenty Fifteen; what’s in, what’s left, what needs testing.
    • Weekly bug scrubs starting Friday.
    • Status of the plugin install/update UI improvements.
    • Volunteers for some mobile media testing.
    • Updates from @helen @markjaquith @boonebgorges on their respective focuses.
    • Any other business.
  • John Blackbourn 7:30 pm on October 8, 2014 Permalink
    Tags: , agenda   

    Agenda for October 8th dev chat 

    Agenda for today’s dev chat (October 8 2014 20:00 UTC) in #wordpress-dev.

    • Updates from @helen and @markjaquith on post/user dropdown performance, and editor focus improvements, respectively. Anything needed from either party?
    • Updates from @boonebgorges on his query enhancements. Any pending blockers, feedback, testing, etc needed?
    • Updates from myself, @johnbillion, on the session management UI feature plugin.
    • Let’s chat about improvements to the plugin and theme install/updates UIs. @nacin and @melchoyce
    • Status of ticketing and beginning to address mobile media management concerns. @rboren might not be around for the meeting. What’s ticketed? How can we progress this?
    • Other areas that people are focusing on and want help with.
    • 4.0.1.
    • Birthday wishes (if applicable).
    • Pascal Birchler 11:11 am on October 9, 2014 Permalink | Log in to Reply

      It feels like WordPress 4.1 is already coming along nicely. And you even put birthday wishes on the agenda. Cool! I’ll definitely attend the dev chat on my birthday :)

  • John Blackbourn 5:48 pm on October 1, 2014 Permalink
    Tags: , agenda   

    Agenda for October 1st dev chat 

    We’ll be discussing 4.1 in today’s dev chat (October 1 2014 20:00 UTC). The release schedule can be found here.

    Here’s the agenda:

    We won’t be touching on 4.0.1 this meeting unless something specific comes up (nacin will be on a flight). An RC for 4.0.1 is expected by the end of the week.

    Anything else you’d like to discuss? Leave a comment.

    • Marko Heijnen 5:53 pm on October 1, 2014 Permalink | Log in to Reply

      Is there something to discuss for the Taxonomy roadmap?

      Also with a RC for 4.0.1, we can expect a release for early next week?

    • Spencer Hill 6:04 pm on October 1, 2014 Permalink | Log in to Reply

      I’d like to do, or assist with, the mockups for the improved UIs for installing and updating Plugins, Themes, Core, etc…

    • Dovy Paukstys 6:31 pm on October 1, 2014 Permalink | Log in to Reply

      So, hypothetically, why don’t we commit to core the ability for a theme to suggest/require a plugin to be installed? IE, TGM Plugin Activation could be just part of core… I know WP.com doesn’t use it, but theme devs almost everywhere else do. Just an idea.

    • Andrew Ozz 6:36 pm on October 1, 2014 Permalink | Log in to Reply

      I’ll be continuing on refining wpView. The TinyMCE devs are going to implement it (or something similar) natively. If that happens in the next few weeks we will have to switch to their implementation. Also on editor-scrolling (DFW merge?) with @avryl and @markjaquith #29806.

      Another focus for 4.1 would be on fixing and improving all things on mobile browsers. Starting with the media modal, there are still a lot of relatively “low-hanging-fruits” to be picked and a lot of smaller changes that will have big UX impact.

      Another thing that needs fixing/updating is the custom menus “back-end”, particularly how menus are being saved.

      • Avryl 6:58 pm on October 1, 2014 Permalink | Log in to Reply

        Other editor related things:

        • We could consider adding some UI to insert content inline, as previously explored by CEUX (content blocks) and the FEE. I’m working on a separate plugin right now that lets you insert content anywhere, not just an empty paragraph.

        Add a block

        • We could also consider adding some more inline tools when you select certain elements such as an image (and later maybe for text too, but this would be a good start). Example:

        Add a block

        • Explore how we could make the sidebar less distracting and better, especially the “Publish” box, perhaps a bit like https://wordpress.com/post/?

        Add a block

      • Nick Halsey 7:28 pm on October 1, 2014 Permalink | Log in to Reply

        Re: menus, other than a couple of minor tweaks in the APIs, I definitely think it would be worth waiting for the Menu Customizer to fix the scaling issues with menu-saving. We need to completely re-think the approach there, and leveraging the live-previewing and backbone-like JS frameworks that the Customizer provides makes things inherently modular and scalable, per my GSoC posts here.

    • Konstantin Obenland 6:37 pm on October 1, 2014 Permalink | Log in to Reply

      Very brief update on Twenty Fifteen theme from @obenland.

      @iandstewart will be around, so he’ll do the honors. :)

    • Dominik Schilling (ocean90) 7:06 pm on October 1, 2014 Permalink | Log in to Reply

      Because I can’t attend todays meeting, some words here:

      I will continue my work with the language switcher/site language. Most work will be around #29395 with some API improvements and I hope to do some language pack improvements too (like installing necessary plugins).
      Per-user languages are out of scope for 4.1, we need a solid framework first.

    • Nick Halsey 7:52 pm on October 1, 2014 Permalink | Log in to Reply

      I’d like to discuss some of the Customizer improvements that we’re slating for 4.1 (also, reminder that we have weekly meetings in Fridays, per the make/core sidebar). We need help in several places:

      • Internal JS API work, which is a prerequisite for almost everything else, and very high priority: #28709, #29572. Need dev feedback for one, @westonruter is working on the other.
      • Re-doing media in the Customizer: #21483
      • Killing off the Appearance->Headers and Appearance->Background admin pages, emphasizing the improved versions in the Customizer along with Twenty Fifteen’s focus here.
      • Re-thinking the Customizer on mobile: #28784

      Particularly on the last one, it would be good to get a few UI/UX people working on it, as well as to do extensive device testing, along the lines of what @ryan is doing elsewhere in core. There are several other things we’re slating, but those are the big ones that need attention and general feedback.

    • Ryan Boren 10:00 pm on October 1, 2014 Permalink | Log in to Reply

      My first pass meeting notes.

    • Apiweb 12:31 pm on October 2, 2014 Permalink | Log in to Reply

      #29325 – Use tag in Post Date

      I think it would be interesting to start using Moment.js and MomentTimezone to start displaying dates in “format / timezone” corresponding to the site visitor.

  • Andrew Nacin 7:56 pm on September 26, 2014 Permalink
    Tags: , agenda,   

    Announcement: 4.1 kickoff meeting this Monday, September 29, at 1400 UTC. This is an unusual time for us that we’d like to try out. The Wednesday meeting (October 1) is still on for 2000 UTC as well.

    Around the world:

    • 10am U.S. Eastern (GMT-4), 7am U.S. Pacific (GMT-7).
    • This is midnight Tuesday for east coast of Australia (GMT+10).
    • If you’re at WordCamp Europe’s contributor day (GMT+3), this will be 5pm.

    More to come with regards to 4.1 over the weekend, but I wanted to make sure everyone saw this (as it was decided at this week’s dev meeting). But please think about what you’d like to work on or what you’d like to see. This comment thread is also open.

    This initial post said Monday, September 28. Monday is September 29, and that’s the day of the meeting.

    • Casey Driscoll 8:05 pm on September 26, 2014 Permalink | Log in to Reply

      I think you got an ‘off-by-one’ there buddy.

    • Marko Heijnen 9:32 pm on September 26, 2014 Permalink | Log in to Reply

      I would like to see more and better support of dealing with images like generate missing image sizes on the fly, zoom support, filters etc. See for some code https://github.com/markoheijnen/Improved-image-editor.

      Also I would love to help out streamlining the taxonomy APIs but no clue what the current status of the roadmap is.

    • Jeff Chandler 10:11 pm on September 26, 2014 Permalink | Log in to Reply

      I found this out thanks to a reader. The text for chat.freenode.net is wrong. It should be webchat.freenode.net http://webchat.freenode.net/ for the web-based client.

      • Andrew Nacin 10:12 pm on September 26, 2014 Permalink | Log in to Reply

        chat.freenode.net is the IRC server. I guess we could link it to webchat.freenode.net.

        • Kim Parsell 1:42 pm on September 28, 2014 Permalink | Log in to Reply

          There is a link to webchat.freenode.net in the blue box at the top of the main page on make/core, in the Weekly Meetings section. Does it need to be added anywhere else?

    • Jeff Chandler 11:07 pm on September 26, 2014 Permalink | Log in to Reply

      Ohh, my bad. That would have been my second guess. Anything that makes it easier to participate!

    • Joseph 2:04 pm on September 27, 2014 Permalink | Log in to Reply

      I see there has been a huge discussion about the “WordPress Heartbeat and heavy admin-ajax.php usage” here http://www.inmotionhosting.com/support/website/wordpress/heartbeat-ajax-php-usage Wish this is easily adjustable with WordPress core.

    • bvl 2:17 pm on September 27, 2014 Permalink | Log in to Reply

      I would like WordPress to be natively be multilingual, with preferably these abilities:

      1. neglectable (performance/storage) impact for non-multilingual sites

      2. makes any plugin or theme – out of the box – multilingual ready as long as it adheres to current (WP 4.0) best practices regarding i18n.

      3. can group posts as language alternatives (needed to quickly find post translations)

      4. if no language is specified on a table row it applies to any language

      5. back-end can be single-language while front-end is multilingual.

      6. regardless of the language set for the back-end, the user can switch the edit-language to any of the supported front-end languages.

      7. slugs are unique per language

      8. promote as best practise: put admin (back-end) specific translations in separate translation files

      The sought after solution would allow the developer for example to define an option, custom field or term to be language specific (default) or not.

      Even if a theme or plugin wouldn’t be built to be multilingual ready it would still be.
      The editing user would simply set the edit language (in admin bar) to the required language and WordPress would automatically retrieve/save the correct data based on the current editing language and the defined language specificness.

      Of course all relevant API functions and hooks would need to incorporate the language into their logic too. For example, this way when a non-multilingual prepared plugin retrieves an option value it would get a language specific value!

      Many theme and plugin developers who only used to and familiar with single language sites don’t understand the need for and problems and needs of multilingual sites. This probably won’t change for the majority of them. They don’t want to put the extra afford in to find out what’s needed and how to implement it. The ones that do are put off by the lack of a standard. With the above proposed solution they wouldn’t even have to! It would work out of the box!

    • Michel - xiligroup dev 7:53 am on September 28, 2014 Permalink | Log in to Reply

      @ bvl and @nacin
      I fully agree with most of your notes about multilingual features. As data-designer, author of free xili-language plugin since more than 5 years based on taxonomy and other core wp features (no new tables, no cookies,…) only cms data model… i can say that few features in WP core (api, filter) (and time) will be necessary to ship an easy to use plugin. Based on the initial data model, this architecture remains reliable during the succession of version since 2.3 to 4.0 and the amazing power of the wp core (loop and UI). But we must be also prudent about the users target – multilingual activated in a simple single instance of WP (targeted by xili-language) or multilingual activated on a multisite installation (purpose of xili-language ms or multipress -MultilingualPress- by a german group.

      More technically for @nacin

      Plugin xili-language was the first to follow the WP data model and to use a taxonomy (language).
      It is because WP and a theme is translation ready that xili-language can works.
      Since more than 5 years, it was an opportunity to discover gradually the core of WP and to use as possible the core available functions especially for the dashboard side or CPT or CT.

      Without commenting yet, I will list below some subjects that can improve internationalization (and bi/multilingual opportunities):
      A) textdomain
      creation of a default text domain for theme:
      Example: default comment form and WP_locale class use default domain and need to be re-instanciated to be core independant and current language dependant.
      Because (recently and not for all) declared textdomain et language files sub-folder are not reliable, plugin continue to detect these datas.

      B) .po / .mo files (theme and plugin)
      as for core since recently, separation of file for frontend and admin sides. Adding a text domain when data saved in options can be translated.

      C) WP_table taxonomy columns in admin UI:
      If you add a column, no problem to adapt the content of a cell.. But first default columns (like description) are not filterable. So impossible to, per example, add a displayed translation.

      D) taxonomy and xili-tidy-tags
      As you can imagine, I read and read again taxonomy.php.
      The original approach, of xili-tidy-tags (one of the three plugins in xili-language trilogy) is that: it is possible since 2009 to create a taxonomy of terms. It is not exactly like alias features used also in multilingual data model. It need few special queries to do that type of grouping/taxonoming of terms… As wished formerly in tracs, I think it can be a very powerful tool if these queries (with good rules) can be incorporated in Core.

      I am ready to work and detail subject by subject here described or those of the internationalisation topic…

  • Mark Jaquith 5:20 pm on September 10, 2014 Permalink
    Tags: agenda,   

    9/10 Agenda 

    WordPress 4.0 “Benny” is out the door, warming hearts, flying off shelves, and many other euphemisms besides. After a brief respite to enjoy our success and a job well done, we turn our eyes to the future: 4.0.1, 4.1, and more.

    • Ionel Roiban 5:31 pm on September 10, 2014 Permalink | Log in to Reply

      Congratulations, everyone!

    • Stephane Daury (stephdau) 5:43 pm on September 10, 2014 Permalink | Log in to Reply

      4.1 release lead nominations: I’m going to go right in crazy mode and suggest @rmccue.
      Note: I have not discussed that with him, so it’ll catch him by surprise.
      My logic is as so:

      • in May, we had a big IRC convo during our weekly chat about committing to WP API.
      • From what I can tell, said API is quite ripe for 4.1, or could be with the proper effort.
      • Making Ryan a lead (if he can afford to) could be a good way to make WP API the big ticket item for 4.1
      • Stephane Daury (stephdau) 5:46 pm on September 10, 2014 Permalink | Log in to Reply

        That’s also obviously my vote for the focus in 4.1. :)

      • Justin Sainton 6:41 pm on September 10, 2014 Permalink | Log in to Reply

        Really great suggestion! I think @rmccue would make an awesome lead, but I just don’t know about it for the release where he’s the lead on such a major component as the WP-API.

        Just spitballing here, but I wonder if it wouldn’t be a better situation to have someone as a release lead who can shepherd the whole release, not just that specific component? In my imagination, getting the API in the 4.1 release would require someone like Ryan to be more fully devoted to that specific component than to the whole release.

        Just my two cents.

      • Andrew Nacin 6:41 pm on September 10, 2014 Permalink | Log in to Reply

        When the API is merged in, we’d probably be best served with Ryan’s focus to be 100% on the API, and not need to worry about anything else also going on. The release lead is as much a project manager as it is a final arbiter, shepherd, and what not. Also, the API is going to be a big ticket item in the release it’s in, no matter what. :)

      • Michael Beil 4:44 am on September 12, 2014 Permalink | Log in to Reply

        I concur with having @rmccue at the helm.

    • Stephane Daury (stephdau) 5:51 pm on September 10, 2014 Permalink | Log in to Reply

      Call to action on feature plugins for 4.1 and beyond: in the same line as my WP API suggestion, and if it does make it in 4.1, I (we?) would like to resume work on the Press This rewrite, with the twist of building it as a WP API client. It could act as a great bundled example.

    • Andrew Nacin 6:57 pm on September 10, 2014 Permalink | Log in to Reply

      Some questions to ask:

      • What have we done in the last few releases that could benefit from a v2, even small things?
      • What have we added in the last few releases that needs to be propagated to other areas?
      • What have we not touched in a very long time and is long overdue for a revisit?
      • What brand new features should we consider working on?
      • What existing features need a complete rethink?
      • What are some bite-sized things that we could do to make a big impact? (3.9 and 4.0 were full of these.)
      • What are big things that are broken and that we feel like we could fix / make better?
      • What might Twenty Fifteen benefit from having in core?

      Also, if you want to help lead a release or want to suggest someone, be sure to read this post from 4.0.

      • Stephane Daury (stephdau) 7:08 pm on September 10, 2014 Permalink | Log in to Reply

        For #1 and #2: we delayed a move to Backbone.js (propagate) for the plugins browser/modal (updated in last release) in 4.0, under my advice, to focus on functionality rather than getting bogged down in a library switch. Should that be tackled that in 4.1, building on the experiences of the Media Grid et al?

      • Nick Halsey 7:30 pm on September 10, 2014 Permalink | Log in to Reply

        To address several of those points, I’d like to continue iterating on the Customizer. Starting to build out better JS APIs in particular, building up to several features that’ve been delayed due to the lack of structure here.

        I’d really like to get media in the Customizer rebuilt (initial patch on #21483), and to officially deprecate and redirect/deep-link the old header and background admin screens. Given Twenty Fifteen’s emphasis on those features, this seems like a good time to finally pull the trigger here.

      • John Blackbourn 7:31 pm on September 10, 2014 Permalink | Log in to Reply

        What have we not touched in a very long time and is long overdue for a revisit?

        I think we need to have a think about all the JavaScript which is landing in WordPress these days, and make sure we are documenting it well enough, whether we need to prioritise an action/filters API for this, whether we are doing enough to educate contributors and other developers on the JavaScript APIs, whether we need a better structure for the .js files, etc etc. See also Eric’s post on wp-hackers.

        What are some bite-sized things that we could do to make a big impact?

        Fix the currently rubbish comment notification settings. See #6286, #14676, #761, Email Alerts plugin.

      • Ihor Vorotnov 2:01 am on September 11, 2014 Permalink | Log in to Reply

        Jumping in here. The feature which is highly anticipated by literally any WP developer outside US and several other english-speaking countries is… some multilingual features in core.

        Here’s my idea in details: https://wordpress.org/ideas/topic/native-multilingual-cms-features-one-more-time#post-27185

        Basically, even making terms slugs non-unique and adding some super-taxonomy `language` will allow major plugin developers (WPML, Polylang) do the rest. WPML currently allows to have posts and pages with same slugs, but not categories, tags and custom taxonomies.

        Right now I’m building a pretty large international website, which will function a s a website and a mobile app platform (backend) – thanks to JSON API. Having urls like `example.com/ru/profile-2/edit` or `example.com/ru/profile-ru/edit/` (just plain simple hierarchical pages) is kind of freaky. Or `example.com/ru/events/country/canada-2/city/toronto-2` and `example.com/ru/events/country/canada-ru/city/toronto-ru`…

        Sooner or later, we need to add solid multilingual features to core to become CMS / Framework, not a blog platform.

    • Zach "The Z Man" Abernathy 7:18 pm on September 10, 2014 Permalink | Log in to Reply

      I personally would love to see a little more work in the area of media with respect to actually managing the media items. For instance, being able to group things in folders would be a huge improvement.

    • John Blackbourn 7:21 pm on September 10, 2014 Permalink | Log in to Reply

      I would like to get the ball rolling on open and closed Multisite networks which didn’t get any traction in 4.0 due to time constraints.

    • Boone Gorges 7:23 pm on September 10, 2014 Permalink | Log in to Reply

      I won’t be able to make this meeting, but I’d like to spend some time during the 4.1 cycle improving WP_*_Query classes. Improved test coverage (see eg #29560), followed by fixing some of the more egregious bugs (such as #19623), and adding what I see as some missing features (#29181, #29181, and a few others I am cooking up). May also look into abstracting some of the common logic into some sort of base class that the others will extend.

    • Robert Dall 8:01 pm on September 10, 2014 Permalink | Log in to Reply

      I’d like to fix the poor UI In the widgets since they were last updated. Specifically #27180 I know we can do better.

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

      I’d like to work on getting our JS unit tests running automatically on multiple browsers. I’d also like to look into some automated tests around front end performance of the admin and finding areas that we can speed things up (and also maintain a benchmark of how things are).

    • Xavier Borderie 8:16 pm on September 10, 2014 Permalink | Log in to Reply

      I’d vote for changing the in-editor image update, making like the one in Confluence. I use this wiki tool at my job, and love that, while WP uploads the file and shows the library, letting me inserting the media, when I really want to directly insert it in place. Makes a huge difference.

      • Xavier Borderie 8:17 pm on September 10, 2014 Permalink | Log in to Reply

        “in-editor image upload*”

      • Xavier Borderie 8:35 pm on September 10, 2014 Permalink | Log in to Reply

        Top notch foreign typography. It’s very hard, for instance, using French quotes or non-breaking spaces in the editor without resorting to copy-paste. The editor tries to hot-swap curly quotes but fails in many cases.

      • Xavier Borderie 8:39 pm on September 10, 2014 Permalink | Log in to Reply

        For translators: mark clearly strings that are used in JS, HTML labels/title tags or e-mail, because some translations use HTML entities to get some local things done, and that obviously does only work in HTML situations, not the others. I’m willing to work on that.

      • Xavier Borderie 8:29 am on September 11, 2014 Permalink | Log in to Reply

        Finally tackling that multilinguism issue — or at least build the foundations in 4.1, because it’d make for a great 4.2 announcement (‘cos, y’know, 42, Hitchhiker’s Guide, the Babel fish, all that :) ). Allegedly, the SPIP CMS does it very well (see here for their introductory post).

        • Vincent Mimoun-Prat 8:01 am on September 18, 2014 Permalink | Log in to Reply

          +1 For that too. Multilingual support is as of today more or less buggy depending on the plugin you are using. There are very few options out there and they all are flawed to some extend.

          It would be great to see at least a first step towards a multilingual base framework that plugins could eventually use to build a UI on top of that.

          Current approaches:

          • WPML has CPT and lots of meta data to translate taxonomies -> extra useless queries, bloated UI and code, …
          • Multilingual Press requires one subsites per language -> lots of duplicate site setup required + does not work for e-commerce where you would need two separate shops, would have two separate stocks, …
          • Some other plugins use markup within posts/taxonomies -> Makes editing a nightmare.

          Basically because no foundation for multilingual support is there, we don’t have a mean to get a decent solution to the problem.

      • Xavier Borderie 12:44 pm on September 15, 2014 Permalink | Log in to Reply

        Oh, and since I just got another two requests for that non-ending issue: please do something about the “WordPress address (URL)” and “Site address (URL)” setting fields! People keep using it with no other thought, this bringing their site down, hoping for others to help them out! There must be a better way: hide it, add a warning, anything else than giving the impression that the use can enter URL in these fields and that WordPress will magically set everything in place :)

    • Stephen Edgar 9:50 pm on September 10, 2014 Permalink | Log in to Reply

      The Export API was proposed for 4.0 and didn’t make it, would be great for 4.1:
      Export API improvements/overhaul #22435

    • Dan Milward 11:34 pm on September 10, 2014 Permalink | Log in to Reply

      I agree with Nick Halsey. For me it’d be something small and scene setting for more socket.io integration in the future – its hard to argue against the technology on the basis that Automattic acquired it right?

    • Brandon Wamboldt 2:15 am on September 11, 2014 Permalink | Log in to Reply

      The last few releases have made great strides in user experience in the admin, but now I think the team should focus on developers a bit for 4.1. As somebody who works frequently in WordPress, a big pain point is still list tables.

      I frequently create custom tables for data that really don’t fit the mold of post types, and I often have to duplicate large amounts of code to create a list view that mimics the other list views (posts/pages/etc). If you guys could ease that, it would be awesome!

    • Shail 5:00 am on September 11, 2014 Permalink | Log in to Reply

      For me most awaited feature is taxonomy meta. Is this feature in race? I know this is a very big change but I like to see it in core.

    • Ryan Boren 12:50 pm on September 11, 2014 Permalink | Log in to Reply

      I’ll dump my rough notes.

      Mobile and media. Media and mobile.

      Context, Trust, Awareness, Flow

      Press This. With the mobile improvements to the media modal that landed in 4.0, Press This can use the modal without being crippled on phones. The wordpress.com/post/ editor on wordpress.com has worked through some of the same problems that Press This needed to work through, hopefully smoothing the way. The /post/ editor also showed what you can and cannot get away with. Media, preview, and links are important. wpviews and wplinks are must haves. Media must be visual, not raw html, short codes, or even placeholders. Creating galleries should be possible and easy. Press This has a freedom that the /post/ editor does not. PT doesn’t have to worry with existing content edit flows. It can be tailored to a fairly one way creation flow (akin to Tumblr). It also has an advantage in that it can and does allow escaping to the full editor in the admin when the user needs more than PT provides.

      Press This is not just UI. It is bookmarklets, extensions, side-loading, re-blogging, and sharing. It is the sharing mechanism in Android and iOS8. Someday it will be accommodated by the apps. Keep the entire Press This and sharing ecosystem in mind. When dev resumes, prioritize bookmarklets and fleshing out the sharing mechanisms, especially on mobile. Press This the UI is, in part, a trojan horse for getting a decent mobile posting interface on phones, but the sharing big picture should not be lost to new UI fascination.

      Press This the UI should be a marquee user of WP API.

      Large (full screen-ish) images should be a tap/click away in the media modal. Creating and captioning galleries is difficult when provided only thumbnails. Maybe borrow the attachment details modal from grid view.

      Re-think media modal for touch devices. Get rid of tabs, especially in the absence of multi-select. Full images on tap with details below (like the attachment modal) rather than opening the sidebar and presenting another thumbnail sized image. That sidebar is awful on phones.

      Re-think the media modal in general. We know more about how it is used than we did back when. We know what plugins are actually rather than speculatively doing with it. Is having a separate gallery flow still a necessary compromise? Is a sidebar the best way for plugins to integrate? Is there anything blocking VideoPress and Dropbox plugins from integrating? Which plugins integrate well with the media modal?

      Create gallery and image posts from the media library grid view. Give bulk selection a purpose. This will accommodate mobile flows where images are uploaded to the media lib from a mobile device (via Android’s multi-select capable sharing mechanism, for example) and then gallery posts are later created from a desktop. This is a means of working around our lack of mobile multi-select and gallery creation interfaces.

      Phone UX improvements, particularly menus. Is it possible to swipe to open/close side menus on the mobile web? Side menus must have swipe to be usable. Tapping a menu icon in b’ar should dismiss the menu instead of visiting a link. There is often no safe “tap outside” room on a phone, so all menus should dismiss when their icons are tapped. Very aggravating.

      When adding links on mobile, don’t require highlighting text to activate link icons. Buggy on phones.

      Tweak wplinks for phones. It’s already pretty good and keyboard up/down responsive, but mostly by accident.

      Multi-select upload everywhere.

      B’ar consistency. The front page b’ar on touch devices is my favorite. Tablets in landscape show the narrower b’ar in the admin, which always disappoints me.

      Images uploaded to the media library and then added to a post don’t show up in the “Uploaded to this post” filter. Not being able to filter down to images already on the post makes setting featured images tedious. Uploading from mobile to media lib and then posting later is a common mobile flow.

      Fix the image editor on phones.

      Lose media-new.php?

      Oh wouldn’t it be nice…

      Settings that don’t suck.

      An index.php featuring Press This and a reader.

      Reader views for all list table screens.

      Theme switching from the customizer.

      Notifications, Stream.

    • Paal Joachim Romdahl 11:01 pm on September 11, 2014 Permalink | Log in to Reply

      Improving/renewing Settings was briefly touched upon but stopped up. Having a real useful Settings section would of course be really helpful. I bet a lot of people would have input about this and I bet there are also a few developers that really would like to come together and make this happen.

    • Stephen Edgar 5:54 am on September 12, 2014 Permalink | Log in to Reply

      Another suggestion, and with 99 stars at the time of writing:
      https://core.trac.wordpress.org/ticket/12706 – Custom post status bugs in the admin

      • pampfelimetten 8:37 am on September 18, 2014 Permalink | Log in to Reply

        Oh, yes please! I’m waiting for ages to have this fixed. It’s pretty weird that so much of the post status functionality is hardcoded, when you can tailor pretty much everything else to your needs in wordpress.

    • leemon 6:11 pm on September 12, 2014 Permalink | Log in to Reply

      Please, tackle the following taxonomy bugs once and for all:
      https://core.trac.wordpress.org/ticket/5809 – Updating a term in one taxonomy affects the term in every taxonomy
      https://core.trac.wordpress.org/ticket/5034 – Impossible to have duplicate category slugs with different parents

      Fixing this would be cool too:
      https://core.trac.wordpress.org/ticket/22938 – Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list


    • Paal Joachim Romdahl 9:12 pm on September 12, 2014 Permalink | Log in to Reply

      Certain features are directed toward a developer and would not really help a “regular” user as much. I am thinking that features also could be placed into categories of who would this be helpful for. Placing a feature into: Developer, Designer, Advanced Users, Basic Users. Most people who are associated with being here on this forum are very likely Developers. A few probably Designers and a very very would then place themself into the remaining two categories.

      As I work with education I identify myself have very strong empathy for a person who has just began with WordPress. And oftentimes see WordPress through their eyes. Core needs eyes on features from people with different backgrounds that can share thoughts and their perspectives into seeing a much larger view.

    • Rodrigo Primo 8:59 pm on September 16, 2014 Permalink | Log in to Reply

      Fixing the performance issue with the algorithm used to display a list of hierarchical posts (pages or another custom post type) would be a great improvement for 4.1. This ticket has a patch already and is waiting for dev feedback.


    • Vincent Mimoun-Prat 7:53 am on September 18, 2014 Permalink | Log in to Reply


      I have just updated the patch I had submitted for 3.8 and 3.9 on an important performance improvement for meta queries. It would be great if that could be reviewed and included in 4.0.1 or 4.1


    • Paal Joachim Romdahl 12:22 am on September 22, 2014 Permalink | Log in to Reply

      Improving the WordPress importer/exporter plugin would be nice. To have a separate section for media or improving on the media aspect of the import/export.

    • Dave Clements 6:39 pm on September 22, 2014 Permalink | Log in to Reply

      It’d be great to see the work already carried out on #21506 (Standard Theme Hooks) carried forward through testing and implementation.

    • JakePT 7:39 am on September 24, 2014 Permalink | Log in to Reply

      I’m desperate for #20943 to be fixed.

  • Helen Hou-Sandi 8:04 pm on August 27, 2014 Permalink
    Tags: , agenda   

    RC1 is here! Proposed agenda for today’s meeting:

    • What’s come up in the hours since RC1 was released?
    • Keep an eye on support forums and bugs reported against trunk. Great time for triage of non-4.0 tickets as well.
    • Plugin developers: update your readmes and add an icon!
    • Interesting post on wp-hackers. Feedback welcome.
    • Codex page.
    • Any blog posts we need to write for developers?
    • Are there any plugins we need to ship to show off or extend 4.0 features?
    • Release plan.
  • Helen Hou-Sandi 4:13 pm on August 13, 2014 Permalink
    Tags: , agenda   

    All hands on deck for 4.0 Beta 4 and RC 1 

    We’ve been pushing really hard to get to a place where a final beta and then RC phase are appropriate for the 4.0 development cycle.

    This impacts a few things:

    • The release date (currently scheduled for August 27, in just two short weeks).
    • Finalizing help and about page text, and thus string freeze (and, therefore, translators).

    With the help of everybody who’s contributed to this release thus far, we’ve done a really great job with the features we’ve been working on and the overall ticket queue for this milestone. All of that said, we need your help to get the following done:

    Needed to reach the final beta

    • #28328: Focus on editing, while editing (editor scrolling improvements). There is a comment that outlines a few things we feel need at least consideration before we consider this release-worthy. @stephdau has been working through patching – testing of patches is greatly appreciated, as are bug reports (as always).
    • #28842: Media Grid: Bulk selection mode. User testing and further feedback have led us to give a separate selection mode another try. @ericlewis has been doing very heavy lifting throughout the cycle on the feature. There is a patch for testing (not for commit) along with some observations on ticket. Once again, testing and UI/UX observations are very welcome. If you would like to help with patching, please let us know and we can coordinate to avoid duplicate efforts.

    Needed before RC1

    • Commit or punt all tickets currently slated for the 4.0 milestone. Anybody can help by testing/writing patches or marking tickets for commit or punt using keywords. If you’re not sure, feel free to ask in IRC, on ticket, or just move to the next one.
    • Triage all tickets reported against trunk. This is especially important in the RC phase, as we need to monitor things reported against trunk for bugs introduced in the cycle, particularly regressions. Many tickets opened against trunk will apply to earlier versions – please change the version field as appropriate to reflect that. It may help to filter out anything already milestoned for 4.0 or Future Release.
    • QA sweeps across browsers and devices, particularly on new features and checking CSS for anything introduced that may not work in IE8 or in some cases IE7. For instance, any usages of CSS calc() need to have a fallback for IE8 and older.

    If you’d like to tackle something you see here and would like a little more direction to get started, please leave a comment below or head over to #wordpress-dev in IRC. One or more core developers is likely to be around at most hours.

    Finally, for today’s dev chat at 2014-08-13 20:00 UTC, let’s take a quick look at the above, note any other blockers we see, and get people assigned to tasks/tickets as we can.

    • Robert Chapin 5:54 pm on August 13, 2014 Permalink | Log in to Reply

      I can’t make the meeting but I am subscribed to the Formatting component in case anything comes up. Have a good one. :)

    • Mattias Tengblad 1:01 am on August 14, 2014 Permalink | Log in to Reply

      One HUGE blocker for RC1 is that the translators have ZERO strings to translate yet. String freeze anyone? What so freaking hard with communication between groups? Will look really good to have an all new language packs installer with no up to date languages.

  • Helen Hou-Sandi 7:42 pm on August 6, 2014 Permalink
    Tags: , agenda   

    Proposed agenda for today’s dev chat:

    Please propose any other items you might have in the comments.

    • Stephane Daury (stephdau) 7:48 pm on August 6, 2014 Permalink | Log in to Reply

      #27440 only has one issue left (as of .3 patch, .4 to be discussed), and I could use some help with it: UI for section tabs in small screens: they wrap, and mess the layout up.

      Making that a menu was discussed in last week’s chat, but I found it to be meh (extra clicks, etc) in my tries.
      I had in mind to try what an horizontal scrolling bar (as some native apps do), with a visual cue that there’s stuff to the right/left to scroll to, but the CSS is giving me trouble, and I’m empty handed right now.

    • Nick Halsey 7:51 pm on August 6, 2014 Permalink | Log in to Reply

      #28979 should be finalized one way or another before RC as mixed priorities would require a lot of churn (probably introducing a new section-panel parent class, renaming a file, etc.).

    • quangn 9:36 pm on August 6, 2014 Permalink | Log in to Reply

      I have question how about adding “shuffle” and auto play in the player for audio music? I really miss this feature and I wrote several posts about this and it seems no one replied to me :(

    • Mattias Tengblad 12:20 pm on August 7, 2014 Permalink | Log in to Reply

      For the love of god, think of the children…ehm…I mean the translators. Two ~ weeks left to release? We need information, and strings to translate!

    • rajlaksh 5:38 pm on August 9, 2014 Permalink | Log in to Reply

      Is Categories will become like TAGS System? Easy to browse?

  • Helen Hou-Sandi 8:02 pm on July 23, 2014 Permalink
    Tags: , agenda   

    For today’s dev chat, let’s focus on issues being reported in beta, user testing, and what we need to work on in relation to these to get to the next beta. For reference, the first round of user testing on the media library grid view is up on Make UI.

  • Helen Hou-Sandi 7:49 pm on July 16, 2014 Permalink
    Tags: , agenda   

    For today’s dev chat, let’s check in on how we’re feeling about a beta 2, any blockers we might be seeing, and then do a scrub on tickets, particularly focusing on things that can be committed or punted. Please add any other agenda items in the comments.

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