PHP Meeting Recap – October 16th

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: @felipeelia @flixos90 @jdgrimes @mte90 @schlessera @sergey @stevenkword @tobifjellner @vizkr

Chat Summary

The agenda for this week was to continue discussion on the GitHub issues that deal with the planned “Before Upgrading PHP” section.

  • @flixos90 started by giving a brief recap on last week’s meeting, particularly on the discussion of the PHP Compatibility Checker plugin by WP Engine and the changes that need to be made to it in order for it to be referenced and recommended by the Servehappy page and core. Together with the lead developers of that plugin, he will explore the next steps.
  • The meeting then focused on the individual GitHub issues.
  • “Ask hosting provider”: This is kind of a fuzzy issue as to whether that is useful depends entirely on the individual hosting provider. One idea was to focus on managed hosts only for this and in the copy start with something like “If you are on a managed host, they may be able to…” – however, it may be a better decision to not mention this at all, as it would be hard to give valuable advice. No clear decision was made on this yet.
  • “Updates”: WordPress core, plugins and themes should be up to date (of course only plugins that do not require a higher PHP version in their update). As these updates can also break the site without even getting to the PHP part, this point should therefore mentioned after the “Backup and rollback plan” point. In regards to that, it may be helpful to recommend doing an extra backup after everything has been updated (still before the PHP upgrade) – however only if storing multiple backups is possible with the solution the site owner is using for their backups.
  • “Ask plugin/theme support”: This is definitely good advice when using premium plugins or themes with paid support. For community-driven plugins, it really depends on the popularity of the plugin and how many volunteers are helping out for the respective plugin. A related idea that came up was to create a list where support volunteers can add specific plugins with issues on certain PHP versions to so that over time a crowdsourced resource to find out about possible issues in advanced will evolve. Since @danielbachhuber and XWP have apparently been working on an automated solution for a similar cause, it may be valuable to combine these efforts. The result could for example be an API that delivers data on plugin compatibility with different PHP versions, taking both automated and manually submitted data into account. What to present about this point on the Servehappy page heavily depends on what these projects will end up working like.
  • “Check WP.org plugin/theme info”: It was decided that this point should not be included. There is no plugin information on the maximum supported PHP version, and even if there was, the majority of plugin authors would not update it accordingly over time (the same issue that is currently happening with the “Tested up to” field for the WordPress version). Furthermore, most developers whose plugins have issues on a more modern PHP version likely do not know about it or are not maintaining the plugin any longer.
  • “Test locally/on staging”: This point should be ditched as well, as it is much too advanced. A local environment is definitely not something trivial to set up for a non-technical person. For staging it depends on the site owner’s hosting provider again, but even on hosts that offer 1-Click-Staging, it can be a complex task – especially since several hosts do not allow changing PHP versions differently between the environments of a single site.

Next week’s meeting

The next meeting will take place on October 23rd, 2017, 18:00 UTC as always in #core-php, and its agenda will be to finalize discussion on the remaining GitHub issues for the “Before Upgrading PHP” section, with the following week focusing on transfering all these thoughts into copy. If you have suggestions about this 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: October 18th (4.9 week 12)

This post summarizes the dev chat meeting from October 18th (Slack archive).

