The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in the bug tracker.
@iandunn needs your input on the topic of assisting pluginPluginA 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 developers to avoid specific bugs that result in WordPress end users having a bad experience. He has suggested potential solutions including static code analysisStatic code analysis"...the analysis of computer software that is performed without actually executing programs, in contrast with dynamic analysis, which is analysis performed on programs while they are executing." - Wikipedia, and has provided a list of questions to help guide the discussion. Do read it and provide feedback from your perspective.
@francina: Would Stats Dashboards Help Your Team? Read this post for more details. Would folks in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. feel that any sorts of stats on a dashboard would support in their work in core?
New team CC Search to join WordPress. CC Search, a CC0 (Creative Commons Zero) image search engine, is joining the WordPress project with more than 500 million openly licensed and public domain images discoverable from more than 50 sources, audio and video soon to come. Read this post for more information@chanthaboune: more news and context coming in the next few weeks.
Wonderful design reference for those looking for ways to quickly prototype WordPress UIUIUser interface in Figma. Read this blog post.
WP Briefing podcast. @jeffpaul: these are super quick to digest, provide a good on-ramp to what’s latest in WordPress. Check out all the episodes at this link and find links to subscribe in your favorite podcast app.
WordPress 5.8 Release
@francina gave an update – Thanks to everyone who volunteered and right now I can confirm these roles:
Release leadRelease LeadThe community member ultimately responsible for the Release.: Matt Mullenweg (@matt) Release Coordinators: Jeff Paul (@jeffpaul) and Jonathan Desrosiers (@desrosj) TriagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Lead: Luke Carbis (@lukecarbis) Core Tech Lead: Helen Hou-Sandí (@helen) Editor Tech Lead: Riad Benguella (@youknowriad) Marketing and Communication Lead: Josepha Haden-Chomphosy (@chanthaboune) Documentation Lead: Milana Cap (@milana_cap) Support Lead: Mary Job (@mariaojob) Testing Lead: Piotrek Boniu (@boniu91)
@francina: “If I have messaged you and asked to join the release as part of the supporting crew, thanks for being part of the collaborative work that makes WordPress so great. Everyone! Join us in the channel #5-8-release-leads “
If you have any questions about releases which you are following along, and if you want to ask questions: #core and #core-editor are the right channels
[More posts on FSE in the posts requesting feedback section above]
Marketing has social media text available which can be reused to promote the different FSE calls
@helen making a blockBlockBlock 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. based theme with the full site editor
Component maintainers and committers update
@sergey: Work has continued on further fixing some long-standing coding standards issues in core, see ticketticketCreated for both bug reports and feature development on the bug tracker.#52627 for more details.Build/Test Tools, Date/Time, I18Ni18nInternationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill., Permalinks: No major news this week.
@clorith: Site Health catching up a bit on older and unanswered tickets
@audrasjb: Menus, Widgets, Upgrade/Install: nothing new. I scrubbed some tickets in the Menus component but no major news to share.
In the last week, they have been going through the tickets since and will give an update in future devchats.
jQuery
@Hareesh: some attention requested on #52163. With this out of the way, we would have less jQuery migrate warnings, and it would be easier to fix any remaining warnings.
@clorith: jQuery UI hasn’t been updated yet, we are still waiting on their release, which I believe is scheduled for the end of May/start of June
@davidb: jQuery release is right before BetaBetaA 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 then, if the dates hold
@clorith: Yeah, which is a bit tighter than I’d like, but it is what it is… we’ll have a look once it’s ready to see what’s going on and what the best approach is. Building from source while they’re still modifying it isn’t really an option in my opinion.
Open Floor
@notlaura: feedback requested on ticket #53070. Establish a Core CSSCSSCascading Style Sheets. deprecation path, and ask if anyone is interested in working on it! This is something we’ve been discussing in #core-css
Community
@chanthaboune: As you may be aware, many of our fellow contributors are experiencing disruptions in their lives right now above and beyond the (seemingly) routine disruptions of this pandemic life. From big earthquakes to big spikes in COVID cases to unrest right outside their doors, some of your WordPress pals are hurting more than usual.
For my part, I can say take whatever time you need to take care of yourselves. You are important and WordPress is not more important than your health and well-being.
For all of us, if you haven’t reached out to your friends to see how they are, please do.
Welcome back to a new issue of Week in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between April 19 and April 26, 2021.
20 commits
27 contributors
38 tickets created
2 tickets reopened
31 tickets closed
TicketticketCreated for both bug reports and feature development on the bug tracker. numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component.
Add seeking support to stream test library – #52922, #52826
Coding Standards
Remove loose comparison in wp-admin/includes/plugin-install.php – #52627
Use strict comparison in wp-admin/includes/update-core.php – #52627
Use strict comparison in wp-admin/includes/class-wp-terms-list-table.php – #52627
Fix minor, inline spacing issue in wp-admin/setup-config.php – #52627
Code Modernization
Bring consistency to preparing some fields on Networknetwork(versus site, blog) Settings screen: – #51423
Documentation
Add a @since note to wp_mail() about using is_email() for validation – #52628
Editor
Shape blockBlockBlock 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. editor filters to work better with the GutenbergGutenbergThe 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/pluginPluginA 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 – #52920
When loading a plugin in a “sandbox” on activation, do it once – #31104
When loading a plugin in a “sandbox” on activation, do it in a separate function – #31104
Posts, Post Types
Pass the post object to the_password_formfilterFilterFilters 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. – #29008
Upgrade/Install
Prevent possible type errors during installation – #51423
Users
Share current user instance across functions – #28020
Props
Thanks to the 27 people who contributed to WordPress Core on Trac last week:
Edit: 4/23/2021 @ 19:10 UTC – changed the references to contributors in the last paragraph to WordPress.orgWordPress.orgThe 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/ usernames to help to make the connection. – @desrosj
With the schedule finalized and parts of GutenbergGutenbergThe 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/ phase 2 getting ready to merge, it’s time to put together a squad of focus leads for WordPress 5.8.
The roles of release leadRelease LeadThe community member ultimately responsible for the Release. and marketing/communications lead will be filled by @matt and @chanthaboune, respectively.
Expectations
Focus leads should be available for at least 5-6 hours a week to perform their tasks, with more time as milestones like Betas, Release Candidates, and General release approach. On the days of those milestones, you might need to dedicate 4-6 hours to WordPress on one day.
There are no limitations to where you come from. We are a global community, open 24/7 so you will schedule scrubs, if needed, according to your availability and potentially find a deputy to cover other timezones.
Because 5.8 is going to be a busy release, the squad won’t have mentorship or ride-along opportunities, like it did in the past, but as Josepha mentioned there is a public channel for the team to coordinate so that others can learn through observation.
This doesn’t mean you need to have all the answers to volunteer. 🙂 There will be a bunch of people available to help and support (the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. team representatives, long-time contributors, etc…).
Are you interested?
Please leave your name in the comments with the role you are interested in or reach out to me (@francina), @audrasjb or @chanthaboune if you have any questions before raising your hand.
Google is rolling out Federated Learning of Cohorts (FLoC) for the Chrome browser.
Why is this bad? As the Electronic Frontier Foundation explains in their post “Google’s FLoC is a terrible idea“, placing people in groups based on their browsing habits is likely to facilitate employment, housing and other types of discrimination, as well as predatory targeting of unsophisticated consumers.
This is in addition to the privacy concerns of tracking people and sharing their data, seemingly without informed consent – and making it more difficult for legislators and regulators to protect people.
So What Now?
WordPress powers approximately 41% of the web – and this community can help combat racism, sexism, anti-LGBTQ+ discrimination and discrimination against those with mental illness with a few lines of codeLines of CodeLines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses.:
Those websites who want to opt into FLoC are likely to have the technical know-how to simply override this proposed filterFilterFilters 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. in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
When balancing the stakeholder interests, the needs of website administrators who are not even aware that this is something that they need to mitigate – and the interests of the users and visitors to those sites, is simply more compelling.
Furthermore, for WordPress versions that support privacy settings, we can easily add an on-off toggle to enable websites to opt in. This would only require a few more lines of code and only a couple of new strings.
What Do You Mean By “Treat It Like A Security Concern”?
Include the patchpatchA 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 next minor releaseMinor ReleaseA set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality., rather than waiting for the next major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.;
Back-port the patch to previous versions of WordPress.
Why Treat It That Way? Why Not Just Wait For The Next Major Release?
Well, keep your eyes peeled, because there is a ticketticketCreated for both bug reports and feature development on the bug tracker. for future releases on its way!
While it is indeed unusual to treat a new “feature” this way, there is precedent in that something that was not strictly a security vulnerability in comments was back-ported to previous versions for the good of the community as a whole.
Furthermore, a significant number of WordPress sites only update to minor versions. By back-porting, we can protect more sites and more visitors to those sites – and amplify the impact.
Request For Comment
Please join the discussion below!
Whether want to show support, disagree vehemently, or just want to make the implementation the best that it can possibly be, please have your voice be heard.
I’m aware that there is a lot of discussion on other platforms, including Twitter on this matter, but we won’t see all of it, so in addition to spreading the conversation there, please comment here too, so that it can be considered when this is discussed at development meetings and when the ticket is created (consensus building first – and that is done here 😉 )
YOU DO NOT HAVE TO BE A DEVELOPER TO PARTICIPATE. There will be a ticket on core.trac.wordpress.orgWordPress.orgThe 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/ where we will discuss all of the technical stuff. I’m tremendously grateful that there are so many developers, Core, MetaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. and others, around, but blogblog(versus network, site) posts on make.wordpress.org are the places that are accessible to techies and non-techies alike 🙂
Version Control:
1. Edited to add clarification that treatment like a security concern refers to the process / procedure (accelerated development and back-porting).
2. Code snippet updated based on suggestions below. Thank you to Tom for the snippet and to everyone who suggested conditionally appending, rather than replacing.
Added some more info to the Request for Comment.
Update: Let’s move forward with the March release, a July release (to give folks time to adjust their company plans), and a final release in December. I will create a plan to help us lessen the burden of releases, and in December I will see what we’ve accomplished and get some 2022/23 target release months published.
The past few weeks have been very busy in terms of WordPress’ release cadence. There has been the WP 5.6.1 release, WP 5.7 betaBetaA 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, and discussions to start organizing the next major and minor releases are already underway. The roadmap for the year promised four major releases, as well as any follow-up minor releases, and flags have been raised about how we can accomplish that.
tl;dr –I’ve been exploring the problem of making the release process easier with WordPress contributors for 3+ years; high level notes are shared below. From my research, the work to automate what we can (and potentially get the project ready for more releases per year) would take 3-4 dedicated developers who are proficient in our backend tools/infrastructure, at least a project manager, 1-2 internal communications people, and probably a year or more of work (if we had all the resources, and they were working at full capacity). This means that 4 major releases is not a viable plan in 2021.
What are the challenges?
Balancing developer needs with user needs. A rapid release cycle (CI/CD) definitely appeals to some developers. In my observation, our users see no difference between our nuanced guidelines around minors vs majors, and currently experience each type of release (~9ish on average) as “yet another thing I have to update.”
Balancing the OSS philosophy of releasing early and often with the reality that we ship a CMS to ~39% of the web. In my observation, our commitment to backward compatibility and relative consistency is key to our users’ continued use of WordPress, and makes “ship, then iterate” more challenging.
WordPress takes a responsive approach to open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. product and project management, despite our scale. Contributors expect WordPress maintainers to seek out and respond to feedback on both product and process, which is time-consuming.
Related, every release team — major or minor — makes hard calls and unpopular decisions. This results in fatigue and increased risk of burnout in contributor roles that have a limited pool of trained and experienced candidates. The more releases, the more fatigue and burnout risk we run.
Currently, only a small number of active contributors can do the administrative work required during a release, and they split that responsibility across releases for the year. The onboarding process for contributors with that skill set is lengthy, and the main mechanism we use to recruit and start training them (our in-person events) is not available.
Automating the basic tasks involved in a major or minor releaseMinor ReleaseA set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. requires time from skilled developers as well as product ownership and project management. In my observation, we do not have people with those skills and extra time available to help here, given our ongoing need for increased project coordination.
What changes are needed?
Better testing: That would include automated testing, security testing, smoke testing, E2E tests, beta testing, etc.
Seasoned CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. developers: Many more of them, and also more of their time focused on Core.
Better handoff in design/dev iterations: The WordPress project has more developer contributors than design contributors, and few people who have the time, experience, and skill required to coordinate the work at scale.
Shifts in our collective philosophies:A shift to a culture of review, to an ideology of continuous development (as it relates to CMSs and software that is open to a vast networknetwork(versus site, blog) of extenders), and finally a shift in the nuanced application of OSS methodologies (aimless contributions vs agenda-free contributions, non-reciprocal vs no value, coordination vs dictation, etc).
What could we change right now?
Mentorship: The mentorship programs that are in place across teams in the project, could stand a fresh eye to account for active and passive learning that happens during in-person events. If we gave it a little more definition, and some better tools, then we could potentially remove that barrier to entry for all future contributors.
TriagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors.: There was a call for this at the end of 2018, and it suffered from a bit of a false start. Triage is not only a key part of maintaining WordPress, it’s also the common denominator in the paths of success for many of the long-term contributors I’ve spoken to.
Feature Proposals: The feature proposal process was suspended during the first phase of GutenbergGutenbergThe 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/, but I think it’s time to revive it. The benefits of this process are that discussions can happen on the Make network, which opens up feedback to a broader audience, so that when a proposal gets to any final decision makers, the questions have all been answered (or at least asked).
Product/Project Processes: This is hard in open source. We know that trying to design by committee is prone to failure, but making that work have a clear owner feels like we’re walling off the future of the project. I have no solutions, but I will start a few conversations in the near future so we can collectively come to a potential way forward.
Time for your feedback!
I believe that it is essential to reduce the effort required to have a successful WordPress release, but that we should start with some planning. I’d like to hear from folks in the comments if you’re interested and available to lead efforts around any of the things listed above, or if you have anything that needs clarification in what I shared!
While most people here will probably mostly know me as a (PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher) developer, I actually have a background in business studies, so when Matt Mullenweg reached out to me to continue the conversation about WordPress dropping support for older PHP versions in an in-person call, I decided to put my business acumen to use and see if I could come up with a proposal which would make sense from a business point of view for all parties involved, be it the amazing contributors to the WordPress project, the web hosts, the pluginPluginA 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 and theme builders, the web agencies and the users who often run their business via their WordPress website.
In short, I’m proposing a fixed schedule in which every PHP version is supported for five years. Additionally each WordPress release will receive security updates for four years. In effect, this means that users, at a stretch, would be able to run on one specific PHP version for nine years.
A fixed schedule will make this whole process transparent and will allow all parties to plan for the version drops accordingly.
With Matt’s blessing, I’m posting this proposal here on Make to gauge the reactions of the wider community to my idea.
Please feel very invited to leave a comment whether you agree with the proposal or not. Mentioning what your involvement is with WordPress and how this proposal will impact you in a positive or negative way, would be very valuable input for further discussions on this.
Chicken vs egg
The situation we are currently in, is basically one of “Which came first, the chicken or the egg ?”.
WordPress doesn’t drop support for older PHP versions until enough users have moved over to newer PHP versions and a significant enough share of the WP users don’t upgrade their PHP version until they really have to because WordPress drops support for the version.
This is circular logic, which as most developers know, never ends well as you end up in an infinite loopLoopThe Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. where, in the end, neither moves forward.
So who are these users who don’t upgrade ?
Well, while we can’t know for sure, if we look at the figures, we can see some patterns:
Take note of the fact that the percentage of users on WP 5.1 who didn’t upgrade yet is relatively small and only part of that can be attributed to the PHP < 5.6 version drop in WP 5.2.
So let’s look at some likely personas for users who don’t upgrade:
We have the “zombie” persona, sites which are still online, but are not actively updated anymore. These can be, for instance, sites which were linked to a specific event or other date-related topic which are still online for historical reasons, aggregate sites which automatically re-post from other sites without adminadmin(and super admin) involvement, or spam sites etc.
We have the “overwhelmed” persona, who blatantly ignores all admin notices. We all know why and how this happens. The multitude of notices in the admin area once a site has a few plugins and a theme installed trained this user to ignore them.
Then there is the “laid-back” persona, who has seen the notices, but doesn’t feel any urgency until they can’t update their site anymore.
And lastly, the “business” persona, often with a custom theme and a number of custom build plugins who’d rather move the costs of upgrading those to the next accounting year.
As for the user who feels out of their depth – amazing work has been done by the #site-health team to help those out. For those users, I like to use the car analogy:
A website is something users will generally use regularly and expect to “just work”. So let’s make the comparison with something else a lot of people use regularly and expect to “just work”.
Say a car. Similar to WP, when one gets themselves a car, you need to familiarize yourself a little with how it works (interface/admin), but then it just runs. You put in petrol regularly (WP updates) to keep it running. Then once in a while, it needs a proper service. Now you have a choice: either you learn how to service a car yourself (read the site health materials and follow them up) or you go to a garage (hire a specialist) to do it for you. And if you really don’t want to be bothered with all that, you lease a car instead (managed WP hosting solution).
Along the same lines: if you ignore the warning lights in a car (site health admin notices), you can’t pretend to be surprised that at some point it will break down (gets hackedhacked/can’t upgrade anymore). If was your responsibility as a user to act on them after all.
But Juliette, get to the point: how do you think we can get out of this situation ?
Ok, so here goes: I propose a fixed (rolling) schedule for dropping support for older PHP versions.
A fixed schedule means that such version bumps become predictable and with them becoming predictable, they become manageable and plannable.
These last two qualities are extremely important as all parties involved will know well in advance what they need to do and when it should be ready.
The current uncertainty over what WordPress will do leads to inaction, as we saw with two of the example personas, and we can counter that with becoming predictable and reliable with regards to the PHP version bumps.
So I propose that, as of now, we start dropping support for the PHP minor which is more than five years old each December, or if there is no release in December, in the WordPress release which is being worked on at that time.
That would currently look something like this, with the numbers at the top being the version of the WordPress release that December and the numbers at the bottom being the new minimum supported PHP version.
Keep in mind that, per the currently proposed schedule, the new minimum supported PHP version would always already be a version which is no longer actively supported by the PHP project, nor does it have security support anymore at the time it becomes the new minimum supported version for WordPress.
For example, PHP 7.1 was released in December 2016. Active support for PHP 7.1 stopped beginning of December 2018 and security support stopped on December 1, 2019. And based on the current proposal WordPress would still support it until December 2021.
But all those users on old WordPress versions…
Well, WordPress has always had a very liberal policy for backporting security fixes, so as part of this proposal, I’d like to suggest that the WordPress project makes a hard commitment to continuing to backportbackportA 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 for WordPress versions up to four years back.
What that would come down to in practice, is that if a user would always want to use the latest and greatest version of WordPress with the minimum of effort, they would need to ensure their PHP version is updated once every five years.
And if they don’t mind lagging behind a little in their WordPress version, they could even get away with only updating their PHP version once every nine years and still have their website running on a secure version of WordPress.
Now how does that sound ? Is that a liberal enough policy ?
Note: security fixes are currently back-ported as far back as WordPress 3.7. With this proposal, the minimum version of WordPress still receiving security fixes would not longer be a fixed version, but would change to a rolling number.
But what about the users currently on old WordPress versions ?
To solidify the commitment to making this as transparent as possible for the users, I propose we backport the PHP admin notice from the site-health project to the older, still currently security supported, WordPress versions, so that those users will be informed when they log in to their website.
Alongside of that we could ramp up the site-health notices based on this fixed schedule of version drops and committed security fix support.
So… what do you think ? I eagerly await the reactions of you all!
@matt and I are looking forward to seeing everyone this week, either at Contributor DayContributor DayContributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. or in the great line up of scheduled sessions. One of the highlights of these events is the time to be together and share our stories, and not be able to be in person makes that a little harder.
This year, Matt and I are offering office hours together! If you would like to grab some time with us, please sign up with Calendly. A Zoom link will be added to your calendar invite after booking.
I will also be offering additional office hours on Saturday, June 6th. You can sign up for one of those sessions here. All appointments will be 15 minutes with a 5 minute break to allow for transition time.
Update, June 6 – Changed to include the newest member of the release squad, Mary Baum, on Marketing. -Josepha
Excellent progress has been made on WordPress 5.5 so far, and I’m here to do some updates! One of the big things missing from that post was some clarity around who was joining the release squad to help make sure this is a success. This post has the names we know, and I’m happy to take corrections or suggestions as well. 🙂
Release leadRelease LeadThe community member ultimately responsible for the Release.: Matt Mullenweg @matt
AccessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Tech: JB Audras @audrasjb
Joining simultaneously is the WordPress 5.6 release squad! I’ve tagged all of them here, but have left out role assignments. If they make it part way through the ride along process of WP5.5 and decide it’s not what they signed up for after all, then they can step back and someone else can join. 🙂 The WP5.6 release squad will be announced in a roundup/kickoff post of their own.
Just a few hours before the chat, the hardworking team behind the plugins and themes auto-updates feature committed it to Core! Congrats to all!
Check out this related ticketticketCreated for both bug reports and feature development on the bug tracker. that adds Help Tabs text to update-core, themes and plugins WP-Adminadmin(and super admin) screens: #50215
WordCampWordCampWordCamps 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. Europe is around the corner. If you can help CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. onboard new contributors and/or help around, comment on this post.
You still have one more week to vote for new Core team reps. And, yes, you’re eligible to vote if you have any interest in contributing to Core.
The next major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. of WordPress is in active development (Alpha cycle).
@francina noted the team is not quite complete, but it’s confirmed that @matt will return as release leadRelease LeadThe community member ultimately responsible for the Release., @davidbaumwald as co-lead in the role of TriagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. PM and @sergeybiryukov as Core tech lead. The 5.5 team will also mentor the 5.6 team.
@whyisjake leads this point releaseMinor ReleaseA set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality., and the group firmed plans for a release candidaterelease candidateOne 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). on June 3 and a final release June 10.
Components check-in and status updates
@whyisjake was exuberant that the core team was able to merge the auto-updates code today. This is going to do a great deal to help people stay on top of updates for a safer WordPress ecosystem.
The merge is just the latest significant step toward the master plan for 2020. Lazy-loading of images merged a few weeks ago, and XML sitemaps is making great progress as well.
On the accessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) side, @audrasjb shared that most of the accessibility team’s main projects for 5.5 are moving forward. Alternate views for posts, users, and comments lists should be ready for review soon.
@johnbillion wanted to note that weekly meetings for MultisitemultisiteUsed to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site have restarted, on Tuesdays at 17:00 UTC in #core-multisite. Come join them!
In Site Health, @clorith pointed out that the Theme Review Team has implemented requirements for PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher headers in themes. That move should push users in the right direction for updates.
As well, the Site Health component team has had discussions with hosting about bumping the version for Servehappy dashboard nags.
Open floor
@dlh wanted to highlight #48416. He recently encountered a use for it again. If you’re interested in the taxonomyTaxonomyA 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. component, please give it a look.
As work on Full Site Editing continues, it’s important that communication around the project is made explicit so everyone can follow along appropriately. Each person will have their own unique needs in keeping up with a project of this scale so what follows is more of a catalogue of ways to keep up rather than a recommendation for how to do so.
Yearly:
The WordPress.orgWordPress.orgThe 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/Roadmap with Four Phases of GutenbergGutenbergThe 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/ updated by @chanthaboune and/or @matt. This is the highest level overview of the changes coming to WordPress.
Quarterly:
Quarterly Updates from Contribution Teams, coordinated by @chanthaboune. These updates give an overview on what each team is working on, struggling with, and how to get involved.
Monthly:
“What’s Next In Gutenberg?” posts. These updates are wrangled by the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor team and highlight what’s planned for the coming month of work on Gutenberg.
“What’s New In Gutenberg?” posts. These updates are wrangled by the Core Editor team and focus on what’s been released in each biweekly Gutenberg release. Currently, they tend to mimic a changelog.
Weekly:
Core Editor chats. These chats are wrangled by volunteer members in the #core-editor Slack channel. Agendas and summaries are shared on the make/core blog. They focus on task coordination and relevant discussions around Gutenberg releases. There is an Open Floor period in each chat where people can suggest topics to discuss.
Weekly Theme Related Gutenberg Updates (new initiative) wrangled by @kjellr. These posts are focused on themes, including everything from current discussions to recent changes, as well as helpful resources for theme authors.
Daily:
Checking in on FSE PRs and FSE issues on GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/. This will give you a nearly real-time understanding of what’s being worked on by the developers and designers.
Each of these are reliable ways of keeping up with the ongoing work on the new Full Site Editing feature coming to WordPress. A big thank you to everyone helping with these various initiatives!
Feedback welcome
What kinds of updates or communication might be missing? What might make these current updates and chats easier to follow? Share your ideas and feedback in the comments below! A next step to this work will be refining these communication pathways based on the feedback collected here and elsewhere.
You must be logged in to post a comment.