چگونه یک قالب وردپرس استاندارد را تشخیص دهیم
چگونه یک قالب وردپرس استاندارد را تشخیص دهیم؟ ساختار فایل‌ها، علائم کد تمیز، افزونه Theme Check، پرچم‌های قرمز امنیتی و چک‌لیست ده‌دقیقه‌ای — پیش از خرید یا نصب.
«استاندارد» در دنیای وردپرس یک صفتِ تبلیغاتی نیست؛ یک فهرستِ قابل‌بررسیِ فنی است. ده مقاله‌ی منتشرشده‌ی ما در زمینه‌ی قالب — از راهنمای انتخاب تا روش تست — همه جای یک مسئله را نشانه گرفته‌اند: کیفیتِ نامرئیِ کد. در سه سال پاکسازی و مهاجرت، الگوی تکراری‌ای دیده‌ام: سایتی که با قالبِ گران‌قیمت و ظاهرِ چشمگیر شروع شده، دو سال بعد به بن‌بست می‌خورد — نه چون زشت است، چون دست‌کاری‌شده‌ی داخلِ فایل‌هایش را هیچ‌کس نمی‌تواند آپدیت کند، چون کدهایِ تزریق‌شده در footer با حذفِ یک خط سفید، کل سایت را سفید می‌کنند. قالبِ استاندارد در برابرِ قالبِ آلوده مثلِ مصالحِ استاندارد در برابرِ آجرِ شکسته است: از بیرون ممکن است یکی به نظر برسند، ولی زلزله که بیاید (یک آپدیتِ امنیتی، یک مهاجرت، یک هک) تفاوت‌شان آشکار می‌شود. این مقاله، روشِ من برای تشخیصِ این دو از هم است — در ده دقیقه، با ابزارهایِ رایگان، بدونِ نیاز به دانستنِ خط‌به‌خطِ PHP.
«استاندارد» یعنی چه دقیقاً؟
در اکوسیستمِ وردپرس، قالبِ استاندارد سه ویژگی دارد که هر سه قابلِ اندازه‌گیری‌اند: یک — از APIهایِ رسمیِ وردپرس استفاده می‌کند، نه میان‌بُرهایِ شخصی؛ یعنی توابعِ جاوااسکریپت و PHP را همان‌طور که هسته‌ی وردپرس تعریف کرده به‌کار می‌بَرد و چیزهایی که هسته ارائه می‌دهد (مثلِ تصویر شاخص یا منوها) را دوباره از صفر نمی‌سازد. دو — قابل‌به‌روزرسانیِ امن است؛ فایل‌هایش طوری جدا شده‌اند که یک آپدیت، سفارشی‌سازی‌هایِ شما را پاک نکند (همان درسی که «قالب چایلد چیست؟» می‌دهد: کدِ مادر دست‌نخورده، کارِ شما در لایه‌ی فرزند). سه — به سازنده‌ی قابل‌شناسایی برمی‌گردد؛ یعنی چنان امضایی دارد که بتوانید نسخه‌هایش را با هم مقایسه کنید. این تعریف را «قالب چیست و چطور کار می‌کند؟» روی نقشه‌ی کلی نشان داده‌ام؛ اینجا روشِ پیاده‌سازیِ تشخیص است. نکته‌ای که کمتر گفته می‌شود: «استاندارد بودن» ربطی به «زیبا بودن» یا «پرامکانات بودن» ندارد؛ قالبِ ساده‌ای که هر سه ویژگی را داشته باشد، از شلوغ‌ترین قالبِ چندمنظوره (با تعریفِ «قالب چندمنظوره چیست؟») ارزشمندتر است — همان تفکیکِ «امکانات در برابرِ کیفیتِ ساخت» که در مقاله‌ی «امکانات قالب حرفه‌ای» با جدولِ امتیازدهی باز کرده‌ام.
قالبِ غیراستاندارد مثلِ خانه‌ای است که سیم‌کشی‌اش داخلِ دیوارِ گچ‌کشیده‌ست: امروز زیبا، فردا تعمیرناپذیر.
لایه‌ی اول: ساختار فایل‌ها و هدرها
zipِ قالب را باز کنید (فقط باز کنید، نصب نکنید) و پنج نگاهِ اول را این‌طور انجام دهید:
- فایل style.css و هدرش: هر قالبِ استاندارد، ابتدای style.css هدرِ رسمی دارد: Theme Name، Author، Version، License و متنِ لایسنس (GPL). نبودِ License یا نوشتنِ «This theme is proprietary — all rights reserved» پرچمِ اول است: وردپرس با قالب‌هایِ بسته‌شده نمی‌سازد؛ هر جا نوشته «ویرایشِ این فایل ممنوع»، احتمالاً چیزی پشتش قایم است.
- نقشه‌ی فایل‌ها: فایل‌هایِ اصلیِ قالبِ استاندارد نام‌هایِ قابل‌پیش‌بینی دارند (index.php، functions.php، single.php، archive.php...). اگر پوشه‌ای با نام‌هایِ بی‌ربط دیدید («data»، «inc_old»، «tmp») یا فایل‌هایی مثل «wp-locks.php» که هیچ قالبِ سالمی ندارد، شک نکنید و سراغِ لایه‌ی کد بروید.
- فایل‌هایِ آلودگی‌زدایی‌شده: فایل‌هایِ GIF/PNG که داخلشان کد است نه تصویر، فایل‌هایِ PHP درونِ wp-content/uploads (جایی که هیچ قالبی نباید باشد)، و فایل‌هایی با تایم‌استمپِ متفاوت از بقیه (آخرین دست‌کاری). سه پرونده‌ی هکی که در مقاله‌ی «دانلود افزونه‌ی مطمئن» گفتم، همه از همین الگو شروع شدند.
- پوشه‌ی languages: قالبِ استاندارد رشته‌هایش را با
__()و_e()می‌نویسد و فایلِ پتانسیلِ ترجمه (.pot) همراهش است. اگر همه‌چیز هاردکدِ فارسی/انگلیسی است، قالب برای ترجمه ساخته نشده — و معمولاً برای نگهداری هم نه. - اسکرین‌شات و readme: screenshot.png واقعی (مطابقِ نسخه‌ی نصبی) و readme.txt با شرحِ آپدیت‌ها. readme خشک‌وخالی یا changelogِ بی‌نسخه، نشانه‌اش در مقاله‌ی «پیش از خرید قالب چه چیزی بررسی کنیم؟» آمده.
لایه‌ی دوم: نشانه‌های کد تمیز
برای خواندنِ کد لازم نیست برنامه‌نویس باشید؛ چند الگو با چشمِ غیرفنی هم دیده می‌شوند. functions.php مثلِ مغزِ قالب است؛ در قالبِ استاندارد، این فایل پر از توابعِ نام‌دار و کوتاه با کامنت است، نه دیوارِ کدِ بی‌وقفه. سه نشانه‌ی مثبت: enqueue منظم — فایل‌های CSS و JS با wp_enqueue_style و wp_enqueue_script بارگذاری می‌شوند و در کدِ HTML جای دیگری تکرار نمی‌شوند؛ پیشوندِ یکتا — توابعِ قالب نام‌هایش با پیشوندِ نامِ قالب شروع می‌شود (مثلاً mystyle_setup)، چون در وردپرسِ واقعی، تابعِ بی‌پیشوند یعنی «من هر قالب دیگری را هم می‌توانم بشکنم»؛ و کامنتِ نسخه — کنارِ توابعِ مهم نوشته «چرا» این‌طور نوشته شده، نه فقط «چه». سه نشانه‌ی منفیِ قرمز: رشته‌هایِ base64ِ طولانی (eval(base64_decode("...")) که مثلِ نامه‌ی رمزگذاری‌شده‌ی مشکوک است)؛ تابع‌هایِ ناشناسِ فایل‌خوان (file_get_contents با آدرسِ httpِ بیرونی — قالبِ سالم از اینترنتِ بیرون «چیزی» نمی‌گیرد)؛ و iframe/اسکریپت‌هایِ تزریق‌شده در footer.php که حذفشان صفحه را می‌شکند — معمولاً «لینکِ قدرت‌گرفته از وردپرس» نیستند، تبلیغِ پنهان یا کدِ رهگیری‌اند؛ «چرا بعضی قالب‌ها سایت را کند می‌کنند؟» نمونه‌های واقعی‌شان را نشان داده است. دو نشانه‌ی استانداردِ مثبتِ دیگر که در فهرست‌های رسمی وردپرس الزامی‌اند: esc_ها — خروجی‌ها با esc_html/esc_attr/esc_url پاکسازی می‌شوند (نشانه‌ی نویسنده‌ای که XSS را می‌شناسد)؛ و sanitize در ذخیره — ورودی‌هایِ Customizer با sanitize_ها تمیز می‌شوند. اگر کدِ قالب مثلِ کتابِ دست‌نویسِ نامفهوم است، حتی اگر امروز کار کند، فردا قابلِ نگهداری نیست — و قالبی که نگهداری‌ناپذیر است، در واقعِ امر «بی‌استاندارد» است.
قضاوت‌کردنِ کیفیتِ قالب از روی ظاهرش، مثلِ قضاوت‌کردنِ مهندسیِ پل از رنگِ نرده‌هایش است؛ برای پل، باربریِ زیرِ طوفان ملاک است — برای قالب، یک آپدیت و یک روزِ هک.
ابزارها: Theme Check و دو هم‌تاییِ کمکی
هیچ‌کدام از نگاه‌هایِ بالا را نباید با قضاوتِ شخصی انجام داد؛ ابزار هست:
- Theme Check (افزونه‌ی رسمیِ مخزن): قالبِ فعال را می‌گیرد و برابرِ قواعدِ کدنویسیِ وردپرس می‌سنجد؛ صدها قانون را چک می‌کند و گزارشِ خطا/هشدار می‌دهد. نصبش روی استجینگ (نه سایتِ زنده)، فعال‌کردنِ قالبِ موردنظر، و گرفتنِ گزارش — ده دقیقه. خطاهایِ «non-compliant» مثلِ چراغ‌هایِ بازرسیِ فنی‌اند: هرکدام که دیدید، اسمش را در نت بجویید؛ نصفِ جواب‌ها در توضیحِ خودِ گزارش هست.
- Plugin/Theme Checkerهایِ آنلاینِ امنیتی: فایل‌هایِ مشکوکِ known-malware را با امضاهایِ ویروس‌یابیِ عمومی تطبیق می‌دهند؛ برای قالبی که از مارکتِ ناشناس خریدید، لایه‌ی دومِ آزمون است — همان منطقِ «دو چشمِ متفاوت» در مقاله‌ی «افزونه‌های امنیتی».
- ویرایشگرِ متن + جست‌وجویِ ساده: همان الگوهایِ eval/base64/file_get_contents/iframe را در کلِ پوشه‌ی قالب جست‌وجو کنید؛ ابزارِ حرفه‌ای لازم نیست — Ctrl+Shift+F در VS Code کافی است.
یک تذکرِ صادقانه: گزارشِ Theme Check «خطا=بد» مطلق نیست؛ قالب‌هایِ بزرگِ چندمنظوره گاهی هشدارهایِ فنیِ قابل‌دفاع دارند. ولی قالبی که در مخزنِ رسمی وردپرس پذیرفته شده، این آزمون را پاس کرده — پس معیارِ ساده برای مبتدی: قالبِ مخزن = استانداردِ تضمین‌شده؛ قالبِ مارکتِ معتبر = استانداردِ قابل‌سنجش؛ قالبِ ناشناس = استانداردِ ادعایی. اگر می‌خواهید بدانید چرا، «آیا قالب‌های رایگان امن هستند؟» تفاوتِ فیلترِ مخزن با دنیای بیرون را باز کرده و «رایگان یا پولی؟» تصمیمِ اقتصادی‌اش را.
پرچم‌های قرمز امنیتی
هفت مورد که اگر حتی یکی را دیدید، از خرید/نصبِ آن قالبِ خاص بگذرید — هر هفت از پرونده‌هایِ واقعیِ پاکسازیِ خودم‌اند:
- «افزونه‌ی الزامی» با آدرسِ دانلودِ اختصاصی: قالبِ آلوده، افزونه‌ای «لازم» معرفی می‌کند که فقط از سرورِ سازنده دانلود می‌شود. قالبِ استاندارد از توصیه‌ی افزونه استفاده می‌کند (TGM و هم‌خانواده‌ها) و فایل‌هایش در مخزن یا داخلِ خودش است، نه دامنه‌ی مشکوک.
- eval/base64 در functions.php: حتی یک مورد؛ به‌خصوص اگر با کامنتِ «Do not edit» همراه باشد.
- کدهایِ خام در header/footer که با توضیحِ «بهینه‌سازی» آمده: «اسنیپتِ سرعت» داخلِ قالب؟ همان‌طور که در «افزایش سرعت وردپرس» گفتم، هیچ اسنیپتِ جادویی سرعتی وجود ندارد که با یک خط فعال شود — این‌ها معمولاً ردپایِ لینک‌سازی یا جاسوسی‌اند.
- غیرفعال‌شدنِ ویرایشگر/پیشخوان یا ناپدیدشدنِ منوهایِ مدیریتی: قالبِ دست‌کاری‌شده گاهی نقش‌هایِ کاربری را «ساده» می‌کند تا شما دسترسی‌هایش را نبینید.
- فایل‌هایِ PHP در مسیرِ آپلود: wp-content/uploads جای فایلِ اجرایی نیست؛ اگر قالب آنجا چیزی نوشته، یا بدافزار است یا سازنده‌اش معمار نیست.
- درخواست‌هایِ خروجی به دامنه‌هایِ ناشناس: قالب در DevToolsِ تبِ Network باید بی‌سروصدا باشد؛ هر pingِ دوره‌ای به دامنه‌ی «check-theme[.]xyz» یعنی شمارشِ قربانی.
- قفلِ لایسنسِ بی‌مستند: کدی که بدونِ «فعال‌سازی» غیرقابل‌استفاده است ولی هیچ سازنده‌ی شناخته‌شده‌ای پشتش نیست؛ همان فاجعه‌ای که در «افزونه‌ی مطمئن» برای نسخه‌ی نال توصیف کردم — اینجا نسخه‌ی نالِ قالب.
و یادآوریِ کلی از «اشتباهات رایج امنیتی وردپرس» که در همین جا به‌کار می‌آید: امنیتِ قالب مرزِ اول است؛ هر روزی که قالبِ مشکوک روی سرور بماند، فرضِ آلودگی امن‌تر از فرضِ پاکی است.
منبع خرید هم بخشی از استاندارد است
دو قالبِ یک‌کد، دو سرنوشت: از کجا خریدن، بخشی از «استاندارد» بودنِ نسخه‌ای است که روی سرور شما نصب می‌شود. مخزنِ رسمیِ وردپرس (WordPress.org) هر آپلود را با بازبینیِ تیم امنیتی و ربات‌هایِ امضازنی عبور می‌دهد؛ مارکت‌هایِ معتبر (مثل ThemeForest) فیلترِ سفت‌وسختِ خودشان را دارند؛ سایت‌هایِ «دانلود رایگانِ قالب‌هایِ پولی» هیچ‌کدام را ندارند — همان سه‌لایه‌ی بازارِ ایرانی که برای افزونه در مقاله‌ی «افزونه‌ی مطمئن» ترسیم کردم، مو‌به‌مو برای قالب هم صادق است. نشانه‌هایِ منبعِ سالم: سازنده با پروفایلِ قابل‌راستی‌آزمایی، نسخه‌ها با changelogِ شفاف، پشتیبانیِ پاسخگو با آزمونِ «تیکت بزن و زمانِ جواب را اندازه بگیر»، و لایسنسِ روشن. در انتخابِ هوشمندانه‌ی بینِ رایگان/پولی، معیارهایِ خرید را در «انتخاب قالب برای کسب‌وکار» و نقشه‌ی کلیِ انتخاب را در «راهنمای انتخاب قالب وردپرس» نوشته‌ام؛ این مقاله، ذره‌یبینیِ فنیِ همان تصمیم است.
چک‌لیست ده‌دقیقه‌ایِ من
هر قالبِ جدیدی که واردِ استجینگم می‌شود، این ده دقیقه را پاس می‌کند — ترتیبش از ارزان به گران:
- بازکردنِ zip و نگاه به style.css (هدر، لایسنس) — ۱ دقیقه
- جست‌وجویِ کلیدواژه‌هایِ eval/base64/iframe/uploads-php در ویرایشگر — ۲ دقیقه
- نصب در استجینگ + فعال‌سازی و اجرای Theme Check — ۳ دقیقه (اجازه دهید بدود، شما در این فاصله فایل‌ها را ورق بزنید)
- بررسیِ Network در DevTools هنگامِ مرورِ پنج صفحه‌ی اصلی (به‌خصوص درخواست‌هایِ خارجیِ ناشناس) — ۲ دقیقه
- مقایسه با نسخه‌ی رسمی/مخزنِ همان قالب (اگر رایگان است) و چکِ changelogِ دو نسخه‌ی اخیر — ۲ دقیقه
و بعد از پاس‌شدن، تستِ رفتاریِ کامل (شکستنِ فرضی، صفحه‌بندی، RTL، فرم‌ها) را در استجینگ اجرا کنید — همان پروتکلی که در «بهترین روش تست قالب» فهرست کرده‌ام؛ و برای لحظه‌ی تعویضِ نهایی، پروتکلِ «تغییر قالب بدون آسیب». روی سایتِ زنده هیچ‌وقت تستِ کور نکنید؛ قالبِ «استاندارد» در آزمایش مشخص می‌شود، نه در آتش.
اگر قالبِ غیراستاندارد نصب کرده‌ایم؟
اول: این پرونده‌ها پایانِ دنیا نیستند، ولی «همان امشب» باید بسته شوند. سه سناریو از تجربه‌ی خودم:
- قالبِ غیراستانداردِ سالم: (کدهایِ کثیف ولی بدونِ آلودگی؛ رایج‌ترین حالت در قالب‌هایِ ایرانیِ قدیمی) — عجله‌ای برای حذفِ فوری نیست؛ اول مهاجرت را طبقِ «تغییر قالب بدون آسیب» برنامه‌ریزی کنید: بکاپ، استجینگ، فهرستِ وابستگی‌ها (ویجت‌ها، مینوی‌ها، تنظیماتِ Customizer)، و بعدِ مهاجرت چک‌لیستِ سئو و لینک‌ها را اجرا کنید. تا روزِ مهاجرت، لایه‌ی دفاعیِ موقت با «افزونه‌های امنیتی» و اسکنِ هفتگی.
- قالبِ مشکوک/نال: هیچ‌وقت حذف‌کردن از پیشخوان را به‌عنوان «تمیزکاری» کافی ندانید؛ فایل‌هایِ جا‌مانده، اکانت‌هایِ مدیرِ پنهان و cronهایِ تزریق‌شده با حذفِ پوشه نمی‌روند. توالیِ درست همان پنج‌گامِ «افزونه‌ی مطمئن» است: بکاپِ لحظه‌ی جرم → اسکنِ لایه‌ای → قطعِ منبع → چرخه‌ی کلیدها → در آلودگیِ عمیق، بازنصبِ هسته. نشانه‌هایی که «دیر آمده‌اید» را در «چگونه بفهمم سایتم هک شده؟» چک کنید.
- قالبی که آپدیت‌ناپذیر شده: (هر بار بعدِ آپدیت، سفارشی‌ها پاک می‌شوند) — اگر سازنده هنوز هست و پشتیبانی جواب می‌دهد، مهاجرت به چایلد‌تمِ درستِ همان قالب را امتحان کنید؛ اگر سازنده نیست، مهاجرتِ کامل با نقشه‌ی «قالبِ کسب‌وکاری» را بگذارید در تقویمِ فصلِ بعدی.
و برای تیم‌ها، درسِ ساختاری: قالب را مثلِ وابستگیِ نرم‌افزار (dependency) مدیریت کنید — منبعِ مشخص، نسخه‌ی قفل‌شده، و آپدیتِ مرحله‌ای در استجینگ؛ همان انضباطی که هسته‌ی وردپرس و افزونه‌ها را هم سالم نگه می‌دارد. قالب را به حالِ خود رها نکنید: هر سه ماه، همان چک‌لیستِ ده‌دقیقه‌ای را روی نسخه‌ی نصبیِ زنده هم اجرا کنید؛ استاندارد، وضعیت نیست، پایش است.
جمع‌بندی
«قالب استاندارد وردپرس» با سه نشانه شناخته می‌شود: APIهایِ رسمیِ وردپرس، ساختارِ قابل‌به‌روزرسانی، و سازنده‌ی قابل‌راستی‌آزمایی. روشِ تشخیص در ده دقیقه: هدرِ style.css و لایسنس → جست‌وجویِ الگوهایِ مشکوک (eval، base64، iframe، PHP در uploads) → گزارشِ Theme Check → سکوتِ تبِ Network → مقایسه با نسخه‌ی رسمی. و قانونِ طلاییِ من از سه سال پاکسازی: استاندارد بودن را از منبع می‌خرند، نه از اسکرین‌شات. قدمِ امشب: قالبِ فعلی‌تان را همین ده‌چکلیستِ بالا اجرا کنید — خیلی از صاحبانِ سایت، اولین گزارشِ Theme Checkِ سایتِ خودشان را با تعجب باز می‌کنند؛ خطاها/هشدارهایِ قالبِ خودتان را با اعداد در دیدگاه بنویسید، رایج‌ترین موارد را در نسخه‌ی بعدیِ همین فهرست اولویت می‌دهم. 🧭
نویسنده در وردپرس کار.