Jb Audras 11:30 pm on February 12, 2020
Tags: 5.4 ( 53 ), auto-update ( 24 ), security, two-factor ( 12 )

Dev Chat summary – February 12, 2020 (5.4 week 5)

@davidbaumwald facilitated the chat on this agenda.
@audrasjb and @marybaum took care of publishing the meeting notes.

This devchat marked week 5 of the 5.4 release cycle.

Announcements

WordPress 5.4 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 was released on Tuesday 11 as expected 🎉

WordPress 5.4 Beta 1

Highlighted posts

Upcoming releases – 5.4

As mentioned, WordPress 5.4 Beta 1 was released on February 11th, 2020.

Please help by testing the Beta and reporting any bugs on WordPress Trac (or Gutenberg GitHub repository).

The Docs squad has published the first two dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.:

The idea is to publish dev notes as soon as possible during the beta cycle and then publish the Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. before Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)..

@audrasjb offered a quick update on Automatic Updates for Plugins and Themes. Because there is still work needed, along with extensive testing, decision is to start by managing autoupdates in a feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. and then merge into CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for 5.5.

Work on this feature plugin will start in the coming weeks.

Components check-in

@valentinbora is the new Administration Component maintainer.

In 2014, Administration was proposed to be moved from a component to a focus so it wouldn’t end up as a dumping ground for tickets. That decision led to its removal from the Components page, but not anywhere else.

Recently, this component returned to the Components page as per this Meta ticket, and it turned out that Administration still has a lot of tickets. The long term idea is to triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. all the tickets that are there and, as part of that process, move those tickets to other components with the administration focus.

@whyisjake is now a Security Component maintainer.

Open floor

@whyisjake told the group that he’s going to help Two-Factor Authentication, currently developed on GitHub, move toward becoming a feature plugin for WordPress Core.

A first step: a proposal on Make/Core. @desrosj and @clorith are also interested in the project, which has been a discussion topic in the core-passwords SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel and in this GitHub pull request.

@whyisjake shared that he attended the CMS Security Summit last week, and Two-Factor Authentication was a major takeaway from the event, as was bringing automatic updates into Core.

@xkon added that #49200 needs input, so the team asks for yours. If you have any interest at all in cryptographic signature for plugins and themes, please follow the discussion on the dedicated Slack channel, core-signatures, and consider helping out.

#5-4, #auto-update, #security, #two-factor

Ian Dunn 4:03 pm on August 16, 2019
Tags: auto-update ( 24 ), security

Follow-up Discussion on Major Auto Updates

Last week’s proposal to automatically upgrade old sites to 4.7 has garnered a lot of feedback, which has been very helpful in refining the idea and getting a sense of how different parts of the community feel about it.

To follow up on that, I’d like to have a meeting in #core on Tuesday, August 20, 2019, 2100 UTC to continue the discussion. No decisions will be made during the meeting, but I hope that we can have a productive conversation and move closer to some kind of resolution.

To join the meeting, you’ll need an account on the Making WordPress Slack. If you’re not able to attend, but would like to give feedback, please leave a comment on the proposal.

#auto-update, #security

Ian Dunn 7:45 pm on August 7, 2019
Tags: auto-update ( 24 ), security

Proposal: Auto-Update Old Versions to 4.7

Foreword: To help anchor some of the main concerns from the comments, I’d like to highlight a few important points in this post. – Josepha

This post contains a careful roll out plan. This would not be be a sudden and un-communicated change.
There will be options for site admins to opt-out of the update with clear instructions starting 30 days prior.
This would apply to small segments of each version sequentially, not all at once. This helps us check the updates in batches and limit the risk of breaking sites irrevocably.

Based on the ideas in last week’s discussion, I’d like to propose a new policy regarding backporting security fixes to old versions, and a plan to implement it.

Policy

Note: This has been edited since it was published, to incorporate feedback from the comments.

Apply security updates to the latest 6 versions, and slowly auto-update insecure sites to the oldest secure version.

That would mean that the currently secured versions would be 4.7 - 5.2, and the 3.7 - 4.6 branches would eventually be auto-updated to 4.7.

In practice, that’d provide roughly 2 years of security fixes for each branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"., and roughly 10% of current sites would eventually be auto-updated to 4.7. Security fixes would not be guaranteed for any specific length of time, though. Once 5.3 is released, 4.8 would become the oldest secured version.

