من ووردبريس إلى موقع ثابت باستخدام Claude Code: كيف أعدت بناء هذا الموقع في نصف يوم

كان هذا الموقع يعمل سابقًا على WordPress. أما الآن فهو مجرد مجلد من ملفات Markdown وسكربت بايثون من 183 سطرًا فقط، بناه وكيل برمجي يعمل بالذكاء الاصطناعي من تصدير ووردبريس خلال نصف يوم. هذه قصة كيف جرى ذلك، ولماذا لا تزال نفس طريقة العمل هي من يدير الموقع حتى اليوم.

ما تحصل عليه في النهاية

أولًا، الدليل — هذا هو ناتج الطرفية الفعلي من اليوم الذي اكتملت فيه إعادة البناء:

$ python3 _build/build.py
Built 15 files (7 projects, 3 pages, 4 categories).

خمس عشرة صفحة HTML كانت هي الموقع بأكمله وقت الترحيل: الصفحة الرئيسية، وأربع صفحات تصنيفات، وسبعة مقالات مشاريع، وثلاث صفحات معلومات. جميعها مُصيَّرة مسبقًا، وجميعها ملفات عادية، بلا أي كود يعمل على الخادم مع كل طلب.

ملف تصدير ووردبريس الذي جاءت منه كان بحجم 572 كيلوبايت ويضم 123 عنصرًا — مقالات وصفحات ومرفقات صور وكومة من المسودات المهجورة. سبعة مقالات حقيقية فقط نجت من الرحلة. البقية كانت فوضى تجاهلتها أداة الاستيراد عمدًا.

أما الآلة التي تبني كل هذا فتتسع في جدول واحد:

العنصر	عدد الأسطر
build.py (المولّد نفسه)	183
migrate.py (أداة الاستيراد التي تُستخدم مرة واحدة)	166
القوالب (5 تخطيطات صفحات)	139
الأجزاء الجزئية (التنقل، التذييل، البطاقة)	51
site.yaml (كل إعدادات الموقع)	36
serve.sh (المعاينة المحلية)	12
.htaccess (قواعد الخادم)	57
المجموع	644

أضف إلى ذلك CSS (322 سطرًا) وملف جافاسكريبت واحدًا (31 سطرًا فقط — مجرد زر لفتح قائمة التنقل على الجوال) ليبقى الموقع بأكمله أقل من 1000 سطر. بلا node_modules، وبلا إطار عمل بناء، وبلا ملف lockfile يثير المشاكل.

الجزء الأول: التخلص من ووردبريس

لم أكتب أيًا من هذا بيدي. وصفت لـ Claude Code ما أريده، فكتب هو أداة الاستيراد، ثم المولّد، ثم القوالب، بينما اقتصر عملي على مراجعة الناتج وقول "لا، اجعلها هكذا بدلًا من ذلك". طوابع الوقت على الملفات تؤكد ذلك: من لحظة الحصول على ملف التصدير إلى موقع مبني وقابل للتصفح في أقل من ساعتين. نصف يوم، لا عطلة نهاية أسبوع كاملة.

خط الأنابيب الذي استقر عليه العمل:

التصدير ومرآة الوسائط

يصدّر ووردبريس كل شيء عبر أدوات ← تصدير ← كل المحتوى. فتحصل على ملف WXR — وهو XML يحتوي مقالاتك وصفحاتك وتصنيفاتك وسجلات المرفقات. هذا هو المُدخَل الوحيد لأداة الاستيراد.

الشيء الوحيد الذي لا يتضمنه التصدير هو ملفات الصور نفسها، بل روابطها فقط. لذلك يُجلب مجلد uploads بشكل منفصل — عبر SFTP، أو مدير ملفات، أو مرآة بسيطة بأمر wget — إلى assets/uploads/، مع الحفاظ على بنية السنة/الشهر نفسها التي كان ووردبريس يستخدمها حتى تعمل الروابط المُعاد كتابتها بشكل صحيح.

ماذا يفعل migrate.py فعليًا

أداة الاستيراد تُستخدم مرة واحدة لكنها آمنة لإعادة التشغيل. لا تستخدم أي مكتبة XML — فقط تعابير نمطية (regex) على نص WXR، وهو أمر يبدو هشًا إلى أن تلاحظ أن XML الصادر عن ووردبريس منتظم جدًا، وأن البحث فيه بأمر grep أقصر بكثير من بناء محلّل كامل. لكل مقال، تسحب الأداة العنوان والـslug والتاريخ والنص والتصنيف والصورة البارزة، ثم:

• تتجاهل الفوضى — المقالات الفارغة وأي شيء عنوانه "(draft)…" لا يصل أبدًا إلى content/
• تُطابق التصنيفات مع مجموعة قصيرة ونظيفة من المفاتيح بدل أسماء ووردبريس الفوضوية
• تحلّ الصور البارزة عبر معرّف المرفق، وإن لم تجده تعود إلى أول صورة مرفوعة في نص المقال
• تعيد كتابة روابط الوسائط من wp-content/uploads/… إلى /assets/uploads/…
• تعيد كتابة الروابط الداخلية — الروابط الدائمة القديمة تصبح روابط أنيقة جديدة، باستخدام خريطة slug مبنية من كل مقال وصفحة
• تحذف تعليقات كتل Gutenberg وتزيل تمامًا كتل العرض الديناميكي — لأن خطوة البناء هي من تولّد قوائم التصنيفات الآن، فالكتل القديمة المدمجة ستبقى فقط تتقادم دون فائدة
• تولّد المقتطفات تلقائيًا — تحذف الوسوم وتقتصر النص على 160 حرفًا، وتستخدمه كنص للبطاقة ووصف meta

الجزء المثير للاهتمام: تخرج المقالات من الطرف الآخر كـHTML مُنظَّف من ووردبريس موضوع داخل ملف Markdown، وليس مُحوَّلًا إلى صياغة Markdown. المُصيِّر يمرّر HTML الخام كما هو، فلم يفقد المحتوى القديم شيئًا، بينما تُكتب المقالات الجديدة بصياغة Markdown عادية. كلاهما يُبنى بنجاح من نفس المجلد. أول مرة فتحت فيها ملف ".md" كان 90% منه وسوم HTML، ظننت أن شيئًا قد تعطّل. لم يكن كذلك.

ماذا يفعل build.py

هذا هو الجزء الذي يعمل إلى الأبد. يقرأ site.yaml لمعرفة التنقل والتصنيفات والروابط، ويقرأ كل شيء في content/، ويُصيّر كل ملف عبر قالب Jinja2 إلى مجلد حقيقي بداخله index.html — روابط نظيفة بلا حاجة لقواعد إعادة كتابة على الخادم. وإلى جانب الصفحات نفسها، ينتج أيضًا:

• شريط تنقل وتذييل مبنيَّين من البيانات — أضف تصنيفًا أو صفحة وسيظهر تلقائيًا
• عنوان ووصف meta ورابط canonical ووسوم Open Graph وTwitter لكل صفحة
• ملفات sitemap.xml وrobots.txt وweb manifest، تُعاد توليدها في كل تشغيل
• مرحلة تنظيف تحذف الناتج القديم أولًا، حتى لا يترك مقال أعيدت تسميته صفحة ميتة خلفه
• لا اعتماديات تشغيل إطلاقًا: خطوط مستضافة ذاتيًا، أيقونات SVG مضمّنة، ذلك الملف الصغير الوحيد من جافاسكريبت، لا شيء من أي CDN

إضافة مقال تعني: ضع ملف Markdown واحدًا في content/projects/، وشغّل عملية البناء. هذه هي طريقة العمل بأكملها.

معاينة، ثم نشر

المعاينة المحلية سكربت واحد — يبني، ثم يُقدّم الموقع. تصفّح كل صفحة قبل أن يقترب أي شيء من الاستضافة الفعلية.

./serve.sh
# builds, then serves the whole site at http://localhost:8099

النشر عبارة عن دفعة rsync موجَّهة بقائمة (manifest) تحدد بالضبط ما يُشحن (HTML وCSS وJS والصور والخطوط وملف .htaccess) وما يُمنع (سكربتات بايثون، ومصدر Markdown، وتصدير ووردبريس، والقوالب). إعدادات الخادم تضيف الضغط، وترويسات التخزين المؤقت، وترويسات الأمان، ومنعًا صارمًا لجلب أي ملف مصدر مباشرة — فحتى لو عرف أحدهم بوجود المولّد، لا يوجد شيء يمكن تنزيله.

الجزء الثاني: كيف يُصان هذا الموقع الآن

وهذا ما جعل إعادة البناء تستحق أن تُنجَز بإتقان: الموقع لم يعد يُصان يدويًا هو الآخر. نفس سير عمل الوكلاء الذي بناه هو من يبقيه محدَّثًا — بما في ذلك التحديث الذي تقرؤه الآن.

بدأت هذه المراجعة بسرب تدقيق. فريق تحقق من دقة كل صفحة منشورة ونقر على كل رابط خارجي؛ وفريق آخر جمع لقطات شاشة وحقائق تقنية دقيقة عن كيفية عمل الموقع. كل ذلك صُبَّ في مواصفة مكتوبة واحدة: ابنِ هذا، لا تختلق أرقامًا، ولا تنشر سرًا أبدًا.

