پیام This site has been updated in the background؛ علت و رفع مشکل

پیام «This site has been updated in the background» معمولاً یک پیام عمومی مرورگر درباره به‌روزرسانی یا رسیدگی به سایت در پس‌زمینه است؛ به‌تنهایی ثابت نمی‌کند سایت هک شده یا متن کمپین شما با موفقیت به کاربر نشان داده شده است. اگر هم‌زمان پوش دریافت می‌شود اما اعلان قابل مشاهده نیست، باید مسیر دریافت رویداد در سرویس‌ورکر، نگه‌داشتن عمر رویداد و نتیجه واقعی showNotification را بررسی کنید.

در این مقاله:

• معنای پیام و چیزی که ثابت نمی‌کند
• چرا waitUntil برای عمر رویداد مهم است؟
• خطاهای نمایش اعلان و مسیر جایگزین
• تفاوت‌های مرورگر، iOS و اندروید
• چک‌لیست عیب‌یابی برای توسعه‌دهنده
• اگر بازدیدکننده سایت هستید
• پرسش‌های متداول

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

معنای پیام و چیزی که ثابت نمی‌کند

مرورگر هنگام اجرای بخشی از کار سایت در پس‌زمینه ممکن است متنی عمومی مانند این عبارت نشان دهد. این متن الزاماً متن ارسالی سرویس پوش نیست و نباید آن را معادل «اعلان با موفقیت نمایش داده شد» دانست. ممکن است سرویس‌ورکر رویداد را دریافت کرده باشد، اما به‌دلیل پایان زودهنگام اجرای کد، داده نامعتبر، مجوز مسدودشده یا شکست در ساخت اعلان، نتیجه قابل مشاهده نباشد.

سه مرحله را از هم جدا کنید:

1. تحویل رویداد: مرورگر رویداد پوش را به سرویس‌ورکر فعال می‌رساند.
2. پردازش: کد سرویس‌ورکر داده پیام را می‌خواند و گزینه‌های اعلان را می‌سازد.
3. نمایش: فراخوانی showNotification با مجوز و محدودیت‌های دستگاه اجرا می‌شود.

موفقیت مرحله سوم نیز به معنی خواندن اعلان توسط انسان نیست. در گزارش‌های Pushfa، تأیید نمایش پس از موفقیت showNotification ثبت می‌شود؛ این شاخص را نباید با کلیک یا مطالعه پیام یکی دانست.

چرا waitUntil برای عمر رویداد مهم است؟

سرویس‌ورکر برای رویدادهای پس‌زمینه دائماً در حال اجرا نیست. مرورگر می‌تواند پس از پایان تابع رویداد، فرایند را متوقف کند؛ بنابراین اگر نمایش اعلان یا خواندن داده را به یک Promise واگذار کرده‌اید، باید آن کار را با event.waitUntil() به عمر رویداد متصل کنید. در غیر این صورت، کد ممکن است در رایانه توسعه‌دهنده ظاهراً کار کند اما در دستگاه واقعی پیش از نمایش متوقف شود.

نمونه زیر فقط الگوی عمومی است و باید با ساختار payload و منطق پروژه شما تطبیق داده شود:

self.addEventListener('push', function (event) {
  const task = (async function () {
    let data = {};
    try {
      data = event.data ? event.data.json() : {};
    } catch (error) {
      data = {};
    }

    const title = typeof data.title === 'string' && data.title
      ? data.title
      : 'اعلان جدید';
    const options = {
      body: typeof data.body === 'string' ? data.body : '',
      data: { link: typeof data.link_url === 'string' ? data.link_url : '/' }
    };

    return self.registration.showNotification(title, options);
  })();

  event.waitUntil(task);
});

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

خطاهای نمایش اعلان و مسیر جایگزین

showNotification می‌تواند به علت‌های مختلف شکست بخورد: مجوز اعلان وجود ندارد، عنوان یا گزینه‌ها مقدار نامعتبر دارند، سرویس‌ورکر مورد انتظار فعال نیست، یا مرورگر اجازه نمایش در وضعیت فعلی را نمی‌دهد. استفاده از تصویر، آیکون یا داده‌ای که از شبکه خوانده می‌شود نیز می‌تواند سطح خطا را بیشتر کند.

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

• مقدارهای خالی عنوان و متن را پیش از فراخوانی پاک‌سازی کنید.
• برای تصویر اختیاری، شکست بارگذاری را از نمایش اصلی جدا کنید؛ تصویر نباید علت حذف کل اعلان باشد.
• اگر لینک در داده پیام وجود ندارد، یک مسیر امن و داخلی به‌عنوان مقدار پیش‌فرض در نظر بگیرید.
• خطای Promise نمایش را ثبت کنید، اما اطلاعات خصوصی کاربر یا کل payload را در لاگ عمومی ننویسید.