A set number of versions creates a consistent limit on the amount of work required to backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. security fixes. Auto-updating insecure versions allows us to continue protecting older sites, rather than seeing them fall into the hands of spammers and criminals.

Implementation Plan

Auto-updating major versions is already a relatively safe process, because of WordPress’ commitment to backwards-compatibility, and the robust safety checks and rollback feature included in the auto-update system. However, this should still be done cautiously, to avoid breaking any sites.

A small subset of sites would be tested first, so that any problems can be identified and corrected before the majority of sites are updated. Sites would be updated one version at a time, to minimize the number of things that could go wrong.

Auto-updates of old branches would be done at a different time than new releases, to avoid a situation where there could be multiple problems to troubleshoot at once.

The process for auto-updating insecure versions would look like this:

Note: This has been edited since it was published, to incorporate feedback from the comments.

Publish a post on wordpress.org/news, to inform the wider world about the upcoming updates as far in advance as possible. A specific date for updates will not be known at this point, but it will be at least 6 weeks in the future.
Release 3.7.30 - 4.6.15, which will:
1. Allow admins to opt-out of major auto updates by clicking a simple button.
2. Email all site admins/editors to ask them to upgrade to the latest version, and inform them that their site will be auto-updated to 3.8 in the near future if they don’t opt-out. It will link to some documentation with more details, and include a link that they can click to opt-out. They’ll be warned about the security implications of opting-out. Editors won’t be able to directly install the update, but they can reach out to admins who can.
3. Add an adminadmin (and super admin) notice within wp-admin, containing similar information as the email. The notice will be visible to all site users.
4. If users opt out, they will no longer get the emails asking them to update, but will continue seeing the wp-admin notices.
Test auto-updating 3.7 to 3.8 against test sites, and make any necessary improvements to the auto-update system.
1. One necessary modification would be to email the site owner if the auto-update fails and is rolled back to 3.7. The email should be a strongly-worded warning, letting them know that their site could not be upgraded to a secure version, and that they should manually update immediately. If they don’t update, it’s almost guaranteed that their site will be hackedhacked eventually.
2. Similarly, if the auto-update fails and the user is stuck on an insecure version, an admin notice should be displayed in wp-admin with a warning similar to the email above. This would replace the pre-release banner from 3.7.30 described above.
3. We could potentially look into ways to make an educated guess about the chance of an undetectable error, and abort the update on those sites, to minimize the risk of breaking something. For example, if a known incompatible pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is installed. In those cases, we’d want to send the admin the same warning email & admin notice, letting them know that they’re stuck on an insecure version, and need to manually update immediately.
Update the Core handbook with details on the new process, so that everyone knows how to deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. major auto-updates.
Publish a document on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ explicitly stating a support policy, to avoid confusion.
1. Only the latest major version is officially supported and guaranteed to receive security updates.
2. There are no LTS releases, and all releases older than the current release are EOL.
3. We make an effort to backport security fixes to the previous 5 major releases, but no guarantee is made, as sometimes it is not feasible or practical.
4. Everyone is strongly recommended to always run the latest major version.
T-30 days: Release 3.7.31, which will:
1. Send all site admins and editors a 2nd email, similar to the 1st, letting them know that their site will be auto-updated to 3.8 in 30-45 days, and include instructions to opt-out, etc.
2. Update the 3.7.30 wp-admin notice to include the date range of the impending update.
3. Include any necessary improvements to the auto-update system, as described in step 3.
Deploy the auto-updates in phases:
1. The general process would be to deploy to a subset of 3.7 sites, then wait 1 week to see if any issues are reported. If anything unexpected happens, the process can be paused in order to fix those issues, and then restarted.
2. T-0 days: Deploy to 2% of 3.7 sites, selected randomly to get a representative sample.
3. T+7 days: Deploy to another 18%.
4. T+14 days: Deploy to the remaining 80%.
If all goes well, the process can be repeated to update 3.8 sites to 3.9, and so on until all sites are running 4.7. Some of the steps can be automated to make the process easier in the future.

Feedback

Overall, would you like to move forward with the general approach of this policy/plan?
Would you make any tweaks to improve it?

Update: The policy and implementation plan have been updated to clarify some miscommunications that were revealed in the comments:

CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s official policy has always been to only support the latest version, and this proposal does not intend to change that. It only means to impact the number of versions that we backport to, and to start auto-updating very old versions to a more recent version.

This is consistent with — and moving towards — the Core team’s pre-existing long-term plan of getting to the point where all WordPress sites are running the latest version automatically and transparently, similar to how Chrome and other modern software work.

Older versions are not guaranteed to receive all security updates, since that is not always possible. The versions that receive updates would not be considered LTS versions; they would only receive the security updates that are feasible to backport. Everyone should always run the latest version.

This proposal is not intended to become permanent. It seems like a prudent action for the current situation, but like everything else, it should be re-evaluated in the future, as the situation changes.

#auto-update, #security

Aaron D. Campbell 5:00 pm on July 5, 2018
Tags: minor releases ( 25 ), security

WordPress 4.9.7

WordPress 4.9.7 is now available. This maintenance and security release fixes 17 bugs.

Download WordPress 4.9.7 or visit Dashboard → Updates and click “Update Now”. Sites that support automatic background updates are already beginning to update automatically.

Thank you to everyone who contributed to WordPress 4.9.7:

1naveengiri, Aaron Jorbin, abdullahramzan, alejandroxlopez, Andrew Ozz, Arun, Birgir Erlendsson (birgire), BjornW, Boone Gorges, Brandon Kraft, Chetan Prajapati, David Herrera, Felix Arntz, Gareth, Ian Dunn, ibelanger, John Blackbourn, Jonathan Desrosiers, Joy, khaihong, lbenicio, Leander Iversen, mermel, metalandcoffee, Migrated to @jeffpaul, palmiak, Sergey Biryukov, skoldin, Subrata Sarkar, Towhidul Islam, warmlaundry, and YuriV.

WordPress versions 4.9.6 and earlier are affected by a file deletion issue where a user with the capability to edit and delete media files could potentially manipulate media metadata to attempt to delete files outside the uploads directory.

Thank you to Slavco for reporting the original issue and Matt Barry for reporting related issues.

Other highlights of 4.9.7 include:

TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies.: Improve cache handling for term queries.
Posts, Post Types: Clear post password cookie when logging out.
Widgets: Allow basic HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. tags in sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. descriptions on Widgets adminadmin (and super admin) screen.
Community Events Dashboard: Always show the nearest WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. if one is coming up, even if there are multiple Meetups happening first.
Privacy: Make sure default privacy policy content does not cause a fatal error when flushing rewrite rules outside of the admin context.

You can see the full list of changes in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

The previously scheduled 4.9.7 is now referred to as 4.9.8, and will follow the release schedule posted yesterday.

#minor-releases, #security

Jeffrey Paul 4:43 am on June 29, 2018
Tags: 4.9.3 ( 9 ), 4.9.7 ( 12 ), core ( 561 ), core-js ( 131 ), dev chat ( 714 ), gutenberg ( 475 ), security, summary ( 819 )

Dev Chat Summary: June 27th (4.9.7 week 6)

This post summarizes the dev chat meeting from June 27th (agenda, Slack archive).

4.9.7 planning

Confirmed @pbiron and @joshuawold as co-release leads with @sergeybiryukov and @psykro as co-deputies
Likely focus for 4.9.7 to be “Try GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/” prompt and privacy fixes
Release timing for 4.9.7 will be confirmed amongst release leads and shared when ready
Consensus that release leads have previous contribution experience (not necessarily CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. contributions), also helpful that a lead or deputy has commit access
Aiming to expand roster of individuals who have experience leading releases, so one approach is pairing “new” leads with “experienced” ones though other candidates could feasilby be experienced enough to not require a co-lead
Though no defined process exists on selecting or confirming leads, if someone has concerns about a nominated lead they can directly talk with @jeffpaul if they’re not comfortable speaking up during the devchat though ideally concerns are more transparent or at least leverages a group and not a single entity to coordinate concerns appropriately

Updates from focus leads and component maintainers

The Gutenberg team released v3.1 and published release notes as to the updates included
The JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. team published notes from their meeting where they discussed sunsetting the packages repository, an alternative to wp.apiRequest, a deprecation strategy, data module improvements, the build process, and inline docsinline docs (phpdoc, docblock, xref). Many thanks to them for continuing to share notes from their chats
Reminder to focus leads and component maintainers to try and publish meeting notes from your chats to help socialize what’s happening across the different teams in #core.

