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.

#4-9, #bug-scrub, #core-customize, #media-widgets, #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

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

New login page looks good.

New login page looks good.

#design