تصاویر بعد از انتقال وردپرس نمایش داده نمی‌شوند؛ تشخیص URL، فایل و Thumbnail

نمایش‌ندادن تصاویر پس از انتقال وردپرس معمولاً یکی از چهار علت دارد: صفحه URL اشتباه درخواست می‌کند، فایل منتقل نشده، سرور اجازه خواندن یا ارائه آن را ندارد، یا WordPress به سایزی از تصویر اشاره می‌کند که وجود ندارد. آیکون تصویر شکسته به‌تنهایی لایه خراب را مشخص نمی‌کند.

پاسخ سریع: یک درخواست ناموفق تصویر را در Network مرورگر باز و URL کامل و HTTP Status را ثبت کنید. URL را با فایل مورد انتظار در wp-content/uploads مقایسه کنید. اگر Host قدیمی دارد، جایگزینی آگاه به serialization انجام دهید؛ برای 404 مسیر، Case نام، Thumbnail، Rewrite، CDN و Origin را بررسی کنید؛ برای 403 سراغ Permission و Access Rule بروید. پیش از Regenerate یا Replace سراسری، همان لایه را اثبات کنید.

از یک درخواست خراب دقیق شروع کنید

Developer Tools را باز، صفحه را Reload و یک تصویر Failed را انتخاب کنید. URL، Status، Redirect Chain، Response Header، Initiator و پیام Mixed Content را ثبت کنید. URL را مستقیم باز و با src و srcset HTML مقایسه کنید.

این شواهد مشکل URL دیتابیس را از Filesystem و Delivery جدا می‌کند. Thumbnail در Media Library ممکن است علتی متفاوت از فایل Full-size داخل نوشته داشته باشد.

پیش از تغییر، HTTP Status را تفسیر کنید

• 404: URL اشتباه، فایل یا Thumbnail مفقود، Case نام، مسیر Origin یا Rewrite
• 403: Permission، Ownership، Hotlink Protection، WAF یا Storage Policy
• Loop در 301/302: تعارض دامنه، HTTPS، CDN یا Proxy
• 5xx: Origin، PHP Image Handler، Proxy، Storage یا کمبود منابع
• 200 با محتوای اشتباه: Soft Error، پاسخ CDN یا MIME/Content خراب

برای URL دارای دامنه قدیمی کل Library را Regenerate نکنید و برای فایل مفقود Search-Replace اجرا نکنید.

وجود فایل درخواست‌شده را بررسی کنید

مسیر URL را به Upload Path مقصد تبدیل و نام دقیق فایل را کنترل کنید. Filesystem لینوکس معمولاً Case-sensitive است؛ Photo.jpg و photo.jpg یکسان نیستند. Count و Size پوشه‌های سال/ماه مبدأ و مقصد و خطا یا Exclusion انتقال را مقایسه کنید.

فایل Placeholder خالی نسازید و فقط Attachment Record دیتابیس را کپی نکنید. رکورد Media Library توضیح رسانه است، اما Binary باید در Storage وجود داشته باشد.

Upload Base URL و Path را تأیید کنید

نصب استاندارد معمولاً Media را از wp-content/uploads ارائه می‌کند، اما Multisite، Offload Plugin یا تنظیم تاریخی ممکن است مسیر دیگری داشته باشد. Upload Configuration و Attachment Metadata را بررسی کنید.

مستند رسمی Media Library رکورد رسانه را از فایل Uploadشده‌ای که نمایندگی می‌کند جدا می‌داند. وجود رکورد در Library حضور فایل روی Storage جدید را ثابت نمی‌کند.

مرجع دامنه و مسیر قدیمی را پیدا کنید

HTML، Post Content، Attachment URL، CSS، Widget، Page Builder، Theme Option و Plugin Setting serialized را بررسی کنید. اگر دامنه یا Path تغییر کرده، Replacement سازگار با serialization را ابتدا Dry Run کنید:

wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --dry-run

