Check the stable release against an official source

At the review on 25 October 2026, the official WordPress release archive lists version 7.1.3, released on 6 October, as the latest stable release. That is a dated observation, not a permanent upgrade recommendation. Recheck the official archive when using this tutorial later. The practical workflow captures site state, identifies when review is needed and prepares application tests before any actual change to the installation.

Record the core version, plugins and themes before an update. The inventory tool saves these details and the update-check response in a new file. That inventory exposes implementation details, so keep it in a private working directory. A network or permission failure while checking releases must not be interpreted as proof that no update exists. Resolve a failed command before using its output to make a deployment decision.

Capture inventory and use an expiring review policy

The example policy recognizes one reviewed core baseline for a short period. Available updates, unfamiliar versions and expired policy dates all require review. Even a numerically newer version is not automatically accepted because it has not been assessed by this policy. This avoids silently promoting an unexpected release or development build into the deployment workflow merely because its version appears larger than the previously recorded stable release.

Run python -m unittest test_review_updates.py for version and date cases. In a private directory, execute python inventory.py /srv/staging/site and then python review_updates.py wordpress-inventory.json. Inventory collection uses WP-CLI and performs no upgrade. Matching the core baseline does not establish plugin security, absence of malware or compatibility of the site's forms and shop. Those conditions require separate checks that reflect the actual installation and its important user journeys.

Before a real update, create a coordinated backup and perform a restore drill. Install the intended target in staging and check login, forms, search, Persian content and isolated test payments. Core checksum verification can reveal changes to official files, but it does not cover every custom file or plugin. Treat a successful checksum result as one observation rather than a replacement for a complete security assessment or application acceptance test.

Complete files to save

Save all four files together. The article explains execution and verification; no code is replaced with ellipses.

1. Collect inventory without upgrading

File: inventory.py. Save every line under this filename.

import json
from pathlib import Path
import subprocess
import sys


def wp(site, *arguments):
    return subprocess.run(['wp', f'--path={site}', *arguments], check=True, capture_output=True, text=True, encoding='utf-8').stdout


if __name__ == '__main__':
    site = Path(sys.argv[1]).resolve()
    evidence = {
        'core': wp(site, 'core', 'version').strip(),
        'updates': json.loads(wp(site, 'core', 'check-update', '--format=json')),
        'plugins': json.loads(wp(site, 'plugin', 'list', '--format=json')),
        'themes': json.loads(wp(site, 'theme', 'list', '--format=json')),
    }
    # Keep inventory private. This command only reads WordPress state.
    with open('wordpress-inventory.json', 'x', encoding='utf-8') as output:
        json.dump(evidence, output, ensure_ascii=False, indent=2)

This file belongs to the complete example above; execution order, prerequisites and limits are explained in the article.

2. A stable baseline with an expiry date

File: policy.json. Save every line under this filename.

{
  "reviewed": "2026-10-25",
  "expires": "2026-11-08",
  "testedStable": "7.1.3",
  "source": "https://en-gb.wordpress.org/download/releases/",
  "meaning": "Dated core baseline only; not a malware scan or plugin security audit."
}

This file belongs to the complete example above; execution order, prerequisites and limits are explained in the article.

3. Produce an explicit review decision

File: review_updates.py. Save every line under this filename.

import argparse
from datetime import date
import json
from pathlib import Path
import re


def review(inventory, policy, today):
    if not date.fromisoformat(policy['reviewed']) <= today <= date.fromisoformat(policy['expires']):
        return 'review-policy-date'
    version = inventory.get('core', '')
    if not re.fullmatch(r'\d+\.\d+\.\d+', version):
        return 'review-unrecognized-version'
    if inventory.get('updates'):
        return 'core-update-reported'
    if version != policy['testedStable']:
        return 'review-new-or-different-baseline'
    return 'core-matches-dated-baseline-check-plugins-and-application'


if __name__ == '__main__':
    parser = argparse.ArgumentParser()
    parser.add_argument('inventory', type=Path)
    args = parser.parse_args()
    policy = json.loads(Path(__file__).with_name('policy.json').read_text(encoding='utf-8'))
    result = review(json.loads(args.inventory.read_text(encoding='utf-8')), policy, date.today())
    print(json.dumps({'assessment': result}))
    raise SystemExit(0 if result.startswith('core-matches-') else 1)

This file belongs to the complete example above; execution order, prerequisites and limits are explained in the article.

4. Test unknown releases and expired policy

File: test_review_updates.py. Save every line under this filename.

from datetime import date
import json
from pathlib import Path
import unittest
from review_updates import review


class UpdateTests(unittest.TestCase):
    def setUp(self):
        self.policy = json.loads(Path(__file__).with_name('policy.json').read_text())
        self.today = date(2026, 10, 25)

    def test_baseline(self):
        self.assertTrue(review({'core': '7.1.3', 'updates': []}, self.policy, self.today).startswith('core-matches-'))

    def test_update_and_unknown_versions(self):
        self.assertEqual(review({'core': '7.1.2', 'updates': [{}]}, self.policy, self.today), 'core-update-reported')
        self.assertIn('unrecognized', review({'core': '7.2-beta1'}, self.policy, self.today))
        self.assertIn('different', review({'core': '7.1.4'}, self.policy, self.today))

    def test_expired(self):
        self.assertEqual(review({'core': '7.1.3'}, self.policy, date(2026, 11, 9)), 'review-policy-date')


if __name__ == '__main__':
    unittest.main()

This file belongs to the complete example above; execution order, prerequisites and limits are explained in the article.

Test compatibility and prepare a recoverable release

Release with an explicit target version, maintenance window and rollback criterion. After the change, inspect important pages, application errors and scheduled tasks again. If another stable version has appeared by the time you use this example, update the policy and compatibility evidence first. Do not select a beta merely because of its larger version number. The objective is an assessable change with a known recovery route and evidence from the real application.

Implementation checklist

  • Recheck the official stable release at use time.
  • Keep plugin and theme inventory private.
  • Review policy age and application compatibility.
  • Prepare backup and rollback criteria before release.

References

Editorial guidance: Liyan Knowledge.

Published: