ترحيل WordPress إلى HubSpot

أيًا كان مسار الاستيراد الذي تختاره من المسارات الثلاثة، فجميعها يتوقف عند المدونة: صفحات الموقع وصفحات الهبوط (landing pages) وأي شيء آخر غير المنشورات يجب إعادة بنائه يدويًا داخل قوالب HubSpot ووحداته. موقع من 200 صفحة لا يتقلص إلى استيراد يعقبه تنظيف في النهاية؛ إنه إعادة بناء 200 صفحة، وينبغي أن يقول العرض ذلك بوضوح بدل أن تحمل كلمة «استيراد» افتراضًا لا تستطيع تأييده.

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

لا شيء في HubSpot يحل محل functions.php، لأنه لا يوجد تحته نظام hooks أو filters أصلًا. وكل ما كانت تفعله إضافة يجب أن يظهر من جديد على هيئة ميزة أصلية في HubSpot، أو تطبيق من Marketplace، أو وحدة مخصصة، أو دالة serverless، أو خدمة من طرف ثالث، بقرار واحد لكل إضافة، وتقول وثائق المطورين في HubSpot نفسها صراحةً إنها لن تغطي قالبًا مبنيًا حول إضافات معقدة.

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

تُبنى عادةً في WordPress أعضاء الفريق ودراسات الحالة والمواقع ودلائل المنتجات على هيئة custom post types، ولا يملك HubSpot مفهومًا مطابقًا لها. يمكن لجداول HubDB أن تحقق النتيجة نفسها بتوليد صفحة لكل صف برابطها وتحليلاتها الخاصة، لكن هذا المسار يتطلب Content Hub Professional ويقتصر على 10 صفحات ديناميكية لكل جدول؛ والبديل هو CRM custom objects، وهي تقع خلف فئة Enterprise بدلًا من ذلك.

الحل البديل: قرّر مبكرًا، لكل custom post type، هل سيصبح جدول HubDB أم كائنًا مخصصًا، لأن هذا القرار الواحد يحدد فئة الاشتراك التي يحتاجها المشروع كله. وتشغيل عدة custom post types جنبًا إلى جنب مع بيانات Advanced Custom Fields يجعله في الغالب مشروع Content Hub Professional بحد ذاته، وهذا جدير بأن يُعرض على من يملك الميزانية قبل إقرار عرض السعر لا بعده.

قالب WordPress مكتوب بـ PHP؛ وقالب HubSpot مكتوب بـ HubL، بوراثة قوالب خاصة به عبر extends، ومناطق السحب والإفلات الخاصة به المبنية من كتل widget_container، وتحميل أصوله الخاص عبر require_css وrequire_js وget_asset_url بدلًا من wp_enqueue_style وget_template_directory_uri. ولا ينتقل مطور PHP إلى ذلك مباشرة، ومطورو HubSpot أندر، وبصورة عامة أغلى في استقطابهم لإعادة البناء.

الحل البديل: حسم من سيتولى البناء فعلًا قبل كتابة عرض السعر لا بعده. فريق WordPress الحالي يحتاج وقتًا للتأهيل على HubL، ومكان ذلك الوقت في التقدير منذ البداية بدل أن يُمتص بصمت بعد أن يكون المشروع قد بدأ.

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

الحل البديل: افحص الموقع الحي (crawl) للحصول على جرد كامل للروابط قبل أن تبدأ إعادة البناء، وعامل مطابقة إعادة التوجيه جزءًا من البناء نفسه لا مهمة تُترك ليوم الإطلاق. وأبقِ موقع WordPress متاحًا في بيئة تجريبية (staging) للرجوع إليه طوال الفترة، وتوقع أن يستقر الأداء بعد أسبوعين إلى أربعة أسابيع من تحويل نهائي نُفّذ بصورة صحيحة.

لا يعمل أسرع مسارات الاستيراد الثلاثة إلا إذا كانت WordPress REST API العامة متاحة وغير معدّلة، وإضافات الأمان والإعدادات headless والروابط الدائمة المخصصة والتحصين المؤسسي العام تقيّد هذه الواجهة أو تعطلها بانتظام. وحين يفشل فإنه يميل إلى الفشل دون أن يخبرك لماذا، وهي اللحظة التي تتحول فيها مكالمة تحديد النطاق إلى تشخيص.