Devchat coordination

@jeffpaul will be offline most of July, so @joemcgill, @audrasjb, and @antpb will help coordinate devchats (collecting agenda items and publishing an agenda, running the actual devchat meeting, and publishing a devchat summary). post-devchat note: @whitneyyadrich also volunteered to assist with devchat coordination

General announcements

@jeffpaul: some comments lately about security issues and the security team, reminder about responsible security disclosures, people’s views will be better received if they’re formed as offering solutions to problems rather than continuing to point out problems
- @paragoninitiativeenterprises: recent security advisory showed longer ETA than expected, security team needs more resources (e.g., personnel) and it falls upon the community to ensure the security team has the manpower it needs
- @jeffpaul: anyone who feels they have the ability and interest to contribute to WordPress Security should reach out to @aaroncampbell
Effort from .ORG to contact hosts with large amounts of WordPress installs to help manually update sites from 4.9.3, current count hovering over a million sites but down significantly, still working with some groups (e.g., Google search console team) to try to get more people updated

Next meeting

The next meeting will take place on July 4, 2018 at 20:00 UTC in the #core SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. 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, #4-9-7, #core-js, #dev-chat, #gutenberg, #security, #summary

Aaron D. Campbell 3:59 pm on February 1, 2017
Tags: 4.7 ( 124 ), release ( 22 ), security

Disclosure of Additional Security Fix in WordPress 4.7.2

WordPress 4.7.2 was released last Thursday, January 26th. If you have not already updated, please do so immediately.

In addition to the three security vulnerabilities mentioned in the original release post, WordPress 4.7 and 4.7.1 had one additional vulnerability for which disclosure was delayed. There was an Unauthenticated Privilege Escalation Vulnerability in a REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. Endpoint. Previous versions of WordPress, even with the REST API PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, were never vulnerable to this.

We believe transparency is in the public’s best interest. It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.

On January 20th, Sucuri alerted us to a vulnerability discovered by one of their security researchers, Marc-Alexandre Montpas. The security team began assessing the issue and working on solutions. While a first iteration of a fix was created early on, the team felt that more testing was needed.

Meanwhile, Sucuri added rules to their Web Application Firewall (WAF) to blockBlock 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. exploit attempts against their clients. This issue was found internally and no outside attempts were discovered by Sucuri.

Over the weekend, we reached out to several other companies with WAFs including SiteLock, Cloudflare, and Incapsula and worked with them to create a set of rules that could protect more users. By Monday, they had put rules in place and were regularly checking for exploit attempts in the wild.

On Monday, while we continued to test and refine the fix, our focus shifted to WordPress hosts. We contacted them privately with information on the vulnerability and ways to protect users. Hosts worked closely with the security team to implement protections and regularly checked for exploit attempts against their users.

By Wednesday afternoon, most of the hosts we worked with had protections in place. Data from all four WAFs and WordPress hosts showed no indication that the vulnerability had been exploited in the wild. As a result, we made the decision to delay disclosure of this particular issue to give time for automatic updates to run and ensure as many users as possible were protected before the issue was made public.

On Thursday, January 26, we released WordPress 4.7.2 to the world. The release went out over our autoupdate system and, over a couple of hours, millions of WordPress 4.7.x users were protected without knowing about the issue or taking any action at all.

We’d like to thank Sucuri for their responsible disclosure, as well as working with us to delay disclosure until we were confident that as many WordPress sites were updated to 4.7.2 as possible. We’d also like to thank the WAFs and hosts who worked closely with us to add additional protections and monitored their systems for attempts to use this exploit in the wild. As of today, to our knowledge, there have been no attempts to exploit this vulnerability in the wild.

#4-7, #release, #security

Matt Mullenweg 5:32 pm on January 9, 2017
Tags: security

Aaron Campbell Leading Security

@aaroncampbell is now the new lead of security triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. and resolution for the WordPress project, also known as the Security Czar. Many thanks to Nikolay Bachiyski for kicking this role off and getting a lot of the infrastructure we use in place. This is also a good time to thank the dozens of volunteers who participate in the security group, and the researchers and reporters who bring issues to our attention.

#security

