PHP Meeting Recap – September 18th

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: @brainfork @jdgrimes @mikelking @mte90 @nerrad @pross @schlessera @screamingdev @sergey @tfrommen @xkon

Chat Summary

The entire meeting revolved around discussing the draft document that the #marketing team has produced for our PHP “servehappy” page. We went through the document paragraph by paragraph in order to have a guided approach to discussing the content.

Even though we went way past the normal meeting duration, we only got through the first half of the document so far.

Here’s a non-exhaustive list of observations we had:

  • The page talked about having “detected an issue”. Although that makes sense when we redirect people from within the WordPress admin dashboard, we should first try to build a generic page that makes sense as well when you directly access it.
  • We should make sure that negative points we raise with old PHP versions do not draw a negative picture of WordPress itself.
  • A lot of thoughts went into the paragraph that opposed backward support to the recommended version. We want to emphasize that you should not run on older PHP, even though WordPress does support it.
  • Country-specific assumptions, such as using the term “dollars”, should be avoided as far as possible.
  • Some of the copy feels clunky when reading it as a technical person, but no-one feels able to improve upon it without making too many assumptions about the technical knowledge of its intended audience.
  • We’re still discussing how best to refer to the different PHP versions and branches, and what relative terms like “latest” or “most current” mean in this context. This is why we’re trying to avoid direct version references whenever possible.
  • There were some inconsistencies in terms of what “we” refers to. We decided to consistently use “we” to refer to “we, the people working on the WordPress project” and address the visitor as “you, the site owner”.
  • We had some discussion about “more features being delivered through plugins”, and whether that should include “themes” as well. We opted to leave themes out of there, because, even though you can technically introduce new features through themes, best practices recommend having the theme be about the visual presentation only and having plugins provide new features instead. We don’t want to further spread the misconception that themes should include actual required functionality.

Next week’s meeting

The next meeting will take place on Monday, 25 September 2017, 20:00 CEST, as always in #core-php, and its agenda will be to discuss the second half of the draft document to finish what we started. 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

Customize Meeting Summary: September 18th

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

Participants: @westonruter, @jbpaul17, @melchoyce.

Discussion highlights

CodeMirror (“Better Code Editing“)

  • @melchoyce to review three assigned tickets, #41872 being most urgent and other tickets with @mentions
  • @westonruter: working on ensuring the new CodeMirror-enhanced Custom CSS is compatible with Jetpack
    • Created a reusable “code editor” customizer control so that Jetpack can extend it, also for other plugins to add their own code editor controls easily
    • Need support from the Jetpack team to review and finish off the initial PR that I opened
    • @melchoyce: I’ll ping Jetpack folks this week once we’re all back from the Automattic Grand Meetup (most should be back by Wednesday)

Drafting and Scheduling

  • Best to wrap UX work, as @sayedwp has gotten started on that this week
  • @westonruter to get latest code pushed up to the test environment for review
  • @melchoyce: realized earlier this week that the apps have a similar draft/publish flow
    • @jbpaul17: Are we aligned with the flow there and if not should we align with what they have or open an Issue for them to update to what we’re working on for core?
    • @melchoyce: We are pretty close, I’ll compare side by side this week