الحل البديل: اختبر WordPress connect على المدونة الحية أثناء مرحلة الاستكشاف (discovery)، قبل أن يصبح مفاجأة في أسبوع البناء بوقت طويل. الرجوع إلى smart copy ثم إلى تصدير XML مسار حقيقي للمضي قدمًا، لكن كل خطوة هبوط أقل دقة من سابقتها وتحتاج تنظيفًا أكثر، ومكان ذلك في التقدير فور استبعاد المسار الأول.

صفحة 404 وصفحة خطأ 500 ونتائج البحث ومطالبة كلمة المرور وصفحة تفضيلات الاشتراك، كلها تحتاج إلى بناء جديد في HubSpot، ولا تظهر أي منها في عدّ الصفحات المبني على خريطة الموقع (sitemap). ولهذا بالضبط تغيب عن التقدير وعن قائمة الإطلاق معًا، ولهذا لا تُلاحَظ الفجوة إلا بعد أن يكون الموقع قد صار حيًا.

الحل البديل: سمِّ كل صفحة نظام صراحةً في جرد القوالب عند تحديد النطاق بدل افتراض أن خريطة الموقع تحسب لها حسابًا. كل واحدة منها جهد قليل بحد ذاتها، ومجموعها أمر يسهل أن تُحرَج به إذا غاب يوم الإطلاق.

لم يُبنَ Content Hub يومًا منصةَ تجارة إلكترونية، ويغطي Revenue Hub المدفوعات وعروض الأسعار والفواتير والاشتراكات دون أن يتناول يومًا كتالوج المنتجات أو سلة التسوق أو الدفع أو الشحن أو الضريبة أو المخزون. ومتجر WooCommerce ببساطة لا مكان له ليُعاد بناؤه داخل HubSpot: هذا الجزء من الموقع لن ينتقل، أيًا كان ما تقوله بقية الخطة.

الحل البديل: أبقِ المتجر على منصة تجارة إلكترونية مخصصة وكامِل تلك المنصة مع HubSpot بدلًا من محاولة إعادة بنائه هناك، أو قل بوضوح إن الترحيل غير مناسب لموقع تقوده التجارة الإلكترونية. يمكن لمحتوى المنتجات وصفحات الأسعار أن تنتقل؛ أما واجهة المتجر نفسها فلا، ويستحق هذا التمييز أن يُذكر قبل الالتزام بأي شيء.

يقف Advanced Custom Fields خلف كل بناء WordPress يستحق الاسم تقريبًا، ويحمل بيانات حقول مهيكلة على المنشورات والصفحات وأنواع المنشورات المخصصة على حد سواء. لدى HubSpot حقول الوحدات (module fields) للمحتوى الذي ينتمي إلى قالب واحد وHubDB للبيانات الجدولية، لكن لا شيء يؤدي الدور الذي يؤديه ACF: حقول مخصصة اعتباطية تُرفق بأي سجل محتوى كان.

الحل البديل: صنّف كل مجموعة حقول ACF إلى حقول وحدات (module fields) حيث تنتمي البيانات إلى صفحة واحدة، أو أعمدة HubDB حيث تتكرر عبر السجلات. الحقول المتكررة (repeater) والمحتوى المرن (flexible-content) هي الحالة الصعبة فعلًا هنا وتحتاج عادةً إلى إعادة هيكلة لا مطابقة واحد لواحد، فاحسب لها ميزانية منفصلة عن الحقول الأبسط.

يتوقف Content Hub Free عند 25 صفحة، وتقع HubDB والمحتوى الذكي واختبارات A/B وتوصيات SEO والتقارير المخصصة كلها خلف فئة Professional؛ وتقع العضويات ودعم المواقع المتعددة والنطاقات الجذرية الإضافية والتقسيم (partitioning) خلف Enterprise فوق ذلك. وموقع لم يكلّف شيئًا يُذكر في استضافته على WordPress قد يحتاج إلى اشتراك Professional أو Enterprise لمجرد أن يفعل من جديد ما كان يفعله أصلًا، وهذه الفجوة جديرة بأن تُعرض على من يعتمد الميزانية قبل اكتشافها في منتصف البناء بوقت طويل.

