بعد إجراء بعض التجارب، لاحظت أن بعض منشوراتي لا تعرض الصور حتى قبل إجراء أي عملية ‘إعادة تعيين’.
بدلاً من ذلك، تظهر أيقونة صغيرة للصورة، تُظهر مسار الصورة عند تمرير الماوس فوقها، وتعرض الصورة فقط عند النقر عليها.
وتختفي هذه الأيقونة أيضًا (ويبدأ ظهور مساحة بيضاء أو عنصر نائب للصورة مكانها) إذا قمت بـ ‘إعادة بناء HTML’ من قائمة النقاط الثلاث، أو حتى إذا قمت بأي عملية ‘إعادة خبز’ من داخل الحاوية.
يرجى التكرم بإرشادي.
إذا لم تقم بإجراء إعادة تعيين خريطة (remap) ولا تزال حزمة S3 الخاصة بك تعمل بشكل طبيعي، فلا يجب أن يكون قد تغير شيء عما كان عليه من قبل. هل كانت تلك الصور تعمل من قبل قبل أن تبدأ في هذه الرحلة؟
نظريًا، ستفقد الاتصال بملفات الصور فقط إذا قمت بإيقاف تشغيل حزمة S3 الخاصة بك أو قمت بإعادة تعيين الخريطة (remap) بشكل غير صحيح.
شكرًا.
لاحظت أن أيقونة الصور تُظهر المسار /bucket/uploads/optimized/folder/… (وبما أنه لا توجد صورة بهذا المسار، فإن الصورة لا تظهر، بل تظهر الأيقونة فقط).
ولكن عند النقر على أيقونة الصورة تلك، تظهر الصورة/يتم تقديمها من مجلد ‘Orig’، أي /bucket/uploads/original/…
لا أعرف كيف يمكن لصورة واحدة أن تحتوي على مسارين مختلفين مخزنين لها؟!!
على أي حال، أصبحت المشكلة الآن هي: كيف يمكنني العثور على المنشورات التي تحتوي على صور مرتبطة بمسار خاطئ (تحت ‘optimized’)؟ لكي أستطيع تصحيح/إعادة تعيين عناوينها إلى المسار الصحيح تحت ‘Original’.
شكرًا لك @nathank، @Pravi، و@itsbhanusharma. بما أنني أخلط بين مشاكل/مشاهد مختلفة، فأنا أجد نفسي حاليًا في الوضع التالي:
بعض منشوراتي لا تعرض الصور التي تم رفعها إليها، بل تظهر إما أيقونة صغيرة تحتوي على رابط/عنوان خاطئ لحوض التخزين (bucket) عند تمرير الماوس فوقها. أو، تظهر بعض الصور بشكل صحيح مع مسار الحوض الصحيح فقط عند النقر على تلك الأيقونات الصغيرة. أما بعض المنشورات الأخرى فلا تظهر صورها على الإطلاق، بل يظهر مجرد مساحة بيضاء فارغة.
وعندما قمت بتشغيل عملية إعادة تعيين (remap) باستخدام الأمر (remap wrongbucketurl correctbucketurl)، وجدت في منشور واحد تم اختياره كعينة أنه على الرغم من أن الأيقونة الصغيرة استُبدلت بالصورة الصحيحة (مما جعلني سعيدًا)، إلا أنه في اليوم التالي اختفت الصورة تمامًا، حتى الأيقونة لم تعد موجودة. وبدلاً منها ظهرت مساحة بيضاء فارغة. لذا اضطررت لاستعادة موقعي الإلكتروني إلى حالة اليوم السابق.
عند تشغيل هذا الأمر، كانت النتيجة كالتالي:
# rake posts:missing_uploads
Looking for missing uploads on: default
19 post uploads are missing.
19 uploads are missing.
6 of 7792 posts are affected.
لم قمت بعد بنقل ملفاتك إلى التخزين المحلي. لقد تفحصت موقعك ولا يزال عنوان URL الخاص بـ S3 موجودًا.
الأمر يشبه هذا:
./launcher enter app
discourse remap //bxyzbucket1.s3.dualstack.ap-south-1.amazonaws.com/uploads/ /uploads/default/
discourse remap //bhdisco.s3.dualstack.ap-south-1.amazonaws.com/uploads/ /uploads/default/
rake posts:rebake
لقد جربت العديد من متغيرات هذه العملية عدة عشرات من المرات، ولا تزال لا تعمل.
لا تظهر صورنا باستخدام S3 لأن الإدارة قررت عدم رغبتها في وجود سلة S3 ذات وصول عام، لذا نحتاج إلى العودة إلى التخزين المحلي.
في البداية، تفحصت الروابط المعطلة ومن خلال ذلك تمكنت من تحديد القيم التي أحتاجها لاستخدامها في إعادة التوجيه (كنت أظن ذلك)، والآن تعمل مجموعة من الصور. لكن معظمها، أقول أكثر من 90%، لا يعمل. وعلى عكس حالة الروابط المعطلة من S3 حيث يمكنك على الأقل فحصها للبدء في معرفة ما يحدث خطأ، كل ما أحصل عليه هو هذا:
هل يعرف أحد ما الذي قد يسبب فشل هذه الصور؟ لقد علقت في هذا الأمر منذ أيام. أجد الأمر لا يصدق أن: أ) لا توجد طريقة للعودة مرة أخرى، وب) أن شخصًا ما (ليس أنا) قام بنقلنا بينما لا توجد طريقة للعودة.
وللتوضيح، لقد اتبعت العملية الموصوفة أعلاه من قِبَل @nathank. لقد جربت ذلك عدة مرات، مع اختلافات طفيفة في المسارات في خطوة إعادة التوجيه، لأنني غير متأكد مما إذا كانت تلك التعليمات عالمية أم تعتمد على شكل دليلك (دليلنا يحتوي على العديد من الدلائل الفرعية التي تم نسخها بنجاح من S3 باستخدام خطوة مزامنة S3).
سأقدر حقًا أي مساعدة، فأنا على وشك أن أتفكك من الإحباط.
أعتقد أن ما تريد فعله هو تفعيل خيار include_s3_uploads_in_backups المخفي، ثم عمل نسخة احتياطية واستعادتها (أنصحك بتجربة ذلك أولاً على خادم اختبار جديد). هذا ما يحدث عندما يلغي عميل CDCK اشتراكه، حيث يمكن استعادة تلك النسخ الاحتياطية إلى موقع مستضاف ذاتيًا جديد دون أي مشاكل.
مرحبًا جاي، شكرًا على الرد، واعذرني على جهلي هنا، لكن كيف يمكنني تفعيل ذلك؟
عذرًا. شيء مثل
./launcher enter app
rails c
SiteSettings.include_s3_uploads_in_backups=true
exit
exit
لقد حاولت فعل ذلك، لكنني حصلت على:
NoMethodError: الطريقة غير المحددة
include_s3_uploads_in_backups=' للوحدة SiteSettings من (pry):1: فيpry’
ثم أدركت أنني ربما كان علي إعادة تفعيل تحميلات S3 لأنني كنت قد أوقفتها، لكنني ما زلت أحصل على نفس الخطأ.
آه، نحن نستخدم حاويتين، وأنا أشغل هذا في web_only. أمر Rails غير موجود في حاوية البيانات، لذا أفترض أن هذا هو النهج الصحيح.
يبدو أن الأمر كان يجب أن يكون:
SiteSetting.include_s3_uploads_in_backups=true
نفذت هذا الأمر ثم أنشأت نسخة احتياطية جديدة. استعدت من تلك النسخة الاحتياطية، لكن لا يوجد أي تغيير — لا تزال معظم الصور تعرض أيقونة التالف المذكورة أعلاه. حاولت إعادة بناء الحاويتين أيضًا، لكن هذا لم يُحدث أي فرق.
عند تنزيل ملف النسخ الاحتياطي المضغوط وفحصه، تتأكد من أن جميع الملفات موجودة بالفعل، وبعد الاستعادة تكون مرئية في نظام الملفات. لكن Discourse يرفض ببساطة التعرف عليها وعرضها.
للتوثيق، نجحتُ في النهاية في حل هذه المشكلة. بدأت من جديد (أي من لقطة لنظرة instance الخاصة بي)، وأنا متأكد إلى حد كبير أن العملية التي نجحت في النهاية كانت كالتالي:
SiteSetting.include_s3_uploads_in_backups=truediscourse remap لتحديث الإحالات إلى مواقع ملفات S3 المختلفة الخاصة بي إلى موقع محليشكرًا لـ @pfaffman على توجيهي إلى الاتجاه الصحيح هنا.
تعديل
ربما من الجيد أن أثير هذا الأمر. بعد منشوري السابق، أدركت أن ست موضوعات لا تزال تحتوي على صور معطلة (على الرغم من أن الغالبية العظمى تعمل بشكل صحيح الآن).
هذه هي أقدم ستة منشورات لدينا، وجميع الصور الأصلية كانت لها عنوان URL مختلف لـ S3 مقارنة بباقي الصور. من الواضح أن هذا ليس مجرد صدفة. لذا، تحققت من أن جميع هذه الملفات موجودة في مجلد uploads/default/original/1X، وهي موجودة بالفعل. ثم نفذت أمر remap باستخدام عنوان URL الفريد هذا لـ S3 - ويبدو أنه عدّل العدد الصحيح من المنشورات. ثم أعيدت خبز المنشورات وإعادة بناء الحاويات، لكن هذه الموضوعات لا تزال معطلة. هل لدى أحد أي فكرة عن سبب فشل عدد قليل منها بهذه الطريقة؟
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.