من هناك تفرّع العمل — وكيل مسؤول عن البنية (تصنيفات، لغة ثانية، تمديدات محركات البحث)، ومصمّم، ووكيل كتابة لكل مقال، بما فيها هذا المقال. نموذج سريع يكتب مسودة كل صفحة انطلاقًا من ملف الحقائق الخاص بها. ثم نموذج أقوى يحرّرها من ناحية الأسلوب والدقة. بعد ذلك تأتي مرحلة تدقيق عدائية تحاول كسر النص — تعيد التحقق من الأرقام مقابل الحقائق المصدرية، وتنقر الروابط من جديد، وتبحث عن أي شيء يبدو مختلَقًا. أو، بصراحة، أي شيء يبدو وكأن ذكاءً اصطناعيًا كتبه. وهو، في هذه الحالة، ما حدث فعلًا.

أعطِ وكيلك هذه المهمة أيضًا

هل لديك موقع ووردبريس قديم لا تريد الاستمرار في ترقيعه إلى الأبد؟ هذه هي الوصفة التي أعطيتها لوكيلي. اشرح كل خطوة لوكيلك ودعه يكتب الكود.

1. صدِّر. لوحة تحكم ووردبريس ← أدوات ← تصدير ← كل المحتوى. ضع ملف WXR في مكان يستطيع الوكيل قراءته، مثل _build/source.xml.
2. انسخ الوسائط. انسخ wp-content/uploads/ من الاستضافة القديمة إلى assets/uploads/، مع الحفاظ على بنية السنة/الشهر.
3. اطلب سكربت ترحيل. يحلّل عناصر WXR، ويتجاهل المسودات والمقالات الفارغة، ويطابق التصنيفات مع قائمة قصيرة ونظيفة، ويحلّ الصور البارزة (مع الرجوع إلى أول صورة داخل النص إن لزم الأمر)، ويعيد كتابة روابط الرفع والروابط الداخلية، ويحذف تعليقات كتل Gutenberg، ويولّد المقتطفات تلقائيًا، ويكتب ملفات Markdown بترويسة frontmatter.
4. اطلب مولّدًا. يقرأ إعدادات الموقع ومجلد المحتوى، ويُصيّر عبر قوالب (أساسية، رئيسية، تصنيف، مقال، صفحة، وأجزاء تنقل/تذييل/بطاقة مشتركة)، وينتج مجلدات بروابط أنيقة، ويولّد sitemap.xml وrobots.txt وweb manifest.
5. أعد بناء التصميم من الصفر. لا تنقل CSS القالب القديم — ورقة أنماط واحدة نظيفة، وخطوط مفتوحة مستضافة ذاتيًا، وأيقونات SVG مضمّنة، وصفر طلبات خارجية.
6. عايِن كل شيء. سكربت من سطر واحد يبني ثم يُقدّم الموقع محليًا. انقر كل صفحة.
7. اكتب إعدادات الخادم. الضغط، ترويسات التخزين المؤقت، ترويسات الأمان، قواعد منع الوصول لملفات المصدر، وحل بديل للروابط بلا امتداد.
8. انشر بقائمة (manifest). ادفع الناتج عبر rsync، مع استبعاد صريح لمجلدات المصدر والسكربتات، ثم تحقق من أن الرابط الفعلي يُعيد الحالة 200.
9. احتفظ بملف التصدير. يبقى ملف WXR داخل المشروع — إعادة تشغيل سكربت الترحيل تعيد توليد مجلد المحتوى بنظافة كلما احتجت استيرادًا جديدًا.

القائمة الكاملة لاعتماديات التشغيل:

pip install jinja2 pyyaml markdown

هذا كل شيء.

مطبّات محتملة

• إن نسيت نسخ مجلد uploads فلن يحذّرك أحد. عملية البناء تنجح بينما كل صورة مصغّرة تُعيد الخطأ 404. تعلمتُ هذا بالطريقة الصعبة.
• الناتج والمصدر يتشاركان نفس المجلد. ملفات HTML المبنية تحطّ في نفس جذر المشروع الذي يضم مصدر بايثون وMarkdown — الفصل عند النشر يعتمد بالكامل على قائمة allow/deny. بدا الأمر معكوسًا في البداية، لكنه ما يبقي النشر مجرد عملية rsync بسيطة.
• إعادة تسمية تصنيف قد تترك مجلدًا ميتًا خلفها. خطوة التنظيف تحتوي على أسماء التصنيفات مكتوبة مباشرة داخلها. أعد تسمية أحدها في الإعدادات، وانسَ تلك القائمة، وسيبقى المجلد القديم منشورًا ويتيمًا.
• التواريخ تُرتَّب كسلاسل نصية، لا كتواريخ فعلية. لا مشكلة طالما كل تاريخ مكتوب بصيغة YYYY-MM-DD. اكتب واحدًا بشكل خاطئ وسيغرق أحدث مقالاتك بهدوء إلى القاع.