أنا حاليًا أنقل بعض المحتوى من Dokuwiki (dokuwiki [DokuWiki]) إلى Discourse. بناء Dokuwiki ليس علامة markdown نظيفة، لذلك يحتاج إلى تحرير يدوي. عادةً ما أستخدم المحرر القديم حيث يمكنني رؤية جميع الأحرف هناك. ولكن مع المحرر القديم، أرى “تأثيرات قفز” غريبة: عندما تحدد كتلة نصية وتحاول تنسيقها، يقفز المؤشر لأعلى ولأسفل. إعادة تنسيق النص الأطول شبه مستحيلة بهذه الطريقة، حيث يجب عليك دائمًا إعادة تحديد موضع نافذة التحرير الخاصة بك مرة أخرى. من الصعب وصف ذلك، يمكنني فقط عرضه باستخدام تسجيلات الشاشة … تم وصف التأثير سابقًا في قفز المؤشر حول مربع نص المؤلف / المحرر
المحرر RTE لا يُظهر هذا التأثير. لكنني أفتقد خيارًا لتنظيف الكود غير المرغوب فيه المستورد من أنظمة أخرى …
إذا كان العدد أكثر من قليل، فمن المنطقي الحصول على نص برمجي للاستيراد للقيام بذلك. إذا لم يكن العدد كبيرًا، فمن المحتمل أن يكون من المنطقي الحصول على بعض التعليمات البرمجية لإصلاح علامة markdown بدلاً من محاولة تحريرها يدويًا. (حل آخر أكثر غرابة هو وجود إضافة لمعالجة تعديلات docuwiki).
ليس كثيرًا، ولكن ربما يكفي للتفكير في حل قائم على البرمجة النصية/البرمجة. الشيء الصعب هو أن الكود هو صيغة dokuwiki (wiki:syntax [DokuWiki]) بالإضافة إلى كود واجهة مستخدم محسّن من قالب bootstrap3 (https://getbootstrap.com). يبدو لطيفًا ولكني لم أفكر في ترحيل المحتوى عندما قمت بإعداده بهذه الطريقة. المشكلة الرئيسية ليست صيغة dokuwiki، بل أكواد bootstrap <div> … . مثال للكود:
<div class="level1"> </div> <h2 class="page-header pb-3 mb-4 mt-5">Plattenplatz ermitteln</h2> <div class="level2"> <p>Filtern auf ext4, was ist verfügbar?</p> <pre class="code"> root@tokoeka ~ # df -h -t ext4 --total Filesystem Size Used Avail Use% Mounted on /dev/mapper/pve-root 196G 39G 148G 21% / /dev/md0 486M 400M 57M 88% /boot /dev/mapper/pve-data 3.0T 560G 2.3T 20% /mnt/data /dev/mapper/pve-backup 414G 40K 393G 1% /mnt/backup total 3.6T 598G 2.8T 18% - </pre> <p> </p> <p>Filtern auf ext4, was wird genutzt?</p> <pre class="code"> root@tokoeka ~ # df -h -t ext4 --output=used Used 39G 400M 560G 40K 598G </pre> <p> </p> </div>
إذا قمت بلصق محتوى حافظة بنفس محتوى text/html هذا في وضع المحرر الغني، فستحصل على محتوى ينتج عنه تنسيق ماركداون التالي:
## تحديد مساحة القرص
التصفية حسب ext4، ما هو المتاح؟
```
root@tokoeka ~ # df -h -t ext4 --total Filesystem Size Used Avail Use% Mounted on /dev/mapper/pve-root 196G 39G 148G 21% / /dev/md0 486M 400M 57M 88% /boot /dev/mapper/pve-data 3.0T 560G 2.3T 20% /mnt/data /dev/mapper/pve-backup 414G 40K 393G 1% /mnt/backup total 3.6T 598G 2.8T 18% -
```
التصفية حسب ext4، ما هو المستخدم؟
```
root@tokoeka ~ # df -h -t ext4 --output=used Used 39G 400M 560G 40K 598G
```
إنه يفقد المعلومات التي لا نهتم بها (مثل divs، classes، إلخ)، ولكنه سيفهم hN أو pre أو أي شيء محدد في مخطط ProseMirror الخاص بنا، والذي يحترم ملحقات المحرر المختلفة الخاصة بنا التي تسجل تعريفات parseDOM التي يستخدمها محلل ProseMirror، بما في ذلك تلك الموجودة في مكونات السمات أو الإضافات.
أما بالنسبة للسؤال الأصلي:
أعتقد أنه عندما يقوم المحرر الغني بتحميل المستند، فإنه لا يكون نفس HTML هذا بعد الآن، أليس كذلك؟
لأن المنشور raw الذي يحتوي على كتل HTML يجب أن يتم عرضه كعقدة محرر تعليمات برمجية “تمر عبرها”:
