نسخهٔ پایدار را از کدام منبع بررسی کنیم؟

در بازبینی ۲۵ اکتبر ۲۰۲۶، بایگانی رسمی وردپرس نسخهٔ ۷٫۱٫۳ با تاریخ انتشار ۶ اکتبر را آخرین انتشار پایدار نشان می‌دهد. این عدد یک واقعیت تاریخ‌دار است و برای استفادهٔ بعدی باید دوباره با منبع رسمی تطبیق داده شود. این مقاله به جای وعدهٔ امنیت دائمی یک نسخه، روشی برای ثبت وضعیت سایت، تشخیص نیاز به بررسی و آماده‌کردن آزمون پیش از تغییر ارائه می‌کند.

پیش از به‌روزرسانی، نسخهٔ هسته، فهرست افزونه‌ها و قالب‌ها را ثبت کنید. ابزار موجودی این اطلاعات و پاسخ بررسی انتشار جدید را در یک فایل تازه ذخیره می‌کند. این گزارش می‌تواند جزئیات فنی سایت را آشکار کند؛ آن را در پوشهٔ خصوصی نگه دارید. خطای شبکه یا دسترسی هنگام دریافت وضعیت به‌روزرسانی نباید به معنی نبود نسخهٔ جدید تفسیر شود؛ اجرای ناموفق ابزار باید ابتدا بررسی شود.

موجودی سایت و سیاست تاریخ‌دار پیش از تغییر

سیاست نمونه تنها خط مبنای هسته را در یک بازهٔ کوتاه می‌پذیرد. اگر انتشار جدید گزارش شود، نسخه ناشناخته باشد یا تاریخ سیاست منقضی شده باشد، خروجی نیازمند بازبینی است. حتی نسخهٔ جدیدتر از خط مبنا خودکار پذیرفته نمی‌شود، چون هنوز در این سیاست بررسی نشده است. این انتخاب کمک می‌کند انتشار آزمایشی یا تغییر خارج از برنامه بی‌صدا وارد جریان استقرار نشود.

با python -m unittest test_review_updates.py آزمون‌های نسخه و تاریخ را اجرا کنید. سپس در پوشهٔ خصوصی با python inventory.py /srv/staging/site گزارش بگیرید و python review_updates.py wordpress-inventory.json را اجرا کنید. ابزار موجودی از خط فرمان وردپرس استفاده می‌کند و چیزی ارتقا نمی‌دهد. تطبیق نسخهٔ هسته به معنی سالم‌بودن همهٔ افزونه‌ها، نبود بدافزار یا سازگاری فرم‌ها و فروشگاه نیست؛ این موارد آزمون جدا می‌خواهند.

پیش از اقدام واقعی، پشتیبان هماهنگ و تمرین بازیابی داشته باشید. نسخهٔ هدف را ابتدا روی محیط آزمایش نصب و ورود، فرم، جست‌وجو، متن فارسی و پرداخت آزمایشی را بررسی کنید. بررسی چکیدهٔ فایل‌های هسته می‌تواند تغییر فایل‌های رسمی را نشان دهد، اما فایل‌های سفارشی و همهٔ افزونه‌ها را پوشش نمی‌دهد. خروجی موفق این بررسی را با نتیجهٔ یک ارزیابی کامل امنیتی یکسان نگیرید.

کدهای کامل و قابل ذخیره

چهار فایل زیر را در یک پوشه ذخیره کنید. دستورهای اجرا و بررسی در متن آمده‌اند؛ هیچ کد با سه‌نقطه جایگزین نشده است.

1. ثبت موجودی بدون ارتقای سایت

نام فایل: inventory.py؛ همهٔ سطرها را با همین نام ذخیره کنید.

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)

این فایل بخشی از مثال کامل بالاست؛ ترتیب اجرا، پیش‌نیازها و محدودیت‌های نتیجه در متن مقاله توضیح داده شده است.

2. خط مبنای پایدار با تاریخ انقضا

نام فایل: policy.json؛ همهٔ سطرها را با همین نام ذخیره کنید.

{
  "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."
}

این فایل بخشی از مثال کامل بالاست؛ ترتیب اجرا، پیش‌نیازها و محدودیت‌های نتیجه در متن مقاله توضیح داده شده است.

3. تصمیم قابل پیگیری برای بازبینی

نام فایل: review_updates.py؛ همهٔ سطرها را با همین نام ذخیره کنید.

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)

این فایل بخشی از مثال کامل بالاست؛ ترتیب اجرا، پیش‌نیازها و محدودیت‌های نتیجه در متن مقاله توضیح داده شده است.

4. آزمون انتشار ناشناخته و انقضای سیاست

نام فایل: test_review_updates.py؛ همهٔ سطرها را با همین نام ذخیره کنید.

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()

این فایل بخشی از مثال کامل بالاست؛ ترتیب اجرا، پیش‌نیازها و محدودیت‌های نتیجه در متن مقاله توضیح داده شده است.

آزمون سازگاری و انتشار با امکان بازگشت

انتشار اصلی را با ثبت نسخهٔ هدف، پنجرهٔ تغییر و معیار بازگشت انجام دهید. پس از تغییر، پاسخ صفحه‌های مهم، خطاهای برنامه و کارهای زمان‌بندی‌شده را دوباره ببینید. اگر در زمان استفاده نسخهٔ پایدار دیگری منتشر شده است، ابتدا سیاست و شواهد آزمون را به‌روز کنید. انتشار بتا را صرفاً به دلیل بزرگ‌تر بودن شمارهٔ نسخه انتخاب نکنید؛ هدف، تغییر قابل ارزیابی با مسیر بازگشت روشن است.

چک‌لیست اجرای عملی

  • انتشار پایدار با منبع رسمی همان روز تطبیق داده شود.
  • موجودی افزونه و قالب خصوصی ثبت شود.
  • سیاست تاریخ‌دار و آزمون سازگاری هر دو بررسی شوند.
  • پشتیبان و معیار بازگشت پیش از انتشار آماده باشد.

منابع

تدوین و راهنمای عملی: دانشنامه لیان.