---
title: WordPress Version Checker — Find Core, WooCommerce and Plugin Versions Before Peak
description: How to check the WordPress version of any site, plus WooCommerce and plugin versions, from the dashboard, WP-CLI or page source, and what to do with them.
source: https://pingvera.com/blog/wordpress-version-checker.html
---
# WordPress Version Checker: Find Core, WooCommerce and Plugin Versions Before Peak

You can check a WordPress version in three ways. If you can log in, open Dashboard > Updates in wp-admin. If you have shell access, run `wp core version`. If you have neither, look in the page source for `<meta name="generator" content="WordPress x.y.z">` or open the site's RSS feed, which carries a `<generator>` line with `?v=x.y.z`. An online "WordPress version checker" reads those same public markers, so it can only report what the site chooses to show.

For a store, the core version is only part of the answer. As of 13 October 2026 the current release is WordPress 7.1.3, WooCommerce 11.2 came out on 7 October, and an actively exploited flaw in a third-party WooCommerce extension was still in the news in September. To decide whether a store is safe to run through Black Friday, you need core, WooCommerce and every plugin version in one list, compared against what is current.

## At a glance

- Inside wp-admin, Dashboard > Updates shows the core version and pending updates. The Plugins screen shows each plugin's version.
- `wp core version` and `wp plugin list` (WP-CLI) give the same data in a form you can export across many sites.
- Public markers (generator meta tag, RSS feed) reveal core version only, and a theme or plugin can remove them.
- WordPress officially supports only the latest version. Older branches get security fixes as a courtesy through auto-updates.
- WooCommerce 11.2 ships with a documented fatal-error conflict with older PublishPress Future versions, so check plugin versions before updating WooCommerce.
- Black Friday 2026 falls on 27 November. Do your version audit now, while you still have time to update and test before any code freeze.

## Why version checks matter in October 2026

The WordPress core team shipped three security releases in under three weeks. WordPress 7.1.1 (17 September 2026) included 11 security fixes. WordPress 7.1.2 (22 September) fixed a critical vulnerability that let an unauthenticated attacker make page template resolution include a readable local PHP file, which could lead to remote code execution under some conditions. The team backported that fix to every branch back to 4.7. WordPress 7.1.3 (6 October) followed with 7 security fixes and 4 bug fixes. For both 7.1.2 and 7.1.3 the release posts recommend that you "update your sites immediately".

The WordPress security page says that "only the latest version of WordPress is officially supported", and that the security team backports fixes to older versions as a courtesy so that older sites receive critical fixes through auto-updates. In practice, a store on the 6.9 branch can still be patched if it reaches 6.9.10, the latest 6.9 release offered by the WordPress update API this week. A store with background updates disabled stays on whatever version someone last installed by hand.

On the WooCommerce side, the 11.2.0 release notes (7 October 2026) list a database update, several security hardening changes and one compatibility warning: PublishPress Future versions 3.0.0 to 4.10.3 "can cause a fatal error on sites running WooCommerce 11.2, because they load their own outdated copy of Action Scheduler." The fix is PublishPress Future 4.10.4 or later, installed before you update WooCommerce. You will only see that conflict coming if you know which version of the plugin each store runs.

Plugins carry their own risk. BleepingComputer reported in September that attackers were exploiting CVE-2026-27540 in the premium WooCommerce Wholesale Lead Capture plugin, an unauthenticated file upload flaw that allows PHP web shells. Versions 2.0.3.1 and older are affected. Version 2.0.3.2, released on 20 February, fixes it, and Wordfence reported blocking more than 100,000 attacks. Months after the patch, unpatched stores were still being hit.

## How to check the WordPress version, step by step

Use the first method you have access to. Record the results in one sheet per store.

