X-post: Our Strengths and Challenges

X-comment from +make.wordpress.org/updates: Comment on Our Strengths and Challenges

Editor Chat Agenda: January 23rd

This is the agenda for the weekly editor chat meeting on Wednesday, 23rd January 2019, 14:00 GMT:

If you have anything to propose to add to the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

#agenda#core#editor-chat

Privacy Office Hour Notes – January 9th, 2019

Huge thank you to all who attended the very productive office hours! The recap notes are a bit delayed, but they were not forgotten! A full agenda can also be found in an earlier post, and the full transcript can be found in Slack.

Here are the highlights of the meeting:

Agenda Item 1 – Roadmap Review

  • @idea15 reminded us that there is a more recent version of the Roadmap.
    • @desrosj will investigate how to give more maintainers access to update the roadmap page.
  • @lakenh mentioned Trac issue #44161, regarding IP addresses stored within the usermeta table.
    • @xkon provided an example of a user meta session token, and it contained both a user agent and IP address.
    • @lakenh also discovered that the community-events-location user meta field also contains a full IP address.
      • He also suggested perhaps anonymizing that particular IP by dropping the last few places as the geographical location shouldn’t change by much.
    • @desrosj then asked if these fields were accounted for within the original data export/erasure tools.
      • @garrett-eclipse delivers the bad news that they were not.
      • Ticket to track this issue has been opened, #45889.

Agenda Item 2 – 2019

  • @idea15 gave an update on the cross-project privacy group which broke ground at Drupal Europe. Joomla’s Glip (similar to WordPress’ Slack) now has representatives from this WordPress Privacy team, Drupal, Joomla, Typo3, Umbraco, as well as other industry representatives who are all providing aid to make all CMSs have great privacy features built-in.
  • @desrosj helped to set expectations for what privacy-related changes are acceptable moving forward based on a recent discussion in #core-committers. Small enhancements and bug fixes will generally be OK to include in new releases with little oversight. Larger enhancements will need approval by version release leads.
  • Brainstorm session for how the team’s goals and the greater WordPress project’s goals overlap in 2019.
    • @desrosj suggested the following three areas of being places that we can help out:
      • Providing a way for users to opt-in to automatic plugin and theme updates.
      • Providing a way for users to opt-in to automatic updates of major Core releases.
      • Building a WordPress.org directory for discovering blocks, and a way to seamlessly install them.
    • @desrosj also suggested Health Check as a possible area, as perhaps there are some server level privacy checks that could be built in.
      • @clorith expressed that the team was open to any ideas and that privacy features for Health Check can be created as GitHub issues on its repo for consideration.

#core-privacy, #privacy

New User Related Short Circuit Filters

WordPress 5.1 introduces new short circuit filters to WP_User_Query and count_users().

The users_pre_query filter was introduced in #44373 and runs before the database query takes place. This enables short-circuiting the database query entirely to return custom results. Returning a non-null value from the filter will bypass WordPress’s default user query (similar to the posts_pre_query filter for WP_Query added in #36687).

Developers should note that filtering functions that require pagination information are encouraged to set the total_users property of the WP_User_Query object (which is passed to the filter by reference). If WP_User_Query does not perform a database query, it will not have enough information to generate these values itself.

Using the users_pre_query Filter

Below is a rough example of how a plugin can use the filter to replace the default behavior of WP_User_Query with a call to a remote data store.

function myplugin_do_external_users_query( $users, $user_query ) {
	$response = wp_remote_get( 'https://my-remote-data-store/foo/bar' );

	if ( 200 === wp_remote_response_code( $response ) ) {
		$response           = json_decode( wp_remote_retrieve_body( $response ) );
		$users              = array_map( 'intval', $response->user_ids );
		$query->found_users = (int) $response->found_users;
	}

	return $users;
}
add_filter( 'users_pre_query', 'myplugin_do_external_users_query', 10, 2 );

Similar to posts_pre_query, callbacks must be careful about fields – the external API may have to return user IDs or quasi-WP_User objects, depending on the value of fields.

A more in-depth example of how this filter can be utilized can be found in this project, which enables user query caching.

Filtering the count_users() Function

In addition, a pre_count_users filter was added in #43693 which enables short-circuiting the count_users function before the database query takes place. Returning a non-null value from the filter will bypass the default queries.

Using the pre_count_users Filter

Here is a sample code snippet showing how to use this filter:

function myplugin_do_external_users_count( $user_count) {
	$response = wp_remote_get( 'https://my-remote-data-store/foo/bar' );

	if ( 200 === wp_remote_response_code( $response ) ) {
		$response = json_decode( wp_remote_retrieve_body( $response ) );
		$user_count    = $response->user_count;
	}

	return $user_count;
}
add_filter( 'users_pre_query', 'myplugin_do_external_users_count', 10, 2 );

