@peterwilsoncc and @audrasjb led the weekly meetings of the WordPress Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team, respectively at 05:00 UTC and 20:00 UTC. Here is the meeting agenda.
Link to 05:00 UTC devchat meeting on the core channel on Slack
Link to 20:00 UTC devchat meeting on the core channel on Slack
Release announcements
WordPress 5.7.1
WordPress 5.7.1 was released on Wednesday April 14, 2021. This security and maintenance release features 26 bug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes in addition to two security fixes.
There are only 6 tickets in the next milestone (5.7.2), and as for now there is no urgent thing to address.
WordPress 5.8
Some blog (versus network, site) posts were published on Make/Core:
@annezazu shared that 2 weeks are left to go on a Query Quest and give feedback. Worth noting there is also an Italian version of the testing process (props to @piermario). If you have issues with the call for testing or questions about setting up a test site, please feel free to ask @annezazu in the #fse-outreach-experiment channel on Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
@chanthaboune shared that the next step for WP 5.8 is to get a release team together.
While she’s finally not available to lead the release squad, @francina will be available to help wrangling contributors and mentoring. She will also publish a call for release team members on Make/Core.
Make/Core News
Blog posts that need feedback: FLoC concerns
One blogpost was discussed during most of the meeting time:
@carike posted the proposal, and an active discussion started with more than 100 commenters. For those interested, there is a summary of the discussion on WP Tavern. Worth also noting that @helen, lead developer of the project, published a top comment about the proposal.
@peterwilsoncc previously shared a comment from the Security team in the initial post: based on the information presented, this should not be considered a security issue A security issue is a type of bug that can affect the security of WordPress installations. Specifically, it is a report of a bug that you have found in the WordPress core code, and that you have determined can be used to gain some level of access to a site running WordPress that you should not have. at this time.
Worth noting that 3 people from Google Chrome DevRel team attended the meeting: @michaelkleber as Chrome Tech Lead for the ads-related APIs, @r0wan and @samdutton as Chrome DevRel.
Below you’ll find some direct quotes from this open floor discussion:
@michaelkleber shared that the FLoC initiative is just at the beginning of what Chrome calls an Origin Trial — that’s the way we introduce new proposed APIs to get feedback from developers.
@joyously asked whether FLoC simply is a cookie of another flavor or not.
@r0wan answered there is a key difference with a cookie is that it’s a 1:1 token the server sets on the client. With the FLoC id, it’s a 1:many grouping that does not enable that same direct link back to an individual across different sites. It’s also not a value that the server gets to set for the client.
@michaelkleber added that the key contrast with third-party cookies is that a FLoC cohort can’t be used to know information specifically about you. Instead it allows some kind of probabilistic information about a large group of people that you’re temporarily part of (each FLoC cohort has thousands of people in it).
@carike shared with a detailed use case and asked for the safeguards that are in place to prevent this.
@helen’s asked what is the utility is of disabling FLoC on the content provider front vs. on the consumer front.
@michaelkleber answered that in the final end state, they expect the way FLoC will work is that the only pages that will be relevant to calculating your cohort are the pages that call the FLoC API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. So pages will “opt in” by using some new JS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. function call. The HTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. header The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. being discussed here was introduced as a way that pages could include random 3rd-party JS without worrying that it would invoke that API without them expecting it. So the HTTP header is saying “There is a new API that exists in the web, and I want to be sure my page cannot use it”.
@michaelkleber: FLoC doesn’t involve saving any new information, it’s just calculated based on the recent browsing history — and not the full URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org even, just the domain name.
@helen: So on its own by default, a WordPress-served page of content is not going to be used to calculate. However, if you were to, say, embed something that includes a piece of JS, that JS could then call the API and it would include the entire page?
@r0wan answered: so a default WordPress page with no use of the FLoC JS API and no ad-tagged resources in it will not be used as part of the FLoC calculations. If that site includes a third-party that uses FLoC then that would include the top-level page.
@michaelkleber: There is a bunch of on-device clustering that goes into making sure that your FLoC is shared with thousands of other people. If you want to read more about the technical details of clustering, here’s the page that describes it all.
@macmanx: So, is there’s no point in a site blocking FLoC if that site is not using FLoC-enabled resources? If a site were not using AdSense, it’s most likely not even going to be included in FLoC? And, on the other hand, if that site were already running AdSense, it probably benefits from FLoC and would not want to block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.?
@samdutton nodded: During the current FLoC origin trial, a page visit will only be included in the browser’s FLoC computation for one of two reasons:
@macmanx: So, FLoC only triggers when resources that benefit (or are assumed to benefit) from FLoC are present. If I have that right, then WordPress blocking FLoC software-wide would be similar to blocking Google Fonts software-wide. It would have an effect but would actually be more of a negative impact to the site itself.
@michaelkleber: We’re running the Origin Trial so that we can get feedback, and what we hear from people (including you, now) is the kind of feedback that affects the end decision.
So it seems to me that this group is generally in favor of our best-guess plan (only look at pages that actually invoke the FLoC API), for which thank you. But I’m sure we’ll hear other opinions as well.
@mkaz: I think debating the merits of FLoC is a bit beyond the point, it may or may not be evil, probably no more or less than say AdSense. Where we wouldn’t introduce something to WordPress that would explicitly block a site from implementing AdSense, right?
@carike: The proposal just changes it from opt-out to opt-in. It does not prohibit someone from opting in.
@westonruter: If the page has to opt-in to FLoC by using an API then what’s the point of also requiring the site to opt-in to allowing FLoC as well? Going back to the Google Fonts example, if WordPress blocked Google Fonts from being used except if an opt-in is used, then if a theme enqueued a Google Font stylesheet then they’d also have to add the code to opt-in to not blocking Google Fonts. That doesn’t make sense to me. It’s like requiring a double opt-in?
@mkaz: It doesn’t seem like the area of the WordPress software to automatically opt people out of something in their browser.
@helen: So, a user/consumer disabling FLoC in their browser would mean they are not dropped into a bucket that’s used to determine ads/whatever that they see around the web (or… wherever). A WordPress site by default will not be used as a part of determining a given user’s bucket.
@macmanx: It seems to me, based on all this discussion, the best place for anti-FLoC measures are in the browser under control of the viewer, not in the site. If a site is triggering FLoC in the first place, it likely intends to benefit from FLoC in some way.
@carike shared a quote from the Chromium repository: “Any request made within an ad iframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. is considered an ad resource request.”
@michaelkleber: The point is that Chrome’s Ad Tagging is trying to figure out exactly which resources are ads — very important if you want to, for example, unload ads that use too many bytes. So the rule is “anything loaded inside an ad counts as part of the ad”. But for FLoC, we’re asking a much coarser question: “Does this page have any ad stuff on it at all?” So details about which specific items are part of that ad are irrelevant.
@jorbin: In my personal opinion, WordPress is best off making a decision of no action at this time (not that we are making a decision in the meeting). FLoC as of right now is in such a small trial that we as a project should continue to monitor it and try to encourage that the final implementation is one that is going to align with us a project, but as of now it doesn’t present any danger to individuals on the web and in fact has the potential to benefit many publishers.
At the end of the chat, @jorbin shared a reminder about the Post & Comment Guidelines on Make/Core blogs to everyone that has posting abilities on make/core that we do have a page with expectations for posting there and that 1) All posts should be peer reviewed (it currently states by a committer A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component., but I personally would say project leaders who are not committer would fall into that bucket) and 2) That the peer reviewer should be recognized in the post.
The Google Chrome DevRel Team members shared that everyone is welcome to get in touch them via the chromiumDev Twitter account or the FLoC repository on GitHub.
After the devchat, @helen opened a ticket Created for both bug reports and feature development on the bug tracker. to summarize the discussion and to discuss the next steps: #53069: Consider implications of FLoC and any actions to be taken on the provider (WordPress) front. Everyone is welcome to contribute to the discussion in this Trac ticket.
Thanks @chanthaboune for the quick review.
#5-7-1, #5-8, #dev-chat, #summary