1. Log in to wp-admin and open Dashboard > Updates. The page states the installed WordPress version and whether a newer one is available. Note the date of the last update check shown at the top.
2. On the same screen, or under Plugins, note every plugin with an update available. Then go to Plugins > Installed Plugins and record name, version and whether auto-update is enabled.
3. Open WooCommerce > Status. The System Status report lists the WordPress version, WooCommerce version, PHP version, active plugins with versions, and template overrides in the theme that are out of date. Use "Get system report" to copy it as text.
4. With shell access, run WP-CLI from the site root:
 - `wp core version --extra` shows the version, database revision and package language.
 - `wp core check-update --force-check` asks the WordPress Version Check API for newer releases and skips the cached answer.
 - `wp plugin list --fields=name,status,version,update_version,auto_update --format=csv` exports the plugin inventory.
 - `wp plugin list --update=available` lists only plugins with an update waiting.
5. Without any access, view the page source of the homepage and search for `generator`. WordPress can print `<meta name="generator" content="WordPress 7.1.3">`. Also try `/feed/`, where the RSS output can include `<generator>https://wordpress.org/?v=7.1.3</generator>`. If neither appears, someone removed the markers. That hides the version from scanners and does nothing to patch the site.
6. Compare what you found with the current releases: the WordPress releases page and the WooCommerce developer blog. For each plugin, compare with the vendor changelog and check for open advisories.
7. Decide per store: update now on staging, update after the next sale window, or hold. Write the reason next to each held item.

## Which method answers which question

## Pre-peak version audit: copy and use

Paste this into your ticket system for each store and fill it in. The thresholds are examples, so set your own.

STORE VERSION AUDIT (date: ____ checked by: ____)

Store URL: ______________________
Access method used: [ ] wp-admin [ ] WP-CLI [ ] public markers only

CORE
 Installed WordPress version: ______ Branch: ______
 Latest release on this branch: ______ Latest overall: ______
 Background security updates enabled? [ ] yes [ ] no [ ] unknown

WOOCOMMERCE
 Installed version: ______ Latest: ______
 Database update pending after last upgrade? [ ] yes [ ] no
 Outdated template overrides in theme (from Status report): ______

PLUGINS (from wp plugin list or Status report)
 Total active: ____ With update available: ____
 Any plugin listed in a current advisory? [ ] yes -> name/version: ______
 Plugins that bundle their own libraries (e.g. Action Scheduler): ______
 Plugins not updated by vendor in 12+ months: ______

PHP
 Version: ______ Supported by host until: ______

DECISION
 [ ] Update on staging this week, then production
 [ ] Security-only updates now, feature updates after peak
 [ ] Hold (reason + owner + review date): ______________________

AFTER UPDATE (same day)
 [ ] Place a test order with a real payment method
 [ ] Confirm the order email arrived
 [ ] Check the error log for new fatal errors
 [ ] Check the order count over the next 2 hours against a normal day

Worked scenario (illustrative)
An agency maintains 30 WooCommerce stores. On Tuesday, a developer runs `wp plugin list --update=available --format=csv` across all of them and merges the output into one sheet. Four stores show WooCommerce with an update to 11.2 waiting. One of those four runs PublishPress Future 4.9, inside the range the WooCommerce release notes warn about.

The developer updates PublishPress Future on that store's staging copy, then WooCommerce, then runs the database update and places a test order. The site loads and the order goes through. Only then does the same sequence run on production. On the other three stores, WooCommerce goes first, because none of them has the conflicting plugin.

In the same sheet, two stores turn out to have background updates disabled and sit on an older 6.x release. They have not received the September backport. Those two get the core update first, before any WooCommerce work.

The numbers here are made up. The method holds: one export, one comparison against release notes, and an update order chosen per store instead of "update everything" on all 30.

## Common mistakes

