Felix Arntz 3:36 pm on July 27, 2017
Tags: , , , , ,   

New Contributors Meeting Recap – July 26

Yesterday our weekly new contributors meeting was held, again with some great questions and insights into contributing to WordPress core. Here is the recap for the chat, alternatively the full chat log is also available.

Participants: @adamcarter @audunhus @desrosj @dipendahal @flixos90 @hardeepasrani @johnbillion @joyously @jsonm @samikeijonen @stevenkword @welcher @xkon

Discussion Highlights:

  • Working on one of the three focuses (Gutenberg, Customizer, REST API) is preferred, but it’s also as great to contribute to another area of core as development in those components of course has not stopped. Contributions are welcome everywhere, the focuses only gain more traction and attention at this point.
  • VVV is only one way to contribute to WordPress core. It is the recommended way to do so since it has all the tools needed preinstalled and configured, but contributors are free to choose whichever way they like. It might just require more setup work when not using VVV.
  • An easy way to make your IDE / editor aware of the WordPress coding standards regarding whitespace usage is to use the .editorconfig file that trunk contains. This file uses a common standard, and there are plugins available for almost all popular environments that automatically parse the file and adjust the whitespace settings for the project. Extensions can be found at on the website of the project. Some IDEs like PHPStorm already come with built-in tools for the WordPress coding standards.
  • While every new change in WordPress requires unit tests to verify its correct behavior (except for wording or docs changes, or those that are too complex to test for other reasons), it is not required that the person who writes a patch also needs to provide unit tests for it. It would be nice, but if someone doesn’t feel comfortable enough for the time being or first would like to get the patch reviewed, that’s perfectly fine as well.

Tickets Discussed:

  • #41370 is a good-first-bug ticket that could use some attention and work. It belongs to the REST API focus, so is likely to get reviewed and also merged quickly once ready. The goal of the ticket is to figure out why creating a term that already exists results in a 500 error, and change that to a more meaningful 400 or 409 error. Please have a look if you are interested in the REST API.
  • #41318 is another ticket that could use some work, particularly unit tests to ensure the existing patch works correctly.

First Props:

From this week on, we’ll highlight new contributors with their first props in this post. Props is what you get when a changeset lands in core where you have significantly helped with, for example through a patch, unit tests or something else. Please let us know about your first props when you get them. You can easily get an overview of your props at this URL: https://core.trac.wordpress.org/search?q=props+USERNAME&noquickjump=1&changeset=on (replacing USERNAME with your actual wordpress.org username)

This week, @xkon received his first props. Congrats! 🎉

Next week’s Meeting:

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

Thanks to everyone that attended! As always, please feel free to leave a comment below or reach out to any of the moderators with questions on Slack.

#new-contributors, #summary

Felix Arntz 2:26 pm on July 27, 2017
Tags: , ,   

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

Jeffrey Paul 2:55 am on July 27, 2017
Tags: , , , , , ,   

Dev Chat Summary: July 26th (4.8.1 week 6)

This post summarizes the dev chat meeting from July 26th (agenda, Slack archive).

4.8.1 RC feedback & release timing

  • No issues on the widgets front
  • Those who reported breakage from 4.8 widget changes and have tested RC have said the fixes work
  • @westonruter to write a dev note
  • @westonruter and @obenland to work on 4.8.1 release on Tuesday, August 1st as per previous plan
  • @obenland to work with @pento or @azaozz on walk thru for releasing a minor version
  • Post-4.8.1 release action item: get more committers access & training on releasing / Mission Control

Editor / Gutenberg media intricacies

  • Last Fridays’ release of 0.6 slipped due to vacations, working to push it out as soon as feasible
  • Several media intricacies that could use help / discussion, especially Issue#1986
  • 100 PRs open that could use help in reviewing/testing
  • Gutenberg part of weekly agenda of #core-media meeting (Thursdays at 18:00 UTC)

General announcements

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

Jeffrey Paul 5:33 pm on July 25, 2017
Tags: , , ,   

Dev Chat Agenda for July 26th (4.8.1 week 6)

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

  • 4.8.1 RC feedback & release timing
  • Editor / Gutenberg media intricacies
  • 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

Ryan Welcher 2:51 pm on July 25, 2017
Tags: , ,   

New Contributors Meeting Recap – July 19

Last week’s New Contributors Meeting was held on Wed July 19th at 19:00. Once again, there were lots of great questions asked in the #core channel. Read the full chat archive here.

Discussion Highlights:

Tickets Discussed:

  • #41155 – WordPress 4.8 Admin Sidebar Sub Menu Navigation Issue
  • #41317 – Consistent sub menu item spacing when count indicator is present
    • Congrats to @JDTrower for pushing it along and getting it in the 4.9 Milestone!
  • #41314 – If the required fields are not set on user profile’s save, every field’s value will be dropped

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

Thanks to everyone that attended! As always, please feel free to leave a comment below or reach out to any of the moderators with questions on Slack.

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

#new-contributors, #summaries

Jeffrey Paul 2:49 am on July 20, 2017
Tags: , , ,   

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

This post summarizes the dev chat meeting from July 19th (agenda, Slack archive).

4.8.1 schedule

  • Access to Mission Control was lacking and delayed 4.8.1 beta release
  • Working to commit #40974, #38964, #40794 for 4.8.1 beta
  • Final planned bug scrub is Thursday, July 20th 16:00 UTC / Thursday, July 20th 16:00 UTC
  • Bug scrub will be focused on punting anything not headed towards a commit by Friday
  • If tickets in milestone drops to zero, we will continue with the planned 4.8.1 schedule:
    • RC – Monday, July 24th (hard string freeze)
    • Launch – Tuesday, August 1st

General announcements

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

Felix Arntz 4:56 pm on July 19, 2017
Tags: , ,   

PHP Meeting Recap – July 17th

This recap is a summary of the second weekly 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: @drewapicture @flixos90 @jdgrimes @joyously @mte90 @psykro @ptasker @schlessera @screamingdev @sergey @sobak @varjik

Chat Summary

