من شبه المؤكد أن هذا بسبب Discourse فقط. إنهم ببساطة لا يرسلون إشعارات إذا كنت قد استخدمت الموقع قبل عدد معين من الدقائق. ولكن مع عدم وجود طريقة للمستخدمين النهائيين لرؤية ذلك، فإن هذا يجعل الإشعارات غير جديرة بالثقة. لكنني أؤكد لك، لقد تلقيت إشعارات دفع لنظام iOS لكلا هاتين الرسالتين. يمكن أن تعمل، طالما أنك تعلم أنه لا يجب الوثوق بها أبدًا.
أعتقد أن المشكلة عكسية. عدم استخدام الموقع على هاتفي مؤخرًا بما فيه الكفاية يبدو أنه يوقف تلقي أي إشعارات.
ربما، لكننا جميعًا نخمن فقط. الشيء الرئيسي الذي نحتاجه هو أن يوفر Discourse تسجيلًا كافيًا للمستخدمين النهائيين. ما هي الإشعارات التي أرسلها Discourse؟ ما هي الإشعارات التي قرر Discourse عدم إرسالها؟
عندما يتلقى تطبيق الويب التقدمي (PWA) إشعارًا، يُسمح له بتسجيل ذلك محليًا في IndexedDB على الجهاز. يحتاج المستخدمون إلى أن يكونوا قادرين على عرض هذا السجل، ومقارنته بالسجل الخاص بالخادم، لمعرفة متى/إذا أرسل Discourse الدفعة ولكن الجهاز لم يتلقاها.
ولكن، بشكل عام، أود أن أقول: لا تفترض أن المشكلة خطأ Apple، وخاصة لا تفترض أن مجرد انتظار iOS 18 سيساعد. نحتاج إلى أن يقوم Discourse بالعمل هنا، وإلا فلن يتحسن أي شيء أبدًا.
هذا يبدو وكأنه تسجيل مطول جدًا بالنسبة لي:
تسجيل مطول هنا، ربما يكون سهلاً بما فيه الكفاية:
"تم تخطي إخطار سام بـ “الحمولة” لأن سام كان متصلاً بالإنترنت.
ولكن إذا كنت تريد فقط تصحيح هذا، فلماذا لا تضبط SiteSetting.push_notification_time_window_mins على 0؟
ثم يصبح المستوى التالي من التسجيل مطولاً جدًا جدًا:
- تم تخطي الإخطار بسبب تمكين المستخدم لـ “عدم الإزعاج”
- انتهاء مهلة موفر إشعارات الدفع discourse/app/services/push_notification_pusher.rb at cacaa90f4d01452358322ea8b5564f15f4816c74 · discourse/discourse · GitHub
- انتهاء صلاحية الاشتراك
- خطأ في الاستجابة
الكثير من الأشياء المختلفة يمكن أن تحدث بشكل خاطئ… على الرغم من أنه في أي وقت يمكنك على الأرجح استخدام DE للتحقق: ابحث في جدول push_subscriptions عن اشتراكات دفع الويب المحدثة.
إعجاب واحد (1)
اسمحوا لي أن أبدأ بالقول إنه من وجهة نظري، تكمن المشكلة في أن الناس يكتبون هنا وفي منتدىي، قائلين “أعتقد أن إشعارات الدفع لا تعمل بشكل صحيح”، ويشارك مستخدمون آخرون، قائلين، “نعم! أنا أيضًا! يجب أن تكون الإشعارات معطلة/غير موثوقة”. أحيانًا يلومون Apple، وأحيانًا يلومون Discourse، لكنهم جميعًا يتفقون على أن إشعارات الدفع الخاصة بـ Discourse غير موثوقة.
أود أن أكون قادرًا على التحقيق في هذه الحالات بنفسي، قائلاً “لم تتلق إشعار الساعة 12:31 مساءً على هاتفك، وهذا هو السبب…”، لكنني لا أعتقد أن ذلك ممكن حاليًا.
نعم، يمكن أن تحدث الكثير من الأشياء المختلفة، بما في ذلك الأشياء من جانب العميل، والتي لا يمكنني التحقيق فيها في DE.
- هل تلقى Service Worker حدث الدفع؟
- هل قام Service Worker باستدعاء
showNotification؟ - هل تم منح إذن
showNotification، أم أنshowNotificationلم تحقق شيئًا؟ - هل كان الجهاز نفسه مضبوطًا على “عدم الإزعاج”؟
أود بشدة الحصول على بعض الوثائق للمسؤولين تشرح كيفية استخدام DE لتشخيص فشل الدفع، على الأقل فيما يتعلق برؤية ما إذا كان الإشعار قد تم إرساله.
لكنني أعتقد أنه سيكون من المفيد للغاية الاحتفاظ بسجل على جانب العميل يمكن للمستخدمين إرساله إليّ، مما يسمح لي بالمقارنة مع سجل DE.
أولاً، نصف الأشخاص الذين يشتكون من هذا على الأقل ليسوا مسؤولين عن منتداهم. لهذا السبب نحتاج إلى أن يقوم Discourse بتنفيذ هذا:
ولكن، نعم، أشك في أن ضبط هذا على 0 سيقضي على 80٪ من شكاوى “إنه لا يعمل”.
بشكل عام، ثقة المستخدم في إشعارات Discourse منخفضة جدًا. كلما كان هذا الموضوع أكثر قابلية للبحث للمسؤولين (وحتى للمستخدمين النهائيين)، زادت موثوقية إشعارات Discourse.
4 إعجابات
أنا مرتبك بعض الشيء بشأن هذه الجزئية، نحن ندفع إلى عنوان URL مباشرة من الخادم…
هذا هو منطقي. انظر إلى ما يقوله المستخدمون في هذا الموضوع.
يبدو أن هذه المشاركات تشير إلى أن المشكلة قد تكون خطأ Apple. ربما يقوم Discourse بالدفع إلى عنوان URL، ولكن بعد ذلك، لسبب ما، لا تقوم Apple بتسليم الدفعة. لماذا يمكن أن يكون ذلك؟
- ربما تُرجع Apple رمز 4xx أو 5xx لوظيفة الدفع، وتحتاج Discourse إلى إعادة الدفع.
- ربما تلقت Apple الرسالة، ولكنها غير قادرة (أو غير راغبة؟) في تسليم الرسالة إلى الجهاز.
- ربما تلقى الجهاز الرسالة، ولكن Apple لا تقوم بتشغيل حدث
pushللعامل الخدمي. - ربما تلقى العامل الخدمي حدث
push، ولكنه يحتوي على خطأ ولم يستدعshowNotification(ربما ليس هذا، سيكون واضحًا جدًا…؟) - ربما تلقى العامل الخدمي حدث
pushواستدعىshowNotification، ولكن Apple رفضت عرض إشعار مرئي. هناك في الواقع العديد من الأسباب التي قد تحدث بها هذه المشكلة:- تم ضبط الجهاز على عدم الإزعاج (ولكن يجب أن يظهر الإشعار في النهاية في مركز الإشعارات، في هذه الحالة، أعتقد)
- تم منح الإذن في وقت ما، ولكن تم إلغاؤه الآن (يمكن لتطبيق الويب التقدمي اكتشاف هذه الحالة وتسجيلها!)
- قد يكون المستخدم قد قام بتكوين التطبيق بإعدادات إشعارات غريبة، لذلك يقوم فقط بالدفع إلى مركز الإشعارات ولكنه لا يعرض لافتة
- … أو ترفض Apple عرض الرسالة لسبب آخر متعلق بالسياسة (ربما يعتقدون أن الإشعار هو بريد عشوائي؟)، وربما يكونون أكثر تساهلاً في إصدار مستقبلي من iOS
وهذا لا يأخذ في الاعتبار أيًا من الأسباب التي قد لا ترسل بها Discourse نفسها الإشعار (عدم الإزعاج، مرشحات الدفع، push_notification_time_window_mins).
إذا كان كل ما يمكننا قوله هو: “حسنًا، في الساعة 12:31 مساءً، أطلق Discourse إشعارًا بالمعرف XXX إلى Apple، وأعادت Apple رمز حالة 201 Created، ولكن ليس لدينا فكرة عما حدث بعد ذلك”، فلن يتمكن هؤلاء المستخدمون/المسؤولون من التحقيق بشكل أكبر. سنضطر فقط إلى إلقاء اللوم على Apple والتخلي عن إشعارات الدفع. (“ربما ستعمل إشعارات الدفع عبر الويب لنظام iOS 18 في عام 2024.”)
بدلاً من ذلك، نحتاج إلى أن نكون قادرين على القول: “تُظهر سجلات جهازك أنه في الساعة 12:33 مساءً، استيقظ العامل الخدمي بحدث دفع للإشعار بالمعرف XXX، واستدعى showNotification، ويمكننا رؤية عبر واجهة برمجة تطبيقات الإشعارات أن Apple تقول إن الإذن لـ showNotification لهذا الدفع XXX قد تم منحه.”
(أعتقد أيضًا أنه يجب أن يكون هناك زر “إرسال إشعار اختبار” في صفحة https://meta.discourse.org/my/preferences/notifications يسمح لك بجدولة إشعار في المستقبل، على سبيل المثال، بعد N دقائق أو N ساعات، مما يسمح للمستخدمين باختبار حالة “لا يعمل بعد بضع ساعات”.)
3 إعجابات
من جهتي، لم أتمكن من إعادة إنتاج هذا على موقع الاختبار الخاص بي. الإشعارات تعمل هناك دون مشكلة. المشكلة هي موقع الإنتاج الخاص بي. تتوقف الإشعارات عن العمل كل بضع ساعات في كل مرة أقوم فيها بتمكينها. نظريتي الوحيدة هي أن حجم إشعارات الدفع قد يكون مشكلة؟ موقع الإنتاج الخاص بي نشط للغاية ولديه أكثر من 50 ألف عضو، لذلك يتم إرسال الكثير من الإشعارات إلى حساب المستخدم الخاص بي (وبشكل عام).
لذا قمت أنا و @WorldIsMine بإجراء تجربة صغيرة.
- انتظرنا حتى توقفت إشعاراته عن العمل
- تحققنا من أن اشتراك الدفع الخاص به لا يزال في جدول
push_subscriptions
- أرسلت إشعار دفع من وحدة تحكم rails وتأكدت من تسجيل جميع الاستثناءات
u = User.find(1)
payload = { excerpt: "Test", "translated_title": "Test!" }
PushNotificationPusher.push(u, payload)
- لم يكن هناك استثناء
- لم يستلمها
- (للتحقق مرة أخرى، تمكنت من إرسال إشعار دفع لنفسي)
إذًا، هل هذا شيء من طرف Apple؟ ماذا يمكن أن يكون؟
5 إعجابات
هل لديكم إمكانية الوصول إلى جهاز Mac لاختبار Safari على نظام macOS؟ ستتمكنون من إعداد أدوات المطور لتصحيح أخطاء عامل الخدمة هناك.
إعجاب واحد (1)
على حد فهمي، لا توجد خدمة عامل متضمنة هنا.
لا، تتطلب جميع إشعارات دفع الويب عامل خدمة على نظام iOS. Sending web push notifications in web apps and browsers | Apple Developer Documentation
حسنًا، هذا خارج نطاق خبرتي، للأسف ليس لدي أي خبرة في هذا الأمر من جانب العميل، ولا جهاز ماك تحت تصرفي.
على الأقل استبعدنا الأمور المتعلقة بالخادم.
آها! أعتقد أنني اكتشفت خطأ واحدًا على الأقل في هذا، تم تقديمه في موضوع منفصل.
7 إعجابات
على الرغم من أنني كنت آمل أن يؤدي إصلاحك إلى تحسين الأمور، إلا أنني لست متأكدًا.
تم نشر Meta معها لمدة أسبوع. لقد قمت بتمكين الإشعارات المباشرة على تطبيق الويب التقدمي الخاص بجهاز iPhone الخاص بي. اليوم… توقفت عن العمل.
تم إنشاؤه في 5 يناير.
سأحاول تصحيح هذا باستخدام نص برمجي لمعرفة ما الذي يؤدي إلى تعطله ومدة استمراره، ولكن الكثير يشير هنا إلى أن Apple لديها ببساطة خطأ من نوع ما.
كلما فكرت في هذا أكثر، كلما اعتقدت أن Discourse Hub هو الحل الآن لأجهزة Apple.
3 إعجابات
شكراً لتتبعك هذا!
هل نقرت على أي إشعارات؟ أسأل لأنني أتساءل عما إذا كانت Apple تقوم تلقائيًا بإيقاف إشعارات الويب إذا تلقيت عددًا معينًا منها دون النقر على أي منها.
إعجاب واحد (1)
لا نزال بحاجة إلى هذه الميزات لتحليل حالات الفشل:
- تعليمات حول كيفية استخدام مستكشف البيانات لرؤية سجل إشعارات الدفع.
- سجلات على الجهاز، بحيث يمكننا استخراج هذه السجلات وربطها بالسجلات من جانب الخادم.
يجب أن تتضمن السجلات الطوابع الزمنية لجميع أحداثpush، بما في ذلك الحمولة الكاملة، بالإضافة إلى حالةNotification.permission - زر “إرسال إشعار اختبار” يقوم بتكوين إشعار للمستقبل بعد N دقيقة/ساعة.
6 إعجابات
ملاحظة، إشعارات PWA الخاصة بي تعمل بشكل جيد خلال الأسابيع الثلاثة الماضية على meta
8 إعجابات
إليك تحديث مقلق، يشير إلى أننا نواجه المزيد من المتاعب في هذا الجبهة:
3 إعجابات
للعلم، الأخبار التي أوردها @nathank أعلاه قد تم تأكيدها بالكامل من قبل Apple.
في عمل من أعمال الامتثال الخبيث الصارخ لقانون الأسواق الرقمية للاتحاد الأوروبي، الذي يهدف إلى جلب المزيد من الانفتاح والمنافسة إلى المنصات الرقمية، قررت Apple إنهاء تطبيقات الويب التقدمية (PWAs) في الاتحاد الأوروبي مع متصفح Safari iOS 17.4 القادم.
سيؤدي هذا إلى منع تثبيت تطبيقات الويب التقدمية (PWAs) على الشاشة الرئيسية، واستخدام الإشعارات الفورية، والمزامنة في الخلفية، وسيتداخل مع التخزين دون اتصال بالإنترنت وغير ذلك. وسيكون له تأثير عالمي يتجاوز مجرد الاتحاد الأوروبي، نظرًا لأن الشركات ستكون أقل احتمالًا للاستثمار في تطبيقات الويب، وتطبيقات الويب التقدمية (PWAs) على وجه الخصوص، إذا لم يتمكن مستخدمو iPhone في الاتحاد الأوروبي من استخدامها.
يجب أن أفترض أن هذا سيكون عائقًا كبيرًا للعديد من مجتمعات Discourse و Discourse نفسها. إذا كان هذا هو الحال بالنسبة لأي شخص، فإنني أوصي بشدة بملء هذا الاستبيان من مجموعة Open Web Advocacy. إنهم يقودون المعركة ضد هذا، ويعملون على إبلاغ فريق قانون الأسواق الرقمية بجميع الآثار المترتبة على هذه السياسات وغيرها على تطوير الويب. إنهم يحاولون بشكل عاجل جمع شهادات وبيانات من الشركات التي ستتأثر بهذه التغييرات، حتى يتمكنوا من تزويد قانون الأسواق الرقمية بمعلومات أفضل لمقاومة ذلك.
يرجى زيارة هذه الصفحة لمعرفة المزيد، وملء استبيانهم حول كيفية تأثير هذا على عملك، ونشر الكلمة! سيكون من الرائع بشكل خاص إذا تمكن Discourse من إطلاع مستخدميه على التغيير القادم، حتى يتمكن كل منهم من التواصل مع OWA لشرح كيفية تأثير ذلك على أعمالهم ومجتمعاتهم.
7 إعجابات