- Trusting an online checker as the full picture. It reads the generator tag or guesses from public files, and it cannot see plugin versions reliably or tell you that a fix was backported.
- Treating "no generator tag" as "secure". Removing the marker changes what scanners see. The installed code is the same.
- Updating WooCommerce first and checking plugins afterwards. The 11.2 release notes describe exactly this trap with an outdated bundled Action Scheduler.
- Forgetting the WooCommerce database update. The 11.2 release notes say it requires one, so schedule it for a quiet hour and confirm it finished before you close the ticket.
- Leaving premium plugins out of the audit. They update through their vendor, not wordpress.org, so a dashboard that says "everything is up to date" can still be missing a premium plugin fix such as Wholesale Lead Capture 2.0.3.2.
- Reading "the homepage loads" as proof the update worked. A fatal error can sit on checkout, an AJAX handler or a scheduled job while the homepage stays green.

The method has limits. Version numbers tell you what is installed. They do not tell you whether a store was already compromised before you patched it, and they do not catch conflicts that no vendor has documented yet. A version audit lowers known risk. Test orders, error logs and order monitoring after each change catch what the audit misses.

## FAQ

### How do I check the WordPress version of a site I don't manage?

View the page source and search for `generator`, or open `/feed/` and look for the `<generator>` line. If both are missing, you cannot get the version reliably from outside, and any tool that claims to is guessing.

### Is it enough to be on the latest version of an older branch?

It keeps you covered for the critical fixes the security team backports, as with the 7.1.2 fix that went back to 4.7. Only the latest version is officially supported, so plan the move to the current branch after your peak period.

### Should I update WooCommerce right before Black Friday?

Apply security fixes when they are released, after a staging test. Feature releases can usually wait until after the sale if your current version still receives security updates. Our [Black Friday code freeze guide](https://pingvera.com/blog/black-friday-code-freeze-security-patches.html) covers how to separate the two.

## Related reading

- [Black Friday code freeze 2026: what to lock, what you must still patch](https://pingvera.com/blog/black-friday-code-freeze-security-patches.html)
- [WordPress health from the inside: what external monitoring cannot see](https://pingvera.com/blog/wordpress-health-monitoring-inside.html)
- [Post-deployment website checklist](https://pingvera.com/blog/post-deployment-website-checklist.html)
- [Client website inventory template](https://pingvera.com/blog/client-website-inventory-template.html)

## Where Pingvera fits

The last block of the audit, checking orders after an update, is the step teams tend to skip under time pressure. Pingvera's WordPress connector sends WooCommerce order events (`order.created`, `order.failed`) in real time. Its anomaly detector compares order flow to an hourly baseline and alerts when the site is up but nobody is buying. Deploys and incidents appear on the same timeline as those order events, so an update that broke checkout shows up next to the drop in orders. The Free plan covers up to 5 sites.

## Sources

- [WordPress releases (news archive)](https://wordpress.org/news/category/releases/)
- [WordPress 7.1.2 security release](https://wordpress.org/news/2026/09/wordpress-7-1-2-release/)
- [WordPress 7.1.3 maintenance and security release](https://wordpress.org/news/2026/10/wordpress-7-1-3-maintenance-and-security-release/)
- [WordPress Version Check API](https://api.wordpress.org/core/version-check/1.7/)
- [WordPress security (supported versions and backports)](https://wordpress.org/about/security/)
- [WordPress hardening guide](https://developer.wordpress.org/advanced-administration/security/hardening/)
- [WooCommerce 11.2.0 release notes](https://developer.woocommerce.com/?p=8771575)
- [WP-CLI: wp core version](https://developer.wordpress.org/cli/commands/core/version/)
- [WP-CLI: wp core check-update](https://developer.wordpress.org/cli/commands/core/check-update/)
- [WP-CLI: wp plugin list](https://developer.wordpress.org/cli/commands/plugin/list/)
- [WordPress reference: get_the_generator()](https://developer.wordpress.org/reference/functions/get_the_generator/)
- [BleepingComputer: Hackers target WordPress sites via third-party WooCommerce plugin](https://www.bleepingcomputer.com/news/security/hackers-target-wordpress-sites-via-third-party-woocommerce-plugin/)

Last reviewed: 13 October 2026