In the beginning of the meeting, the discussion from last week about investigating ways to increase the amount of sites on a supported PHP version was continued.

  • It was highlighted that a possible notice displayed to admins of sites on old PHP versions should have pluggable parts that would allow hosts to serve upgrade instructions specific to their platform. The minimum required there would be a host-specific link to a page with detailed instructions, which could for example be set through environment variables. This should be possible independently from core so that further integrations or changes would not require a new core release.
  • There should also be a general “Browse Happy”-type information page on wordpress.org, that the notice could link to either as a fallback or in addition to the host-specific URL. Such a page should explain what PHP is and why it matters that a supported version should be used. It should be an easy-to-understand and precise document that could also be shared in other instances. A GitHub repository could be set up to start work and beforehand gather similar sites that have already been created by third parties.
  • While we have mentioned before that plugins should be able to define their minimum required PHP version (see #40934), it should also be possible to define the PHP version the plugin has been tested up to. Otherwise we could only prevent installs of newer plugins, but outdated ones could still break on a new PHP version without any further notice.
  • In regard to that, while it may be impossible to do that, it would be great if WordPress had the possibility to automatically scan installed plugins and show a message to the admin that, for example all their plugins work correctly with PHP 7 or that some specific plugins might cause trouble on PHP 7. While the recommendation is to upgrade to PHP 7, there are several plugins that are not yet compatible, and a user should not learn that the hard way.

Later in the meeting @drewapicture emphasized that we had so far skipped a significant part: While everyone that was part of a discussion had apparently been convinced that WordPress should push for a more modern PHP version, we had never framed the actual problem (or problems) that this is currently causing. Therefore it was decided to take a step back and think about what those are. Even if WordPress is not going to raise the minimum requirement, the task is to specify why it is worth pushing hosts and users to a newer version. A good idea to approach this is to phrase problems like “WordPress supporting legacy PHP is…”. Here are some of the initial takes that came up:

  • WordPress supporting legacy PHP is making the developers spend more time chasing obscure bugs and less time building new features.
  • WordPress supporting legacy PHP means it will at some point completely lose connection to current PHP.
  • WordPress supporting legacy PHP has become more of a liability than a feature for its users.
  • WordPress supporting legacy PHP means other platforms will outpace WordPress soon.
  • WordPress supporting legacy PHP causes most development to just evaporate as compatibility friction.

These were just a few first thoughts that came up, and it’s important to spend more time on clearly defining the problem before proceeding, and especially consider how this causes a global problem for WordPress aside from specific groups like administrators, hosts or developers.

We need solid arguments to get backers, and we’d also need to figure out who the decision-makers are, get them involved and their buy-in. If you are reading this and you are a lead developer, long-time core developer or another kind of stakeholder in the project, we would be happy to have you onboard, or at least join the meeting for next week to help us frame the problem of WordPress supporting unsupported PHP versions.

In the aftermath of the meeting, there have since been several good thoughts and discussions happening in the channel which should also be considered in next week’s meeting. If you’re interested, please take some time to browse through the recent chats in the channel.

Next week’s meeting

The next meeting will take place on Monday 18:00 UTC, as always in #core-php, and we will take this meeting to bring forward and discuss the problems that supporting an outdated PHP version in WordPress results in. 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

Jeffrey Paul 2:33 pm on July 19, 2017
Tags: , , ,   

Dev Chat Agenda for July 19th (4.8.1 week 5)

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

  • 4.8.1 timing
  • 4.8.1 Beta help needed (support with Mission Control)
  • 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

William Earnhardt 1:06 am on July 19, 2017
Tags: , , ,   

Multisite Recap for the week of July 17th

Office Hours Recap

The agenda for this office hours meeting was to review the current state of the multisite roadmap and plan out how to complete it for publishing as an official document on the make blog.

The meeting’s chat log

Attendees: @desrosj, @earnjam, @feshin, @flixos90, @jeremyfelt, @jmdodd, @johnbillion, @maximeculea, @spacedmonkey, @stephdau, @stevenkword

Chat Summary:

  • @jeremyfelt shared a link to the draft roadmap document for review.
    • @desrosj suggested using the Taxonomy roadmap posts an example
    • We agreed that the roadmap should be broken up into specific sections for REST API, Internal APIs, and Implementation, with each of those sections having their own users, sites, and networks areas.
    • We will also need a section of the document dedicated to “bootstrap” or file organization and load order. See #40647, #40948, #29684, #40646
  • The first priority should be the REST and Internal APIs. Once those are in better shape, they can be used to make improvements to the multisite UX/UI and we can focus on the different network admin screens that need attention.
  • Because networks are managed in widely varying ways, the primary goal of multisite should be to provide standardized data structures and low-level database APIs to support a range of network and multi-network implementations through plugins and custom code. The roadmap should reflect this philosophy.
  • We will need to discuss the “global” state (data spanning multiple networks) and make decisions on what should be implemented there. Right now users are the only global data, but even things like number of users are stored per-network and not globally.
  • Before getting too detailed on the actual roadmap document, we will spend the next few office hours meetings discussing specific items that will go into and affect the direction of the roadmap, including network meta, global state, and some Internal API decisions (See #40180 and #40228)

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 continue going through the list of multisite-related good-first-bug tickets for new contributors, review their status, and adjust keywords as necessary.

The meeting’s chat log

Attendees: @earnjam, @euthelup, @flixos90, @greatislander, @maximeculea

Chat Summary:

  • #40363: Remove current_blog_ cache invalidation from clean_blog_cache()
    • Waiting for feedback from @jjj and @jeremyfelt over possible backward compatibility concerns with removing these
  • #41163: Display active theme name on Sites screen
    • This could make use of a wp_blogmeta table if it gets implemented, but in current form would require switch_to_blog() calls for each row in the list table.
    • Related to #40268
    • good-first-bug keyword removed since it will require further discussion across multiple tickets.
  • #41168: Identify the active theme when editing a site’s themes
    • Discussion revolved around disabling ability to disable the active theme to protect users from not being able to switch back after changing the theme.
    • Because of a possible inconsistency with network-enabled themes and a common paradigm of deprecating old themes by disabling them, the agreed upon suggestion was to only apply a label for the active theme and not change the enable/disable functionality.
  • #41166: .htaccess config should not be shown on network setup screen when Nginx is in use
    • Existing patch is in good shape, but needs minor update to use $is_nginx global
    • Suggested updates to the codex for subdirectory/subdomain configuration
  • #41169: Inaccurate descriptive text when adding a new site
    • Slight verbiage change to patch suggested.
    • Patch has since been committed and ticket closed.

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

Ryan Welcher 8:07 pm on July 18, 2017
Tags: , ,   

New Contributors Meeting Recap – July 12

This week’s New Contributors Meeting was held on Wed July 12th at 19:00. Once again, there were lots of great questions asked in the #core channel. Read the full chat archive here.

Discussion Highlights:

Tickets Discussed:

  • #40921 – Inconsistent Handling of mp4 by Audio Widget
  • #40138 – Bundled themes: the tag cloud widget should output a list
  • #22669 – iPad: Can’t Scroll Plugins Modal
  • #41168 – Identify the active theme when editing a site’s themes

The next meeting will take place in the #core slack channel on Wed, July 19th 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