پیش از حذف --dry-run Scope را مرور کنید. HTTP، www، URL escaped، CDN و Staging قدیمی را جدا جست‌وجو کنید. راهنمای انتقال به دامنه جدید URL Replacement و Redirect را توضیح می‌دهد.

فایل اصلی را با Thumbnail اشتباه نگیرید

WordPress هنگام Upload چند اندازه مشتق می‌سازد. ممکن است Original وجود داشته باشد اما فایل -300x200 یا سایز تعریف‌شده قالب مفقود باشد. نام درخواست خراب را با Attachment Metadata و Disk مقایسه کنید.

اگر قالب یا Image Size جدید به مشتق‌های ساخته‌نشده نیاز دارد، فقط پس از Backup و تست نمونه Regenerate کنید. Regeneration فایل Original مفقود را بازیابی نمی‌کند.

Thumbnail Regeneration را برای مشکل درست استفاده کنید

فرمان رسمی wp media regenerate Thumbnail را بازسازی و امکان محدودکردن به فایل مفقود یا Size منتخب را فراهم می‌کند. برای Library بزرگ ابتدا Attachment مشخص یا Staging را تست کنید.

wp media regenerate 123 --skip-delete
wp media regenerate --only-missing --yes

ID نمونه است. سازگاری Plugin، Disk، CPU، RAM و Backup را بررسی کنید. تا زمانی که مطمئن نیستید صفحه بیرونی یا Cache به سایز قدیمی اشاره نمی‌کند، فایل ناشناخته را حذف نکنید.

Ownership و Permission را بررسی کنید

وب‌سرور برای ارائه Media به Read و برای Upload و Thumbnail تازه به Write مناسب نیاز دارد. Ownership صحیح به مدل Deployment بستگی دارد و فرمان عمومی ندارد. فایل سالم و خراب را مقایسه کنید.

از chmod 777 استفاده نکنید؛ دسترسی گسترده مشکل Ownership را پنهان و ریسک را زیاد می‌کند. مستند WordPress نیز Permission مناسب wp-content را برای Upload ضروری می‌داند.

روی مقصد یک Upload تازه تست کنید

تصویر کوچک و غیرحساس از Media Library Upload کنید. ساخت Original و Sizeها، دریافت از Browser و Owner فایل را کنترل کنید و در صورت عدم نیاز از داخل WordPress حذف کنید.

اگر Media قدیمی کار می‌کند اما Upload جدید نه، Permission نوشتن، فضای Disk، Temp، PHP Limit، Image Library و Storage را بررسی کنید. اگر Media جدید سالم و قدیمی خراب است، Copy، URL و Metadata اولویت دارند.

Mixed Content پس از HTTPS را تشخیص دهید

صفحه HTTPS ممکن است تصویر HTTP را Block کند. Console و URL نهایی را ببینید. URL ذخیره‌شده یا تولیدشده را اصلاح و تشخیص HTTPS پشت Proxy را درست کنید.

محافظت Browser را خاموش نکنید. راهنمای HTTPS وردپرس اهمیت Proxy Header صحیح برای جلوگیری از مشکل Scheme و Redirect را توضیح می‌دهد.

خرابی CDN را از Origin جدا کنید

تصویر را از CDN عمومی و با روش مجاز مستقیم از Origin و Host Header درست درخواست کنید. Status، Cache Header، Content-Type و Body را مقایسه کنید. Negative Cache ممکن است پس از رسیدن فایل همچنان 404 بدهد.

Origin hostname، Path Prefix، TLS، Policy، Cache Key، Image Optimization و Purge Scope را بررسی کنید. ابتدا یک URL تست را Purge کنید، نه کل Cache را.

Media Offload و Object Storage را مرور کنید

Offload Plugin ممکن است URL را Rewrite و Object را در S3-compatible Storage بخواهد. Bucket، Region، Endpoint، Credential، Prefix، Policy، Signed URL و CORS را کنترل کنید. Credential را در خروجی Debug افشا نکنید.

