Make WordPress Core

Updates from July, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • Dominik Schilling 12:38 pm on July 4, 2016 Permalink |
    Tags: ,   

    This Week in 4.6: July 4 – 10 

    This is the jump-start post for the eleventh week of the WordPress 4.6 release cycle.

    Beta 2 will land on Wednesday. Our target until then is to get the ticket count in the 4.6 milestone down to 80. (Beta 3 => 40, Beta 4 => 20, RC1 => 0.)

    Priority tickets/projects this week:

    Meetings this week:

    Bug Scrubs

    Feature Chats

    Weekly Chats

    * July 4 is a federal holiday in the US. Meeting could be canceled or postponed.

  • Eric Binnion 9:02 pm on June 15, 2016 Permalink |
    Tags: ,   

    Week In Core, June 7 – June 15 2016 

    Welcome back the latest issue of Week in Core, covering changes [37659-37720]. Here are the highlights:

    • 62 commits
    • 67 contributors
    • 61 tickets created
    • 15 tickets reopened
    • 80 tickets closed

    Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

    Code Changes



    • Set a defined line-height for number type inputs to fix display issue in Safari. [37693] #37024


    Bundled Theme

    • Twenty Ten: Revert pot changes after update test.[37715]



    • Do not flag a comment as a duplicate if the comment_author_email is provided but not a match. [37713] #37093
    • Fix pagination totals in the response of the inline delete actions when filtering the List Table by comment_type. [37664] #36991


    • Ensure MediaControl fetches the necessary attachment data for rendering when dynamically added via JS. [37701] #36521
    • Update server-sent setting validation notifications as changes are entered. [37700] #36944


    • Prevent jumping when using the backspace button in the Text editor in Firefox and IE. [37684] #37072
    • quickTags: when the user selects some text by triple-clicking, then wraps it in a tag, and the last selected char is \n, insert the closing tag before the line break. [37661] #29571
    • Adjust the sidebar position when moving a postbox from one column to another. [37659] #35230



    • Docs: Add extensive documentation to the remove_accents() DocBlock outlining the accented characters core replaces. 37669] #34677


    • After [37702], correct the expected result in test_size_format(). [37705] #37037
    • In size_format() and wp_convert_bytes_to_hr(), replace kB with KB for consistency with other units. [37702] #37037
    • Docs: Replace HTTP links with HTTPS. [37674] #36993
    • Docs: Improve the DocBlock summary for add_theme_support(). [37673] #32246
    • Docs: Add documentation for the variadic second parameter, $args, accepted by add_theme_support(). [37672] #37067
    • Docs: Improve documentation for the $feature parameter in the DocBlock for add_theme_support(). [37671] #32246, #37067



    • Revert the test added in [37716], as it causes errors when running the full suite. [37718] #36790
    • Adjust the regex in wp_maybe_decline_date() to handle word boundaries correctly. [37717] #36790
    • Add a unit test for wp_maybe_decline_date(). [37716] #36790
    • Add context and translator comments to Back to %s strings. [37703] #37095
    • In remove_accents(), add support for de_CH and de_CH_informal. [37698] #37076
    • Simplify the WordPress update notice for translators. [37675] #35721

    Login and Registration

    • Fire wp_no_robots() in wp_die() only if function exists. This covers cases where wp_die() is used before general-template.php is loaded. [37689] #34401


    Networks and Sites

    • Docs: Update the documentation for get_site() and the get_site filter following the removal of the $output parameter in [37652]. [37699] #35791
    • Use to_array() method on WP_Site objects in wp_get_sites(). [37667] #36717
    • Introduce get_current_network_id(). [37670] #33900
    • Tests: Split get_blog_details() test into individual tests [37666] #36566
    • Tests: Move get_blog_details() tests to their own file [37665] #36566
    • Tests: User a data provider for wp_get_sites() tests. [37662] #36566
    • Tests: Move wp_get_sites() tests to their own file [37660] #36566
    • Avoid a PHP notice in get_permalink() if default category is unavailable. [37707] #36529


    • Normalize WP_PLUGIN_DIR in the test added in [37332], otherwise it fails on Windows. [37719] #29154
    • Fix edge-case where the tab=upload page can be accessed directly. [37681] #35429

    Posts, Post Types

    • Docs: Improve the return description for wp_get_post_categories() to include more information about possible return values. [37686] #37002


    • After [37692], don’t skip set_found_posts() when no posts are found. [37712] #36687
    • Allow plugins to supply post results instead of having WP_Query fetch them from the database. [37692] #36687
    • Docs: Improve first-order clause documentation for the $meta_query parameter in the constructor for WP_Meta_Query. [37688] #32659


    • Introduce a redirect_term_location filter to change the redirect on term editing. [37696] #36367
    • More specific cap check when processing category data on post save. [37691] #36379
    • Introduce term_taxonomy_id parameter for WP_Term_Query. [37683] #37074
    • Tests: Move WP_Tax_Query tests to a more appropriate file. [37682] #37074

    Text Changes

    • Text Changes: Simplify two strings in wp_password_change_notification(). [37704] #35736


    • Make default “read more” link more accessible. [37706] #36572




    • Embeds: In WP_oEmbed::get_provider() and WP_oEmbed::get_html(), parse the $args string to an array, as we treat it as an array later. [37720] #37071
    • wp_signon() expects an array as the $credentials argument, not a string. [37697] #37071
    • Stop WP_List_Table notices from persisting on pagination navigation. [37663] #35620

    Thanks to @flixos90, @adamsilverstein, @AdamSoucie, @afercia, @afragen, @alexvandervegt, @azaozz, @boonebgorges, @dashaluna, @dd32, @dlh, @DrewAPicture, @EFAREM, @ethitter, @flixos90, @grapplerulrich, @Ipstenu, @iseulde, @j-falk, @jeherve, @jeremyfelt, @jipmoors, @jnylen0, @joelwills, @joemcgill, @john_schlick, @johnbillion, @johnjamesjacoby, @johnpgreen, @joostdevalk, @jorbin, @JoshuaGoodwin, @azaozz, @jpdavoutian, @Kau-Boy, @khag7, @kraftbj, @mapk, @melchoyce, @michael-arestad, @obenland, @ocean90, @odysseygate, @pansotdev, @paulwilde, @pento, @peterwilsoncc, @Presskopp, @rachelbaker, @ramiy, @ramiy, @rmccue, @ronalfy, @ryelle, @semil, @SergeyBiryukov, @simonvik, @spacedmonkey, @stephdau, @svovaf, @swissspidy, @TimothyBlynJacobs, @tlovett1, @westonruter, and @zakb8 for their contributions!

  • voldemortensen 8:46 pm on June 13, 2016 Permalink |
    Tags: , ,   

    Shiny Updates V2: Partial Merge Approved 

    During the extra meeting held today, Monday June 13th, 2016 at 13:00 MDT, Shiny Updates V2 was approved for a partial merge to core. The changes that will be merged are install, update, and delete for themes and plugins in single and multisite.

    This affects:

    • plugin.php
    • plugin-install.php
    • import.php
    • themes.php
    • themes-install.php
    • The “more-detail” modals in those screens

    The parts that will not be merged are the changes to update-core.php. The team now has time until Wednesday, June 15th 23:59 UTC to get the core patch committed.

    Congratulations and thanks to the Shiny Updates team for all the hard work they’ve put in this release. Most notably @obenland, @swissspidy, and @mapk. Thanks to everyone who reviewed, helped test, or otherwise contributed to Shiny Updates V2, we hope to see you involved with Shiny Updates V3. 🙂

    The full chat log is located here: https://wordpress.slack.com/archives/core/p1465844429000062

    • David Anderson 9:51 pm on June 28, 2016 Permalink | Log in to Reply


      The current state of wp-admin/themes.php prevents my plugin (WP’s most-installed backup plugin) from doing its job (which is, creating a pre-upgrade backup via a modal that pops up, much in the way that the filesystem credentials modal can also pop up and cause the upgrade to wait for it to finish).

      I’ve filed a patch in Trac to add a needed trigger here:

      Many thanks,

  • Dominik Schilling 1:24 pm on June 13, 2016 Permalink |
    Tags: ,   

    Additional meeting to consider the Shiny Updates plugin for merge 

    As announced in last week’s dev chat we’ll have an additional meeting to consider the Shiny Updates plugin for merge today, June 13th, 2016 at 19:00 UTC.

    Following a summary of the merge discussion from June 8th.

    Merge Criteria

    A plugin exists in the official WordPress plugin repository, is updated regularly, and is used/tested by the community.

    ✅ https://wordpress.org/plugins/shiny-updates/

    Weekly chats are taking place on Slack, and the feature lead is attending the weekly core dev chat.

    ✅ Meetings took place in #feature-shinyupdates.

    A kickoff post and regular update posts are published publicly, tracking the progress and major decisions of the feature plugin.

    ✅ Kickoff post at https://make.wordpress.org/core/2016/04/18/shiny-updates-chat/ and update posts at https://make.wordpress.org/core/tag/shiny-updates/

    The feature works in all of the browsers that WordPress officially supports.

    ✅ IE8+ and other current browsers were tested

    Touch devices can use the entire feature with no hindrance, with visual records for major flows through all new interfaces on all devices posted on Make/Flow. Make sure it functions properly on mobile by asking the Flow team to review it.

    ✅ https://make.wordpress.org/flow/tag/shiny-updates/

    Visual records comparing old flow with new flow are provided for any feature that changes or replaces existing interfaces.

    The code conforms to the WordPress coding standards.

    ✅ Assured through the use of a code sniffer and Travis CI: https://travis-ci.org/obenland/shiny-updates

    Similarly, the code is well-tested, and has unit tests.

    ✅ QUnit tests: https://github.com/obenland/shiny-updates/blob/master/tests/tests.js, closed issues: https://github.com/obenland/shiny-updates/issues?q=is%3Aissue+is%3Aclosed

    The code is well-documented. (Be sure to ask the Inline Docs team to review it.)

    🅾️ @drewapicture wasn’t around but @obenland said that “he’d like to wait with the review until there is a core patch, and he pinged me this morning saying he wanted to review it today”.

    The code follows the plugin security best practices, and has undergone a security audit.

    🅾️ Only a rough audit was done. @aaroncampbell was asked to look at it.

    The user interface/experience has been tested through user testing, and appropriate feedback was incorporated. (Be sure and ask the Design team to review it.)

    🅾️ @mapk was the design lead and provided help with design questions. Turns out there was no review for the whole project, only comments on GitHub issues and talks in Slack. A review was requested on May 16th.

    The design is fully responsive, displaying properly on any mobile device, and using graphics that are ready for hi-dpi/retina displays.

    ✅ https://make.wordpress.org/flow/tag/shiny-updates/

    HTML validates to the proper doctype.

    The code has all of the proper hooks in place for localization. (Be sure to ask the Polyglots team to review it.)

    WordPress continues to function, and the feature is still usable, with JavaScript turned off.

    ✅ That’s true, except for the Update All button.

    The feature can be used with just a keyboard.

    ✅ Confirmed by @aferica.

    Any required accessibility support has been added, including (but not limited to) off-screen text, ARIA, and JS-assisted. (Be sure to ask the Accessibility team to review it.)

    A merge proposal has been published on the Make/Core blog once the plugin is ready.

    ✅ https://make.wordpress.org/core/2016/06/02/proposal-more-shiny-updates/


    More Feedback

    • @jorbin: The QUnit tests should be merged with the existing tests.
    • @michael-arestad started with a design review during the chat.
    • @helen asked: “Given that there was a goal of really polishing the plugin and that it literally has the word “shiny” in the name, how much changing post-merge are people comfortable with?”
    • @mikeschroder raised a concern on error specificity which is something that he’d consider to be a big support problem.
    • @jorbin asked: “Who is comfortable merging after the unit test changes unless something the team working on shiny updates team or security team or design team considers major comes up?” @jorbin, @joemcgill, @azaozz, @jeremyfelt, @mapk, @markjaquith, @mikeschroder, @ocean90, @boonebgorges, @karmatosed, @ipstenu, @afercia, @rachelbaker, and @paulwilde reacted with a 👍.
    • @helen objects: “This seems a little like flexing to favor a merge – that poll is actually saying “this is not ready for merge until XYZ”. I am not saying that that is necessarily a terrible thing, but per my question about what amount of change people (project contributors, committers, etc.) are comfortable with, I am wondering if there is a bit of shifting of mindset from “ideal feature process” to “let’s get it in”.


    With 3 teams having a blocker and at least one person who needs more time to review it was decided to set a new deadline for feedback: Monday, June 13th 2016 at 12:00 UTC. An additional meeting will be held on Monday, June 13th 2016 at 19:00 UTC.

  • Pascal Birchler 9:47 pm on June 2, 2016 Permalink |
    Tags: , , , ,   

    Proposal: More Shiny Updates 

    The Bleak screen of Sadness™ 😢 that users encounter when installing/updating/deleting plugins or themes is a terrible experience WordPress users. It’s not timely anymore and doesn’t reflect the values WordPress strives to adhere to. Instead, WordPress needs a simpler and more straight forward experience when installing, updating, and deleting items.

    That’s why the Shiny Updates Team is proposing a merge of the Shiny Updates plugin into WordPress 4.6 💥. We’re eager to hear feedback from WordPress core contributors and users alike.

    Old plugin install process

    Existing plugin install process, showing The Bleak Screen of Sadness.

    Purpose & Goals

    The Bleak screen of Sadness™ is disruptive to user workflows, pulling them out of the context of plugins or themes, and dropping them into a screen filled with technical details that most users don’t care about or don’t understand. Shiny Updates deals with these details behind the scenes, maintaining the context of the triggered actions and leaving users with clear actions and results.

    This caters to two core principles of WordPress, designing for the majority, and striving for simplicity. Users don’t really care about the internal process of installing or updating themes and plugins. Listing out these technical steps for them is unnecessary at best.

    With Shiny Updates these actions also don’t require a page reload anymore, which creates a simpler workflow without context changes and lets users achieve their goals of an enhanced WordPress experience quicker.

    We also revamped the whole Dashboard -> Updates page to improve simplicity and make the process of updating translations and WordPress core shiny as well. 🎉

    Project Background

    Whether it was through the update mechanism available under Dashboard -> Updates or the automatic updates introduced in version 3.7, WordPress has always been encouraging users to update their sites to the newest versions.

    Plugin updates have been made shiny in WordPress 4.2, but now we want to extend this to other areas as well. Shiny Updates v2 improves the update process for themes, translations and even WordPress itself, as well as install and delete workflows for plugins and themes.
    As of today, the plugin has been downloaded about 8,000 times and is actively installed on over 1,000 WordPress sites. We’ve gotten input from many users and core committers through GitHub and during regular meetings in the #feature-shinyupdates.

    You can read more about the shiny updates flow with various visual records on make/flow, where we also shared results of the various user tests we did. Doing multiple rounds of user testing has really shaped the whole project and helped us refine the plugin and improve the overall usability of installing updates in WordPress.

    Implementation Details

    Shiny Updates builds upon the shiny plugin updates feature already existing in core, which basically consists of some JavaScript and Ajax callbacks for updating plugins in the background. As such, it can easily be extended by the new JavaScript parts of Shiny Updates. All new JavaScript functionality is available under the wp.updates umbrella.

    Here’s it looks like in action:

    In addition to that, we propose a revamped updates overview under Dashboard -> Updates. It’s simpler, more elegant, more shiny:

    Shiny Updates Table

    With Shiny Updates, the Dashboard -> Updates page gets a much needed overhaul

    Relevant Core Tickets

    Merging Shiny Updates into core would resolve a long list of outstanding trac tickets related to updates, including #31529, #31530, #31531, #31532, #31534, #31535, #31773, #33637 and #35032. All tickets related to Shiny Updates can be found here.

    Remaining Issues

    There are a few remaining bugs on GitHub, which will be resolved by Friday, June 3rd. Since the revamped updates table relies on plugin icons being returned by the Plugins API, the API needs to be changed as part of the plugin directory update. The new directory will launch well before the 4.6 release, so that shouldn’t be a big deal. As a bonus, this change would also enable us to fix #30186.

    Contributors and Feedback

    This is a proposal and is subject to revision based on your feedback. If you haven’t already tried out the plugin, please download and install it from WordPress.org or the comfort of your WordPress admin. You can review the current code and leave feedback at the project’s GitHub repository or in #feature-shinyupdates on Slack.

    Thanks a lot to everyone who has been contributing to this plugin since its inception, especially @obenland for leading this project, @adamsilverstein for his numerous contributions, @mapk for helping with testing and UX, and @ocean90 for giving valuable feedback despite being super busy with leading 4.6.

    So far we’ve received positive feedback from different core teams like the accessibility and design teams, and we have reached out to @drew who will review the docs once a core patch is ready.

    • Paal Joachim Romdahl 9:58 pm on June 2, 2016 Permalink | Log in to Reply

      Nice update Pascal!

    • FolioVision 10:11 pm on June 2, 2016 Permalink | Log in to Reply

      Thanks for all the news about changes to updates. Still, aren’t we rushing incorporations into core with just 1000 installs and limited feedback?

    • Todd Lahman 10:34 pm on June 2, 2016 Permalink | Log in to Reply

      It would be nice if the theme updates were able to provide a “view version details” like, as it displayed for plugins. It would be helpful if users could see the theme changelog, for example, before updating.

      • Pascal Birchler 11:53 pm on June 2, 2016 Permalink | Log in to Reply

        No worries, we got you covered! This will be part of the revised updates table, see this GitHub issue

      • Pascal Birchler 10:56 am on June 3, 2016 Permalink | Log in to Reply

        Actually, there’s currently no easy way to show a “View version details” link that opens a modal showing the theme information that is fast, shiny and accessible. That’s why we decided to not include this for now in Shiny Updates, but instead look at it separately in trac.

    • menkom 10:42 pm on June 2, 2016 Permalink | Log in to Reply

      Fantastic addition, smoother workflow…. but wouldn’t it be nice to also have a sweet little button that also allows you to roll back to the previous installed version is ‘shit’ hit the fan :D. I think it will give that added sense of confidence.

      • Pascal Birchler 12:00 am on June 3, 2016 Permalink | Log in to Reply

        I’d want to encourage users to be using the latest and greatest version of WordPress. That’s why security updates are installed automatically if possible. Adding a rollback functionality is the opposite of that effort and the opposite of shiny updates 🙂

      • Ipstenu (Mika Epstein) 2:43 am on June 3, 2016 Permalink | Log in to Reply

        Sadly that wouldn’t be possible with anything but major releases of core.

        Plugins and themes are not reliable enough with their uses of versioning to make it a reality.

      • Hugh Lashbrooke 7:47 am on June 3, 2016 Permalink | Log in to Reply

        There’s a plugin that adds a roll back option for all of your plugins if you really want that kind of thing.

    • Justin Sternberg 10:43 pm on June 2, 2016 Permalink | Log in to Reply

      You mentioned the W.org API needing an update, which makes me curious/concerned if/how this affects plugins which use an alternate update source (like the github updater plugin). Has anyone tested shiny updates with the github updater?

      • Pascal Birchler 11:56 pm on June 2, 2016 Permalink | Log in to Reply

        The dotorg API change mentioned in the post is not required for Shiny Updates, it would simply allow us to display a plugin’s icon in the updates table. Nothing that would conflict with GitHub updater or other similar solutions. So far there were zero problems with those.

    • buzztone 10:58 pm on June 2, 2016 Permalink | Log in to Reply

      I’ve been using the Shiny Updates plugin on several sites over several versions. This will be a significant well justified improvement to WordPress core.

    • Rene Hermenau 6:24 am on June 3, 2016 Permalink | Log in to Reply

      LOVE it! Thats a really neat feature. The screencast is very usefull to convince people of the need for using updates.

    • Biz2Web 6:41 am on June 3, 2016 Permalink | Log in to Reply

      We like the general idea and love that you’re working on this. For us however the plugin falls short on some points and if this would be forced into core feel like a step back on several areas. To name one: no selective updates but only “All” or “Single” items updates. Also the plugin fails to update core on the first site I try and therefore “Update all” doesn’t work either (I think). Anyhow, making / leaving this optional doesn’t seem to be that bad a choice for now to us and of course we’re very interested to see where this goes in the future. Let me emphasize that we love the initiative and work you put in here.

      • Biz2Web 6:45 am on June 3, 2016 Permalink | Log in to Reply

        Ah, scrap that remark on selective updating. That’s available albeit on the plugin pages not the update page itself. Remains the fact that core with Shiny Updates wouldn’t update and without it that worked fine. Maybe a caching plugin issue. Not sure how / if the plugin accounts for that. Anyway, keep up the good work!

      • Pascal Birchler 6:56 am on June 3, 2016 Permalink | Log in to Reply

        Not adding checkboxes was a conscious decision and part of our efforts to streamline the whole updates page. Updating multiple or all items is way easier thanks to the added shininess, even without the checkboxes.

        Regarding the failed core update, it would be very helpful if you could submit an issue on GitHub with more information on that (like WordPress version, JavaScript errors, etc.).

    • Anthony Hortin 7:40 am on June 3, 2016 Permalink | Log in to Reply

      Looks great but why, after all these years, can we still not update existing plugins by uploading a zip file (in the case of plugins that aren’t from the .org repo)

    • Ross Wintle 8:17 am on June 3, 2016 Permalink | Log in to Reply

      Oh gosh yes, what Anthony just said. Can I +1 that?

      I do also see why you consciously chose an all-or-nothing approach. But I think I’d like to at least see “Update All”, “Update plugins”, “Update themes” and “Update translations” as options. Major core updates can introduce changes or new functionality and I like to brief my clients on these changes before running major core updates. So updating just plugins and just core has been a feature that I use a lot.

      Otherwise, great work and I’m really loving it.

    • Ross Wintle 8:30 am on June 3, 2016 Permalink | Log in to Reply

      Forgive me for testing some edge cases. I had some issues with the original shiny updates, so I’m trying out some stuff with this shiny updates update.

      I’m also not massively keen on the dynamically-added failure notices (https://cloudup.com/cwJsWXtSop7).

      The GIF below is a simulation of an case where connection from the web server to wordpress.org it lost and multiple updates fail. It results in the screen jumping all over the place in a situation where things are failing and the user may be panicking.


      It would also be good, if possible, to get more information about failures when they happen. A network connection fault has a very different resolution to a file permissions problem. I’d like to see more information about why an update failed, even if it’s tucked away behind a “more details” link or something.

    • Ross Wintle 9:09 am on June 3, 2016 Permalink | Log in to Reply

      Sorry – one more thing. This screen isn’t a whole lot of fun: https://cloudup.com/co20RuhJPNG

      The blue button at the top is lying (it says “Updated” when that’s clearly not the case) and there’s no indication about what to do next. It really needs a “try again”, “reset”, “refresh status” or something. I know that if I refresh this page then the statuses will reset, but I’m not normal…the flow for an ordinary user in this situation would be:

      • Log in to Dashboard
      • “Oh, I have updates”
      • Navigate to Updates
      • Click “Update All”
      • Updates fail
      • Argh. Panic. What do I do now?

      We should really try to help users in a situation where something seemingly bad (failed updates) has happened.

    • seraphyn 9:33 am on June 3, 2016 Permalink | Log in to Reply

      Great Idea, but wouldn’t it be great to show the changelog within the row of the updateable plugin?
      Atm we know we need to update and to find out what was happening with the code, the reason etc we need to investigate.

      • Pascal Birchler 10:55 am on June 3, 2016 Permalink | Log in to Reply

        We display the upgrade notice every plugin author can set in the readme.txt file, just like core currently does. You can click on “View version %s details” to read the changelog. Nothing changes there.

    • Vitor Madeira 11:14 am on June 5, 2016 Permalink | Log in to Reply

      This is such a great idea.

      Pascal, I wonder if it would be possible to integrate within the Shiny Updates, a “one click” solution so users can rate their installed plugins.

      I mean, some two to three days after the user had installed the plugin, your interface would show the five star button that’s available on the plugin repository in wordpreess.org, so users would only have to click in there, and the plugin rating would be updated in the repository immediately.
      (Eventually, a text field would open next, so the user could writesome words regarding his/her opinion telling why had chosen to rate the plugin the way it rated on the stars button.)

      You see, when someone needs to go to wordpress.org searching for plugins, it is so strange to see that most of plugins have thousands of installs but the vast majority only get few tens (well, some get few hundreds, but that is really rare) of ratings.

      That is just not good. Something is not working well on the plugin rating scheme nowadays.

      Your solution would be the best thing that plugin rating could get to increase a bit more the precious information that one needs to get when a search for a new plugin is on our way on the repository.

      Thank you so very much for all your precious work.

    • jeffmcneill 1:15 pm on June 6, 2016 Permalink | Log in to Reply

      I’ve got a few issues. 1. In multi-site it appears to activate the root site, but not the network, and throws me back to the root site’s plugins, not the network plugins. Clearly not multi-site aware. 2. From the Add Plugin area it allows to install and activate but not deactivate or remove? Should be able to at least deactivate if can activate from the add plugin screen. 3. Still have the horrible presentation of the six “featured” plugins every-single-time-I-go-to-add-a-plugin. I don’t get it, that is the same sadness as the grey screen, actually it is more noisome. I realize that automattic and buddypress have five of the top six. Couldn’t there be something either more relevant (none of those plugins are relevant to me, but I see them every-single-time), or more calming. Even a grey screen of sadness would be better. Same with “Recommended” plugins, complete noise. “Popular” plugins? Meh. Now, the “Favorites” tab is actually a great one, if that could be the default and if the username could be saved, well now, that would be amazing functionality and lack of sadness.

    • Ahmad Awais 6:51 am on June 7, 2016 Permalink | Log in to Reply

      Thanks for the update, Pascal! Looks pretty cool. I just tested and it worked just fine. Few concerns though

      Let’s just say there could be a setting in General setting where one could disable the Shiny updates, just like there was for image uploading via old browser uploader, just to be safe in the next two major releases.

      • Ahmad Awais 7:06 am on June 7, 2016 Permalink | Log in to Reply

        @swisspiddy BTW when a plugin is installing we get the maintenance screen, this is not the case with Shiny updates. It could potentially break sites.

      • Pascal Birchler 7:30 am on June 7, 2016 Permalink | Log in to Reply

        Why would you want to disable Shiny Updates? Keep in mind that Shiny Updates have already been enabled for plugin updates since 4.2. There’s no reason I’d want to disable that now.

        Regarding the maintenance screen, other users will see that, except you. Hence no breakage. If you want to navigate away from the page, you’ll get an AYS confirmation dialog.

        If you encounter any issues, please feel free to submit it on GitHub 🙂

    • Brian Krogsgard 3:49 pm on June 8, 2016 Permalink | Log in to Reply

      I’m a bit concerned about the lack of selective updating, where a user can update multiple plugins, but exclude some.

      Primary use case: add-ons to plugins, for example, WooCommerce. In such an instance, I would normally update the add-ons so that they will be compatible. with the new major version of WooCommerce. Then I would update WooCommerce.

      I understand the notion of clearing up the screen, but it isn’t uncommon for users to have a dozen or more plugins that need updating at one time. In this scenario, where someone may be consciously holding off on one or two updates, isn’t it good to be able to selectively update the rest?

      I realize you can still multi-select on the plugins page, but doesn’t that just create a separate and confusing experience? It feels a bit like removing functionality for the sake of it to me.

  • Konstantin Obenland 8:06 pm on June 1, 2016 Permalink |
    Tags: , ,   

    This is a summary of the shiny updates chat from May 31. (Slack log)

    Attendees: @ocean90, @swissspidy, @mapk, @afragen, @screamingdev, @ipstenu, @obenland


    • Merge plan
      @swissspidy will have a merge proposal ready for review and publish on 6/2. Friday, 6/3, was set as the deadline for code changes so that there will be enough time to prepare a core patch prior to next weeks Feature Plugin meeting.
    • Overall status
      We discussed various options around how to display a notice on update-core.php when there are no updates pending. The issue of dismissible updates was brought up, and whether that could be deprecated. That should be brought before a bigger audience at the next dev chat. Allowing plugin installations from import.php came up as well; we need to find a solution there and make the experience better. We ended with discussing implementation details of various open tickets, that don’t have an effect on the bigger picture

    Next meeting is on Tuesday June 7, 20:00 UTC.

  • Konstantin Obenland 1:06 am on May 27, 2016 Permalink |
    Tags: , , ,   

    This is a summary of the shiny updates chat from May 24. (Slack log)

    Attendees: @ocean90, @swissspidy, @mapk, @ryelle, @melchoyce, @adamsilverstein, @obenland


    • Open Pull Requests
      • @swissspidy was waiting for feedback and a merge on PR120, which happened right after conclusion of the meeting.
      • @ryelle was waiting for clearance to re-globalize pagenow in order to make more parts of shiny updates testable.
    • Overall status
      We should be at a point where we can write the merge proposal and a patch in the coming week. We have one more week to fix more bugs and get some more user eyes on update-core and themes. @ocean90 mentioned two core tickets that should be fixed before merge, #13071 and #36914 and asked for review and testing there.

    Next meeting is therefore on Tuesday May 31, 20:00 UTC.

  • Konstantin Obenland 7:50 pm on May 17, 2016 Permalink |
    Tags: , ,   

    Shiny Updates Chat Summary 5/17/16 

    This is a summary of the shiny updates chat from May 17. (Slack log)

    Attendees: @ocean90, @swissspidy, @j-falk, @mapk, @ethitter, @obenland


    • Accomplished work since last week
      • Review requests were posted to the Accessibility, Flow, Polyglots, and Design teams.
      • The feature project landing page was written and published.
      • @swissspidy merged update-core.php into master.
      • Lots of bug fixes and smaller enhancements went in.
    • Activate after install
      We discussed what the best way would be to provide users with the ability to activate a plugin after it was installed. @swissspidy offered to work on a way that would switch the install button to an activation link after the install queue emptied, so it can be user tested for a more informed decision.
    • Update core
      @swissspidy‘s update-core work was merged into master, where it will remain to receive a broader test coverage than it would in a branch. All updates (except for ‘update all’ button) work via ajax.
    • Open floor
      We decided on a new meeting time, 20:00 UTC, that is one hour later than before.

    Next meeting is therefore on Tuesday May 24, 20:00 UTC.

  • Konstantin Obenland 8:16 pm on May 11, 2016 Permalink |
    Tags: , ,   

    Shiny Updates Chat Summary 5/10/16 

    This is a summary of the shiny updates chat from May 10. (Slack log)

    Attendees: @ocean90, @swissspidy, @paaljoachim, @j-falk, @mapk, @obenland


    • Accomplished work since last week
    • Remaining work
      The landing page for feature projects still needs to be written, as well as contributor groups asked to review Shiny Updates. @ocean90 opened a few issues that need addressing as well. These things should all be done by the time of the next meeting though.
    • Activate after install
      Shiny Updates introduced a disconnect between installing a plugin and then activating it. @mapk offered to solicit more UX feedback to address what happens when there are plugin install request in the queue while the user wants to activate a plugin, and how WP signals a successful installation while changing the button action to Activate.
    • Open floor
      …was mostly spent on discussing approaches to update-core.php and inconsistencies between the theme and plugin install UI.

    Next meeting is on Tuesday May 17, 19:00 UTC.

  • Konstantin Obenland 7:43 pm on May 4, 2016 Permalink |
    Tags: , ,   

    Shiny Updates Chat Summary 5/3/16 

    This is a summary of the shiny updates chat from May 3. (Slack log)

    Attendees: @ocean90, @swissspidy, @ethitter, @adamsilverstein, @mapk, @obenland


    • Accomplished work since last week
    • Remaining work
      @obenland will work on the Shiny Updates landing page for feature projects and fix a bug that were discovered during the most recent user test. @mapk offered to conduct another user test focused on the new interactions with some learnings from the previous one. Goal is to identify any hiccups or behaviors that are unexpected to users. @swissspidy wants to continue working on update-core.php and see if we can get it into shape for 4.6.
    • Most recent user tests
      We briefly talked about the most recent user test (linked above). It showed a variety of bugs that @obenland initially assumed were based on being in subviews of the plugin list. After the meeting it turned out that the test site ran an outdated version of WordPress that didn’t include some of the date that Shiny Update needs to work. It was a good demonstration of progressive enhancement here though, as all actions still worked, they just weren’t shiny. More user tests to come, to make sure that users agree with the new interactions.
    • Schedule for 4.6 inclusion
      Next up is writing the merge proposal that was requested to be published around 6/1, definitely before 6/8.

    Next meeting is on Tuesday May 10, 19:00 UTC.

    • Scott Fennell 7:55 pm on May 4, 2016 Permalink | Log in to Reply

      Hello! I have a question about the shiny updates work — and thanks for the work, by the way.

      I have written a plugin for my own personal use (not a .org plugin) which allows me to use the core update class for updating plugins/themes that are hosted in a private bitbucket account. It works by flitering the plugin/theme data at `pre_set_site_transient_update_plugins` and `pre_set_site_transient_update_themes`.

      I was wondering if the shiny updates work could jeopardize either of those filters. Would you be able to comment on this concern?

      Aside: My plugin is pretty similar to a more well-known project called GitHub Updater.

      • Konstantin Obenland 8:03 pm on May 4, 2016 Permalink | Log in to Reply

        Hi Scott, thanks for your feedback!

        Shiny Updates doesn’t use these filters, it’s more focused on the UI of installing/updating/deleting plugins and themes. I’d encourage you though to download and activate the plugin to test how it interacts with your plugin just to make sure (and maybe let us know if you encounter any bugs or weird behavior).

    • Andy Fragen 8:03 pm on May 4, 2016 Permalink | Log in to Reply

      Hey Scott! Aside from some styling changes that will likely need to be made, the functionality of GHU and Shiny Updates work great together.

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