من Lovable إلى WordPress: مشروع يتحول إلى قالب حقيقي

مثال على التحويل من Lovable إلى WordPress مفتوح من الطرفين

كل ما يلي يصف تحويلًا من Lovable إلى WordPress أجريناه فعلًا. الأصل تطبيق Lovable: bruce-banner.lovable.app، وهو معرض أعمال لمصوّر. النتيجة هي bruce.html2wp.dev، وتعمل على WordPress. يمكنك الدخول إلى لوحة التحكم عبر /wp-admin باسم المستخدم demo وكلمة المرور demo.

أنتج التحويل خمس صفحات وخمس مقالات على القالب bruce-banner. هذا ضمن النسخة المجانية (Free)، التي تحوّل حتى خمس صفحات في كل تحويل ولا تحتاج إلى مفتاح. افتح الموقعين جنبًا إلى جنب قبل أن تكمل القراءة. يدور هذا المقال حول الفرق بينهما، لذلك يمكنك أن تقيسه بنفسك.

تحويلان آخران من Lovable مفتوحان بالطريقة نفسها. الأول spark-remix-kindred.lovable.app الذي صار terra.html2wp.dev، وهو متجر ملابس محبوكة على WooCommerce. والثاني bloom-echo-remix.lovable.app الذي صار soria.html2wp.dev، وهو موقع مصوّرة أعراس. بيانات الدخول إلى لوحة تحكم WordPress في المواقع الثلاثة هي demo / demo.

ما يحتاجه جهازك لنقل موقع Lovable إلى WordPress

البناء والعمل في المتصفح وكل الفحوصات تجري على جهازك. لا يذهب إلى الخدمة التي تولّد القالب إلا الناتج المبني. لذلك هذه ليست خدمة ويب ترفع إليها ملف ZIP، ولها متطلبات يجب أن تعرفها مسبقًا:

• Node 20 أو أحدث للبناء والسكربتات المحلية.
• Python 3 مع الحزمتين Playwright وPillow. يتحكم Playwright بمتصفح حقيقي، وبهذه الطريقة يتحول تطبيق React إلى HTML.
• Docker مع الأمر docker compose. يشغّل نسخة WordPress مؤقتة على جهازك، ويفحص المحوّل القالب فيها قبل أن تراه.
• php-cli، لأن كل ملف PHP يمر بفحص للصياغة قبل أن يدخل ملف ZIP.
• jq وcurl وbash وtar. يجب أن يكون WordPress الهدف بالإصدار 6.6 أو أحدث.

تفحص الإضافة كل هذا في الخطوة الأولى وتطبع قائمتين. الأولى تعرض ما تستطيع تثبيته بنفسها داخل مجلداتك. الثانية تعرض ما عليك أنت أن تقرره: Docker، وإصدار أحدث من Node، وتشغيل Docker. ولا تثبّت المجموعة الثانية أبدًا دون علمك.

تثبيت الإضافة

ننشر الإضافة مرتين، مرة لكل وكيل. السكربتات ورقم الإصدار متطابقة في Claude Code وCodex. اختر الوكيل الذي تستخدمه.

Claude Code

/plugin marketplace add iOSDevSK/html2wp-cc-plugin
/plugin install html2wp@html2wp

ثم نفّذ مرة واحدة في الطرفية (Terminal):

python3 -m playwright install chromium

Codex

codex plugin marketplace add iOSDevSK/html2wp-codex-plugin
codex plugin add html2wp@html2wp

لا يلزم أي إعداد آخر للنسخة المجانية: لا مفتاح، ولا تسجيل، ولا بطاقة دفع. إذا كنت تفضّل ألا تعمل في الطرفية، يمكنك تشغيل التحويل نفسه في تطبيق html2wp لسطح المكتب (دليل مع لقطات شاشة).

كيف تنقل مشروع Lovable إلى جهازك

عنوان الموقع المنشور ليس مدخلًا مدعومًا، وهذا مقصود. النسخة المأخوذة من صفحة منشورة تحتفظ بالنتيجة المعروضة فقط. وتضيع منها معرفة الكود المصدري: أي المسارات (routes) موجودة، وما المكوّنات، وماذا ينتج البناء.

لذلك المدخل مجلد. يزامن Lovable مشروعك مع مستودع على GitHub. اربط المستودع وانسخه إلى جهازك بأمر clone، فيصير المشروع عندك محليًا. أيا كان شكل واجهة Lovable هذا الشهر، فالمستودع هو ما تحتاجه: الملفات نفسها التي يبني منها Lovable الموقع.

git clone https://github.com/<you>/<your-lovable-project>.git
cd <your-lovable-project>

لست مضطرًا إلى تشغيل npm install أو البناء أولًا. التحويل يتولى ذلك بنفسه.

اكتب «convert this project»

في ذلك المجلد، وبعد أن تفتح وكيلك، اكتب:

/html2wp:html2wp

convert this project

لا توجد في Codex أوامر تبدأ بشرطة مائلة. بدلًا من ذلك اكتب له convert this project into a verified WordPress block theme، وسيجد المهارة (skill) بنفسه. مع Claude Code أو Codex، هذه الجملة هي التعليمات كلها. لا تكتب ملف إعدادات ولا تختار أمر بناء.

يستغرق Flash نحو 30 دقيقة وFull نحو ساعة، بحسب عدد الصفحات وسرعة جهازك. يعمل التحويل في الغالب دون تدخل منك، ويخبرك أين وصل بعد كل خطوة، فلا تتوقع صمتًا.

ماذا يحدث لكود React عند الانتقال من Lovable إلى WordPress

هذه هي الخطوة التي يضيفها مشروع Lovable.

تطبيق Lovable القديم (React وVite) فيه ملف index.html واحد. لا يحوي وسم body فيه إلا عنصرًا فارغًا يعمل داخله تطبيق React، ومعه وسم script، فلا يوجد ما يمكن تحويله. أولًا يبني المحوّل المشروع. ثم يمر متصفح حقيقي على كل مسار بينما يراقبه مسجّل. النتيجة HTML ثابت لكل مسار، وهو بالضبط ما تحتاجه بقية العملية. أما المشروع الأحدث على TanStack Start فيعرض صفحاته على الخادم أصلًا، ومع ذلك يبنيه المحوّل ويمر على كل مسار بالطريقة نفسها.

ما يلتقطه المسجّل

• الحالة التي لا توجد إلا بعد تشغيل JavaScript. الأكورديونات المفتوحة، ومحتوى القوائم المنسدلة، والفئات (classes) التي يغيّرها سكربت. يخزنها المسجّل كبيانات على العناصر، ويعيد تشغيلها مشغّل صغير عام (runtime). لا أحد يكتبها يدويًا من الذاكرة.
• عتبات التمرير بدقة البكسل. رأس الصفحة الذي يتغير عند scrollY > 40 يستخدم رقمًا اختاره شخص ما. يعثر المسجّل على هذا الرقم ويحدد موضعه بالضبط. أما التخمين التقريبي فسيغيّر رأس الصفحة في اللحظة الخطأ، وإلى الأبد.
• علاقات «لا يفتح إلا عنصر واحد». تفتح A ثم B. هل أغلق A؟ تسجيل كل عنصر وحده لا يجيب عن ذلك، لذلك يختبره المسجّل على حدة.
• حركات الظهور عند التمرير تبقى. يلتقطها المسجّل، ويعيد القالب تشغيلها تمامًا كما في الأصل. يبقى المحتوى ظاهرًا دون JavaScript، ولا يختفي العنصر إلا أثناء عمل المشغّل، ومع prefers-reduced-motion يتخطى القالب الحركة. نقيس تطابق 1:1 والصفحة ساكنة، بعد انتهاء الحركات.

ما لا يزيّفه

• السلوك الذي لم يستطع تسجيله يدخل قائمة. لكل صفحة قائمتها. اقرأها.

لهذه الخطوة فحص خاص بها، لأن أي فحص لاحق لا يراها. يلتقط المحوّل صورة شاشة لكل مسار وهو يعمل، ويقارنها بنسخته الثابتة الملتقطة بعرض 1440 و820 و390 بكسل. إذا اختلفتا تفشل الخطوة. كل خطوة لاحقة تقيس من النسخة الملتقطة إلى WordPress، لذلك أي عيب ينشأ هنا سيمر من جميعها.

الفحص الذي لا يمكنك تخطيه

عندما تنتهي الفحوصات الآلية، لا يكون التحويل قد انتهى بعد. يضع المحوّل كل صفحة في صورة واحدة بجانب أصلها، وتقرأ أنت كل صورة من أعلاها إلى أسفلها.

في أحد التحويلات غاب قسم كامل في أسفل الصفحة، وأظهرت المقارنة بالبكسل فرقًا لا يتجاوز 0.4%. صفحة كهذه تجتاز الفحص دون ذلك القسم. الفحوصات الآلية بطبيعتها لا ترى ثلاثة أنواع من العيوب. الأول عنصر تحكم يبدو مثاليًا لكنه لا يفعل شيئًا. الثاني قيمة مكتوبة مباشرة في الكود من الصفحة الوحيدة التي جاء منها القالب. الثالث أي شيء لا يظهر إلا بعد التمرير أو النقر أو إرسال نموذج.

افحص أيضًا إمكانية تعديل المحتوى، إلى جانب صحة مظهره. قد تتطابق الصفحة حتى البكسل، ومع ذلك يعجز المالك عن تعديل الأسئلة الشائعة أو شبكة الميزات فيها. رأينا هذا في موقع حي: أكورديون من خمسة أسئلة بدا مطابقًا، لكن لم يتح أي محرر تعديله. فحص ركّز على المظهر وحده سمح بمروره. لذلك تحقق في كل صفحة من أنك تستطيع تعديل كل مجموعة متكررة وكل كتلة نص من wp-admin.

تثبيت القالب

يظهر في مجلد مشروعك ملف ZIP للقالب، وبجانبه CONVERSION-REPORT.md. لا شيء غير ذلك. مجلد العمل الذي يحوي البناء يقع خارج مشروعك، في مجلد ذاكرة مؤقتة (cache)، فيبقى مستودعك نظيفًا. التقرير هو الاستثناء، لأن قارئه أنت. يذكر ما شمله التحويل، وما وجده الفحص، وكل تحذير (بما فيها التحذيرات المقبولة)، وما بقي مفتوحًا.

في WordPress، اذهب إلى «المظهر ← قوالب ← أضف جديد ← رفع قالب» (Appearance → Themes → Add New → Upload Theme)، واختر ملف ZIP وفعّله. القالب مستقل بذاته. الصفحات والمدونة والنماذج والقوائم وSEO وإعادة التوجيه كلها من كوده هو. لا يحتاج إلى أي إضافة ليعمل، ولا يتصل أبدًا بأي خادم تابع لنا.

تعديل الموقع بعد نقله من Lovable إلى WordPress: ثلاثة طرق

تصبح مقالات المدونة مقالات WordPress عادية، فتكتبها في محرر الكتل فورًا. أما نص الصفحات فيبقى في HTML الخاص بك، ولتعديله يوجد خياران يستحقان المعرفة. أحدهما أداة بناء صفحات.

إذا كنت تحوّل الموقع كي يبقى التصميم، فأداة بناء الصفحات هي بالضبط ما يدمّره. نقل التصميم يدويًا إلى أداة بناء هو الخطوة التي يتوقف بعدها الموقع عن مشابهة التصميم، ولهذا وجد هذا المحوّل. أما إذا كان التصميم مجرد نقطة بداية، والعميل سيعيد بناء نصفه في الربع القادم على أي حال، فأعطه Elementor.

Lite أم Pro، إن اخترت Visual Edit

تعمل دردشة AI في Pro بمفتاح API الخاص بك. لا نبيعك رموزًا (tokens)، وتدفع تكلفة استخدامها مباشرة لمزوّدك.

Lovable أم WordPress؟ لا يلزمك الاختيار

عادة يطرح الناس المسألة كخيار بين أمرين. لكن موقع المحتوى لا يفرض هذا الخيار. تصنع في Lovable تصميمًا بسرعة. وفي WordPress يعيش الموقع سنوات ويعدّله شخص آخر. يحتفظ التحويل بالميزة الأولى وينقل الموقع إلى الثانية. يعمل القالب على أي استضافة WordPress، فلم يعد على الموقع أن يبقى حيث بنيته.

ما ينتقل هو الموقع: الصفحات والمدونة والنماذج والقوائم وSEO وإعادة التوجيه. وما لا ينتقل هو التطبيق الذي خلفه: تسجيل الدخول وقاعدة البيانات واستدعاءات API الخاصة بك. إذا كان مشروعك في Lovable معظمه من هذا النوع، فأبقه في Lovable. المتجر يقع في المنتصف. مع ترخيص Pro يصير كتالوجه متجر WooCommerce، كما حدث مع Terra Studios.

كم يكلّف التحويل من Lovable إلى WordPress وما الذي يرفضه

النسخة المجانية (Free) متاحة للجميع، دون مفتاح ودون تسجيل: ثلاثة تحويلات بخمس صفحات لكل منها وخمس إعادات تشغيل إجمالًا. يحسب الرقمان لكل عنوان IP، لذلك يحصل المكتب الذي يتشارك عنوانًا واحدًا على حصة واحدة للجميع. النسخة المجانية مخصصة لتجربة الأداة والمواقع الشخصية والعمل غير التجاري.

ترخيص Pro يلغي حد الصفحات ويجعل التحويلات وإعادات التشغيل غير محدودة. ويضيف أيضًا الخطوة التي تحوّل المتجر إلى WooCommerce. هذه الخطوة غير موجودة في النسخة المجانية إطلاقًا: يرفض التطبيق التحويل المجاني لموقع فيه متجر رفضًا تامًا، ولا ينفّذ نصفه. سعر Pro هو 49 يورو شهريًا أو 490 يورو سنويًا، والأسعار في صفحة الأسعار. خلال النسخة التجريبية (بيتا) تكون الدفعة الأولى أرخص بنسبة 30%، ويصلك المفتاح بالبريد الإلكتروني.

من المفيد أن تعرف حالتي رفض مسبقًا. مشروع React لا توجد مساراته إلا لكل سجل (/product/:id دون بيانات لعرضها) هو تطبيق ويب، وليس موقعًا يحوّل. يرفضه المحوّل علنًا بدل أن يسلّم نسخة عشوائية واحدة من القالب. وهذه نسخة تجريبية: الفحوصات تلتقط معظم الفروق، لا كلها. لهذا السبب يبقى الفحص صفحة بصفحة جزءًا من العملية، وليس لمسة تجميلية اختيارية.

تجد دليلًا للعملية كلها خطوة بخطوة في توثيق تطبيق html2wp. وتحويلات Lovable الثلاثة التي يمكنك فتحها من الطرفين موجودة في المثال في بداية هذا المقال.