More Filters Coming Soon…

Several additional filters for similar query objects are currently being explored and worked on, and are currently slated for a future release:

  • A short circuit for WP_Comment_Query (#45800).
  • A short circuit for WP_Site_Query and WP_Network_Query with a plan to add a sites_pre_query filter (#45749).
  • A short circuit for WP_Term_Query with a plan to add a terms_pre_query filter (#41246).

Why Add These Filters?

These query pre-filters enable plugins to use an alternate database store for queries, for example returning results from an external service such as an Elasticsearch server. The process started with the main post query, and these are now being expanded that to other queries in WordPress.

#5-1, #dev-notes

Proposed Revision to CSS Coding Standards

During the Core Dev Chat on January 16th, 2019, a proposal for a minor change to the lengthier multi-part values section was briefly discussed.

The following is what the current CSS Coding Standards recommend in the property values section:

Multiple comma-separated values for one property should be separated by either a space or a newline, including within rgba(). Newlines should be used for lengthier multi-part values such as those for shorthand properties like box-shadow and text-shadow. Each subsequent value after the first should then be on a new line, indented to the same level as the selector and then spaced over to left-align with the previous value.

Code examples:

	text-shadow: 0 -1px 0 rgba(0, 0, 0, 0.5),
                 0 1px 0 #fff;

	transition: 0.15s color ease-in-out,
                0.15s background-color ease-in-out,
                0.15s border-color ease-in-out;

However, the current recommendation leads to indentation made with spaces or mixed tabs and spaces.

Ideally, indentation made with spaces or mixed tabs and spaces should always be avoided and, to preserve the indentation alignment, all lengthier multi-part values should be in a new line.

Worth noting that, in many cases, new lines and tabs are already used across the WordPress admin stylesheets, for example:

	box-shadow:
		0 0 0 1px #5b9dd9,
		0 0 2px 1px rgba(30, 140, 190, .8);

Proposed change

During dev chat, general consensus was expressed in favor of changing the CSS Coding Standards values section as follows:

Multiple comma-separated values for one property should be separated by either a space or a newline, including within rgba(). Newlines should be used for lengthier multi-part values such as those for shorthand properties like box-shadow and text-shadow, including before the first value. Values should be indented one level in from the property.

Code example:

	box-shadow:
		0 0 0 1px #5b9dd9,
		0 0 2px 1px rgba(30, 140, 190, .8);

The proposed change aims to improve consistency across the admin stylesheets, code readability, and style linting.

Any feedback is welcome! Please share your thoughts in the comments below.

#css, #standards

Media Meeting Recap – January 17, 2019

Overview

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

Attendees: @joemcgill @mikeschroder @karmatosed @desrosj @antpb @aaroncampbell @designsimply

Transcript: Read on Slack

5.1.0 Triage

Earlier in the day, @aaroncampbell, @mikeschroder, and @desrosj cleared the list of tickets reported against trunk awaiting review.

During the meeting, attendees scrubbed the remaining Media tickets in the 5.1.0 milestone.

  • #40590: wp_video_shortcode always adds controls=”controls”: The team wasn’t confident in the current approach. Punted to future release.
  • #45407: Add block attributes to wp_calculate_image_sizes to allow for proper handling of sizes attribute: This doesn’t seem to be ready for 5.1 but @joemcgill will make a final determination this week.
  • #40175: Upload Validation / MIME Handling: @joemcgill uploaded a patch this week. @pento reviewed and this will likely fall out of 5.1 and be marked for early 5.2. Testing/feedback is appreciated.
  • #44563: WordPress 4.9.7 Media delete changes break plugins deleting media via stream wrappers: No movement this week, punted to future release.
  • #44760: Media library module dates filter doesn’t fully display: @mikeschroder is owning and will either commit or punt.
  • #44836: Uploaded plugin installation page: There is an extra tag messing with a link: No movement. Punted to future release.
  • #45633: finfo_file() returns text/plain for json file instead of application/json: This is punted to future release, pending #40175.
  • #43826: get_post_galleries() should return gallery blocks: This remains a blessed task for now.
  • #45707: Add parameter $real_mime to wp_check_filetype_and_ext: This might land as a relief while #40175 is pending, as long as it doesn’t introduce future compatibility challenges.

Recent Trac Bulk Edit

The team discussed how we should handle the recent bulk edit closing of tickets. Of the tickets closed, 163 are Media component tickets. The general consensus is that we shouldn’t leave them as wontfix but no final decisions were made. Next steps are for everyone to leave feedback on the original P2 about how to handle this project wide, and we will plan to make a decision about Media tickets next week.

Next meeting

The next #core-media meeting is set for Thursday, January 24, 2019, 21:00 UTC. Leave any agenda suggestions in the comments of this post. See you there!

#media, #summary

Editor chat summary: January 16

Phase 2

  • 4.8 has been included in WordPress 5.1
  • 4.9 is going to be released next week according to the regular schedule.
  • In order to address some feedback about how to get involved for phase 2 this post was shared to hopefully clarify this more.
  • Task Co-ordination
    • The idea is not to get everything done for next week, a simple task could be to do some research and clarify the work needed to accomplish a task.
    • The main features/focus for phase 2 are highlighted here.

Block Proposals Flow

  • @karmatosed raised the point of getting new blocks into core.
    • When should something be proposed to core? Not all blocks should be core
    • How can you propose a block to core?
    • What ‘state’ should it be in?
    • How do we proceed from proposal to iterate and collaborate?
    • Don’t want to end up with 1000s of the same block

Widgets > Blocks

  • Need devs to build prototypes.
  • Would be great to get more people contributing and building these blocks.

PRs to highlight

  • E2e tests reorganisation@gziolo has been doing some great work on e2e tests both for accessibility and also a way to make the e2e tests setup usable outside the Gutenberg repository, reference here.
  • A note for those who write e2e tests, they have been moved them to packages/e2e-tests/specs folder. As new blocks are developed supporting documentation should be developed and attached to the block some way.
  • New package with all e2e test utils wordpress/e2e-test-utils which is going to be published to npm next month and will allow some code reuse for those who can start writing e2e tests for their WordPress sites.
  • aXe accessibility testing
    • The set of tools for accessibility static analysis which need integration with e2e tests to ensure that regressions are caught early on, learn more here.
    • Issues need fixing, some of them are related to the fact that WordPress uses “screen-reader-text” class. More info here.
  • Async mode for the data module
    • A big milestone in terms of performance improvements that is going to be included in 4.9.
    • Make sure to test it extensively with your custom blocks plugins. More info here
  • Ready to review:

Action Items

Open Floor

  • @chrisvanpattenwill have some free cycles this week to review docs PRs, particularly from a grammar/clarity/readability perspective. If anyone has PRs you want reviewed please DM him.
  • @luehrsen — would love to see a ‘blocks’ section on the ideas page: where people can propose blocks and plugin devs can pick that up. (Good case in point is @melchoyce’s Restaurant Design blog post)
  • Although @joostdevalk has expressed a desire to kill that ideas page in the past, and now that he’s in his new marketing position for the project he may very well follow through on that
  • @youknowriad — A premise of Gutenberg is to enable people to build custom blocks easily (for niche use-cases)
  • @ajitbohra — Perhaps a block library/pack as a plugin, for blocks that are not intended for core.
  • @paaljoachim — supports having options in blocks to create a top and bottom margin/padding, as we need space between blocks in the layout.

The meeting archive is here.

The agenda for the next meeting is here, please add anything you want to discuss.

#meeting-notes, #editor-chat

#core-editor, #editor, #gutenberg

Dev Chat Agenda: January 16th

Do you like devchat? I like devchat. This is the agenda for the weekly devchat meeting on Wednesday, January 16 2019 at 2100 UTC:

If you have anything to propose to add to the agenda or specific items related to those listed above, please leave a comment below. Either way, we look forward to seeing you at the devchat this week!

This meeting is held in the #core channel in the Making WordPress Slack.

#5-1, #agenda, #core, #dev-chat

WordPress 5.1 Schedule Updates

Good news, everyone! WordPress 5.1 is on schedule, and progressing nicely. At the time of writing this post, we have 123 open tickets milestoned for WordPress 5.1, down from nearly 500 a week ago. Thank you to everyone who’s helped triage these tickets! 💖

To keep things running smoothly as we head towards the Release Candidate and WordPress 5.1, I have some intermediate targets that I’d like us to aim for.

Beta 2: January 21, 2019

There’s still a moderate amount of ticket triage to do, including working through the 87 tickets reported against trunk that haven’t been milestoned. Many of these are reported against the wrong version, but they do need to be triaged prior to beta 2.

After beta 2 is released, any bug reports against versions prior to 5.1 will be move to the 5.2 or Future Release milestones.

Beta 3: January 29, 2019

This is the soft string freeze release. All string changes (except for the About page) will be moved to the 5.2 milestone.

Release Candidate 1: February 7, 2019

There should be no open tickets in the 5.1 milestone by RC1, apart from release-related tasks.

5.1 will be branched with RC1, and work can begin in trunk on WordPress 5.2. As we’re back to standard commit review practice, any WordPress 5.1 fixes will need to be reviewed by two committers before porting to the 5.1 branch.

WordPress 5.1: February 21, 2019

🎉

#5-1

X-post: Expanding WordPress Leadership

X-comment from +make.wordpress.org/updates: Comment on Expanding WordPress Leadership