ربما يمكن إصلاح ذلك باستخدام CSS. هل لا يظهر أبدًا، أم يمكنك التمرير للأعلى لرؤيته؟ ما هو المتصفح ونظام التشغيل الذي تستخدمه؟ ربما يمكننا جعله ثابتًا في الأعلى. المشكلة هي أن بعض المتصفحات حاولت مؤخرًا أن تكون “إبداعية” ونقلت شريط المتصفح إلى الأسفل.
المتصفحات هي Firefox و Chrome على نظام أندرويد في هاتف موتورولا. يحدث نفس الشيء مع تطبيق Discourse.
شريط الأزرار موجود دائمًا، لكنه يظهر أسفل قائمة منبثقة عندما يكون التحديد في أول 3 أسطر ظاهرة في مربع النص.
من الحلول الممكنة إدخال 3 أحرف سطر جديد (CR/LF) قبل النص الأول. ثم احذف هذه الأسطر الإضافية قبل النشر.
إعجاب واحد (1)
نعم، لقد جربته للتو. أفهم ما تقصده. الأمر مزعج للغاية. لكنني أعتقد أن الأشرطة في الأسفل أسوأ حتى. كما أنني بحاجة إلى البحث عن كيفية القيام بذلك، ولا يتم دفع أجرة لي مقابل ذلك. لكن على الأرجح توجد طريقة أنظف للقيام بذلك. أنا أراهن أن مشاريع أخرى تواجه نفس المشكلة وأن هناك حلاً معياريًا. لكن كما قلت، لدي أولويات أخرى. آسف على الصراحة 
تعديل: ملاحظة فقط. توجد طريقة لتعطيل النقر بالزر الأيمن (النقر المزدوج على الهاتف المحمول). https://stackoverflow.com/questions/381795/how-to-disable-right-click-context-menu-in-javascript لكن بعد ذلك لا يستطيع المستخدمون النسخ. الأمر فوضوي…
3 إعجابات
الحل البديل ممكن، لكنه غير مريح فقط.
ربما توجد طريقة باستخدام CSS للجوال لتجنب هذا الإزعاج. سأقوم بالبحث عنها.
إضافة الكثير من الكود لهذه الحالة الخاصة لن يكون استخدامًا جيدًا لوقتك واهتمامك. (بالإضافة إلى أنه يزيد من الحمل.) شكرًا لمشاركتك مشاريعك مع المجتمع. لقد كان ذلك سخيًا جدًا منك.
3 إعجابات
حسناً، شكراً جزيلاً على التقرير. لقد قمت بإصلاحه للتو
6 إعجابات
نصيحة فقط: تضيف أطر عمل Rails الطريقة .present? في بعض فئات Ruby، وهي أفضل من المقارنة مع السلاسل النصية الفارغة. تعمل هذه الطريقة بشكل أساسي مع المصفوفات والسلاسل النصية.
كما توجد الطريقة .empty? وهي عكس .present?.
5 إعجابات
أزلت هذا الزر عمدًا لأن الصور يجب أن تُحمّل عبر المحرر. لكنني اكتشفت للتو أن قائمة اختيار الملفات لا تظهر على متصفح Firefox للأندرويد لسبب ما. للتحقيق في هذا الأمر، يتعيّن عليّ تثبيت أداة تصحيح الأخطاء عن بُعد، لذا سيستغرق إصلاح الأمر بعض الوقت. حتى ذلك الحين، ما عليك سوى استخدام المحرر المتقدم لرفع الصور.
تعديل: في الواقع، يعمل الأمر بشكل مثالي. لم يكن الزر يفتح فقط لأنني رفضت سابقًا منح التطبيق صلاحية الوصول إلى الكاميرا. لذا يمكنك ببساطة استخدام زر رفع الصور نفسه الذي تستخدمه على سطح المكتب. انظر إلى لقطة الشاشة التي رفعتها للاختبار إذا كنت مرتبكًا:
https://cidian.social/t/file-upload-from-mobile/292
إعجاب واحد (1)
أريد تمكين خيارات العريض، المائل، الرابط، ورفع الصورة فقط داخل شريط الأدوات. كيف يمكنني فعل ذلك؟
إعجاب واحد (1)
سأضيف خيارًا لتكوينه بمجرد الانتهاء منه.
4 إعجابات
هل يعني ذلك عدم وجود حل بديل لهذه المشكلة؟ ألا يمكنني تعديل ملف إعدادات CKEditor المستخدم داخل الإضافة؟
هل ستقوم بجعله يعمل مع إضافات أخرى مثل Image Annotation، و BB markup، وغيرها؟
3 إعجابات
حسناً، دعني أوضح نقطة: عندما أتحدث عن «أشياء لا تعمل»، فأنا أعني فقط أنها لا تُعرض في نافذة الإدخال WYSIWYG. فكل شيء يعمل بشكل صحيح في المنشور النهائي. هذا المحرر مجرد طريقة مختلفة لكتابة Markdown في الوقت الحالي، والنتيجة النهائية تبقى Markdown. من منظوري، فإن الاعتماد على «HTML فقط» هو المسار الصحيح للمستقبل. فـ Markdown وBBCode وما شابهها أصبحت من الماضي، حيث تقدم تجربة مستخدم معقدة بشكل مفرط. لكن بالطبع، لن أقوم بتنفيذ كل ميزات BBCode أو الإضافات المخصصة، لأنني لا أحصل على أي فائدة من ذلك. أولاً وقبل كل شيء، أهتم بحالة الاستخدام الخاصة بي، لكنني أيضاً أهتم بتبسيط تجربة المستخدم في Discourse للآخرين. إذا كنت تحب Markdown وBBCode وجميع هذه «العلامات» في محررك، فقد لا يكون هذا الخيار مناسباً لك.
أود أيضاً أن تصبح هذه المناقشة أكثر بناءً. سأكون سعيداً للاستماع إلى حالات الاستخدام والأسباب التي تدفع الناس لاستخدام محرر WYSIWYG بدلاً من المحرر الحالي. كما أنني مهتم بمعرفة الفوائد التي تتوقعونها من هذا التغيير والأهداف التي ترغبون في تحقيقها.
ربما يمكن أن يقودنا ذلك إلى نتيجة إيجابية. فعبارة «هل يمكنك فعل كل هذه الأمور العشوائية؟ … (مجاناً)» ليست مفيدة.
مع أطيب التحيات،
Spirobel
6 إعجابات
هل صحيح أن التحول إلى HTML وعدم دعم Markdown سيجعل جميع المنشورات التي تم إنشاؤها بصيغة HTML غير قابلة للتعديل بمجرد إيقاف تشغيل الإضافة؟
إعجاب واحد (1)
@spirobel، على الرغم من أنني شخصيًا لا أستخدم إضافتك، إلا أنني أعجب بوظيفتها وأحييك على جهدك الكبير!
رغم أنني أتفق على أن bbcode هي صيغة قديمة، إلا أن فكرة أن Markdown أصبحت من الماضي غير صحيحة من وجهة نظري - بل العكس تمامًا، فالمجموعة الأساسية من الميزات ستبقى لسنوات طويلة.
السببان الرئيسيان هما:
- التنسيق أثناء الكتابة - يمكنك تنسيق النص بشكل صحيح بمجرد الكتابة، مما يسهل التركيز والكتابة بإنتاجية.
- قابل للقراءة حتى دون معالجة - بناء جملة Markdown الأساسي مفهوم بديهيًا كنص خام، وهو أمر مفيد جدًا لعدة أسباب.
المشكلة تظهر عندما تحاول توسيع ميزات Markdown (مثل الصور والجداول وما إلى ذلك)، فأعتقد أنها تميل إلى التعثر وأحيانًا تنهار بسبب بناء جملة غير مقروء وصعب الكتابة.
من وجهة نظري، فإن أفضل المحررات تقدم نوعًا من الحل الهجين:
- تنسيق بناء الجملة الأساسي يُعرض مدمجًا مع إبقاء أحرف بناء الجملة مرئية في وضع التحرير.
- الميزات الموسعة (مثل الصور والجداول) يجب أن تُعرض أيضًا في وضع التحرير، وربما لا يتم تمثيلها بأحرف بناء الجملة الفعلية على الشاشة. وربما، جاز لي القول، يجب اعتبارها إضافات يتم تخزينها بتنسيق يناسب نوع البيانات.
6 إعجابات
شكرًا جزيلاً لك على تعليقك!
أفهم ما تقصده، لكنني ما زلت أختلف معك. 
على المدى الطويل، يُخدم المستخدمون المتقدمون بشكل أفضل باستخدام الاختصارات. على سبيل المثال، يمكن أن يكون هناك اختصار للتحوير (الخط المائل). لذا يمكنك الضغط على الاختصار وأنت لا تزال تكتب. وقد يكون الاختصار شيئًا مثل CTRL+*، مما يجعله قريبًا جدًا من استخدام Markdown.
بشأن النقطة 2، يمكنني القول إن HTML مقروءة أيضًا لأنها تُعرض دائمًا (في المتصفح)، وإذا نظرت إلى جزء من HTML في محرر نصوص، يمكنك قراءته أيضًا. حسنًا، قد يبدو Markdown أجمل قليلاً، ولكن فقط إذا التزمت بالميزات الأساسية جدًا، وعندها لا يهم الأمر على أي حال.
الحل الهجين غير قابل للتطبيق للأسف. أحد الأسباب التي جعلتني أؤمن بـ “HTML فقط” هو أنه يسمح لي بالتركيز على بناء واجهة مستخدم بدلاً من الحصول على دكتوراه في اللسانيات الحاسوبية أثناء تصحيح أخطاء محلل اللغة. الفكرة هي تقليل الدين التقني وليس زيادته.
في النهاية، أستطيع أن أفهم تمامًا وجهة نظرك. لقد قرأت أيضًا النصائح حول Markdown. لكن بالنسبة لي، نموذج “HTML فقط” أكثر إقناعًا لما أعتزم القيام به. أدرك أيضًا أنه لا فائدة من محاولة إقناع الأشخاص الذين يحبون Markdown حقًا. يجب عليهم البقاء مع المحرر كما هو الآن. لكنني أعتقد أن هناك جمهورًا مختلفًا قد يهتم باتخاذ مسار مختلف. هذا الإضافة (plugin) هو أكثر بكثير من مجرد محرر WYSIWYG. لدي هذه الرؤية لاستخدام Discourse لبناء برمجيات تتيح للناس تحرير البيانات المهيكلة بشكل جماعي دون الحاجة إلى تعلم لغة تنسيق. إذا نظرت إلى مشاريع كبرى مثل ويكيبيديا أو ويكاموس وجميع الإجراءات الرسمية المتضمنة في المساهمة فيها، فأرى قدرًا هائلاً من الإمكانات المهدرة. أريد تغيير ذلك. وإذا أردت تغيير ذلك، فيجب أن أستفيد من الميزات التعاونية في Discourse مع التخلي عن مفهوم الحاجة إلى لغة تنسيق لإدخال البيانات في النظام.
أفهم سبب استخدام Markdown في Discourse في البداية، والأسباب جيدة حقًا. لكن أهدافي مختلفة، لذا أتبع أيضًا نموذجًا مختلفًا.
5 إعجابات
ممتاز، إضافة رائعة، @spirobel! هذا بالضبط ما يحتاجه مستخدمونا غير التقنيين، وأعتقد أنه سيعزّز سير العمل في موقعنا بشكل ملحوظ. شكرًا لك على الوقت والجهد الذي بذلته في تطويرها. لاحظت بعض المشكلات التي قد تكون مفيدة
تضارب مع Shared Edits
لقد قمت للتو بتثبيت هذه الإضافة بالإضافة إلى Discourse Shared Edits. ومن غير المفاجئ إلى حد ما أنهما يتعارضان قليلاً. لكن يبدو أن الأمر قابل للإصلاح. هل تفكر في العمل على جعلهما متوافقين؟ شخصيًا، أرى أن كلًا منهما لا غنى عنه في المستقبل.
ما يحدث هو أنه عند تعديل مشاركة منشور باستخدام المحرر الأساسي، يتم مسح النص الموجود في المنشور ولا يمكن استرداده إلا من خلال التراجع عن التعديل.
@mentions لا تظهر الاقتراحات
يبدو أن محرر Discourse الأساسي يعطل وظيفة الإشارة (@mention) جزئيًا. عندما أحاول الإشارة إليك هنا، أرى ما يلي:
عند تفعيل المحرر الأساسي، تتوقف الاقتراحات عن الظهور. وينطبق ذلك أيضًا إذا قمت بالتبديل إلى “التحرير المتقدم”.
6 إعجابات
نعم، لا يزال هذا العمل قيد التطوير. لقد أضفت الإشارات إلى قائمتي. لم ألقِ نظرة على التحرير المشترك بعد، لكنه بالتأكيد ممكن التنفيذ. ومع ذلك، قد لا يتحقق ذلك من خلال ضمان التوافق مع إضافة التحرير المشترك. التغيير الذي يقدمه المحرر الأساسي كبير جدًا، لذا فمن المرجح أن يكون الحل داخل المحرر الأساسي نفسه.
4 إعجابات
هل تحدثت مع @sam بشأن ذلك؟ قد يكون مهتمًا بهذه الإمكانية، وهو بالتأكيد سيقدّم نصائح حكيمة.
إعجاب واحد (1)