Media Meeting Recap – February 15, 2018

Overview

This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, February 15, 2018 at 1900 UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on Trac.

Attendees:
@mikeschroder @antpb @blobfolio @flixos90 @jdub233 @sergey @desrosj @azaozz

Transcript: Read on Slack

Gutenberg

  • The best way to follow along with media related Gutenberg items is the media label in GitHub.
  • Repository milestones have been re-arranged to make it easier to see what is going on.
  • Add block playlist: A discussion took place around how mediaElement should be added to Gutenberg. The two options discussed were to include it in the npm package list or make a global instance of Core's mediaElement Library. Consensus was to go with Core's implementation. @antpb is blocked on the playlist block with lack of mediaElement component. He is working on building a mediaElement REACT component that will need to be utilized in the audio and video blocks. Before this is complete enough to merge, he'll need some help understanding how to make the Core library globally accessible in Gutenberg.

5.0 Tickets

The next part of the meeting was spent on tickets in the next major milestone (5.0).

#33979 – Add filter for 'post_gallery_item'
#38228 – Add filter to default gallery shortcode output

Discussion around how granular gallery filters should be. With #3379 we gain a filter to add  styles individually per item in the Gallery. It was discussed that we will need tickets to add more granular filters going forward for captions and other image attributes. From @desrosj : "Currently the shortcode builds the HTML string as it goes. I think if the attributes were built in an associative array, that could just be filtered, and then the element built at the end. That could allow additional attributes to be added, widths to be changed for specific images making it easier to do different grid layouts." This sparked the question above around how Gutenberg will handle backwards compatibility with filtered attributes.

The following tickets need a combination of code review and approval:

  • #33979 – Add filter for 'post_gallery_item'

Seems good to go as a first step towards more granular Gallery filters if it won’t make it more difficult for Gutenberg to provide backcompat.

Next Meeting

The next #core-media meeting is set for Thursday, February 22, 2018 at 1900 UTC. Hope to see you there!

Dev Chat Summary: January 31st (4.9.3 week 3)

This post summarizes the dev chat meeting from January 31st (agenda, Slack archive).

4.9.3 update

Updates from focus leads and component maintainers

Servehappy

  • Question from @azaozz in latest meeting: What if the PHP education page (codename "servehappy") was not on any .org-related website, but inside of core?
  • We'd like to ask for feedback on this, what are all your initial feelings on that? Note that this is separate from the prompt for the user to switch the PHP version in their hosting account.
  • Some considerations:
    • The main condition for this to happen is to have the entire content powered by the .org API. The content will be highly dynamic and may need adjustments regularly, so we must not be dependent on core releases to change it.
    • A new API endpoint would need to be built for that purpose that should send the content of all sections of the page, to some degree targeted to the current request. Parameters like the PHP version active, plugin slug (in case the user is sent to the page because a plugin requires a higher PHP version), data about the host (if available), would be part of the request. This would allow the content to target the user's problem as well as possible.
    • All content that endpoint returns should not be hard-coded, but easily manageable through a backend (maybe a special section in make.wordpress.org/core/?).
    • How is it possible to change the .org API? Who has access? We'd need to figure out how the process of working on that could be streamlined.
    • Summary of thoughts from PHP meeting recap
  • Next step is for the Servehappy team (including @azaozz) to discuss this during the next PHP meeting (on Monday 16:00 UTC) and come back with a recommendation

General announcements

  • @afercia uncertain about what can go in a minor release, specifically about fixes or small enhancements that require a dev note given that minor releases auto-update
    • Changes that require a dev note in a minor release, with such a short notice, don’t give plugin and theme authors the time to update.
    • As further changes to the minor release policy, best to have recommendation prepared for upcoming devchat

Next meeting

The next meeting will take place on February 7, 2018 at 21:00 UTC / February 7, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. 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-3, #core, #core-editor, #core-php, #dev-chat, #documentation, #js, #minor-releases, #servehappy, #summary

PHP Meeting Recap – January 29th

This recap is a summary of our previous 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.

You can find this meeting’s chat log here.

Chat Summary

The agenda for today was to discuss UX mockups and the hosting situation.  However, @jaymanpandya was not around for the meeting and we don’t have any mockup update so we were unable to discuss.  That portion of the meeting was postponed until next week.  @azaozz was present at the meeting and we spent the entire meeting interacting with him with regards to this comment he made.

He expressed some concerns regarding both content (what the servehappy page contains) and location (where the servehappy page lives) of the servehappy page.