الحل البديل: احسب الفئة المطلوبة من تدقيق الميزات وبنية المحتوى، ثم ضعها في العرض بعبارات واضحة. اكتشاف متطلب HubDB في منتصف البناء مشكلة تجارية للجنة التي تعتمد الإنفاق، لا مشكلة تقنية لمن يبني الموقع.

معالجات admin-ajax وأي PHP عشوائي من جهة الخادم لا مقابل مباشر لها في HubSpot. WP-Cron هو الاستثناء الوحيد الجدير بالمعرفة: يشغّل Data Hub Professional workflows مشغَّلة بجدول زمني باستخدام إجراءات الشيفرة المخصصة (custom code actions) بـ JavaScript أو Python، وهو نمط تصفه وثائق HubSpot نفسها بأنه كتابة cron jobs، وتغطي دوال serverless جزءًا إضافيًا منه ضمن حدود تنفيذها. وما يتبقى يحتاج إلى خدمة خارجية يُبحث عنها.

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

يخزن WPML وPolylang كلٌّ منهما الترجمات في بنية بياناته الخاصة ونظام روابطه الخاص، وجواب HubSpot، وهو مجموعة مترابطة من النسخ اللغوية لصفحة أو منشور، ليس له مسار استيراد من أي من الإضافتين. وموقع ثنائي اللغة بالعربية والإنجليزية مبني على أي منهما لا ينقل ترجماته؛ بل يعيد بناءها، وبنية الروابط تحتها ستتغير عادةً في أثناء ذلك.

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

تنصح HubSpot نفسها بعدم نقل الشيفرة الخاصة بـ WordPress، بما فيها أي شيء تحت wp-includes أو wp-content، وتوصي بإعادة تصدير رموز التتبع التابعة لأطراف ثالثة من المورّد نفسه بدل اقتطاعها من WordPress. ويجب إعادة رفع الوسائط إلى أداة HubSpot Files على حدة، مع توجيه كل إشارة إلى صورة داخل المحتوى إلى الموقع الجديد.

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

أعلى بنود الاكتشاف خطورة. اكشفها أثناء تحديد النطاق لا أثناء البناء.

أكّد الفئة المستهدفة قبل الوعد بفصل مكافئ.

المنشورات وحدها تُستورد عبر أي من المسارات الثلاثة؛ أما الصفحات، وهي الحصة الأكبر في معظم المواقع، فإعادة بنائها يدوية بالكامل

يفشل WordPress connect بصمت أينما كانت REST API معطلة أو مقيدة، وهذا شائع في الموقع المحصّن وقلّما يتضح قبل محاولة الاستيراد فعلًا

لا يوجد نظام إضافات ولا نظام hooks في جانب HubSpot أصلًا، فما كان functions.php يفعله لا مكان له يذهب إليه دون إعادة بناء

لا مقابل لـ custom post types في HubSpot، والقرار بين HubDB والكائنات المخصصة لكل واحد منها يحدد فئة الاشتراك التي يحتاجها البناء كله

يقع HubDB خلف Content Hub Professional؛ وتقع العضويات ودعم المواقع المتعددة والنطاقات الجذرية الإضافية خلف Enterprise فوق ذلك

صفحات النظام غير مرئية لعدّ الصفحات المبني على خريطة الموقع، ولهذا تغيب بانتظام عن التقدير وعن قائمة الإطلاق معًا

المنشور المستورد الذي ما زال يشير إلى رابط صورة تحت wp-content يستمر في العرض بلا مشكلة إلى أن تُطفأ استضافة WordPress، ثم ينكسر كله دفعة واحدة

إعادة التوجيه يدوية بالكامل وهي كل مخاطر SEO في هذا الترحيل؛ والتعجل فيها هو أكبر سبب منفرد لفقدان الترتيب بعد الإطلاق

لا يمكن إعادة بناء WooCommerce داخل HubSpot بأي شكل، ولا استثناء

حقول ACF المتكررة (repeater) والمحتوى المرن (flexible-content) تحتاج إلى إعادة هيكلة حقيقية لا مطابقة مباشرة، وهذا العمل يسهل التقليل من شأنه عند تحديد النطاق

لا ينتقل مطور PHP إلى HubL مباشرة دون وقت تأهيل، ومكان هذا الوقت في التقدير لا أن يُكتشف تأخيرًا بعد أن يبدأ البناء

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