Garth Mortensen 10:37 pm on January 6, 2017
Tags: 4.7 ( 124 ), 4.7.1 ( 10 ), maintenance ( 12 ), release ( 22 ), security

4.7.1 Release Candidate

A Release Candidate for WordPress 4.7.1 is now available. This security and maintenance release fixes 62 issues reported against 4.7 and is scheduled for final release on Wednesday, January 11, 2017. Note this does not address a number of other issues, which are slated for a 4.7.2 release.

Thus far WordPress 4.7 has been downloaded over 9 million times since its release on December 6, 2016. Please help us by testing this release candidate to ensure 4.7.1 fixes the reported issues and doesn’t introduce any new ones. As always, the entire WordPress project is grateful to security reporters for practicing responsible disclosure.

PHPMailer Update

Last month a security vulnerability (CVE 20016-10033) in the PHPMailer library was made public. WordPress uses this library as the basis for its email functionality. The Security Team has spent some time analysing this vulnerability, and how it applies to WordPress. This vulnerability does not appear to be directly exploitable in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., or any major plugins in the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party directory. The wp_mail() function, which WordPress Core and most plugins use for sending email, blocks this vulnerability from being exploited.

All Changes

Here’s a list of all closed tickets, sorted by component:

Bootstrap/Load

#39132 – WP 4.7, object-cache.php breaks the site if APC is not enabled in php

Build/Test Tools

#39327 – Database connection errors in unit tests on 4.7

Bundled Theme

#39138 – wordpress 4.7 default theme does not get installed when upgrading
#39272 – Twenty Seventeen: Incorrect $content_width
#39302 – Twenty Seventeen: Featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. not displayed on single template
#39335 – Twenty Seventeen: customize-controls.js incorrectly assumes theme_options section is always present
#39109 – Twenty Seventeen: starter content array needs a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.
#39489 – Twenty Seventeen: Bump version and update changelog

Charset

#37982 – 4.6.1 Breaks apostrophes in titles and utf-8 characters

Comments

#39280 – comment permalink wrong in WordPress 4.7
#39380 – wp_update_comment can cause database error with new filter

Customize

#39009 – CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.: the preview UIUI User interface language should be the user language
#39098 – Customize: Clicking on child elements of preview links fails to abort navigation to non-previewable links
#39100 – Customize: Edit shortcuts do not work if page hasn’t been saved and published
#39101 – Customize: edit shortcuts for custom menu widgets do not work
#39102 – Customize: Shift-click on placeholder nav menu items fails to focus on the nav menu item control
#39103 – Customize: menus aren’t deleted
#39104 – Customize: starter content home menu item needs to be a link, not a page
#39125 – Customize: Video HeaderHeader 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. YouTube field has issues when whitespace is inserted at beginning or end of URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org
#39134 – Customize: custom CSSCSS Cascading Style Sheets. textarea is scrolled to top when pressing tab
#39145 – custom-background URL escaped
#39175 – Customizer assumes url is passed with replaceState and pushState
#39194 – Invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. parameters in Custom CSS and Changeset queries
#39198 – Customize: Apostrophes in custom CSS cause false positives for validation errors
#39227 – Changeset parameter not generated
#39259 – ‘custom_css_post_id’ theme mod of `-1` doesn’t prevent queries
#39270 – Use a higher priority on wp_head for inline custom CSS
#39349 – Customizer (mobile preview) site title extra padding
#39444 – Text Decoration Underline removes on hover in Customizer

Editor

#39276 – Link Editor bugbug 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. – target=”_blank” not removed
#39313 – Add New button not disappearing in Distraction-free Writing mode
#39368 – .page-template-default body class in editor doesn’t appear in initial post/page load.

External Libraries

#37210 – Update PHPMailer to 5.2.21

Feeds

#39066 – `fetch_feed()` changes REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. response `Content-Type`
#39141 – RSS feeds have incorrect lastBuildDate when using alternate languages

General

#39148 – Correct concatenated dynamic hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.
#39433 – Update copyright year in license.txt

HTTPHTTP 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. APIAPI 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.

#37839 – wp_remote_get sometimes mutilates the response body
#37991 – fsockopen logic bug
#37992 – fsockopen hard codes port 443 when http scheme used
#38070 – RegEx to remove double slashes affects query strings as well.
#38226 – “cURL error 23: Failed writing body” when updating plugins or themes
#38232 – Setting `sslverify` to false still validates the hostname