For reference and as a reminder, the servehappy information page is the first initiative of the entire project aimed for launch in the first quarter of 2017.  You can read more about it (and how it fits into the larger “servehappy” project in the roadmap, the project readme, the related trac ticket and see the current draft.  Also keep in mind that “servehappy” is a codename for the project.  It won’t necessarily be reflected in any final form for the public facing content.

By the conclusion of the meeting we arrived at the need to focus primarily on location as it is something we haven’t fully worked out yet (it hasn’t received the same level of discussion/planning as the content).  We identified some initial factors that should influence where this servehappy information page lives.  For the purpose of this summary, I’m going to list the headings and capture some of the related discussion under each heading.

Where should the “servehappy” information page  live?

Here’s some factors that can influence the location:

Factor: Privacy

This factor concerns the privacy of any information shared by site owners/sites for the servehappy page generation/content.

Some related background:

  • this landing page in it’s initial form is intended to be a more general encouragement to upgrade PHP, why one should upgrade PHP, and some instructions on how to upgrade PHP (including linking out to various specific host instructions).
  • When the admin notice is implemented, one initiative discussed is to link from that to this page and send along with the link via url parameters some basic information (such as php version and possibly plugin slugs that are on old php versions) that allow the servehappy page to be tailored more directly to the visitor.

Related comments in chat (this is not in chronological order but has been grouped for relevance):

  • concern over passing data via parameters and the privacy implications
  • php version and php info is already sent to the wp.org servers
  • “They are running an unsupported PHP version.” That’s all we need to know (@schlessera)
  • I see it similar to how you prepare a link that contains the language as a URL argument. Don’t think that’s a privacy issue (But IANAL). (@schlessera)
  • access logs can link ip/referring domain to PHP version… (@nerrad)
  • Before we talk about “privacy” issues, I think it’d be good to identify exactly what you think we plan on sending to this page and what is concerning from a privacy point of view instead of ambiguous assumptions. (@nerrad)

Factor: Maintainability

This factor concerns the degree of effort needed to implement, maintain and update the content and anything else related to this server.

Factor: User Trust

This factor concerns how likely user’s will act on something when it conveys something they can trust (i.e. wp-admin, vs external hosted page)

Proposed locations for the Page:

In the course of the meeting we arrived at a discussion on two primary locations where the servehappy information page would be hosted/served.  They are summarized below along with the relevant discussion pertaining to each location.  The plan is to bring this to a future core dev meeting so that we can get some opinions from others in the wider WP core team/community to help with the decision for where this content will live.

External Site:

This includes the potential of being a custom domain/separate site, WordPress codex, or as a page on WordPress.org

  • privacy concerns
  • We’ve already discussed just using an internal WP-org page, but it would be a less focused layout, and be not as optimized to achieve the actual goal. (@schlessera)
  • Seemed to be general consensus that maintaining the content would be easier in this location.

WordPress Core (powered by WordPress.org API)

  • Regarding why the external page, the core notice about PHP initially shouldn’t overwhelm the user immediately with tons of content. A page inside of core would be an alternative, but we would like it to be independent of core version releases. An alternative could be to have a page IN core, however its entire content would need to be powered by the wordpress.org API, so we would need a new endpoint for the education parts. (@flixos90)
  • ‘read more..’ in the notice could point to the page in core.
  • We need to keep in mind though, the more WordPress-centric we build it, the lower the possibility to open it up to collaboration with further projects. That may not be that important of a goal anyway, but something to consider. (@flixos90)
  • We will try to make the content as targeted as possible, but the more targeted it becomes the more information we need to have about different hosts and the more data the new API endpoint for the page needs to support. The fallback will be to send an email to the host with predefined content. (@flixos90)
  • With the API, you cannot easily add/remove elements. Either it’s one blob of content (which will make management a hassle) or it’s separate sections, and we cannot easily add/delete things. (@schlessera)
  • Again, I also want to emphasize it’s hard to tweak the .org API because there aren’t many who have access, but as long as all the actual information is not hardcoded somewhere in there, it sounds alright to me. (@flixos90)
  • I think we could easily manage the content as separate sections and send these individual sections over with the API. And then we could also send call to action data, like host-specific links or a fallback. (@flixos90)
  • We should build the API in a way though that the content is easily editable without any meta trac interaction required. Where could that happen? Which backend of a .org site could power that API? (@flixos90)

Next week’s meeting

  • Next meeting will take place on Monday February 5, 16:00 UTC in #core-php
  • Agenda: Followup on the location discussion, hosts situation, feedback on mock-ups for the PHP Compatibility checker plugin (which will promote the servehappy page), feedback on mockups for the servehappy page.
  • If  you have comments/feedback/suggestions about any of the above agenda items, but cannot make the meeting, please leave a comment on this post so that we can take them into account.

To prepare for the next meeting, here are some mockups for the PHP Compatibility checker:

  • https://xd.adobe.com/view/3f36c02e-6bbb-471c-b52f-78b8f9b7fbee/?fullscreen
  • https://slack-files.com/T024MFP4J-F8ZQ08V4Z-e421fe42bb

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

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

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 @mrasharirfan

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

Dev Chat Summary: August 30th (4.9 week 5)

This post summarizes the dev chat meeting from August 30th (agendaSlack archive).

4.9 schedule review

  • 4 weeks until the feature project merge deadline, 5 weeks until Beta 1
  • CodeMirror feature plugin (aka Better Code Editing) aiming for merge in 2 weeks
    • @westonruter: Integration with CodeMirror’s linter is almost done to prevent the user from being able to save changes to the file editor, Additional CSS in the Customizer, and the Custom HTML widget if there are syntax errors in the code.
    • Demo: Blocking WordPress file editor saves via linting in CodeMirror
    • Still want to implement a PHP linter to help prevent whitescreening a site
    • Prior effort by @georgestephanis to add a PHP linter by using the PHP binary on the server had to be reverted because it will not be available on many hosts
    • May be able to implement a rudimentary PHP linter that uses CodeMirror’s tokenizer and use it to at least make sure that basic syntax is valid
    • For anyone who wants to contribute, please follow Issue#48
    • Aiming to release v0.5.0 of the plugin on WordPress.org today
    • It needs user testing and code review.
  • @azaozz: looking for second opinion on #41752.
    • Should we refactor the JS so it still works with (very) old plugins and themes?
    • It should replace the UI with a simple input type=“file”. If yes, any takers to do that?
    • If only a handful of plugins/themes affected, then we could work with the plugin authors to update rather than maintain back-compat in core for something that is dead.
    • @westonruter: will upload the results of my acking for affected plugins/themes to Trac when it finishes
  • @westonruter: one of the 4.9 feature ideas that had excitement was updating themes and plugins via ZIP upload, where this is not allowed (see #9757)
    • This work currently needs an owner, otherwise it is in risk of getting punted from the release
    • There are some good orientation comments at the end by pento and dd32 which can help you get started
  • @westonruter: big Customizer features planned for this release, including drafting and scheduling, have designs currently being worked on by @joshuawold and @folletto (see: #39896 #28721)
  • Reminder of the tickets in the goals post targeted for 4.9, please help specifically with these… thanks!

Update to Editor weekly meeting focus

  • Office hours on Wednesdays at 17:00 UTC are becoming tickets sessions to go through issues together for each weekly milestone of Gutenberg.
  • Please join then to help move that project forward.

#4-9, #core, #core-customize, #core-editor, #dev-chat, #summary, #swfupload

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

This post summarizes the dev chat meeting from July 26th (agendaSlack 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

Media meeting recap – June 29, 2017

Overview

This post is a summary of the latest weekly Media component meeting, which took place in #core-media on Slack, on Thursday, June 29 at 18:00 UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on Trac.

Attendees:
@joemcgill, @sergeybiryukov, @mikeschroder, @adamsilverstein, @desrosj, @azaozz, @karmatosed, @matias, @youknowriad, @mkaz, @joen.

Transcript: https://wordpress.slack.com/archives/C02SX62S6/p1498759231771175

Media + Gutenberg

Our agenda this week focussed on getting a better understanding of the current product vision for working with media in Gutenberg in order to coordinate priorities and ensure future improvements to the media component align with the needs of the new editor experience.

The major takeaway from this conversation was that Gutenberg intends to handle the UI flows for editing media within post content inside the editor itself rather than relying on the wp.media.frame modal for these actions. The image gallery block in Gutenberg is a good example of this change.

Editing gallery settings in the current media modal

The current screen in the media modal for editing gallery settings

 

Editing gallery settings in the Gutenberg sidebar

A preview of editing image gallery settings in the Gutenberg sidebar

By handling post-level setting in the editor, people can immediately preview changes in the editor. This change reduces the burden of the current media modal to act primarily as media library, and as a way to manage media information that applies site-wide. This should also make it more clear when changes will affect a media item site-wide, which is a nice UX win.

Some next steps

To prepare for this shift, we need to document the current flows that will need to be adjusted in order to support this separation between managing post-level data and site-wide media library data.

Additionally, the Gutenberg team asked for help creating blocks for additional media elements like video, audio, etc. The Gutenberg GitHub repo now contains a “media” label for collecting issues that relate to the media component.

Other housekeeping items

Earlier this week, @desrosj ran a separate bug scrub focussed on new tickets on the Media component. We plan on running separate scrubs throughout the 4.9 release cycle. If you’re interested in helping with that effort, please contact @desrosj or @joemcgill on Slack.

#gutenberg, #media, #media-library, #media-modal

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

  • 21 commits
  • 25 contributors
  • 43 tickets created
  • 3 tickets reopened
  • 46 tickets closed

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

Code Changes

Administration

  • Dashboard: Better titles for the Recent Drafts widget. [40877] #37595

Build/Test Tools

  • Fix PHP 5.2 compatibility for grandchild methods which expect exceptions to be raised. [40876] #39822
  • Fixed support of PHPUnit_Framework_TestCase as the base class. [40873] #39822

Bundled Theme

Help/About

I18N

  • Improve translator comments for strings in the community events widget. [40866] #40865

Media

  • Fix an issue selecting media when clicking item edges. [40874] #40578

Misc

Networks and Sites

TinyMCE

  • Force urlencoding of commas in URLs added by plugins to prevent warnings about missing stylesheets. [40862] #40893

Thanks to @bridgetwillard, @adamsilverstein, @afercia, @azaozz, @bhargavbhandari90, @circlecube, @dimadin, @flixos90, @francina, @iandunn, @iseulde, @jenblogs4u, @johnbillion, @johnroper100, @melchoyce, @michelleweber, @obenland, @ocean90, @psiico, @rcutmore, @soniakash, @sudar, @swissspidy, @voldemortensen, and @zachwtx for their contributions!

#week-in-core