کپی دیتابیس بدون Object Store یا کپی Object بدون Metadata درست، Library نیمه‌سالم می‌سازد.

srcset و Responsive Candidate را بررسی کنید

ممکن است src سالم باشد اما Browser بر اساس Viewport یا Pixel Density یک Candidate خراب از srcset انتخاب کند. درخواست واقعی را ببینید، نه فقط اولین URL در HTML. مشتق مفقود و CDN Transform معمولاً فقط روی بعضی Deviceها دیده می‌شوند.

عرض‌های نماینده Desktop و Mobile را تست و پس از اصلاح Origin، Variantهای Device-specific را پاک کنید.

CSS Background و Lazy Load را بررسی کنید

برخی تصاویر از Inline Style، CSS تولیدشده، Page Builder یا JavaScript Lazy Loading می‌آیند. Initiator درخواست را ببینید. Builder CSS را فقط وقتی Cache مستند آن Path قدیمی دارد Regenerate و Rollback Copy نگه دارید.

Placeholder خالی ممکن است از خطای JavaScript پیش از جایگزینی Lazy Attribute باشد. Console و DOM Renderشده را مقایسه کنید.

Encoding و بزرگی حروف Filename را کنترل کنید

انتقال میان Filesystemها تفاوت Unicode Normalization، Case، Space یا نام غیرلاتین را آشکار می‌کند. URL encoded را با Filename دقیق مقایسه کنید. بدون اصلاح همه مرجع‌های دیتابیس و Metadata، Bulk Rename انجام ندهید.

برای مجموعه کوچک، Rename کنترل‌شده همراه Update مرجع امن‌تر از Transformation سراسری است.

پس از Fix اعتبارسنجی کنید

1. تصویر خراب اولیه و صفحه آن را دوباره تست کنید.
2. Full-size و Responsive Variant را بررسی کنید.
3. Upload تازه و ساخت Thumbnail را تست کنید.
4. Console، Log برنامه و پاسخ CDN را بخوانید.
5. برای Image 404/403 و Old Host Crawl کنید.
6. مصرف Disk و پوشش Backup را تأیید کنید.

نمایش تصویر Cacheشده در یک Browser اثبات تعمیر نیست؛ با Cache Bypass و مسیر عمومی Delivery تست کنید.

اشتباه‌های رایج

• Regenerate پیش از بررسی Original
• SQL Replacement خام روی Serialized Data
• استفاده از 777 برای پنهان‌کردن Ownership
• Purge کل CDN بدون تست Origin
• نادیده‌گرفتن srcset، CSS و Lazy Load
• فرض اینکه Media Record یعنی فایل کپی شده است
• حذف Thumbnail قدیمی پیش از پایان Reference بیرونی

چه زمانی کمک تخصصی مناسب است؟

هزاران فایل، Object Storage، CDN Transformer، Page Builder serialized یا تفاوت Filesystem، ریسک Bulk Change را زیاد می‌کند. سرویس انتقال سایت وردپرس می‌تواند Storage، URL، Metadata و Delivery را پیش از Fix محدود مقایسه کند.

پرسش‌های متداول

چرا تصویر در Media Library هست ولی در صفحه نیست؟

ممکن است Attachment Record باشد اما فایل، Size مشتق، URL، Permission، Object در CDN یا Responsive Candidate مشکل داشته باشد.

Regenerate Thumbnail فایل Original را برمی‌گرداند؟

خیر؛ فقط در صورت وجود و خوانده‌شدن Original می‌تواند Size مشتق بسازد.

همه رشته‌های دامنه قدیمی را Replace کنیم؟

خیر؛ Dry Run و طبقه‌بندی لازم است. Email، Log، Identifier و مرجع بیرونی ممکن است عمداً دامنه قدیمی داشته باشند.

چرا تصویر در Desktop کار می‌کند ولی Mobile نه؟

Browser ممکن است در Viewport یا Pixel Density دیگر Candidate متفاوت srcset، CDN Transform یا Lazy Path را انتخاب کند.