Your membership coordinator logs into the site to post an event and sees a banner across the top of the dashboard: a new version of WordPress is available. She has been told to keep things up to date. There is a button that says Update Now. She asks you whether she should click it.
It is a reasonable question with a genuinely complicated answer. The honest answer depends entirely on which kind of update it is, and the dashboard gives you almost nothing to tell them apart. That single button covers two completely different decisions, and treating them as one decision is the most common way association websites get hurt, in both directions.
Two Different Decisions Wearing the Same Button
A security release exists because somebody found a way to break into your website. The risk of applying it is small. The risk of not applying it is that you get compromised. The correct response window is measured in days.
Those are not the same calculation, and they should not produce the same behavior. A feature release exists because the project shipped new capability. The risk of not applying it is close to zero in the short term. The risk of applying it carelessly is that your member portal stops working on a Tuesday morning during renewal season. The correct response window is measured in weeks, after testing.
Most associations pick one policy and apply it to everything. The organizations that update immediately eventually push a major version onto a live site and break an integration. The organizations that batch updates quarterly eventually sit on a critical patch for eleven weeks. Both failure modes come from the same mistake, which is treating "update" as a single category.
July Was the Kind You Do Not Wait On
On 17 July, WordPress shipped 7.0.2. It fixed two vulnerabilities that chain together into unauthenticated remote code execution, CVE-2026-63030 and CVE-2026-60137. Versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 were affected. The fixes landed in 6.9.5 and 7.0.2. CISA added both to its Known Exploited Vulnerabilities catalog on 21 July, which is the federal government stating that the flaws are being used against real targets right now.
Four days from patch to confirmed exploitation in the wild. Researchers named the chain wp2shell, and we wrote about both the exploitation and the cleanup that has to follow a patch. The short version: an attacker needed no credentials and no user interaction, and patching closes the door without evicting anyone already inside.
This is the category where speed is the whole point. There is no version of a maintenance policy where that release waits for a quarterly window. If your association was running an affected version on 18 July and nobody applied it that week, the honest description is not that you were behind on updates. It is that you were exposed, and you did not know it.
August 19 Is the Other Kind
WordPress 7.1 has a scheduled release date of 19 August 2026. It has been through four betas since 15 July, with release candidates on 5 August and 12 August. That is a well-run release process, and 7.1 will very likely be a good version of WordPress.
None of which tells you whether to install it on 19 August. It is also a major release landing on a site that probably has a member portal, an AMS integration, a forms plugin handling event registration, and a theme somebody customized three years ago. None of that was tested against 7.1 by the WordPress project, because the WordPress project has never seen your site.
That is not an argument for never upgrading. Sites that fall multiple major versions behind become expensive and eventually unsupportable, and we have written about what that migration costs when it is deferred too long. It is an argument for the upgrade being a scheduled piece of work with a test pass and a rollback plan, rather than a button somebody clicks because a banner appeared.
The Questions That Actually Decide It
For any release that is not a security fix, five questions settle whether it goes on this week, next month, or after the first point release.
- Is this a security release? If yes, stop reading and apply it. Everything below is about feature releases. Security releases are not a judgment call.
- What does your site depend on that the release could break? Your forms plugin, your AMS connector, your page builder, your custom theme. Check each one against the new version. A plugin whose last update predates the release is a question mark, and a plugin whose author has gone quiet is a risk regardless of what the dashboard says.
- Do you have a staging environment that mirrors production? Not a copy from last year. A current clone where you can apply the update and click through join, renew, register, and log in before any member does. If you do not have one, that is the actual problem to solve, and it is worth more than any individual upgrade decision.
- Can you roll back within an hour? A database backup taken before the upgrade, and a documented path to restore it. Upgrades that cannot be undone are not upgrades, they are gambles with your renewal season.
- Who is watching the week after? Most upgrade damage is not a white screen. It is a form that silently stops sending confirmations, or a members-only page that quietly goes public. Somebody has to check the paths that matter in the days after, because nothing will announce it.
Notice the asymmetry in that list. If the answer to the last three is nobody, then the safest choice is to wait for 7.1.1 and spend the intervening weeks building the staging environment instead. Waiting on a feature release costs you nothing. Waiting on a security release is how organizations end up in the situation we described in July.
Write the Policy Down Before You Need It
The reason these decisions go badly is almost never technical. It is that nobody decided in advance, so the decision gets made under pressure by whoever happens to be looking at the dashboard.
A release policy an association board can approve fits in a paragraph. Security releases are applied within 72 hours, no approval required, because waiting for approval is the risk. Minor releases go on within two weeks after a staging check. Major releases wait for the first point release and get a scheduled test pass against the member portal, the forms, and the payment path. Somebody is named as responsible for each category, and somebody checks the site the week after any change.
That is the entire policy. Once that exists, the banner in the dashboard stops being a question. It is either covered by the policy or it is not, and the person looking at it knows which.
Drupal Has the Same Two Buckets, and a Third Problem
The logic transfers directly. Drupal security advisories carry a risk score and a fixed release, and they belong in the same 72-hour bucket. Minor version updates belong in the tested bucket.
Both projects share a related blind spot worth knowing about. The third problem is one WordPress does not have in the same form. A Drupal contributed module can be marked unsupported, meaning the security team confirmed an issue that the maintainer never fixed. There is nothing to update to. The module has to be removed or replaced, which is project work rather than a maintenance task, and it will never appear as an available update. Any policy that only describes what to do when an update exists has a hole in it exactly there.
When You Genuinely Do Not Need Help With This
If your association runs a brochure site with six plugins, no member login, no payment processing, and no AMS connection, turn on automatic updates for everything and stop thinking about it. The odds that a major release breaks a simple site are low, and the odds that a delayed security patch hurts you are higher. Automatic updates are the right answer far more often than agencies admit.
The calculation inverts as soon as members can log in, pay, or register. At that point an upgrade can break something that costs real money and real trust on the day it fails, and the discipline of staging, testing, and watching afterward stops being overhead and starts being the job.
Where This Lands
WordPress 7.1 on 19 August is a good test of whether your organization has a policy or a habit. If you know today who decides, where it gets tested, and how it gets undone, the release is a scheduled task. If you do not, it is going to be decided by whoever sees the banner first.
Stop Fighting With Free Platforms
Our partnership plans give associations and nonprofits a dedicated web team without the overhead of hiring one. From ongoing maintenance to full-scale builds, every plan includes strategy, development, and support tailored to organizations like yours.