اگر چند کد مسئول نمایش هستند، فقط یکی را مالک رویداد بدانید. ترکیب یک SDK با سرویس‌ورکر سفارشی یا باقی‌ماندن فایل قدیمی می‌تواند باعث پردازش دوباره، نمایش متفاوت یا خطای غیرقابل پیش‌بینی شود. در استفاده از Pushfa، فایل ریشه pushfa-messaging-sw.js و قطعه کد دقیق ارائه‌شده در پنل سرویس را به‌کار ببرید؛ نام بسته، تابع یا مسیر دیگری را حدس نزنید.

تفاوت‌های مرورگر، iOS و اندروید

همه مرورگرها رفتار یکسانی برای رویداد پس‌زمینه و پیام‌های عمومی ندارند. در Safari و WebKit، پوش وب باید به اعلان قابل مشاهده منجر شود؛ حذف عمدی نمایش برای اجرای خاموش کار قابل اتکایی نیست. جزئیات رسمی WebKit درباره الزام اعلان قابل مشاهده را می‌توانید در راهنمای Web Push وب‌کیت بخوانید.

در iOS و iPadOS، وب‌پوش برای وب‌اپی که به صفحه اصلی افزوده شده، از نسخه ۱۶.۴ به بعد و پس از اقدام مستقیم کاربر قابل درخواست است. یک تب عادی مرورگر را با وب‌اپ صفحه اصلی یکی نگیرید؛ این تفاوت می‌تواند علت دریافت‌نشدن یا نمایش‌ندادن اعلان باشد. برای جزئیات این محدودیت، توضیح WebKit درباره Web Push در iOS و iPadOS را ببینید.

در اندروید نیز مجوز و تنظیمات سیستم دخیل‌اند. اندروید ۱۳ و نسخه‌های جدیدتر برای اعلان به مجوز زمان اجرا نیاز دارند و در اندروید ۸ به بعد، کانال اعلان و تنظیم کاربر در همان کانال می‌تواند نمایش را محدود کند. پس تست موفق در یک گوشی قدیمی، رفتار گوشی دیگر را تضمین نمی‌کند.

چک‌لیست عیب‌یابی برای توسعه‌دهنده

1. ثبت محیط: نام مرورگر، نسخه، سیستم‌عامل، حالت تب یا وب‌اپ و زمان رخداد را یادداشت کنید.
2. بررسی worker: در ابزار توسعه، فایل فعال، scope و وضعیت کنترل صفحه را با فایل مورد انتظار مقایسه کنید.
3. بررسی مجوز: مجوز اعلان سایت و تنظیمات کانال در اندروید را بررسی کنید؛ مجوز مسدودشده با تغییر کد رفع نمی‌شود.
4. بررسی payload: نوع داده، عنوان، متن و لینک را با یک پیام آزمایشی حداقلی بررسی کنید. داده‌های حساس را در لاگ نگذارید.
5. بررسی عمر رویداد: هر Promise مرتبط با پردازش یا نمایش باید از طریق event.waitUntil دنبال شود.
6. بررسی نتیجه: ردشدن Promise، خطای کنسول و نتیجه سرویس ارسال را جداگانه ثبت کنید؛ «ارسال شد» با «نمایش شد» یک شاخص نیست.
7. تست دستگاه واقعی: حالت فعال، پس‌زمینه، قفل صفحه، قطع و وصل شبکه و چند مرورگر پشتیبانی‌شده را جداگانه آزمایش کنید.

اگر هیچ رویدادی به سرویس‌ورکر نمی‌رسد، مسئله را در اشتراک، مجوز، ثبت توکن یا مسیر تحویل دنبال کنید و از راهنمای بررسی ارسال و دریافت‌نشدن وب‌پوش کمک بگیرید. اگر دستگاه در زمان ارسال آفلاین بوده است، اعتبار زمانی پیام را جداگانه بررسی کنید؛ راهنمای وب‌پوش در حالت آفلاین و TTL برای همین سناریو است.

اگر بازدیدکننده سایت هستید

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

اگر سایت مورد اعتماد است اما اعلان مورد انتظار را نمی‌بینید، زمان رخداد، نوع دستگاه، نسخه مرورگر و تصویر پیام را بدون داده شخصی برای پشتیبانی بفرستید. در صورت امکان، عنوان یا لینک خصوصی کمپین را در تصویر یا گزارش قرار ندهید.

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

آیا این پیام یعنی سایت هک شده است؟

خیر. متن به‌تنهایی چنین نتیجه‌ای نمی‌دهد و معمولاً یک پیام عمومی مرورگر است. دامنه، مجوزها و رفتار سرویس‌ورکر را بررسی کنید؛ اگر تغییرات مشکوک دیگری می‌بینید، موضوع را از مسیر رسمی همان سایت گزارش دهید.

آیا حذف اعلان یا بی‌صداکردن پوش مشکل را حل می‌کند؟

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

آیا waitUntil تحویل پیام را تضمین می‌کند؟

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