PHP Meeting Recap – July 10th

This Monday the initial weekly PHP meeting took place. This recap is a summary of which ideas and decisions 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 @joyously @mte90 @ptasker @psykro @schlessera @screamingdev @tfrommen

Chat Summary

The topic we discussed this meeting was solely the current minimum PHP version requirement of WordPress, as it is the foundation that many code improvements are likely to rely on.

We came up with several ideas on how to raise awareness and increase pressure on hosting companies to upgrade PHP in a reasonable manner. We did not discuss these in detail yet, it was mostly a brainstorming session. Here is a list of what we came up with:

  • The first item has already been around (see #41191): There should be a nag in the WordPress admin dashboard indicating that an unsupported PHP version is being used. Security and performance are two examples of how to make an upgrade attractive to users. The most important part though will be to make it understandable and reasonable to people not tech-savvy.
  • The second item also exists already (see #40934): It should be possible to specify a minimum required PHP version for plugins. Once this is supported by core, it is likely that more plugins will raise their minimum requirement, so it will eventually be another way to make people aware. It should probably only happen in combination with the point above though, since otherwise there would not be a clear explanation of what PHP even is and why a supported version matters.
  • Related to displaying an admin notice, it could be valuable to gather data on which sites the notice appears to make a solid case for the business benefits of upgrading. However there were concerns expressed about privacy. The good part is that WordPress already collects some information during the update API requests and we could use some of that data to evaluate. A GitHub repository could be used to document the results.
  • Until core provides a solution, every plugin developer should consider showing a nag about the PHP version itself in case the plugin requires a higher version. This implies that the plugin’s main file must be PHP 5.2-parseable, even if the rest of the codebase requires a higher PHP version. Plugins that simply use modern PHP syntax in the main file provide a bad user experience by deliberately causing a fatal error and do not educate users about why the plugin does not work. There is a library by Yoast that can easily be integrated into any plugin and even provides more help than simply saying that the PHP version is outdated. It even makes sense to be integrated if the plugin supports PHP 5.2, in order to raise awareness, and the PHP versions for which it shows can be manually set by the plugin integrating it.
  • It could be helpful to have an article about the issues with a title like “Your WordPress might be insecure” and have that post appear in the admin dashboard news feed. This would be an easy way to raise at least some awareness and would not even require a WordPress update.
  • We could also reach out to the authors of very popular plugins and ask them to publish a post about the topic. It would reach a lot of WordPress users, also via newsletter.
  • The topic could be addressed in WordPress meetups around the globe. If you are a meetup organizer, consider bringing up this topic to educate people why they should upgrade and how to do it.

In addition to the above ideas we took the second half of the meeting to take a closer look at #41191 and think a bit more about the details of how the admin nag should work. These are the results of our discussion and the rough plan going forward:

  • The notice should recommend to jump to a PHP version >= 5.6. In addition it should highlight that jumping to a version >= 7.0 would be even better (especially for performance), but also carefully indicate that outdated plugins might have a higher chance of not working there properly.
  • The notice should initially only show on PHP 5.2 setups. While we want sites to go to a maintained version, this is a huge task and for WordPress to raise the minimum required PHP version it is most important at this point to decrease the number of sites running on PHP 5.2. Only showing it on 5.2 setups instead of everywhere below 5.6 will also reduce the support burden for hosts. Over time, once we are satisfied we can iterate to show the nag on higher versions as well, until we reach 5.5.
  • Once the number of PHP 5.2 sites is low enough, we can bump WordPress core’s minimum requirement to PHP 5.3. While that version is still outdated, the language-specific features of that version justify an upgrade more than any of the other planned upgrades, and furthermore the bump is already drastic enough like that. Jumping from PHP 5.2 to PHP 5.6 would likely result in a disaster. Again, over time we can iterate and bump the requirements until we reach a supported PHP version.
  • Once we are convinced that the time is right to move away from PHP 5.2, it would make sense to set up a clear roadmap for the subsequent version bumps. This gives hosts as well as developers a solid plan and overview so that they are prepared.
  • We still need to figure out which specific goal we should set, in order to determine when to bump the minimum requirement of WordPress to PHP 5.3. This will be a topic in a future meeting.

Next week’s meeting

The next meeting will take place on Monday 18:00 UTC, and we will continue talking about the PHP version bump and related plans there with the goal of figuring out which of our ideas are realistic and which timeframe we should be prepared for. If you have thoughts on the above or other ideas but cannot make the meeting, please leave a comment on this post so that we can take it into account. See you next week!

 

#core-php, #php, #summary

Dev Chat Agenda for July 12th (4.8.1 week 4)

This is the agenda for the weekly dev meeting on July 12, 2017 at 20:00 UTC:

  • 4.8.1 planning (beta, RC, translations, launch)
  • Editor / Gutenberg update
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-8, #4-8-1, #agenda, #dev-chat

New Contributors Meeting Recap – July 5

The inaugural New Contributors Meeting was held on Wed July 5th at 19:00 and had a great turnout with lots of questions asked in the #core channel (read the full archive ).

The informal agenda was to try and answer as many general questions as possible and then move over to a bug scrub/ticket review portion.

Discussion Highlights

Tickets Discussed:

  • #33756 – Improve docs for sanitize_title()
  • #38828 – Update_blog_details() performance improvement ideas
  • #38310 – Improve “wp_update_term” documentation

 

The next meeting will take place in the #core slack channel on Wed, July 12th at 19:00. Please feel free to drop in with any questions or tickets you’d like to discuss!

Thanks to everyone that attended and please feel free to leave a comment below or reach out to any of the moderators with questions.

Moderators: @flixos90, @welcher, @stevenkword, @desrosj

#new-contributors, #summaries

Multisite Agenda for the week of July 10th

Office Hours Agenda

This is the agenda for the weekly office hours meeting on Tuesday 16:00 UTC in #core-multisite.

  • Discuss the state of introducing a wp_blogmeta table and related *_site_meta() functions to store arbitrary data for sites, particularly as a means to extend the future sites REST API endpoint. There have been several discussions at WordCamp Europe, and we should soon come to a conclusion, whether it should be part of core or not. See #37923 for the respective ticket.

Ticket Scrub Agenda

This is the agenda for the weekly ticket scrub meeting on Monday 17:00 UTC in #core-multisite.

  • Go through the list of multisite-related good-first-bug tickets for new contributors. The major goal is to look at those tickets, briefly review where they’re at and adjust keywords as necessary. If a ticket appears to be overly complex or has been open and without activity for a longer while, the good-first-bug keyword should be removed.

Please join the chat if you’re interested in one of the topics. In case you cannot make the respective meeting, we will be working on publishing a recap post afterwards. If you have some thoughts beforehand or would like something related to be part of the agenda, feel free to share your ideas in the comments for this post. See you in the chat!

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

What’s new in Gutenberg? (July 8th)

First, we want to thank everyone who has been testing the plugin and providing feedback. It’s great to see so many people helping with the project. We are collecting feedback from the call to test in the repository, if you are curious.

0.4.0 🐢

We welcome all your feedback and contributions on the project repository, or ping us in #core-editor. Follow the “gutenberg” tag for past updates.

#core-editor, #editor, #gutenberg

4.8.1 Bug Scrubs

The following bug scrubs have been scheduled on tickets milestoned for 4.8.1 and the conversation will take place in #core.:

Reminder of the tentative timeline for 4.8.1 is the last week of July so we’ll be heavily focused on punting tickets out of the milestone to ensure it’s clean ahead of the intended launch timeframe.

#4-8, #4-8-1, #bug-scrub

Dev Chat Summary: July 5th (4.8.1 week 3)

This post summarizes the dev chat meeting from July 5th (agendaSlack archive).

4.8.1 planning

  • #40907 is committed to trunk, but needs user testing
  • #40951 has a good patch, but not committed yet and needs user testing
    • Main holdup is the best use of pointers (or another notice mechanism) to inform users to use the Custom HTML widget going forward for adding arbitrary HTML
    • Another possible use of pointers is when a user pastes HTML into TinyMCE, to correct years of pasting into the Text widget’s textarea
  • Aiming to make a 4.8.1-alpha release build to make it easier for those testing, will also note testing steps on respective tickets
  • Will schedule bug scrubs next week & post those times separately to Make/Core

REST API: image permissions model

Editor

General announcements

#4-8, #4-8-1, #core, #core-editor, #core-restapi, #dev-chat, #summary

Announcement for weekly PHP meetings

As you may have noticed, there is a new Slack channel named #core-php around. This channel is a result of several conversations at WordCamp Europe and a response to the #core-js channel for those who are more focused on PHP development.

While JavaScript is a hot topic in the WordPress space and requires a lot of attention given recent focuses such as Gutenberg or the Customizer, there have also been long-time concerns about PHP-related topics in WordPress core scope, which still lay the foundation for how WordPress works. The new channel aims to provide a space to discuss those topics to make the WordPress PHP codebase more sustainable in the long run.

Weekly meetings

There will be weekly meetings in the #core-php channel, happening every Monday at 18:00 UTC. The initial meeting will take place next week, on Monday 18:00 UTC. The agenda for the initial meetings will revolve around determining the objectives for the channel and which areas to work on. Before looking at code though, the first meeting in particular will focus on the ongoing efforts to increase the number of sites that run on a supported PHP version and to get sites away from the ancient PHP 5.2 so that we get closer to the point where we can raise the minimum required version.

Since we are dedicated to backward-compatibility as much as possible, we need to carefully examine all our steps which will take time. Therefore progress will likely be slower than what is currently happening in #core-js, which at the same time will make the outcome of all efforts as solid and seamless as possible.

Objectives

While it only took about six hours after the channel was created to find a proposal to rewrite the entire WordPress codebase, our steps and decisions should be small and sophisticated, of course considering longevity as well. As stated before, the actual objectives of the channel and weekly meetings will be determined during the initial chats. The following list is a small collection of ideas that have come up already:

  • A major purpose of the #core-php channel could be to look at existing code and figure out how to integrate improved patterns into it. Most core components handle their code changes individually, causing many inconsistencies in the codebase, and one goal of the weekly discussions could be to come up with realistic best practices that could then be documented and enforced for the future and, if possible, also for the code already present.
  • There are also thoughts about a more drastic refactor of specific parts of the codebase, which could use an abstraction layer to maintain backward-compatibility with the way things currently worked. While such efforts would take a longer time and even more solid reasoning to push through, the results may be worth the energy and time investment.
  • Moving to a more modern PHP version is, as mentioned before, another goal. We should continuously investigate possibilities to put pressure on hosts (and reasonably on users as well) so that the number of sites on outdated PHP versions will lower. We can already work on long-term plans in the mean time as our code-focussed enhancements, especially modern coding standards, should preferably take shape before we raise the minimum requirement.

Ideas in addition to the above are always welcome, and we will discuss those one by one. Once there is a consensus about something, we will spread the word to gather further opinions, for example during the weekly core dev chat or in another blog post.

Once we have determined the objectives, we will furthermore need to figure out how to efficiently collaborate on these projects, possibly in smaller working groups.

If you’re interested in making PHP great again, please join us on Monday 18:00 UTC in #core-php. If you cannot make the meeting but have further ideas, you can also leave a comment on this post prior to the meeting.

#agenda, #core-php, #php

Multisite Recap for the week of July 3th

Office Hours Recap

The agenda for this office hours meeting was to focus on the new sites CRUD API (not the REST endpoint).

The meeting’s chat log.

Attendees: @flixos90, @jjj, @maximeculea, @schlessera, @spacedmonkey.

Chat Summary:

  • Discussion about sites CRUD API (not the REST endpoint), see #40364. The goal here was to determine how we could refactor the site insertion and installation.
    • We’re planning to implement wp_insert_site()(for adding a row to the wp_blogs table) and wp_install_site() (for installing the site’s DB tables, populating options, etc). Both should be wrapped by a new wp_create_site() which will become a replacement for wpmu_create_blog().
    • Similarly, we will have wp_delete_site() and wp_uninstall_site() wrapped inside wp_remove_site(), which are counterparts of those before. The latter may not be clear enough, so we might need to find a better name. The naming discussion will continue on the ticket, and we’ll provide a summary about all the new functions.
    • About the technical details, a patch has been posted couple weeks ago. It seems to be a great first pass. However it passes around WP_Site objects which was the result of previous discussions, and there were concerns expressed at WCEU due to inconsistency with similar core functions. We therefore decided to use the common “$args pattern” instead for now, but maybe a chat could take place in #core-php at some point especially about consistency and new patterns.

The next office hours will take place on Tuesday 16:00 UTC. An agenda for it will be posted in advance.

Ticket Scrub Recap

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

The meeting’s chat log.

Attendees: @afragen, @andy, @flixos90, @ipstenu, @jmdodd, @maximeculea, @sergey, @spacedmonkey.

Chat Summary:

  • As we only had two tickets, we gave feedback and asked for more details to the first one, #40459.
  • The second one (see #41177) was more tricky. We had a chat about site deletion which is not triggering an AYS notification. As pointed, this should not be a JS Driven AYS but more be handled with a separate page which is showing up. A patch has been submitted.
  • In addition, we highlighted a great new feature for multisite development: Thanks to @loreleiaurora, it’s now easily possible to setup VVV development multisites for both subdirectory and subdomain setup.

The next ticket scrub will take place on Monday 17:00 UTC. An agenda for it will be posted in advance.

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 Agenda for July 5th (4.8.1 week 3)

This is the agenda for the weekly dev meeting on July 5, 2017 at 20:00 UTC:

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-8, #4-8-1, #4-9, #agenda, #dev-chat