Media

#39195 – Undefined index: extension in class-wp-image-editor-imagick.php on line 152
#39231 – Allow the pdf fallback_intermediate_image_sizes filter to process add_image_size() sizes.
#39250 – Undefinded Variable in Media-Modal

Posts, Post Types

#39211 – is_page_template could return true on terms

REST API

#38700 – REST API: Cannot send an empty or no-op comment update
#38977 – REST API: `password` is incorrectly included in arguments to get a media item
#39010 – REST API: Treat null and other falsy values like `false` in ‘rest_allow_anonymous_comments’
#39042 – REST API: Allow sanitization_callback to be set to null to bypass `rest_parse_request_arg()`
#39070 – WP-API JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. client can’t use getCategories for models returned by collections
#39092 – REST API: Add support for filename search in media endpoint
#39150 – Empty JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. Payload Causes rest_invalid_json
#39293 – WordPress REST API warnings
#39300 – REST API Terms Controller Dynamic Filter Bug
#39314 – WP-API Backbone Client: buildModelGetter fails to reject deferred on fetch error

TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies.

#39215 – Support for string $args in wp_get_object_terms() broken in 4.7
#39328 – Adding terms without AJAX strips “taxonomy” query arg

Themes

#39246 – Theme deletion has a JS error that prevents multiple themes from being deleted.

Upgrade/Install

#39047 – Installer tries to create nonce before options table exists
#39057 – FTPFTP FTP is an acronym for File Transfer Protocol which is a way of moving computer files from one computer to another via the Internet. You can use software, known as a FTP client, to upload files to a server for a WordPress website. https://codex.wordpress.org/FTP_Clients. credentials form doesn’t display the SSH2 fields on the Updates screen

#4-7, #4-7-1, #maintenance, #release, #security

Joe Hoyle 1:32 pm on May 6, 2016
Tags: imagick, security

ImageMagick Vulnerability Information

A few days ago an ImageMagick vulnerability was disclosed dubbed “ImageTragick” that affects WordPress websites whose host has ImageMagick installed. If you control your own hosting for your WordPress site, you should look to implement the following fix(es) immediately.

The full effect of this issue is still unfolding and it’s not clear what the full impact will be; however, there are mitigation steps that should keep you safe with the known exploits so far. This vulnerability is already being exploited in the wild, and proof of concepts are being published.

How is WordPress affected?

Uploaded images to the WordPress adminadmin (and super admin) that contain malicious data can perform a number of exploits via the underlying ImageMagick library. Uploads are available to all users who have the upload_files capability. By default that’s authors, editors, and administrators; contributors, subscribers, and anonymous users do not have that capability. This issue is still developing; however, it should be noted that if un-patched, this exploit allows for Remote Code Execution (RCE).

What steps is the WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Team taking to mitigate this?

The exploit is in the Imagick PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher extension, not WordPress itself (or any library that is shipped with WordPress). The WordPress Security Team is exploring ways to help mitigate this exploit due to the wide usage of ImageMagick in the WordPress ecosystem; however, this exploit is best handled at the hosting level (instructions below).

How do I know if my site is vulnerable?

If you do not control your own hosting environment then it’s likely that your host is taking steps to fix the issue. We recommend you reach out to your hosting provider to verify they are handling the “ImageTragick (CVE-2016-3714, CVE-2016-3718 and CVE-2016-3715)” exploit.

Only WordPress sites that have the PHP Imagick extension installed are vulnerable to this exploit. If you don’t know if your server has this PHP extension, there are a few ways to identify this:

Inspect the output of the phpinfo() function for “Imagick”.
Run php -m | grep imagick on the command line.

How do I patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. the vulnerability?

Currently the best known fix is to add a policy.xml file to your ImageMagick installation to limit the delegates that ImageMagick will use. Due to the ongoing nature of this issue, we recommend you refer to and follow https://imagetragick.com/ for instructions on how to handle the problem.

ImageMagick 6.9.3-10

ImageMagick released an update on 2016-05-03 to fix this issue; however, there are questions around whether this update provides a complete fix. At the time of writing it should be presumed version 6.9.3-10 does not fix the issues completely and you should take steps to patch the issue via the policy.xml file.

