PHP Meeting Recap – March 19th & 26th

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.

Chat log from March 19th
Chat log from March 26th

Chat Summary

Dashboard widget (#41191)

  • The voice of the widget text has been adapted to better match the overall WordPress feel.
  • The accessibility concerns that were raised have been addressed.
  • The widget currently looks like this:
  • The Trac ticket was flagged for ui-feedback and we are now waiting for the #design team to be able to go over the ticket. Once all of their feedback has been processed and incorporated, the version in trunk will be ready to discuss backporting it to the next minor release (4.9.6).

PHP version requirements for plugins & themes (#40934)

Next week’s meeting

  • Next meeting will take place on Monday, April 2, 2018 at 15:00 UTC in #core-php.
  • Agenda: [Go over #design feedback and] discuss how to proceed with plugin requirements.
  • 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.

#core-php, #php, #servehappy, #summary

PHP Meeting Recap – November 6th

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: @bpayton @flixos90 @jdgrimes @mte90 @nerrad @overclokk @psykro @schlessera @vizkr

Chat Summary

The agenda for this week was to review the suggestions @flixos90 has worked on for the “Before Upgrading PHP” section that is available in the Google document, taking the past weeks’ discussions into account.

As other important topics had come up after the agenda had been laid out though, the discussion ended up revolving around different topics, only taking a short peak at the document towards the end of the meeting. Here is the discussion summary:

  • @flixos90 shared some great news about the tool that the XWP team has been working on, which had been mentioned a few times before in other meetings: The tool automatically scans all plugins in the plugin repository for their usage of the WordPress coding standards and, more important for the PHP team, their compatibility with different PHP versions from 5.2 to 7.x. The project is going to be an official part of the repository, and all of this will be handled through an external API. The results of the scans will be displayed on the respective plugin page, and the PHP compatibility checker could leverage that data as well. The API will even be able to scan plugins and themes which are not part of the repository, by temporarily uploading them. This will allow to test even paid or custom developed plugins and themes. That part will not be exposed through any UI in the initial release, but it will be possible through the API.
  • @nerrad commented that this will likely require some changes on the Servehappy page copy that exists so far. These changes will likely be minor though and most importantly take away some points of uncertainty that with that tool at hand won’t matter anymore.
  • It would make sense for the PHP Compatibility Checker to leverage that API, so it needs to be discussed with the responsible people at WP Engine what steps should be taken here. The new API could either be used in addition for more accurate results, but it may possibly even be better to replace the current mechanism with it entirely, as it would improve speed significantly because it could in many cases use data that has already been gathered before rather than running the expensive checks on the server.
  • The above two topics should be discussed in detail once the API has been officially released to the public.
  • @psykro asked whether it would be possible to change the meeting time or host a second meeting. Everyone who responded was open to a change, however it should preferably remain close to when it’s currently scheduled (every Monday at 19:00 UTC). If you are interested, please leave your vote(s) on this Slack post.
  • @mte90 asked about the new plugin headers for a minimum required PHP version and specifically about when the integration with core for it should be developed. While core should not include any PHP-related notices or warnings until the Servehappy page is published, it makes sense to start work on it before. This will not be a major topic for the PHP meetings for now, but should mainly happen in its Trac ticket #40934, unless a rather complex topic comes up which would benefit from a discussion in a meeting. @psykro, @schlessera and @mte90 expressed their interest in working on this. Mockups for the visual side of things should be created early, and the #design team should be asked for help with this. Since the project will likely involve quite a bit of code and it’s not optimal managing this solely through Trac, it was suggested to go either with a plugin-first approach or use a GitHub fork of the WordPress development repository.
  • After that, attendees started reviewing the sections in the Google document and added some comments and suggestions. @nerrad highlighted that the last section about contacting a developer should only be targeted at those site owners that already have an ongoing relationship with one, or at least already know one. People who have never hired a developer are unlikely to do so for a “random” PHP upgrade. More in-depth review and discussion on the Google document was postponed to next week’s meeting.

Next week’s meeting

The next meeting will take place on November 13th, 2017, 19:00 UTC as always in #core-php, and its agenda will be to actually review the initial suggested copy for the “Before Upgrading PHP” section so that it can be passed on to the marketing team afterwards. 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 25th

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

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

Discussion highlights

Drafting and Scheduling

Gallery widget

Customizer UX for themes

Bug scrub

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

Next week’s meeting

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

#core-customize, #summary

Editor Experience Survey

As you’re well aware, a project is underway with the focus on redesigning the editing experience in the wp-admin. As the project moves forward, a better understanding of how WordPress users actually feel about the editing experience is needed. Please take a few minutes to fill out this survey and help influence the future of your favorite CMS, WordPress.

Survey Link:

http://wordpressdotorg.polldaddy.com/s/editor-survey

+make.wordpress.org/design

 

#core-editor, #design, #survey

Dev Chat Summary: September 28 (4.7 week 6)

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

Reminders

  • Schedule: We are 3 weeks from the final chance to merge in major features. This includes Twenty Seventeen.
  • Tickets: There are currently 196 tickets in the 4.7 milestone. This is 14 more than last week. In just 6 short weeks, this needs to be zero. For any tickets you’ve moved into the milestone, please make sure these are active tickets, with some kind of activity in the last 10 days.
  • Bug Scrubs: We’re looking for people to help run a bug scrub, please reach out to @jorbin if you have interest (details here). Bug scrubs this week plus one on Monday and one on Wednesday next week at yet to be scheduled times.

Components & Features

  • Twenty Seventeen (@davidakennedy, @melchoyce)
    • Latest update
    • Add multi-panel feature to pages through add_theme_support (#37974) & Enable Video Headers in Custom Headers (#38172) need eyes and help the most
    • Additional i18n eyes on Better support for non-latin font fallbacks especially designers who use non-latin alphabets natively to hear suggestions for non-latin font stacks that would look good in the theme
    • Next meeting Friday at 18:00UTC (theme-focused), Tuesday (feature-focused)
  • Media (@mikeschroder, @joemcgill)
    • Latest update
    • Unexpected change to media title behavior in WP 4.6.1 (#37989) – Looks like @sergey added a patch that fixes the remaining issues with some UTF-8 characters. Should be committed soon.
    • Media search doesn’t include file name (#22744) – The current implementation is trampling any preexisting JOINs. Should have a patch a new patch ready to test soon.
    • Also looking at pursuing additional media organization improvements through a feature plugin, details still need discussion, @karmatosed on board to help with design
    • Next meeting Friday at 17:00 UTC
  • Customize (@westonruter, @celloexpressions)
    • Latest update
    • Primary commit for Harden panel/section UI code by removing contents from being logically nested (read: goodbye margin-top hacks) (#34391) is in, and a dev note is scheduled to be published after today’s dev chat
      • Some major changes here, so we need plugin and theme authors to test
    • Received design feedback on A New Experience for Discovering, Installing, and Previewing Themes in the Customizer (#37661) and working on making those revisions by the end of this week and planning to publish a feature proposal on Friday
      • Need to discuss themes again during tomorrow’s #design meeting for final approval before the changes are made
    • Need attention on Provide a better gateway for code-based theme customizations with the Customizer (#35395)
      • Discussion of whether this direction is appropriate lead to tentative consensus that this is likely appropriate for core
      • Next steps will be to loop @folletto in to improve the design and polish up the patch
      • Big other block discussed: sanitizing and validating the CSS & most appropriate corresponding capability
        • Currently rudimentary validation in the patch for balanced braces and comments. Need improvement if relying on it heavily, but it provides instant user feedback
        • Capability solution needs to work for multisite if at all possible, since that’s a primary use case
        • Discussion to continue on the Trac ticket and/or #core-customize
  • i18n (@swissspidy)
    • Feedback/help on Introduce a locale-switching function (#26511) would be appreciated
      • The problem is that labels of custom post types and taxonomies are only evaluated once, so switching locales wouldn’t properly translate those.
      • There’s a proposed fix for built-in types and taxonomies, but we prefer a better solution that works for all of these.
  • Editor (@azaozz, @iseulde)
    • Would like to help with a survey (scratchpad/draft). Need to start gathering user usage stats, should be opt-in, start with a plugin first, and release the aggregated data
    • Weekly data tracking (back-end) meeting Wednesday at 1900 UTC
  • HTTPS (@johnbillion)
  • REST API (@krogsgard, @kadamwhite )
    • Latest update
    • Whether the API should follow core behavior and save a revision every time a post is updated
      • Right now every update to a post creates a revision and can be a bit painful for some clients, so: 1) should that always happen? 2) should we have the ability to turn it off?
      • Decided on: 1) Yes.  2) The ability to use auto-drafts like in core makes sense, but doesn’t need to block merge.
    • How to handle image permissions, specifically for the case where an image is attached (uploaded) to a private post and then featured in a public post
      • Specifically, if I upload an attachment to a private post, its visibility is governed by that post, so it too is private but, in wp-admin I can add it as featured media to another public post. When that public post is queried: what happens!?
      • @joemcgill summary: I happen to think it’s an oversight in WordPress that we allow an image attached to a private post to be set as the featured image of another post (and by an author without permission to view the private parent post). We should probably either close this loophole or detach the attachment from the private post whenever it’s set as a featured image on another post.
      • @kadamwhite to document decision, @rmccue @joemcgill @helen et al will identify core tickets that should be opened.
    • Whether (and how) to expose edit locks through the API
      • Main thing here is whether this is a blocker? Decision: edit locks are great, but doesn’t need to block merge.
    • Next bug scrub is Thursday 1400 UTC; next team meeting is 1400 UTC on Monday, October 3rd

#4-7, #core, #core-editor, #core-http, #core-i18n, #core-media, #core-restapi, #dev-chat, #summary, #twenty-seventeen

Dev Chat Summary: September 21 (4.7 week 5)

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

Reminders

  • Schedule: As of this meeting, we are 4 weeks from the final chance to merge in major features. This includes Twenty Seventeen.

Bug Scrubs

Components & Features

  • Twenty Seventeen (@davidakennedy, @melchoyce)
  • REST API (@krogsgard, @kadamwhite )
    • Latest update
    • API discussion is at 7 am Pacific on Mondays
    • Settings endpoints and meta support both have first-passes on them, which need internal review and some more testing before we ship
    • We have a path forward for passworded posts (password in the query string, eww, but only viable option), there really isn’t a way we can see to avoid sending them as a query param
    • Meeting tomorrow in #core-restapi at 21:00 UTC to go through open issues around non-trivial, conceptual issues in WordPress. REST API team will prepare summary of issues for component maintainers and/or lead devs to review, question, and help guide discussion towards consensus.
  • Media (@mikeschroder, @joemcgill)
    • Latest update
    • Moving our weekly meetings up to Fridays at 17:00 UTC starting this week
    • Unexpected change to media title behavior in WP 4.6.1 (#37989) – The main issue here was resolved, but there seems to still be some odd behavior affecting words being chopped off filenames with international characters. Could use extra eyes from anyone (along with @sergey) more versed in i18n. Regression on the attachment titles that we generate on upload all became URL encoded instead of reading like a normal title.
    • Media search doesn’t include file name (#22744) – Committed earlier this week. Please report any issues that come as a result.
    • Next step in improving the organization of the media library is to assess both the infrastructure and UI improvements that need to be made here. Prefer to include #design early in this process, rather than asking for UI feedback on development driven decisions, hope to be part of the #design chat agenda tomorrow
  • Customize (@westonruter, @celloexpressions)
    • Latest update
    • In this week’s meeting we developed a schedule for publishing make/core feature proposals/dev notes for the remaining primary 4.7 customize projects, working backward from anticipated time to commit after the proposal and current readiness:
      • Week of 9/19: Improving sliding panels UI (34391, @delawski)
      • Week of 9/26: A new experience for themes in the customizer (37661, @celloexpressions). Please review soon for any requested changes in direction or design.
        • Summary: The existing themes section in the customizer is replaced with a full-screen theme browser and installer… The UI is nearly identical to wp-admin/theme-install.php… The .org-based theme-install previewer is not accessible here because it is likely to cause confusion with its customizer-like interface and the resulting need to switch contexts back and forth… An overarching goal is to avoid switching in and out of the admin/frontend/customize contexts during theme installation and previewing, instead staying in the hybrid customizer context that provides a combination of frontend plus controls… On the technical side, this heavily leverages JS-templated customizer controls and scales nicely to hundreds of themes.
        • Visual:
        • Please comment on the ticket with your feedback as soon as possible, preferably with specific concerns/ideas and reasons.
        • @celloexpressions to check in with @karmatosed on user testing ahead of posting final feature proposal
      • Week of 9/26: Customize transactions (30937, @westonruter evaluating this week and might punt again)
      • Week of 10/3: Code-editing gateways, via CSS (35395, @johnregan3/@celloexpressions). Awaiting approval/feedback on the acceptability/ability to bundle the two proposed libraries in core, with feedback particularly needed from committers and anyone familiar with the Jetpack fork of CSSTidy.
      • Week of 10/10: Customizer browser history (28536, @westonruter)
  • I18n (@swissspidy)
    • User Admin Language (#29783) – almost ready, another review this week and will commit if no blocker pops up
    • Introduce a locale-switching function (#26511) – @ocean90 to do some benchmarking
    • Introduce some JavaScript i18n functions (#20491) – GlotPress side has a solid plugin for exporting translations as JSON files (assistance on testing would be helpful). Still tinkering with the WordPress side and would love to get some additional feedback there.
  • Editor (@azaozz, @iseulde)
    • No updates, but would love to figure out a way to get more user feedback that helps us set direction for the editor. Will look to add some Core questions to annual survey on WordPress.org. Otherwise will start with something in the beta tester plugin, biased audience but it’s one that exists, is more likely to opt-in, and will be more flexible.
  • HTTPS (@johnbillion)

Open Floor

  • @pbearne on Add filters to wp_new_user_notification and wp_password_change_notification (#38068) – added a set of filters to allow us to override email messages send by the wp_new_user_notification and wp_password_change_notification functions. @johnbillion to review as it relates to work on notifications.
  • @danieliser checking for interest for core in a set of reusable templates, models & functionality for forms, tabs & modals
  • @ericlewis on Bulk actions: Reactivate bulk actions hook + add hander hook for all admin screens (#16031) – could use a review of the latest patch, looking to commit sometime in the next week
  • @dshanske still working through the Pings and Trackbacks component

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

Dev Chat Summary: August 3, 2016

Current status of WordPress 4.6

  • The 4.6 branch was created this week.
  • RC2 was scheduled for today, but because https://core.trac.wordpress.org/report/6 has so many open tickets its being delayed by 24 hours.
  • The first draft of the About page was committed today. Please help review it to make it ✨ Shiny ✨
  • @hugobaeta is looking for feedback on the images he’s created for the About page. The feedback will be heard and discussed in the #design weekly chat on August 4th, 2016 at 20:00 UTC.

Schedule for the next 13 days

The schedule is as follows:

  • August 10 is RC3 with the hard string freeze. The about page must be finalized by then.
  • August 12 will be code freeze. Everything should be done by this date. Only version bumps and the video should committed after this.
  • August 15 is the dry run for WordPress 4.6. We’ll check everything, prepare w.org, do a dry run for release day, and with @davidakennedy and @karmatosed we’ll release the new versions of our default themes as well.
  • And well, August 16, 2016. WordPress 4.6!

About page

As already mentioned, a first pass is committed. Check your dashboard and let us know what you think. Maybe ask some friends who aren’t involved in the release since that’s our target group.

Call for volunteers

The call for future release leads has been published. Leading a release can be a rewarding challenge. If you have questions, feel free to ping @jorbin or @helen. Everyone interested, please express it on the post, pinging @jorbin or @helen isn’t enough. They are more so available for answering questions. https://make.wordpress.org/core/2016/08/01/release-leads-call-for-volunteers/

Component announcements/updates and Open discussion

Currently the contributor handbook is lacking in documentation in regards to contributing via git. Core has supported git contributions for over 2 years. If you have a git work flow, use git, or have git knowledge in general, please consider looking over https://make.wordpress.org/core/handbook/contribute/ and adding docs where appropriate. Please remember that supporting git does not mean using GitHub.

Find full chat logs here: https://wordpress.slack.com/archives/core/p1470254406001902

#4-6, #dev-chat, #summary

Native Fonts in 4.6

When WordPress switched to Open Sans in version 3.8 at the end of 2013, the state of typography on the web was just beginning to evolve. Before, our choices for typefaces were limited to a small subset of fonts reliably installed on most major operating systems. And, in some cases, those fonts were optimized for print, not the web. Open Sans is optimized for the screen, has generous character support, and, best of all, is open source. For these reasons, it was a better option for a modern web app than the system fonts of that time.

Today, the landscape has changed. The majority of our users are now on devices that use great system fonts for their user interface. System fonts load more quickly, have better language support, and make web apps look more like native apps. By using the same font that the user’s device does, WordPress looks more familiar as a result. This change prioritizes consistency from the user’s perspective over consistency in branding. And while typography does play a role in the WordPress brand, the use of color, iconography, and information architecture still feels very much like WordPress.

To this end, Font Natively (#36753) replaces Open Sans with a set of system fonts that covers major operating systems, including Android, iOS, Windows, macOS, and Linux.

The Font Stack

Safari, Chrome, and Firefox on iOS and macOS have new CSS values that return the current system UI font, but on other platforms, the font has to be declared by name. As such, the font stack includes the following:

  • -apple-system for Safari (iOS & macOS) and Firefox macOS
  • BlinkMacSystemFont for Chrome macOS
  • Segoe UI for Windows
  • Roboto for Android and Chrome OS
  • Oxygen-Sans for KDE
  • Ubuntu for Ubuntu
  • Cantarell for GNOME
  • Helvetica Neue for versions of macOS prior to 10.11
  • sans-serif, the standard fallback

The complete CSS declaration: font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;

Details

The operating system’s UI font is used for any text that’s part of the WordPress user interface. In other contexts, like the Editor, we continue to use a serif system typeface, Georgia. This creates a clear typographic distinction between text that is part of the interface, and text that is part of the user’s content.

Not all system fonts provide the same range of weights that Open Sans did. We recommend using only the 400 and 600 weights, which will display most consistently across all platforms. I’ve created a test page that shows the difference between Open Sans and your current device’s system font at every available weight. (A collection of screenshots of that test page is also available).

The order in which they’re called is important, because we want the user’s system font to be the first available font in the stack. For example: if Roboto were listed ahead of Segoe UI, Windows developers who have installed the Roboto font for Android development would see it instead of their native system font. There may be edge cases if users have manually installed these fonts on their machines, but this order should work best for the majority of users.

When using this font stack, it must be called using the font-family property, and not the font shorthand. This works around an issue in Microsoft Edge.

Screenshots

All screenshots were taken on a retina (2dppx) device. If you’re reviewing screenshots on a non-retina display, check out this Cloudup gallery of 1x screenshots.

#4-6, #design, #dev-notes, #fonts

Made some minor style updates to the wpo…

Made some minor style updates to the wporg web site today; changed the dark grey and light blue backgrounds to lighter shades of grey to better match the 3.0 style, as requested by Matt M. Replaced homepage screenshots with new ones from 3.0, as requested by Jane.

#design, #wporg

There was some talk last night about may…

There was some talk last night about maybe doing a little design brushup on the admin header/nav. We only have a couple of days to decide on the design changes if we want to include it in 2.8. Would like to give community designers the opportunity to do a mockup (could give them a psd of the current style), but since they’d need to submit their design suggestions by Monday, and I’m nervous that there might be some backlash for the short/no notice. I mean, MT didn’t get any notice either, so it seems fair. It’s a pretty small design job… Jaquith did a quick mockup in 5 minutes. If anyone does take up the challenge, we can post the comps for a vote on Tuesday. What do people think?

#design