4.9 schedule and priorities review

  • Down to 54 tickets in the 4.9 milestone, aiming to get to 40 in time for Beta 3
  • Beta 3 build process will begin around Wednesday, October 18th 20:00 PDT / Thursday, October 19th 03:00 UTC
  • Starting next week, we’ll have 2x weekly bug scrubs to get to launch
  • Note the critical bug in Safari that breaks the new theme browsing/installation experience in the Customizer; please help on this if you're familiar with Safari
  • Integration issues with Shiny Updates and the new theme installation experience in the Customizer (see: #42184). In particular, the FTP credentials modal needs work for when it gets dismissed.

Dev Notes

General announcements

  • @mnelson4: #38583 could use feedback, ideally from from REST API component maintainers

#4-9, #core, #core-customize, #core-restapi, #dev-chat, #safari, #shiny-updates, #summary

Multisite Recap for the week of October 9th

Office Hours Recap

The agenda for this office hours meeting was to review 4.9 bug and task tickets that still need to be finished and merged within Beta, particularly continuing from where the ticket scrub meeting stopped.

The meeting’s chat log

Attendees: @earnjam, @flixos90, @jeremyfelt, @jjj, @johnbillion, @josheby, @spacedmonkey, @stevenkword

Chat Summary:

  • #41936: It was decided that the new filter pre_get_main_site_id should not actually set the WP_Network::$blog_id property when used and only override the return value when accessing it, as it could otherwise have unexpected consequences if a hook set for it was (temporarily) removed. The latest patch had one issue where a variable had not been correctly renamed after moving the code from the function to the class method. It was furthermore discussed how verbose and strict casting the value returned by a filter should be. It was decided to only return the filter value if 0 < (int) $value. Both issues have since been fixed in the latest patch.
  • #38570 and #41652: @sergey is taking care of these i18n tickets.
  • #41789: @johnbillion will provide feedback.
  • As there is now a 5.0 milestone on Trac, the priority tickets that were previously flagged with “Future Release” and “early” are now being moved into the actual milestone.
  • #40364: @flixos90 asked for feedback for this rather complex ticket, as it should preferably get ready early in the 5.0 cycle. That ticket should be discussed in detail in one of the next few weeks, once the multisite work for 4.9 has wrapped up.

Next meeting

The next office hours will take place on October 17th, 2017, 16:00 UTC. Its agenda will be to continue discussing 4.9 tickets and the dev-note for the Networks & Sites component.

Ticket Scrub Recap

The agenda for this ticket scrub was to review 4.9 bug and task tickets that still need to be finished and merged within Beta, similar to the office hours meeting agenda this week (see above).

The meeting’s chat log

Attendees: @afercia, @flixos90, @jeremyfelt, @jjj, @paaljoachim, @spacedmonkey

Chat Summary:

  • #41936: It was decided that moving the logic that is currently in get_main_site_id() is okay to be moved to WP_Network:get_main_site_id(), since that data is very specific to each individual network. It must furthermore be ensured that all values are properly typecast into the expected type (WP_Network::$blog_id is a string, WP_Network::$site_id is an integer and WP_Network::get_main_site_id() should always return an integer). Minor tweaks suggested were returning get_current_blog_id() instead of a hardcoded value of 1 in get_main_site_id() for non-multisite environments and using an internal variable for the cache key used. @spacedmonkey and @flixos90 will make sure this gets ready.
  • #42093: @jeremyfelt has been working on providing an easy way to run unit tests for a subdomain install. This ticket is currently a task scheduled for 4.9, but may as well be punted to 5.0 in case it does not get ready in time.
  • #39419: It was agreed on that the doc block for the globals should indicate replacements to use for those that are deprecated. @jeremyfelt has since updated the patch. It is still being considered whether globals such as $table_prefix, which are used there, but not actually set up there initially should be listed as well.
  • #41789: It was briefly discussed how to be most precise about the documentation of the get_sites() (and related WP_Site_Query method) return value, without making the description overly complex. @jeremyfelt added the final idea as a comment on the ticket and is now waiting for feedback. It was also mentioned that documentation for the other query classes should probably be changed in a similar way, however the ticket for now should only deal with sites and networks.

Next meeting

The next ticket scrub will take place on October 16th, 2017, 17:00 UTC. Its agenda will be to continue discussing 4.9 tickets, particularly the issue that came up with #40228.

If you were unable to attend one of these meetings but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in one of next week’s chats. See you next week!

#4-9, #multisite, #networks-sites, #summary

Dev Chat Summary: October 11th (4.9 week 11)

This post summarizes the dev chat meeting from October 11th (agendaSlack archive).

4.9 schedule and priorities review

  • Today is the Beta 2 deadline
  • Beta 2 build process will begin around Wednesday, October 11th 20:00 PDT / Thursday, October 12th 03:00 UTC
  • Next on the 4.9 release schedule will be Beta 3 next week on Wednesday, October 18th
  • Alpha/Beta/RC Forum has been quiet, excepting one that turned into a beta2 fix
  • Fix for PHP file editor came in via Twitter
  • Testing ideally focused on:
    • Remapping of nav menus and widgets when switching themes (see #39693 and #39692)
    • The updates the theme/plugin code editors
    • Scheduling and drafting in the Customizer
    • Locking in the Customizer (like post locking, but for your site changes)
    • Theme browsing and installation in Customizer
    • Revamped nav menu creation flow
    • Video and gallery widgets, plus Text widget with embeds
    • Browser testing, especially mobile + IE
  • 16 tickets still need patches
  • Would appreciate help reviewing patches and committing from committers over next two weeks

Dev Notes

  • 24 tickets tagged with needs-dev-note
  • Dev Notes were due with Beta 1, so we're behind on those
  • Please aim to publish those by this time next week so we can compile them into the Field Guide before Release Candidate

General announcements

  • @paaljoachim: Has there been any discussion about Twenty Eighteen theme?
    • No plans as of now for Twenty Eighteen, likely not enough time to start and finish by end of the year anyway
  • @presskopp: looking for an answer on my question on #42131
    • Recommendation to check with the Widget component maintainers who may otherwise be focused on Customize-related defects with 4.9

#4-9, #core, #core-customize, #dev-chat, #media-widgets, #summary

Multisite Recap for the week of October 2nd

Office Hours Recap

The agenda for this office hours meeting was to prepare remaining open enhancements for the 4.9 release.

The meeting’s chat log

Attendees: @flixos90, @spacedmonkey, @jeremyfelt

Chat Summary:

  • #40228 – Review the latest patches for using get_site_by() in get_blog_details().
  • #40201 – Review the latest patches for using get_site() in clean_blog_cache(). @flixos90 and @jeremyfelt agreed that requiring a site ID is okay for clean_blog_cache(), moving the refresh_blog_details hook into clean_blog_cache() is appropriate, and deprecating the refresh_blog_details hook in favor of clean_site_cache is good.
  • @flixos90 committed to committing #40201 and #40228 before 4.9 beta.
  • #42072 and #42073 – Discussed both of these, which involve limiting get_sites() calls to 1 result when only 1 result is used. @jeremyfelt took ownership of these for 4.9.
  • #41762 – Agreed to use WP_Network_Query in ms_load_current_site_and_network(), but to keep the current-network cache key for now.

Next meeting

The next office hours will take place on October 4, 2017, 16:00 UTC. Its agenda will be to go over remaining bugs for 4.9 and the progress of this cycle’s dev notes.

Ticket Scrub Recap

The agenda for this ticket scrub was to review remaining enhancements for the 4.9 release.

The meeting’s chat log

Attendees: @ramiy, @sergey, @afragen, @flixos90, @spacedmonkey, @jeremyfelt, @johnjamesjacoby, @desrosj

Chat Summary:

  • #40180 – Discussion on some of the remaining details for get_site_by().
  • #40228 – Agreed to finish and commit #40180 so that the patches for get_site_by() in get_blog_details() would be easier to review.
  • #40201 – Discussion if clean_blog_cache() should support an empty argument as a replacement for refresh_blog_details(). Agreement that it’s okay to continue requiring that a site be specified.
  • Discussion on when or whether to deprecate refresh_blog_details() or its hook refresh_blog_details, which is now a part of clean_blog_cache(). It seems that it’s okay to postpone this until get_site_by() and clean_blog_cache() are more widely used.

Next meeting

@jeremfelt did not clarify early enough whether or not a ticket scrub will take place on October 3, 2017, 17:00 UTC. 🙈 A loose agenda would be to cover remaining bugs for the 4.9 cycle.

If you were unable to attend one of these meetings but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in one of next week’s chats. See you next week!

#4-9, #multisite, #network-sites, #summary

PHP Meeting Recap – October 2nd

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: @flixos90 @jdgrimes @jpry @joostdevalk @garyj @mte90 @nerrad @schlessera @sergey @techjewel

Chat Summary

This meeting revolved around discussing the “Before Upgrading PHP” section.

First, we quickly brainstormed a list of possible actions we could recommend:

We later created an issue for each of these possible actions, and the above list links to these.

Then, we discussed in more detail how a non-technical site-owner could run compatibility checks, and in what ways we could automate this. There are two main directions that need to be evaluated: static analysis & runtime checks.

The static analysis can be done through the PHPCS library. There’s a usable plugin wrapper called “PHP Compatibility Checker” that already does all the required work of wrapping the PHPCS command line tool into a WordPress plugin and provide a neat user interface. However, this plugin currently contains a direct entry point into the sales funnel of WPEngine, the hosting company that funded its development. While this is just fine to refer people to on a personal basis, we currently consider this a show-stopper when it comes to officially endorsing this plugin, as it would mean that we’re sending existing customers from other hosting providers from within the admin backend they’re hosting to their competitor’s sales page. We decided we’d contact WPEngine to see whether they would be willing to collaborate on a “toned-down” version of the plugin.

[ NOTE: in the meantime, discussions with the hosting company responsible for the above plugin were very fruitful, and they are willing to change the plugin to defuse the sales message. ]

While we also discussed the merits of runtime checks when installing/updating plugins, we came to the conclusion that is is not reliably feasible, as it is not possible to reliably hit all possible code paths of a given plugin/theme in an automated manner.

We briefly went over the new “Required PHP version” information, and whether a “Tested up to PHP version” was already discussed. Most people think that this is not easily kept up to date and will lead to stale information. However, the possibility should be explored whether the statistics collected upon plugin updates could not be used to statistically deduce whether a given PHP version can be assumed to be safe to use.

We briefly mentioned Backups as well before the end of the meeting. These cause some of the same issues, in that we don’t want to link to specific vendors at the expense of others. For now, we’re thinking it’s best to give general advice about what to watch out for with the backups, and then link to something like this page: https://wordpress.org/plugins/search/backup/

As already stated we have created GitHub issues for every topic, and an overview of these can be found in the “Before Upgrading PHP” section of the Sections” project board. Any feedback on this topics is welcome!

Next week’s meeting

The next meeting will take place on Monday, October 9, 2017 at 18:00 UTC, as always in #core-php, and its agenda will be to go over the feedback added to the individual sections and distill the information. If you have suggestions about this 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: October 4th (4.9 week 10)

This post summarizes the dev chat meeting from October 4th (agendaSlack archive).

4.9 schedule

  • Today is the Beta 1 deadline for enhancements and feature requests. All tickets have been scrubbed as of earlier today, any that are still open when the Beta 1 build process begins later today will be punted to Future Release.
  • Next on the 4.9 release schedule will be Beta 2 on Wednesday, October 11th.
  • 30 enhancements and features still in the milestone
  • Beta 1 build process will begin around Wednesday, October 4th 20:00 PDT / Thursday, October 5th 03:00 UTC

Gutenberg block data storage

  • Want to start thinking about and discussing how block data is stored. We currently (specially after allowing meta attributes) have a lot of ways to store block data, with different tradeoffs. It’s going to be important to communicate when each is appropriate.
  • This will come through examples and documentation, but generally such knowledge has also spread by core contributors doing talks and blog posts, etc.
  • As people start to look at creating blocks, there are various ways to specify attributes, and different ways things can be saved (static blocks, dynamic blocks, etc). A lot of the reason people used custom fields or meta attrs will be different as blocks allow individual attributes that are still part of the content.
  • If you have input to share on that, please join in #core-editor and their weekly meetings.

REST API Handbook

  • They are moving / have moved the REST API Handbook content to GitHub.
  • Once it’s deployed, the REST API handbook’s content will be managed in GitHub.

General announcements

  • @rskansing: I want to give a thanks to the security team for always being very nice and polite in regards to my many queries and questions

#4-9, #core, #core-restapi, #dev-chat, #gutenberg, #security, #summary

Multisite Recap for the week of September 25th

Office Hours Recap

No office hours meeting took place this week.

Next meeting

The next office hours will take place on October 3rd, 2017, 16:00 UTC. Its agenda will be to get the 4.9 enhancements ready to be merged before Beta, and then coordinate remaining work on 4.9 bug tickets.

Ticket Scrub Recap

The agenda for this ticket scrub was to look through the multisite tickets without a response.

The meeting’s chat log

Attendees: @afragen, @flixos90, @schlessera, @spacedmonkey

Chat Summary:

  • The issue with the suggestion in #41443 is that wpmu_validate_blog_signup() is supposed to validate new sites submitted by regular users, not by administrators, so that function would not be applicable for usage on the New Site network admin page. However, some restrictions for new user-submitted sites do not apply to admin-created sites, so these restrictions should be reviewed and possibly adjusted to work more similarly to each other.
  • #41685 is a very early ticket, since it requires the site meta API and related blogmeta database table in order to be worked on. It was agreed on that it would generally make sense to store site database versions in the new table instead of an entirely separate table. However, since these versions are not used anywhere in core and since it is questionable whether the blog_versions table can be removed for backward-compatibility reasons, this still needs a deeper discussion once site meta is actually part of core.
  • #41936 was figured out to be a minor bug with the new get_main_site_id() not taking the possibly already set WP_Network::$blog_id property into account. This should definitely be fixed for 4.9. The current patch by @spacedmonkey moves the logic from the function to the WP_Network class method, which is not preferable, but might end up being the only way to accomplish the goal without running into an infinite loop issue. @flixos90 will try to find a better way to fix the issue, but if nobody finds one, the current patch is solid enough to go in. This can happen last minute though, as this will be a bug-fix and does not need to be merged before beta.

Next meeting

The next ticket scrub will take place on October 2nd, 2017, 17:00 UTC. Its agenda will be reviewing the 4.9 enhancements and coordinating who works on the possibly required changes so that another review can happen during the office hours a day later.

If you were unable to attend one of these meetings but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in one of next week’s chats. See you next week!

#4-9, #multisite, #networks-sites, #summary

Dev Chat Summary: September 27th (4.9 week 9)

This post summarizes the dev chat meeting from September 20th (agendaSlack archive).

4.9 schedule

  • Today is the feature project merge deadline
  • Bulk of the code editor improvements already merged into core, along with the Gallery widget
  • Theme browsing in the Customizer and drafting & scheduling in the Customizer to be merged tonight or tomorrow at the latest
  • Beta 1 in next Wednesday, enhancement tickets due by then
  • Bug scrubs scheduled over next week
  • @joemcgill: Anyone wanting to rubber duck #21819 over approaches in the media meeting tomorrow would be good
    • trying to solve a UX issue with a broadly defined outcome and different possibilities include varying levels of tech complexity
  • @danieltj: recommend putting version info into At A Glance metabox #35554
    • @melchoyce: let's get feedback on this and work to a decision in the next couple days

General announcements

  • @azaozz: removal of SWFUpload #41752 needs more testing in the affected plugins
    • would be great to see how the fallback works in all of them, so please help test
  • @kadamwhite: The REST API team is having a bug scrub on Friday at 15:00 UTC, and likely another the start of next week (time TBD). We’ve got a lot of tickets sitting with patches that are pretty close, so if you’ve got outstanding REST patches to discuss hope to see y’all then in #core-restapi!
  • @johnbillion: if anyone is running PHP 7.2 (currently in beta) it'd be great to test trunk. Some fixes will be going in shortly to remove deprecated notices, apart from that it should be bug free.
  • @obenland: Since [41594], orphaned widgets will get merged into the inactive widgets sidebar on theme switch, instead of becoming orphaned. what your opinions are on removing the concept of orphaned widgets entirely, and just have them be part of the inactive sidebar?
    • pre-41594 they would be shown in separate Orphaned Widgets sidebars above inactive widgets
    • @melchoyce: Looking for someone to take screenshots or a video of this in action on 4.8 and on trunk, so we can compare them visually

#4-9, #bug-scrub, #core, #dev-chat, #media-widgets, #php7, #summary

Customize Meeting Summary: September 25th

This post summarizes the Customize meeting from September 25th in the #core-customize Slack channel (Slack archive).

Participants: @westonruter, @melchoyce, @obenland, @sirjonathan, @joemcgill, @sayedwp, @jbpaul17. Misbehaving: @tracbot.

Discussion highlights

Drafting and Scheduling

Gallery widget

Customizer UX for themes

Bug scrub

  • Trac listing of the enhancements and feature requests milestoned for 4.9 for the team
  • #39930: docs changes, so changing this from enhancement task ticket
  • #28721: related to and will be resolved when #39896 is merged
  • #34843: will be resolved by #37661
  • #35827: no one working on this, so punting to Future Release
  • #40527: punting
  • #40922: punting
  • #37964: will be picked up by @sayedwp when #39896 is done
  • #38707: CSS highlight part is implemented, but “revisions, selection, per-page, pop-out” is not
    • “per-page” aspect has been yanked from consideration in the near future
    • will work on revisions, selection, and pop-out in a feature plugin outside of core
  • #39275: likely to be resolved in #39896
  • #40104: @bpayton hopes to have a patch up by Friday
  • Topic for future devchat: What is the difference between a feature request and a feature project. It’s not really formalized. Are we deeming “feature request” to be the same as “feature project”?

Next week’s meeting

The next meeting will take place on Monday, October 2, 17:00 UTC in the #core-customize Slack channel. Please feel free to drop in with any updates, questions, or tickets you’d like to discuss. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9, #bug-scrub, #core-customize, #media-widgets, #summary