WP REST API: Versions 1.2.3 (Security Release) and 2.0 Beta 4

First and foremost: version 1.2.3 of the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. is now available. Download it from the plugin repository or from GitHub. This is a security release affecting sites running version 1.2 or a 2.0 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. releases.

Security Release

Recently, we were alerted to a potential XSS vulnerability introduced in version 1.2 of the APIAPI 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. related to the JSONP support. This vulnerability also existed in version 2.0. Thanks to Alex Concha (@xknown) for reporting this issue to the team responsibly.

This release was coordinated by the REST API team and the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. security team. The security team is pushing automatic updates for version 1.2.3, but do not wait or rely on the automatic update process. We recommend sites or plugins that are using either v1.2.x or 2.0 beta releases update the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party immediately.

If you’d prefer not to upgrade, you can instead disable JSONP support through a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. For version 1:

add_filter( 'json_jsonp_enabled', '__return_false' );

To disable JSONP on version 2:

add_filter( 'rest_jsonp_enabled', '__return_false' );

If you have a question about the security release, you can find the team in #core-restapi on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., or you can privately message @rachelbaker, @rmccue, @danielbachhuber, or @joehoyle.

Version 2.0 Beta 4

Alongside the security release for version 1.2, we’re also releasing the latest beta for version 2.0: 2.0 Beta 4 “See My Vest”. You can download this from the plugin repository or from GitHub.

This beta release includes the security fix from version 1.2.3, so we recommend everyone running a version 2 beta update immediately to fix the issue.

As well as the security release, this beta also includes a bunch of other changes. Here’s some highlights:

Show public user information through the user controller.
In WordPress as of r32683 (scheduled for 4.3), WP_User_Query now has support for getting users with published posts. To match current behaviour in WordPress themes and feeds, we now expose this public user information. This includes the avatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name., description, user ID, custom URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, display name, and URL, for users who have published at least one post on the site. This information is available to all clients; other fields and data for all users are still only available when authenticated.
Send schema in OPTIONS requests and index.
Rather than using separate /schema endpoints, the schema for items is now available through an OPTIONS request to the route. This means that full documentation is now available for endpoints through an OPTIONS request; this includes available methods, what data you can pass to the endpoint, and the data you’ll get back.

⚠️ This breaks backwards compatibility for clients relying on schemas being at their own routes. These clients should instead send OPTIONS requests.
Update JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. API for version 2.
Our fantastic JavaScript API from version 1 is now available for version 2, refreshed with the latest and greatest changes. Thanks to Taylor Lovett (@tlovett1), K. Adam White (@kadamwhite) and Nathan Rice (@nathanrice).
Embed links inside items in a collection.
Previously when fetching a collection of items, you only received the items themselves. No longer! You can now request a collection with embeds enabled (try /wp/v2/posts?_embed).
Move /posts WP_Query vars back to filter param.
In version 1, we had internal WP_Query vars available via filter (e.g. filter[s]=search+term). For our first betas of version 2, we tried something different and exposed these directly on the endpoint. The experiment has now concluded; we didn’t like this that much, so filter is back.

⚠️ This breaks backwards compatibility for users using WP Query vars. Simply change your x=y parameter to filter[x]=y.
Respect rest_base for taxonomies.
⚠️ This breaks backwards compatibility by changing the /wp/v2/posts/{id}/terms/post_tag endpoint to /wp/v2/posts/{id}/tag.

As always, we have a detailed changelog as well as the full set of changes if you’re interested.

(Note that while this version 2 beta breaks backwards compatibility, the 1.2.3 security release does not break compatibility with the 1.2 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"..)

This release had 11 contributors, and we’d like to thank each and every one of them:

$ git shortlog 2.0-beta3...2.0-beta4 --summary
     1   Daniel Bachhuber
    11   Daniel Jalkut
     1   Fredrik Forsmo
     1   Jared Cobb
     3   Jay Dolan
    26   Joe Hoyle
    10   Josh Pollock
    25   Rachel Baker
    50   Ryan McCue
    24   Stephen Edgar
     8   Taylor Lovett

Thank you again to all of our beta testers, and thanks to everyone who let us know how you’re using the API. We’re taking note of all of your feedback, and you might see some further changes related to that in coming releases.

#feature-plugins, #json-api, #rest-api, #security, #updates

Welcome!

Communication