PHP Meeting Recap – July 24th

This recap is a summary of this week’s PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

The meeting’s chat log.

Attendees: @desrosj @dnavarrojr @euthelup @flixos90 @jdgrimes @joyously @markjaquith @presjpolk @psykro @ptasker @sergey

Chat Summary

In the beginning of the meeting, the process of defining the problems an unsupported PHP version causes continued, with a particular focus on WordPress. Some problems that were highlighted by @markjaquith and @jdgrimes:

  • WordPress supporting legacy PHP makes it less appealing for developers from outside of the WordPress world to contribute to the project.
  • WordPress supporting legacy PHP will cause the quality of plugins to decrease over time due to the lack of good developers entering the WP marketplace.
  • WordPress supporting legacy PHP causes security issues and a worse performance (the latter especially compared with PHP 7+). Improvements to both would be an immediate result of upgrading, of which WordPress cannot manage the technical debt completely.
  • WordPress supporting legacy PHP results in several users not having access to some of the best plugins as they require a higher version.
  • WordPress supporting legacy PHP results in a higher chance of running unmaintained plugins.

Afterwards the discussion shifted towards the efforts of informing users about legacy PHP.

  • A challenge is that in most cases the next step would likely not be clear when showing users a notice about an outdated PHP version.
  • A more organical way than showing a notice to let users know that their setup is outdated is official support for PHP requirements of plugins (see #40934): When a user sees their plugin is not going to work any longer, they know for fact that they need to do something. It is important though to not just add the warning that the plugin does not work because of the installed PHP version, but also at the same time being able to inform the user about what this means.
  • A wordpress.org page to link to would be a good first step. It should highlight the problems legacy PHP causes for the user, and provide general information on how to upgrade, the latter being the most tricky part. The benefits of such a page is that it could easily be updated without having to wait for a core release. An early Meta Trac ticket has since been opened to work on such a page.
  • It would also be great to allow hosts to integrate with any notice displayed in the admin, for example they could add a link to their own upgrade page through an environment variable. While many hosts that still have their users on unsupported versions are unlikely to follow WordPress and thus would not take care of this, there are also a number of more considerate hosts that however have not switched their users because they do not wanna do it without their consent. In those cases such an integration could work and be beneficial.
  • WordPress itself bumping the minimum required PHP version at some point should also be highlighted to the user. While we need to be thorough in our steps, such efforts should become visible sooner than later to users so that they have enough time to upgrade.
  • Some users will inevitably not have upgraded when WordPress ups its requirement, and those users will admittedly be in a worse state than they are now. But given that such a great amount of others will be in a much better state, we have to be honest with ourselves that there is no way to make this a zero-pain for everyone. Our goal is to get the number of users on those versions as low as possible and then determine a solid point when to upgrade the requirement, based on those numbers.
  • As mentioned before, plugins are a good reason to upgrade as well. The quality plugins that don’t support PHP 5.2 outnumber those that don’t support PHP 7.0, and that’s only going to increase.

The last topic of the chat was to review the changes proposed as part of #40934 on the Meta side of things.

  • @sergey explained the plans and asked for feedback, particularly for whether they could go in or required more discussion.
  • While the core-related changes in that direction will need more time, particularly with how users are going to be informed, there was consensus that the Meta part of it is ready to be committed.
  • An idea about also being able to specify a “Tested up to PHP” version in the plugin header was brought up, or even supporting semantic version specification like with Composer. After discussing it however, the result was that introducing such a feature would easily cause unnecessary uncertainty among users. Although it could theoretically help users decide whether they should upgrade or not, in most cases it will without a good reason show a warning that the plugin has not been tested. That is because while many plugins would still work on a new PHP version, users would often still see it as not tested just because the plugin developers have not updated the header yet. This is already a commonly known issue with the existing header about which WordPress core version a plugin has been tested with. Therefore such a header should not be introduced.

Next week’s meeting

The next meeting will take place on Monday 18:00 UTC, as always in #core-php, and its agenda will be to brainstorm how a wordpress.org page informing users about legacy PHP could look like and what it should contain. If you have ideas but cannot make the meeting, please leave a comment on this post so that we can take them into account. See you next week!

#core-php, #php, #summary

Dev Chat Summary: January 18th (4.7.2 week 1)

This post summarizes the dev chat meeting from January 18th (agendaSlack archive).

4.7.x Releases

  • Moving to monthly checkins for 4.7.x releases
  • A few people stepped up to lead a future 4.7.x releases, a great way to get involved in the release process. If you’re interested in leading a future minor release, ping @samuelsidler anytime.
  • For 4.7.2, we haven’t set a schedule yet, but we’ll be checking tickets and commits in early February to decide if we should release. @jnylen0 will be the release lead.
  • Reminder for those who helped get 4.7.1 out, please check the handbook to see if updates are needed to help @jnylen0 on 4.7.2.
  • @jnylen0: some API stuff I want to get into a potential 4.7.2, but let me know about other tickets you’d like to milestone
  • Outside pressure on MIME issues not as horrific as one might have expected (ticket #39550: Some Non-image files fail to upload after 4.7.1)
  • Potential that since people using special MIME types (which are the most likely to get caught by this bug) are already aware of having to add in custom mimes, adding in the “unbreak” plugin to fix the problem right now isn’t seen as insurmountable.

REST API team update

  • kicking off the new year by defining the scope of our activities, and prioritizing what is most critical to do first
  • @kadamwhite, @jnylen0, @tharsheblows, @kenshino, & others working on expanding the documentation
  • As we’ve moved the support for the REST API from the “WP-API” github repo, we’re seeing a few repeat questions that can be clarified with better docs & docs organization
  • Today we finished grouping existing docs from the old wp-api.org site into “Using” and “extending” buckets, which are reflected in the left nav; next up, we’ll be adding more docs for using the basics of what’s there
  • @rmccue leading the technical investigations into what to prioritize from an implementation standpoint (see: January 9th 4.8 kickoff meeting notes)
  • a lot that could be converted to use the API within WP-Admin, but change for the sake of change has never been a core value of this project
  • Whereas for something like list table actions, there’s a lot of inconsistency within the admin and converting some of those areas of functionality to use the REST API endpoints would be a clear win
  • We’re using a Trello board to track the areas of investigation
  • the Multisite and BuddyPress teams are both investigating how best to improve or create API endpoints tailored to those use cases
  • @flixos90 did an excellent writeup of our users endpoint discussion
  • We are sorting out how user and site membership management and display should work for the users endpoint.
  • master ticket #39544: REST API: Improve users endpoint in multisite
  • the REST API team intends to continue using the feature projects model to structure proposed API enhancements (such as menu support), with the added requirements of starting from a design document, and checking in with a core committer for periodic review to avoid the feature project from becoming silo’d
  • Multi-site is the first such feature project that’s officially under way.
  • For 4.7.2 we should be looking for related bugs around the existing functionality
  • @jnylen0: propose that we continually evaluate test and documentation coverage for new additions, as an excellent way to find bugs before they ship and we are stuck with them
  • Regarding bugs, to all: when (not if) you find a documentation issue or omission, or find an area where the API does not behave as expected, you are all welcome in #core-restapi at any time and we welcome the feedback.
  • We’re glad to see that the support questions so far tend to fall in a few specific buckets, but this is a new thing and the more eyes on it, the more likely that we’ll be able to identify the key areas where improvement will really drive admin or customizer improvements.
  • REST API team meeting is weekly at Monday 14:00 UTC in #core-restapi, and we welcome one and all to come chime in about how you’d like to see this used

Customizer team update

  • Please read and contribute to the discussion happening on the “What makes a great customization experience?” post
  • Also recommend reading through the meeting that happened earlier today in #core-editor. There’s going to be a lot of overlap, especially as the editor team starts working on content blocks. Lots of discussions have been happening there and in #core-customize related to what we focus on for customizer in the immediate term.
  • We’re identifying some smaller, quick wins we can do to improve the customization experience while content blocks are being built.
  • Update coming on Make/Core soon for more ways to get involved and a separate post from @karmatosed on Make/Design for some ways to help us test the existing customization flow
  • Customize team meeting is weekly at Monday 17:00 UTC in #core-customize, please do join us for general brainstorming and ticket triage (see also: prior meeting notes)

Editor team update

  • Please read and comment on the “Editor Technical Overview” post
  • Recap of #core-editor meeting on a target of a prototype plugin for exploring these concepts from @matveb: Yes, target could be:
    • Data structure.
    • Parsing mechanism.
    • General UI for block display / controls.

Trac Ticket(s)

  • #39535: Canonical redirects disallow tag named comments
    • @asalce: looking to get owner on the ticket and review of patch
    • will ping @markjaquith or @dd32 as maintainers of Canonical component

#4-7, #4-7-2, #dev-chat, #summary

Week In Core, June 29 – July 5 2016

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

  • 77 commits
  • 50 contributors
  • 87 tickets created
  • 12 tickets reopened
  • 86 tickets closed

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

Code Changes

Administration

  • List tables: Make the pagination links and text better responsive. [37912] #33962

Build/Test Tools

  • Unit Tests: Change some @group annotations to @ticket. [37954]
  • Unit Tests: Remove @group foo annotation from Tests_WP_Resource_Hints::test_dns_prefetch_styles(). [37951]
  • Unit Tests: Remove an unused parameter from Tests_Ajax_DimComment::test_with_bad_id(). Prevents a “too few arguments” error in PHP 7.1.0. [37950] #37271

Comments

Customize

  • Fix site icon preview in RTL. [37964] #37286
  • Prevent image controls with selected images smaller than pane width from being distorted through stretching to fit width. [37957] #37277
  • Use the correct variable when referring to the media frame. [37955] #36236
  • Text change on Widgets and Menus screens for buttons directing users to the Customizer. [37904] #37159
  • Add a RTL version of “browser.png” for the site icon preview. [37963] #37063
  • Reverse order of setting sanitization/validation, validating prior to sanitizing. [37942] #34893, #37192, #37247

Editor

Embeds

  • After [37745], check if a featured image exists before attaching an event listener. [37977] #35657

General

  • Docs: Fix a typo across some function and hook docs. s/filterss/filters. [37961] #32246
  • Remove the Pragma header from responses. [37944] #37250
  • Docs: Add changelog entries to the hook doc for the safe_style_css filter denoting recent CSS attribute additions. [37931] #35877, #32246
  • Return “O B” when passing 0 to size_format(). [37962] #36635

HTTP API

  • Add unit tests for wp_get_http_headers() and wp_remote_retrieve_headers(). [37907] #37090

I18n

  • Make the translator comment added in [37858] more explicit and consistent with other similar instances. [37948] #37147
  • Localize the jQuery UI datepicker. [37908] #29420
  • Adjust the regex in wp_maybe_decline_date() to avoid \w and \b, as they don’t work with Unicode characters correctly in PHP 5.3.3 and earlier versions. [37979] #36790
  • Add tests for wp_maybe_decline_date(). Reverts [37718], $wp_locale needs to be cloned. [37975] #36790

Media

  • Avoid PHP notices when trying to show a parent post title of an orphaned post type. [37952] #37186
  • Only show parent post titles when the user can read said post. [37941] #37186
  • Improve form validation errors handling when editing images. [37966] #36316
  • In Walker_Nav_Menu_Edit::start_el() initialize $original_title with false. Prevents displaying “Original:” without a title when adding a menu item without a title. [37953] #36729

Networks and Sites

  • Docs: Remove duplicate text for is_main_site() parameter. [37932] #37241
  • Simplify logic assigning orderby in get_site_by_path(). [37930] #37215
  • Revert [37874]. After [37923], get_blog_details() contained a now unnecessary attempt at back-compat for objects stored in cache. [37929] #36717
  • Revert property type changes in WP_Site. [37922] #34292
  • Docs: Supplement a changelog entry in the DocBlock for the $id property in WP_Network. [37919] #36717
  • Lazy load extended WP_Site properties when requested. [37918] #36935
  • Docs: Add changelog entries to the DocBlocks for the $blog_id and $site_id properties in WP_Site. [37917] #36717
  • Fire the ms_loaded action after multisite’s bootstrap has finished. [37916] #37235
  • Network Admin: Replace “Options saved.” notice with “Settings saved.”. [37959] #37279

Options, Meta APIs

  • Make retrieving registered metadata actually work. The initial implementation used a single argument, which has now been added to the whitelist. [37934] #35658
  • Ensure $args is an array and simplify compat logic. [37933] #35658
  • Actually use fallback auth for the previous registration method. [37928] #35658
  • Introduce an expanded meta registration API. There still need to be lots of tests written for previous and new behaviors, and many things are subject to change. Maybe things will explode. #yolo [37924] #35658

Plugins

  • Return the original value in apply_filters_deprecated() if no filter is registered for the tag. [37911] #10441
  • Tests: After [37861] move tests for deprecated filters into filters.php. [37909] #10441
  • Clean up uninstall_plugins option during database upgrade. [37965] #31625

Posts, Post Type

  • In wp_ajax_inline_save(), do not apply level for non-hierarchical post types. [37913] #35010

Post Thumbnails

REST API

  • Include a refreshed nonce in a X-WP-Nonce header when responding to an authenticated request. [37905] #35662
  • Include auto-discovery Link header when serving API requests. [37903] #35580
  • Reverse order of setting sanitization/validation, validating prior to sanitizing. [37943] #37247, #37192

Script Loader

Text Changes

Themes

  • Avoid announcing the theme search results too many times. [37967] #36848
  • After [37287], remove deprecated feature category. [37947] #33407
  • After [37287], add deprecated theme features to the tag list in WP_Theme::translate_header().
  • Add “Custom Logo” to the list of WordPress theme features. [37945] #33407, #36744
  • Docs: Fix typo in WP_Theme_Install_List_Table description. [37937] #37234
  • After [37742], fix the color of the “Upload Theme” button to match other page title actions. [37968] #35457

Upgrade/Install

  • dbDelta() will no longer try to downgrade the size of TEXT and BLOB columns. [37939] [37938] #36748
  • Change priority for theme/update update rows. [37978] #13071
  • Reject invalid messages in the Shiny Updates postMessage handler. [37976] #37125
  • Fix plugin updates from the details modal on the Dashboard. 37974] #37131, #37126
  • Fix plugin updates from the details modal on update-core.php. [37973] #37126
  • Correctly decrement the update count after translation updates. [37971] #37127
  • Trigger a JS event when updating a theme. [37970] #37216
  • Trigger the correct event after installing an importer plugin. [37969] #37273

Users

  • Docs: In wp_list_authors(), clarify that include and exclude arguments can also be an array. Fix duplicated exclude argument description. [37949] #37239
  • Check zxcvbn is defined before calling. [37940] #34905

Widgets

  • Dashboard: Don’t add a “Configure” link to the toggle button. [37972] #35021

XML-RPC

Thanks to @aaires, @adamsilverstein, @afercia, @aidvu, @azaozz, @barryceelen, @birgire, @borgesbruno, @celloexpressions, @clubduece, @danielbachhuber, @DavidAnderson, @DrewAPicture, @ericlewis, @Faison, @flixos90, @Frozzare, @geekysoft, @grapplerulrich, @helen, @jeremyfelt, @jipmoors, @joemcgill, @jorbin, @Kenshino, @littler.chicken, @markjaquith, @nicholas_io, @Nikschavan, @ocean90, @Offereins, @patilswapnilv, @noahsilverstein, @pento, @peterwilsoncc, @polevaultweb, @Presskopp, @rabmalin, @rachelbaker, @ramiy, @rmccue, @sc0ttkclark, @schlessera, @SergeyBiryukov, @sidati, @spacedmonkey, @swissspidy, @voldemortensen, @welcher, and @westonruter for their contributions!

#4-6, #week-in-core

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.

#4-6, #shiny-updates

Component Page Updates for 4.4

Now that 4.4 is underway, let’s update the component pages to reflect 4.4 activity. The Customize, Editor, and Press This pages serve as good templates, though they all need 4.4 updates. The component pages are targeted at beta testers. They should describe the component, list milestones (roadmap), and explain what needs testing and how to test it. Good component pages assist triage. For details, see the previous round of component page updates.

Also, if your component has a corresponding Slack chat, link to the component page from the chat’s channel topic. This assists using Slack in beta testing flows.

Component maintainers, here are your component pages…

Continue reading

#components, #maintainership

Dev Chat Agenda for July 22

Here’s the agenda for tomorrow’s Dev Chat in the #core channel on Slack.

During Beta Notes @iseulde would like to discuss headings and whether to convert on space or enter in #31441. Please download the latest nightly and test the feature before Dev Chat, so we can talk about it.

Time/Date: July 22 2015 20:00 UTC:

  1. Beta Notes
  2. Feature Updates
    1. Admin UI – If @helen can make it
    2. Menu Customizer – @westonruter
    3. Passwords – @markjaquith
    4. Site Icon – @obenland
  3. Component Updates
  4. Open Floor

#4-3, #agenda

Dev Chat Agenda for July 15

Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

During Beta Notes I’d like to discuss how the installation flow feels now with the new Passwords UI enabled. Please download the latest nightly and create a new install with it before Dev Chat, so we can talk about it.

Time/Date: July 15 2015 20:00 UTC:

  1. Beta Notes
  2. Feature Updates
    1. Admin UI – @helen
    2. Menu Customizer – @westonruter
    3. Passwords – @markjaquith
    4. Site Icon – @obenland
  3. Component Updates
  4. Open Floor

Feature Leads: Let’s review last weeks goals and set new ones for next week.

#4-3, #agenda

Dev Chat Agenda for July 8

Here’s the agenda for tomorrow’s Dev Chat in the #core channel on Slack.

Time/Date: July 8 2015 20:00 UTC:

  1. Beta Notes
  2. Feature Updates
    1. Admin UI – @helen
    2. Menu Customizer – @westonruter
    3. Passwords – @markjaquith
    4. Site Icon – @obenland
  3. Feature Plugin Chat Next Week@samuelsidler
  4. Component Updates
  5. Open Floor

Feature Leads: Let’s review last weeks goals and set new ones for next week.

#4-3, #agenda

Dev Chat Agenda for June 24

Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

Time/Date: June 24 2015 20:00 UTC:

  1. Feature Updates
    1. Admin UI – @helen
    2. Menu Customizer – @westonruter
    3. Passwords – @markjaquith
    4. Site Icon – @obenland
  2. Component Updates
  3. Open Floor

Feature Leads: Let’s review last weeks goals and set new ones for next week.

#4-3, #agenda

Dev Chat Agenda for June 17

Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

Time/Date: June 17 2015 20:00 UTC:

  1. Feature Updates
    1. Admin UI – @helen
    2. Menu Customizer – @westonruter
    3. Passwords – @markjaquith
    4. Site Icon – @obenland
  2. Component Updates
  3. Open Floor

Feature Leads: Let’s review last weeks goals and set new ones for next week.

[EDIT]: Please test https://wordpress.org/plugins/wporg-site-icon/ in preparation for today’s chat.

#4-3, #agenda