Widgets

  • @westonruter: hoping to get the Core Media Widgets plugin updated with the new Gallery widget today for user testing so we can get it merged into core next week (#41914)

Bug scrub

Next week’s meeting

The next meeting will take place on Monday, September 25, 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

Dev Chat Summary: September 20th (4.9 week 8)

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

4.9 schedule

  • 1 week until the feature project merge deadline, 2 weeks until Beta 1
  • Drafting and scheduling (#39896) has designs and is working through development
  • Gallery widget (#41914) is now available in the Core Media Widgets feature plugin, so please test that as we plan to merge it into core next week
  • Updating a plugin via ZIP (#9757) or drag/drop (#24579) is not getting any traction, so they will likely be punted
  • Review needed on #34115 to bring the ability to use oEmbed outside the context of posts
    • This allows the Text widget to have embeds in it, as well as to be able to remove the restriction on the Video widget to only show YouTube and Vimeo
  • Long list of Code Editor tickets that could use contributors
    • If you’re interested and capable with JS and playing with CodeMirror, #41873 is a great place to start
  • Any tickets related to goals in the 4.9 Goals post should be prioritized
  • Bug scrub post will be published with dates/times to scrub features and enhancements ahead of the Beta 1 deadline. If you’re interested in helping run a scrub, then please let @jbpaul17 know.
  • User testing needed on #39693, especially running it through a battery of theme switching tasks; the goal is to improve the “it just works” experience
    • Testing steps include installing a theme, populating sidebars with widgets, switching to another theme, and checking how the widgets appear in the newly switched theme
    • If you switch back to the old theme, the sidebar widgets get restored
    • Testing should be done when switching themes via the WP admin themes page, and also via live preview in the Customizer
    • Themes that have varying numbers of sidebars would be the key to test with. Switching from a theme with 2 sidebars, to one with 4, to another with 1, to another with 5, and so on.
    • If you want to have a public test environment set up with the patch to test, then please ping @westonruter

Editor update

General announcements

#4-9, #core, #core-editor, #dev-chat, #feature-oembed, #media-widgets, #security, #summary

Multisite Recap for the week of September 11th

Office Hours Recap

The agenda for this office hours meeting was to resolve the remaining discussion and blockers for #29684, the proposed get_main_site_id() function and related integration.

The meeting’s chat log

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

Chat Summary:

  • The main purpose this function could serve initially is to auto-fill the $blog_id property of the WP_Network class, which currently is only being populated for the current network in the bootstrap process. There is no database field for the main site of a network, therefore custom logic must run for it to be set. get_main_site_id() makes it easy to detect the main site for a network, and magic getters in WP_Network would allow to automatically set the property once it is first accessed, using the new function. In the end of the discussion it was decided that the logic to auto-fill the property makes sense and can be merged with the new function.
  • It was also discussed whether a network option should be used to store the main site ID. This would bring a performance benefit for multisite setups without an object cache and without the network constants enabled. On the other hand, the main site ID at this point is not really an option, since many areas of WordPress assume it is always the site whose domain and path match the network’s ones. Getting rid of this restriction is something that could be evaluated more closely in the future, but for now this restriction exists, and introducing a network option would give the impression that it would be possible to change the main site ID without any issues. Therefore it was decided to not use a network option at this point, but it can be reconsidered later in a separate ticket.
  • Another topic was whether the actual logic should go into the get_main_site_id() function or whether the function is not required at all and instead the logic should be part of WP_Network. Eventually it was agreed to go with the regular function and call it from WP_Network. Moving the logic into a private WP_Network method would not align well with existing core patterns, where pretty much everything relies on a function. As long as there is no methodological approach for this, functions should remain the source as it currently is.
  • Naming of the new function was discussed as well. It was suggested to call the function get_main_site_id_for_network() or get_network_main_site_id() to be more precise. On the other hand, is_main_site() already exists and would have been called similarly in order to align with the new function. Furthermore the function is available for non-multisites, making the extra network affix a bit more confusing. It was decided to proceed with the current idea of get_main_site_id().
  • All remaining items were solved and as of now the patch has been merged into core.

Next meeting

The next office hours will take place on September 19, 2017, 16:00 UTC. Its agenda will be to further plan 4.9 work and which tickets should receive the main focus in the few remaining weeks until Beta 1.

Ticket Scrub Recap

The agenda for this ticket scrub was to review and discuss some multisite tickets in the 4.9 milestone.

The meeting’s chat log

Attendees: @afragen, @desrosj, @flixos90, @jeremyfelt, @sergey, @vizkr

Chat Summary:

  • The first ticket discussed was #40764: @afragen asked for feedback. @flixos90 verified that the latest patch applies cleanly. @desrosj plans to review the patch itself soon.
  • #41285 was discussed: @jeremyfelt was asked for feedback and responded that he is confident that this change can happen, at least for the $public global. He will dive deeper into whether the $site_id global is safe to remove as well. He furthermore stated that the related tickets #34217 and #39419 should be considered as well. A response from Automatticians working on wordpress.com would be much appreciated.
  • #40364 was the last ticket for the meeting: The proposed action hook names used in the new functions wp_insert_site(), wp_update_site() and wp_delete_site() using the same names were questioned and whether it may be more useful to use more precise names using past tense, such as wp_inserted_site(), so that it is clear they run after the database transaction. It was also considered to run multiple actions. Eventually it was decided to go with the simple approach for now, and stick with one action having the function name. Regarding timing, while the latest patch may possibly be merged at this point, it should rather wait until #41333 has also been completed, to have the full new site API in core in one release. The latter ticket is something that can be worked on during the 4.9 beta, to aim for an early 5.0 merge.

Next meeting

The next ticket scrub will take place on September 18, 2017, 17:00 UTC. Its agenda will be to review multisite bug tickets awaiting review with a focus on recently opened tickets.

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

PHP Meeting Recap – September 11th

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: @brainfork @dnavarrojr @espellcaste @flixos90 @joostdevalk @jdgrimes @milindmore22 @nerrad @pbearne @schlessera @sergey @sobak @vizkr

Chat Summary

The agenda for this week was to review the current progress and plan how to proceed in the upcoming weeks.

  • @flixos90 shared the outcome of the meeting with the #marketing team that had happened some days ago (read the full chat log): The marketing team has started work on the copy for the planned Servehappy page, based on the drafts the PHP team created over the past couple weeks. A Trello board has been set up, and the actual text is being worked on in a Google doc. The team has set a deadline for September 15th. As of writing this post, the document has been completed. They also offered their help in the future for other things that the page would need, such as graphics and illustrations. A special thanks to the marketing team for their efforts!
  • The next PHP meeting will be used to review and discuss the document in detail and figure out questions or suggestions, if any. Anyone from the marketing team is also very welcome to join this chat in particular!
  • It was decided that once the document is considered to be in a good shape, it is time to pitch the idea of the suggested Servehappy page further. In particular more leadership people need to be convinced of the efforts in order to successfully proceed. The page must be officially affiliated with wordpress.org, whether it is hosted as part of it or at a separate location. This is a requirement so that it is eligible for being linked to from WordPress core itself.
  • @schlessera suggested creating a proposal document that describes the problem the team is trying to solve, the goals the solution should meet, the current state of things and what is needed to get this launched. This will provide clear documentation and can be used in addition to the page document itself to pitch the idea. With this, the team hopes to be able to at least get a “conditional” buy-in.
  • It was discussed whether the page should be part of wordpress.org or whether it should be hosted as a separate website, such as servehappy.com or servehappy.org (in either case it should be an official part of WordPress).
    • Having it as a separate site would perhaps make it interesting for other PHP projects as well.
    • Having it as a separate site would give more flexibility on what the overall page layout and design should look like while with .org, it would obviously need to integrate.
    • Having it as a separate site would give parity with something like browsehappy.com, however the Servehappy content would be much more specific to WordPress, so it may be better suited as part of wordpress.org.
    • Having it as a separate site would allow to create separate pages for the bits and pieces if it makes sense, and guide visitors through them.
    • In the end nobody had a heavy preference for either, so where to host this can be approached rather flexibly, as long as it is based on a clear decision by the core leadership. The core leads may very well also have their own preferences for this.
  • In order to bring more attention to the efforts, it was decided that the best way to start once both the copy and proposal documents are ready will be to first publish the proposal on the make blog and then bring it up at the weekly core dev-chat. The post should be available in advance so that it gives people time to prepare. It may also be useful to schedule regular update slots in the dev-chat meetings, in order to provide information on where the project is at and maintain traction.
  • The proposal document should also contain all suggested integration points with core.
    • What feature needs to integrate with the page?
    • Where should the link point to?
    • Is dynamic content transported through the link needed? If so, which GET parameters would the page need to support?
  • Using GET parameters for some dynamic parts of the page would give the visitor a better feeling their specific issue is addressed by the page. However, it needs to be ensured that all data passed is not controversial regarding privacy in any way. It needs to be entirely anonymous.

Next week’s meeting

The next meeting will take place on September 18th, 2017, 18:00 UTC as always in #core-php, and its agenda will be to review and discuss the page document the marketing team has worked on, as described above. 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: September 13th (4.9 week 7)

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

4.9 schedule and requests for contributions

  • 2 weeks until the feature project merge deadline, 3 weeks until Beta 1
  • These tickets need someone to contribute to them or else they’re in danger of not making it in 4.9:
    • Add nested folder structure deeper than 2 levels (#6531)
    • Add better warnings when you’re editing themes and plugins (even if they’re not active) (#31779, #41078)
    • Updating a plugin or theme via a ZIP file (#9757). Also, drag and drop uploading of themes and plugins (#24579)
    • Widgets: Default to “custom URL” in the image widget (#41629)
    • Customizer drafting/scheduling (#39896, #28721)
  • @westonruter: I committed CodeMirror to integrate with the Theme/Plugin editors, Custom HTML widget, and Additional CSS in the Customizer
  • @jbpaul17: looking to schedule bug scrubs, please reach out if you’re interested in helping
    • Component maintainers: Please confirm if you’re running scrubs for your component

#4-9, #core, #dev-chat, #summary

Customize Meeting Summary: September 11th

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

Participants: @westonruter, @jbpaul17, @joemcgill. @melchoyce and other Automatticians travelling today for this week’s Automattic Grand Meetup (“annual company meeting”) and thus not in attendance.

Discussion highlights

Notification area

  • @westonruter: working on drafting design and dependencies we have (see: #35210)
  • @westonruter: Designs should get finalized today and work can get going on that piece quickly
  • @jbpaul17: I should be able to have work start on that shortly

CodeMirror (“Better Code Editing“)

  • @westonruter: aiming to get the core patch committed today
  • @westonruter: opportunity for a contributor to learn and get experience is integrating a PHP linter ahead of 4.9 Beta 1 (October 4th)

Widgets

Other updates

  • @jbpaul17: chasing down potential contributors to help with other items for 4.9, no updates as of now
  • Plan to start bug scrubs after weekly meeting leading up to 4.9 Beta 1

Next week’s meeting

The next meeting will take place on Monday, September 18, 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 items to discuss about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9, #core-customize, #summary

Dev Chat Summary: September 6th (4.9 week 6)

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

4.9 schedule review

  • 3 weeks until the feature project merge deadline, 4 weeks until Beta 1
  • Customizer improvements for merging Changeset drafting and scheduling has yet to kick off development, designs are nearing completion (see: #39896 and #28721)
  • Gallery widget is still under development but it seems to have stalled, TODO’s noted on related GitHub PR
    • @joemcgill to look into avoiding serializing attachments data in the widget this week
  • @obenland working on wrestling the widget mapping issue when switching themes (see: #39693)
  • Page on Front progressing slowly, likely not ready for dev before Feature Merge
  • Theme switching issue for nav menu mapping has already been merged in trunk (see: #39692)
  • CodeMirror feature plugin (aka Better Code Editing) needs testing and a few outstanding issues that would benefit from contributors. Plan is to merge this week.
  • @psykro to look into #9757
  • “Add Media” button in the Text widget great opportunity for new contributors
  • #35827 could use an owner and remaining items in 4.9 Goals post could use contributors to help land in the release

Editor update

Iterating in trunk

  • @matt: I’m fine with more iteration happening in trunk vs how we’re bouncing patches around Trac so much
  • @matt: I’m okay with parts of trunk being broken as we iterate in this phase of dev
  • @desrosj: Do we have an established process for reverting things that break?
  • @obenland: I think we’re not talking about “PHP fatals”-broken, but rather a feature maybe not fully functional

HTML5 input types for validation

  • @afercia: any thoughts about relying on HTML5 input types browsers built-in validation only?
  • @azaozz: used to be buggy, seems to be working properly now
  • @afercia: seems to me still premature to rely on required for validation
  • @afercia: looking to leads to make a decision as new browsers support policy
  • @asaozz: Worth some testing, especially on the “lower end”, IE11
  • @afercia: there are still CSS rules in ie.css for Internet Explorer 6 (and 7, and 8). Can they just be dropped?
  • @azaozz: no need of ie.css in my honest opinion
  • @azaozz: intention is not to completely break old browsers if they still work, but to stop testing in them
  • @clorith: concerned about users locked into older browsers, like IE8, and keeping option for them to enqueue scripts relevant to their browser
  • @afercia: I wanted to start the discussion about this as it relates to the new browsers support policy

General announcements

#4-9, #core, #core-customize, #core-editor, #dev-chat, #gallery, #gutenberg, #html5, #summary, #trunk, #widgets

Multisite Recap for the Week of August 28th

Office Hours Recap

The agenda for this office hours meeting was to take a look at progress on the multisite roadmap and to continue discussing the best approach to checking for the existence of a wp_blogmeta database table (See #37923).

The meeting’s chat log

Attendees: @flixos90, @desrosj, @stephdau, @dac, @johnbillion, @spacedmonkey, @jeremyfelt

Chat Summary:

  • During the core dev chat, everyone was open to the roadmap being published at make.wordpress.org/core/roadmaps/multisite. The REST API team is also interested in posting a roadmap under that structure.
  • Quite a bit of progress has been made by @flixos90 so far on the multisite roadmap document.
  • A good way to contribute to the roadmap now is to read through critically and make comments/suggestions on the direction and content.
  • Everyone is free to make changes/comments. Ping @jeremyfelt if you would like access.
  • @johnbillion is going to add some items related to multisite administration.
  • More needs to be built out around multisite’s bootstrap and the future of “global context” above the level of network.
  • There was some discussion on what an objective on the roadmap for multisite’s bootstrap may be. Everyone seems to agree that “increasing stability and testability” of the bootstrap is a good objective.
  • There should be a general section at the end that covers some things that don’t necessarily fit as part of the main roadmap at this time. That can be considered “a summary to encourage discussion/contribution even if what you want isn’t on the roadmap.”
  • Quite a bit of ground was covered on #37923 as to whether the existence of a wp_blogmeta table (after upgrade) should be stored as a main network option, as an option on every network, or in a new place entirely.
  • @spacedmonkey brought up concerns about the performance issues of loading an option from a different network. During multisite’s bootstrap, all of the current network’s options are loaded into memory. Storing in a single place would result in an extra DB query/cache lookup.
  • @flixos90 and @jeremyfelt prefer (so far) storing the data as an option on the main network. The idea that a global setting storage may exist one day makes it tempting to treat this data as global now.
  • A next step is to lookup more possible “global context” data that could be stored. @spacedmonkey brought up global terms and ms-files as two immediate options. Brainstorming should continue via chat and on the ticket (#37923).

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 review 4.9 ticket progress.

The meeting’s chat log

Attendees: @flixos90, @desrosj, @sergey, @paaljoachim, @jeremyfelt, @spacedmonkey

Chat Summary:

  • #29684 – Had a lengthy discussion on the possibilities of this ticket. Chatted through whether a networks main site ID should be stored as a network option. For the time being, let’s stick with not storing the data anywhere.

There will be no ticket scrub Monday 17:00 UTC. A schedule and agenda for the next ticket scrub will be posted next week.

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

New Contributors Meeting Recap – August 30th

This past Wednesday, the weekly new contributor meeting was held in the #core Slack room. Here is a recap of the meeting. A full chat log is also available.

Participants: @adhun @afercia @alfonso100 @asalce @azaozz @boonebgorges @coderkevin @cousett @davidmosterd @desrosj @flixos90 @harryjackson1221 @jack50n9 @joemcgill @joyously @katmoody @mapk @mp518 @mrasharirfan @nicbertino @pbearne @psdtohtmlguru @ryankanner @sergeybiryukov @sygnoos @thomasplevy @tjnowell @xkon @yahil

Discussion Highlights

Ways other than Trac to find where to help

Accessibility Contributions

If your expertise is not in code, but rather accessibility, the a11y team meets weekly, every Monday at 17:00UTC in the #accessibility Slack room. All are welcome!

Meetings are held regularly for many of the Core components and Make WordPress teams. Attending these meetings is a great way to get a feel for how progress is made within the project and find ways you can offer help.

New PHPUnit Test section in the Core Handbook

@boonebgorges has recently spent some time constructing a new section of the WiordPress Core Handbook, “Writing PHPUnit Tests“.

Miscellaneous Topics

  • @coderkevin inquired if there had been discussions about memory leakage within the test suite. #41641 was mentioned as the ticket to read into for this. The Distributed Host Testing project is also relevant to that ticket.
  • Currently, there is no central place for documentation on the test suite’s factory classes. The inline documentation for the __construct() functions within each factory class is currently the best place for this information.

Tickets Reviewed

  • #41743 (Using the_widget on a widget that has not been registered results in an undefined index notice.)

 

Next Week’s Meeting

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

Thanks to everyone who attended! As always, please feel free to leave a comment below or reach out to any of the moderators (@adamsilverstein, @desrosj, @stevenkword, @welcher) with questions on Slack. Or, feel free to reach out to any core developer or component maintainer with questions specific to certain core areas.

#new-contributors, #summary