هذا المكون الإضافي يعطي حاليًا أخطاء 500 ويمكن أن يؤدي إلى فقدان البيانات. لقد قمت بتعطيله بعد وقوع حدث مماثل. يؤسفني أنني لا أستطيع تقديم المزيد من المعلومات الآن. فقط أنه لم يكن من الممكن تعطيله بمجرد تمكينه.
لا أعتقد أنه تم تحديثه بعد تحديثات الملحن الشاملة على مدار العام الماضي.
شخصيًا، أود أن أرى بعض الاهتمام به حيث سيكون من الجيد جدًا البقاء في Discourse للتحرير التعاوني.
هل يعطي أخطاء ويفقد البيانات أيضًا عند استخدام محرر markdown، أم أنه يحدث فقط في محرر rich text؟
هناك عدد قليل من الإضافات التي لن تعمل في محرر rich text، ويبدو أن هذه واحدة منها.
تعديل: لقد قمت بتثبيته لتجربته ولم أتمكن من إعادة إنتاجه، حتى باستخدام محرر rich text. لم أحاول التحرير مع مستخدم آخر، لكنني تمكنت من تمكين التحريرات المشتركة وتحرير المنشور، ورؤية التغييرات تظهر في الوقت الفعلي. ما هي خطوات إعادة الإنتاج للحصول على أخطاء 500 وفقدان البيانات؟
مكتبة OT التي نستخدمها خشنة جدًا، وعادة ما تعمل بشكل جيد ولكن في بعض الأحيان عندما تصبح المستندات طويلة هناك حالات مرضية.
الخطة هي الانتقال إلى تطبيق يعتمد على CRDT، على الرغم من أنه ليس لدي جدول زمني بعد.
لمن يرغب في الاطلاع على مستقبل التعديلات المشتركة (Shared Edits)، لدي طلب سحب (PR) قيد العمل هنا:
إنه يحل المشكلة المذكورة في المنشور الأصلي (OP) ومجموعة من المشكلات الأخرى، ولكنه سيستغرق بعض الوقت ليتم دمجه نظرًا لأن التغييرات واسعة النطاق للغاية.
شكراً لك @sam، سأكون سعيدًا باختبار هذا على نصوص أكبر في بيئة آمنة. في الواقع، فقدان أجزاء كبيرة من النص هو بالضبط سبب توقفي عن استخدام هذا المكوّن الإضافي، لذا يسعدني العودة إليه.
ما زلنا نستخدم HedgeDoc لتجنب أي مشاكل، ولكن هناك مشكلة هناك عندما يكون مؤشران في نفس النقطة: يصبح التحرير غير موثوق به، خاصة إذا كان الشخص الآخر يحاول القيام بشيء ما، ثم تحدث حالة سباق. أقول هذا فقط في حال صادفت هذا الأمر في الكود الخاص بك.
(لاحظ أنني قد لا أتمكن من الاختبار قريبًا، حيث أنني في إجازة.)