Make WordPress Core

Tagged: dev chat Toggle Comment Threads | Keyboard Shortcuts

  • Adam Silverstein 3:03 am on February 4, 2016 Permalink |
    Tags: , dev chat,   

    Core Dev chat notes for Feb 3 


    • @danielbachhuber announced a WP REST API meeting, happening tomorrow in #core-restapi on Slack: Thursday, February 4, 2016, 11:00 PM GMT. Full details are posted on the make/core blog.
    • A reminder that the feature plugin decision deadline is coming up next week, Feb 10th.
    • For the “Field Guide” posts, @jorbin proposed organizing around “focuses” and called on any feature plugins that get merged to make a post highlighting the following: anything with potential to break backwards compatibility along with significant new classes, functions, and hooks that you expect plugin, theme, and site developers to use. The goal is to have everything published before beta2.

    Feature Plugin Updates

    • Customizer Device Preview: @celloexpressions
      • Very close. Has UI/UX approval, a11y approval.
      • Waiting for fixes after dev review and security audit.
      • Consensus is that, pending the above, it is approved to merge in 4.5.
      • See #31195 and the related make post.
    • Application Passwords: @georgestephanis
      • Application passwords got split off from two factor auth, so we’re only talking about application passwords (Two-Factor is not dead, and will come back at a later date)
      • Lets you use an application password for XMLRPC and the REST API, instead of your normal password or oAuth 1.
      • Questions and discussion around whether there is a large enough use case to make this a core feature. Consensus is that at this point, it doesn’t benefit enough end users to warrant inclusion, but might after or when the REST API endpoints land in core.

    Focus Status Updates

    • Customizer: @westonruter, @celloexpressions
      • Customizer Pane Resize (#32296): Stalled.
      • Selective Refresh (#27355): Getting very close.
        • Selective refresh works well together with postMessage JS-updates, as the JS update can apply an immediate (approximate) preview while the Ajax request is being made to get the actual rendered content
        • Selective refresh `partials` have associated selectors and settings, so shift-clicking on any of the containers will focus on the corresponding control in the pane.
      • Customizer notification area (#35210): Needs help!
        • In progress, but an initial patch based on available mockups is needed here.
        • This is a dependency for the setting validation model (#34893) and creating page stubs via nav menus (#34923).
      • Transactions (#30937): Punting due to dependency on the REST API and on selective refresh.
    • Image Improvements: @joemcgill
      • Main focus on improving the default Imagick compression settings, some progress this week identifying the main hurdles there.
      • Could use additional opinions on #28474 (animated gif resizing) and whether it’s worth pursuing.
      • Could use some additional eyes on #34359 (particularly on multisite installs)
      • Weekly meeting is Friday at 20:00 UTC.
    • Multisite/WP_Site: @jeremyfelt
      • WP_Site is in with only minor issues surfacing.
      • Considering a `sites` endpoint for the REST API – primary use right now would be to refactor the My Sites menu.
      • A new repository for the site(s) endpoint has been set up on github.
      • Some renewed interest in a network settings API (or expanding the settings API to include networks)
      • Make/core post coming soon.
    • Editor: @azaozz, @iseulde
      • Going through and fixing edge cases for the inline link dialog. Please test!
      • Next will be the extending of “editing shortcuts”.

    View the full logs on Slack.

  • Adam Silverstein 10:54 pm on January 27, 2016 Permalink |
    Tags: , dev chat,   

    Core Dev chat notes for Jan 27 


    • Extending the Feature Plugin decision and merge deadline by one week, taking them to Feb 10 and 17, respectively. This does not affect the rest of the release schedule, and betas, RC, and release are all the same dates. This gives feature plugins a little more time to have necessary discussions.
    • @ebinnion has graciously continued with the week in core post, and @rockwell15 volunteered to lend a hand.  If you like these posts, please help!  Many hand make light work.
    • @dd32, @jorbin and a few others are working on finishing up 4.4.2. Ticket owners should review the list of tickets tagged for the release.

    Focus Status Updates

    • Customizer: @westonruter, @celloexpressions
      • Posted a recent status update here on the make/core blog.
      • Customize Device Preview is up and ready for testing #31195, with a make/core post coming shortly.
      • Assistance requested with the Customizer Pane Resize plugin #32296.
      • Some movement on adding a notification area to Customizer #35210, with the need for an initial workup – help needed.
    • HTTPS Improvements: @johnbillion
      • Focusing on avoiding mixed content on https sites – a working http site is much preferable to an https site full of mixed content.
      • Working on a feature plugin which implements various granular controls over forcing HTTPS on a site: forcing enqueued assets to https, rewriting URLs in content on the fly to force their scheme to https, forcing redirects to the https version of the site, etc. Individual options with the ability to enforce the lot.
      • Adding a GitHub repo where this will be worked on and also posting a summary to make/core soon.
    • Image Improvements: @joemcgill
      • Good conversation last week about displaying responsive images in the editor.
      • Team could use help with profiling to Improve default Imagick compression settings #33642.
      • The old #feature-respimg channel has been renamed #core-images to be a place to talk about images in any/all capacities.
      • Weekly meeting is Friday at 20:00 UTC.
    • Editor: @azaozz, @iseulde
      • The inline link dialog is in. Please test! #33301
      • Looking into wpviews soon (Using the TinyMCE API).
      • Also looking at improving the shortcuts soon.
      • Could use help investigating using the image editing tools from TinyMCE for the media library.

    Open Floor

    • @veraxus brought up #16031 and the inability of handle new bulk actions in a non-hacky way (you can add the actions in the list, but not handle the action). Is it worth the effort to rework the patch? Will the core team support it?

    View the full logs on Slack.

  • Adam Silverstein 9:48 pm on January 20, 2016 Permalink |
    Tags: , dev chat,   

    Core Dev Chat Notes for Jan 20 


    Focus Status Updates

    • Customizer: @westonruter, @celloexpressions
      • Good progress has happened for selective refresh, with good feedback and an architectural direction #27355.
      • A responsive preview feature has been getting good feedback and is nearing a committable patch #31195.
      • Update make/core post coming soon.
    • HTTPS Improvements: @johnbillion
      • Nothing specific to report about the HTTPS work, there will be a meeting next week about ‘force ssl’ which he will post about in make/core tomorrow morning for those who want to get involved.
    • Image Improvements: @joemcgill
      • Improving Imagick compression settings #33642 is still a priority.
      • Looking into options for #28474 (better animated GIF handling).
      • Longer term effort: what can be done to improve some of the core API for working with images
    • Multisite/WP_Site: @jeremyfelt
      • Several things assigned to the 4.5 milestone
      • A reorg of filters for network allowed themes went in today.
      • Working at the latest <code>WP_Site</code> patch now with the intent of putting it in today or tomorrow.
      • Office hours on Tuesdays at 21:00 UTC in #core-multisite; bring your bugs.
    • Post New: @michaelarestad
      • @karmatosed is going to be leading a team focused on improving the Revisions UI
      • @hugobaeta is going to be leading the Toolbar Remix team
      • @michaelarestad working on improving the Publishing UX and Metaboxes
      • @michaelarestad made a Sketch template for wp-admin that’s accurate and will be published later this week.
      • Update posts coming soon
      • Join the effort: comment on the original post and join the Slack #design channel.
    • Editor: @azaozz, @iseulde

    Open Floor

    • @ipstenu brought up #35429; @michaelarestad going to review from UX perspective, discussion
    • @azaozz brought up inline link dialog autocomplete, extend suggest.js or use another library (typeahead, select2)? what is the use case? discussion in #core-editor. @sheri offered to help with user testing to determine the best UX.
    • Meeting ended, ticket conversation continued…

    View the full logs on Slack.

  • Adam Silverstein 2:05 am on January 7, 2016 Permalink |
    Tags: , dev chat   

    Core Dev Chat Notes for Jan 6 


    4.5 Schedule

    Focus Runthru

    • Customizer@westonruter reported on & @karmatosed, @melchoyce, @valendesigns and @michaelarestad expressed interest in
      • Features in progress: Customize Pane Resizer, Customize Device Preview. Customize Setting Validation, Create page stubs for adding nav menu items.
      • Features ready: Transactions and Selective Refresh
    • Edit/Publish Flow@michaelarestad
      • Blog post coming soon, incremental steps towards improving the new post and publishing process.
    • Image-centric@joemcgill #33642
      • Finish work on improving compression of images
    • No More Mixed Content (https improvements) – @johnbillion leading & @jeremyfelt, @richardtape, @eric expressed interest

    Open Floor

    View the full logs on Slack.

    • Nick Halsey 2:34 am on January 7, 2016 Permalink | Log in to Reply

      I added some UI mockups for adding content from the nav menus UI in the Customizer (page stubs) – UI/UX feedback appreciated on #34923.

  • Ryan Boren 7:36 pm on November 3, 2014 Permalink
    Tags: dev chat,   

    Dev Chat Summary, October 29th 



    • Beta 1
    • Feature plugin merge window



    Links Mentioned


    Focus 2

    I think Focus v2 is ready to be turned into a core patch and be merged in. Over the last few days we have been working on making it less “twitchy” and narrowing the circumstances under which focus mode is triggered, so we are sure the user is focused on composition when it happens, instead of transiently moving through the editor or absentmindedly clicking.

    Session Manager

    I think the session manager is ready with some minor UI tweaks (simplifications, really) and use of the geo IP API.

    Yes the session management UI is in a similar position

    I’m hoping to get that in patch form and ready to merge before the weekend

    Select 2

    @helen @ericlewis Do you have time to look into the touch problems before Friday? I am very tempted to punt this if we can’t get this merged by early next week, and highly visible touch support problems will prevent it being merged

    I think we can circle back Friday during the bug scrub and make a decision

    i am having bad gut feelings myself.

    I think the work @helen and @ericlewis have done is great, but there are too many unknowns (edited)

    I side with withholding it for just one release. The benefits of waiting (potentially better codebase, more room to test accessibility, etc) far outweigh the benefits of including now (almost certain rewrites in the very near future, for one)

    I’d say cut it. It’s a minor improvement, not a make-or-break feature.

    And with so many other things about to come in, it’s pulling resources in different directions a bit.

    “just one release” – i’ve been tinkering with this since february.

    Fair point, very fair point

    but i am not worried about cutting it for 4.1. it is frustrating, but not worrisome.

    Ok unless the situation with touch support changes in the next few days, we should consider this punted. I have also just been informed that there is a licensing issue which I was unaware of

    Twenty Fifteen

    Twenty Fifteen is steaming ahead

    @obenland @lancewillett @iamtakashi Anything of particular note you’d like to mention?

    It’s looking good

    @celloexpressions just did a great review

    and doubled our ticket numbers :simple_smile:

    Well, that was just as much as I could do in an hour :simple_smile: but it’s pretty good overall, no huge issues. I’m still thinking about the color schemes implementation

    Not much to report on beyond the update here https://make.wordpress.org/core/2014/10/28/twenty-fifteen-chat-summary-october-28/
    Make WordPress Core
    Twenty Fifteen Chat Summary October 28
    Notes for our weekly chat about Twenty Fifteen: Twenty Fifteen continues to feel pretty robust — thanks to everyone who’s been testing the theme, reporting bugs, and contributing to patches with co…

    We had some new template tags land yesterday, I started a ticket for the new `title-tag` support and will publish a post on that later today

    Also working on adding support for the navigational template tags

    Plugin and Theme Install

    Lastly from me, the proposed updates to the plugin and theme install and update process haven’t had much traction lately, as I’ve already noted, due to @nacin @melchoyce @pento @avryl being busy on other things, but we have mockups and that group are going to plow through it starting this afternoon

    So that is still scheduled for 4.1

    Feature Plugins

    Feature plugins need to be in the beta list. Only one of those discussed here is listed, Focus. /wp-admin/plugin-install.php?tab=beta

    @boren: Roger.

    Does that page have a .org analog?


  • Helen Hou-Sandi 9:44 pm on June 1, 2014 Permalink
    Tags: , dev chat   

    Summary of 5/28 dev chat (IRC log):

    • @nacin and @tellyworth have been working on the .org API side for i18n and plugins page improvements respectively and should be ready for work on the core side soon. Be on the lookout for tickets and discussions.
    • @ericlewis has been working through the Media component in Trac and will be holding weekly scrub in #wordpress-dev alongside media grid chats, Fridays at 17:00 UTC.
    • @wonderboymusic has been evaluating various oEmbed endpoints as we add and remove them. Some services need some more evaluation: #28379.
    • Embed representations in wpview need an iframe sandboxing solution investigated to avoid script conflicts inside TinyMCE and the admin: #28249
    • The JSON REST API came a long way in the past week, especially on the documentation front, and is being placed onto the roadmap for the 4.1 release. From @nacin:

    1.0 is a great step in the right direction; let’s push it hard; let’s put it squarely, loudly, and officially on the 4.1 roadmap (I’m comfortable doing that); let’s get a lot of core contributors focusing on it for the final mile, especially when it comes to internals

    let’s get a lot of people to build things on it, including inside automattic, mobile apps, even wordpress.org stuff; let’s branch off 1.0 so we can decide paint and carpet colors on the master branch

    •  And finally, several people were added to various Trac components as component maintainers. You can be added at any time, or get on the road to becoming one by signing up for granular notifications on the components page.
    • Eric Andrew Lewis 10:35 pm on June 1, 2014 Permalink | Log in to Reply

      I think component maintainer gravatars should be surfaced to the components page, so we can see the core community at a glance rather than clickering into each.

  • Helen Hou-Sandi 7:16 pm on May 28, 2014 Permalink
    Tags: , , dev chat   

    Summary for 5/21, Agenda for 5/28 

    Summary of 5/21 dev chat (IRC log):


    • Posts like the i18n goals one serve as a great model for anybody who has ideas for a feature or component roadmap, whether that’s within one cycle or longer term: a list of concrete goals that can be divided up into specific tasks.
    • The make/* blogs should be used as much as possible for discussions and progress updates. Teams that have been using separate P2s but should consider using the make.wordpress.org instead for wider reach and more active participation from the community.
    • Keep in mind that plugins are supposed to encourage rapid and possibly wild experimentation – please do not discourage that.
    • Think of meetings as blocked out times where you can more reliably get a group together and get unstuck as needed, but we should take advantage of async (Trac, P2) and adhoc (IRC outside of meeting) discussion as much as possible.

    Team Updates

    • i18n goals for 4.0 have been posted, @nacin is seeking people to help with a lot of it. @yoavf, @kovshenin, @iandunn, @coffee2code, and @otto42 have done or will do some of the i18n tasks.
    • JSON REST API was given another week to collate a detailed compare-and-contrast with the other available APIs, including the JSON API plugin and Jetpack/.com’s API, and proven client implementations.
    • Media Grid has a narrowed scope for 4.0 inclusion: something more visually driven than the standard list table, much like theme browser brought to themes and is being investigated for plugins in 4.0. Will also fix some long-standing issues that were brought in with 3.5.
    • Editor improvement ideas: @markjaquith and @avryl have put together a proof-of-concept plugin that we should smooth out and make a decision on.

    Agenda for 5/28:

    • Make final decision on JSON REST API.
    • One sentence updates from various groups – i18n, media grid, plugins, oEmbed, etc. Come prepared.

    Please propose any other agenda items in the comments below.

  • John Blackbourn 8:22 pm on May 13, 2014 Permalink
    Tags: , dev chat,   

    Agenda for tomorrow’s Multisite chat 

    We’re having a dev chat about Multisite in #wordpress-dev tomorrow (May 14, 2014 18:00 UTC). I’d like to split the chat into two main areas:

    1. Open vs. closed networks
    2. Everything else

    The concept of an open network where users can create their own sites was the popular impetus for WordPress MU, but is decidedly not the primary use case for multisite anymore. Most operate closed, trusted networks, where site signups are disabled (and often user signups are disabled as well).

    Back in October, Andrew Nacin published a collection of thoughts on potential changes to Multisite, one of which was the idea of open vs. closed networks. I’d like to discuss this concept and whether now is the right time to tackle it. Here are some relevant paragraphs from that post:

    When a network is not designed for “open registration”, there are a number of undue burdens that should be lifted for administrators. Uploadable file types are severely restricted, and the amount they can upload is capped. They cannot activate installed plugins, though there is an option for this. They cannot add users to their sites without knowing their email address (ostensibly to prevent spam), and the user must still go through a “confirmation” process. New sites must go through an “activation” process. They cannot create new users.

    I don’t think WordPress needs to decide that the multisite feature is only geared for closed networks. Rather, a single option — set on install, and controllable via network settings — can control this entire paradigm very effectively.

    Essentially, I am proposing we trust single-site administrators in a closed network to not be spammy, and to be given wide-ranging control of their own sites; but that we do not extend that trust to important areas of security.

    So, let’s discuss whether now is the time to introduce the concept of open vs. closed networks, what form it takes, and to which functionality it extends.

    • What differences should we see between an open network and a closed network?
      • Open user registration
      • Open site registration
      • Capabilities for regular Administrators (plugins, themes, users)
      • Email notifications (amount of, and wording in)
      • User listing and user editing UI differences
      • Site listing and site editing UI differences
      • Network admin dashboard UI differences
    • What form should the open vs. closed network option take? A UI option when installing multisite? Changeable after the fact or set in stone like subdir/subdomain option?
    • What changes need to be considered for existing multisite installs?

    Secondly, let’s discuss all other multisite improvements that we would like to see. Several may well be related to the idea of open vs. closed networks, and that’s ok. Here’s a list to get us started:

    • Reign Rein in notification emails when adding sites, users
    • Improve user searching – #27304
    • Improve user management
    • Better explanations for what archive/spam/delete does to a site
    • Merge in the Hyper Admins plugin
    • Merge in the User Management Tools plugin

    If anyone has particular issues they’d like addressed (bonus points for existing tickets on Trac), leave a comment and we’ll see what we can cover.

    Two other items worth mentioning are:

    • Domain mapping
    • SSL improvements

    I don’t think we’re yet at the stage where we could consider implementing domain mapping in core. It has a prerequisite of removing the subdirectory vs. subdomain paradigm, and we’re not near approaching that (unless someone wants to step up).

    Regarding SSL improvements, I’m planning on arranging a separate working group to tackle a whole raft of SSL improvements in core that aren’t just related to multisite. I’ll be publishing a separate post in the next couple of days to get us started.

    • Robert Dall 8:47 pm on May 13, 2014 Permalink | Log in to Reply

      I couldn’t agree more on adding the Hyper Admins and the User Management Tools into core. That makes a lot of sense.

      I could also see real benefit to the Domain Mapping and SSL Improvements.

      Here is why:

      I am actually in the middle of a project where I am using a multi-site for company that has 5 different websites that offer 5 different areas of the products and or services offered.

      So while we could use 5 different installs of WordPress were using the power of multisite to keep the admin to a minimum.

      Domain Mapping will be of great use to this and many other types of multisite usage.

      SSL and wildcard SSL is someone confusing to the uninitiated any improvement to WordPress multisite and SSL would be of great benefit.

    • Sallie Goetsch 8:49 pm on May 13, 2014 Permalink | Log in to Reply

      That’s “rein in.”

      However, I’m really glad to see Multisite getting some attention. I’m not qualified to help develop it, but I’ve noticed the lack of developments in the last several WordPress versions. What IS the status of domain mapping? Do you still need a plugin for it or not?

      Are there any plans to institute network-wide widget areas? Right now network-wide menus are possible with a plugin, but there’s no way to add network-wide widget areas at all.

      How about default theme settings that the network admin can control? I’ve got a project coming up where we’re actually leaning toward NOT using Multisite in part because the network admins would have to go in and configure theme options for each sub-site separately (even though they will be the SAME for each site, with the only difference being a different logo image). We could hack the theme up so it doesn’t have any other options, but that’s not really a good alternative, either.

      I realize these things are too much to ask for 4.0, but wanted to at least add them to the wishlist.


      • John Blackbourn 3:07 pm on May 14, 2014 Permalink | Log in to Reply

        What IS the status of domain mapping? Do you still need a plugin for it or not?

        Yep, there’s no support in core for domain mapping currently.

        Are there any plans to institute network-wide widget areas? How about default theme settings that the network admin can control?

        Network-wide widgets, menus, and settings are an interesting idea and certainly something I’ve seen requested before. The complication comes when those widgets, menus, and settings need to be present on the main site, which may not be desirable. I’ll add it to the agenda!

    • Rouven Hurling 9:27 pm on May 13, 2014 Permalink | Log in to Reply

      i would love to see #15800 fixed, so that network wide plugins can add a tab the site edit where there can display their options (or in my case, data and options for that client and so on)

    • Knut Sparhell 1:29 pm on May 14, 2014 Permalink | Log in to Reply

      As long as the mulitisite setup can only be done from wp-config.php this should also be where to set a WP_IS_TRUSTED_NETWORK constant. You don’t specifically install a multisite, you install WordPress and transform it to mulitsite by editing wp-config.php.

      The spam site option may be removed unless some sites actually have it set already. The way links was deprecated is the way to go.

      Users should be registered through a signup process to avoid sending passwords over email. Single sites could also gain from a better signup process. For trusted networks this should be unified.

      There is a plugin for dealing with user activation keys, removing unused and unnecessary signups. This could be part of core.

      Shared media could also be something for the future, and have in mind.

      The important thing now is where to start, how to simplify things and not doing things that may block further evolution and flixibility.

      • John Blackbourn 3:10 pm on May 14, 2014 Permalink | Log in to Reply

        As long as the mulitisite setup can only be done from wp-config.php this should also be where to set a WP_IS_TRUSTED_NETWORK constant. You don’t specifically install a multisite, you install WordPress and transform it to mulitsite by editing wp-config.php.

        That’s not quite correct. You add the `WP_ALLOW_MULTISITE` constant but then you still need to go through the setup process in the admin area. This is where I imagine the open/closed network option will go.

        I agree with all your other points!

      • Boone Gorges 4:58 pm on May 14, 2014 Permalink | Log in to Reply

        > There is a plugin for dealing with user activation keys, removing unused and unnecessary signups. This could be part of core.

        Agreed that this is a problem. See also the new “Pending Users” feature in BuddyPress (http://wptavern.com/buddypress-2-0-to-add-signups-administration-screen – BP now creates the wp_signups table for non-multisite as well, to centralize signup management) and this plugin: https://wordpress.org/plugins/unconfirmed

    • Paal Joachim Romdahl 4:50 pm on May 19, 2014 Permalink | Log in to Reply

      An idea… brainstorming….
      What about having a Network page similar to a All Pages/All posts screen. Only here we can create connections. Create a new sub site or link with existing site.

      Create a new sub site options:

      • title, description and perhaps URL.
      • Optional check box for Domain.
      • Check boxes for Shared media, share posts, etc.
      • And probably other options.

      Link with existing site.

      • URL of site
      • Username and password.
      • Check boxes for shared media, share post etc.

      and more.

      This would really make it into a Network page that one can connect existing or new site.

  • Helen Hou-Sandi 2:48 am on May 9, 2014 Permalink
    Tags: , dev chat   

    Summary of 5/7 dev chat (IRC log):

    Proposed 4.0 ideas

    • Multisite enhancements: SSL, get site creation/editing UIs in line with the arbitrary domain/path support. Planning on weekly office hours.
    • Mobile experience: media modal and upload flow, Press This feature plugin.
    • oEmbed discoverability, usability, and caching improvements.
    • Widgets: JS API (#28093)
    • Taxonomy roadmap, part one.
    • Background images in the customizer.
    • Plugin installer improvements: better search and more information (needs .org API support), upgrading a plugin or theme via zip upload (#19641)
    • Export API improvements/overhaul (#22435)
    • Post meta: support for revisions (#20564)
    • APIs for posts/comment types/statuses. Ping @nacin if interested in collaborating (#12706).
    • Continuous a11y enhancements, particularly in the media modal.
    • Texturize patches, continuing on performance enhancements and bugfixes in 3.9.

    If you are interested in any of the above, sound off in the comments below.

    Potential themes for the release:

    • More visual cues in the admin for user tasks, as has been done for themes.
    • Continuing to improve the editing and media experiences.
    • Lots of under the hood things and API attention to make devs happy.

    Feature Plugins

    • Front-end Editor looks like it’ll continue past 4.0, as enabled by being a feature as a plugin, but we should continuously keep an eye on it and see what improvements can be brought into core sooner.
    • Media Grid View and Press This are under way.
    • WP API continues to move forward.

    Patches needing early dev attention

    • #17689: Terms should not be sanitized inside term_exists(). This is the first step in moving along with the taxonomy roadmap, so please look here if this has been of interest to you. Potentially needs more unit tests. Thanks to @aaroncampbell for the latest patch.
    • #14759: Improve the way oEmbed deals with caching (patch from @markjaquith).

    And finally, 3.9.1 is out now, if you haven’t already updated or been updated.

    • Schwarttzy 5:21 am on May 9, 2014 Permalink | Log in to Reply

      How about featured background images?

    • Florian Girardey 7:51 am on May 9, 2014 Permalink | Log in to Reply

      How about better UI for Header images ?

    • helgatheviking 7:55 am on May 9, 2014 Permalink | Log in to Reply

      More admin filter/hooks everywhere! And love for the quick edit.

    • RicaNeaga 9:49 am on May 9, 2014 Permalink | Log in to Reply

      Here’s what the roadmap looks like for Cpanel, from here… http://features.cpanel.net/responses/as-a-server-administrator-i-want-mariadb-support-so-that-i-can-accomodate-both-innodb-and-noninnodb-users

      ”1. We introduce MariaDB 10 with cPanel & WHM version 11.50

      2. In version 11.50 both MariaDB and MySQL are provided, and wholly supported, by cPanel

      3. With version 11.52 we announce that MySQL is considered deprecated, and will be removed in version 11.54

      4. With version 11.54 we no longer provide the MySQL RPMs.”

      So in ~ a year from now a major web hosting control panel is going to ship without any trace of MySQL. Then why not fully supporting MariaDB (10) in the next major release, 4.0, and include MariaDB (10) as an alternative for MySQL in the requirements page? https://wordpress.org/about/requirements/

      • Andrew Nacin 3:03 pm on May 9, 2014 Permalink | Log in to Reply

        WordPress already supports MariaDB, and has for a long time, since MariaDB is a compatible replacement for MySQL. We could put it in the requirements somewhere but it’s still pretty esoteric at this time.

        • RicaNeaga 5:33 pm on May 9, 2014 Permalink | Log in to Reply

          Thanks for the answer and info. MariaDB 10 however is a combination of MySQL 5.5 and 5.6, and with features of its own, it won’t be a 100% drop-in replacement for either of them (MySQL 5.5 or 5.6).

          So maybe it’s a good idea to make sure everything it’s ok, and put it in the requiremets after that. The sooner the better I think, it would make a statement that the wordpress project is also supporting MariaDB in the long run, alongside Google, CPanel, Plesk, RHEL and other major Linux distros.

          Right now I’m annoyed since I’d like to buy a managed server from Germany, and their control panel supports by default only MySQL and PostgreSQL. ”Spreading the word” about MariaDB hopefully would make others ”embrace the future” sooner 🙂

    • Jon Brown 4:55 am on May 10, 2014 Permalink | Log in to Reply

      I’m assuming the Metadata API/UI is still too far out to be considered for 4.0, but I’m going to cross my fingers and hope for it anyway: https://github.com/wordpress-metadata/metadata-ui-api/

      • Helen Hou-Sandi 6:39 pm on May 10, 2014 Permalink | Log in to Reply

        I would think of this as more of a working group that also happens to have a particular end goal in mind, and improvements can (and should be) ongoing. That end goal does not seem likely for 4.0 though, no.

    • Robert Chapin 4:03 pm on May 10, 2014 Permalink | Log in to Reply

      #10041 needs early dev attention. Come on guys. If we don’t do this now, the patch will go stale.

    • rajlaksh 7:25 am on May 13, 2014 Permalink | Log in to Reply

      what about categories like tags in new post page? so u have to enter category name then auto complete search 🙂

      Easy then scrolling 500+ categories.

  • Helen Hou-Sandi 8:30 pm on May 6, 2014 Permalink
    Tags: , dev chat   

    Summary of last week’s dev chat on 4/30 (IRC log):


    Features as plugins

    • Met on 4/29 (IRC log)
    • Current potential considerations seem to be WP API and media grid.
    • Press This is getting some attention from an early stages working group, which could also be a part of the 4.0 release.
    • Admin Help is poised to shift into more of a continuous testing and advisory group, which is awesome.
    • Front-end editor is making good progress, but has UX issues that are getting worked on, needs iteration and experimentation and probably won’t be ready by 4.0, but should continuously be worked on, as is the goal of features as plugins in the first place. Developers needed.

    Potential ideas and their suggesters:

    Summary: we have good things in mind about more media improvements, more editing experience improvements, more visual media grid and better plugin installer experience (following in the footsteps of themes), and behind the scenes wins in taxonomy, multisite, and post type and comment APIs.

    If you’re interested in any of the above or have other ideas, please sound off in the comments.

    Getting involved

    • We are always looking for more people to be involved with Trac gardening, patch review, patch writing, or some combination thereof.
    • Component pages are running well, and most could still use the caretaking of a component owner or somebody who’d like to become well-versed in a particular area of core. To get started, just sign up for component notifications at https://make.wordpress.org/core/notifications/. No need to be an expert now – learning and persistence is more important.To help with a specific plugin, join their weekly chats and/or follow along wherever they post. See the Features as Plugins page for more information.
    • A reminder from @matt to always be dogfooding the product – use WordPress every day.

    Bonus punnage, to the lead’s chagrin:

    > wonderboymusic will make a t-shirt for anyone who gets all 16 of those Cache tickets closed 🙂
    > sams: “Cache Master”?
    > wonderboymusic: Johnny Cache
    > jorbin: If you fix the Cache, you’ll get the Credit. That Checks out.
    > MarkJaquith: I’d put in a cache pun, but I don’t want to be sent to purgetory.
    > johnbillion: You would have to be a cache machine to fix all 16

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