من موقع HTML إلى WordPress المخصص: دراسة حالة لـ Exportimportdept.com

في 9 مارس 2026، اتصل بي Mas Bagus من PT Milenial Solusi Internusa، أو MSI Freight، لمناقشة موقع الملف الشخصي لشركتهم على exportimportdept.com.

لم يكن الطلب الأولي مجرد إنشاء مظهر جديد. أرادت MSI موقعًا إلكترونيًا يكون أكثر استعدادًا للتسويق وتحسين محركات البحث.

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

كانت خطتي الأولية هي إعادة بناء موقع الويب باستخدام GeneratePress وGenerateBlocks.

ومع ذلك، خلال اجتماع عبر الإنترنت، أطلعني فريق MSI على موقع HTML الذي صمموه وطوروه بأنفسهم.

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

وكانت النتيجة 13 صفحة تعتمد على موقع HTML مع الحفاظ على تصميمه.

خلف تلك الصفحات كان هناك نظام محتوى WordPress، وترحيل 32 مقالة، و346 301 قواعد إعادة توجيه للحفاظ على استمرارية عناوين URL القديمة.

ملخص قصير

حالة البداية: التصميم موجود بالفعل، ولكن سير العمل لم يكن جاهزًا

كان لدى MSI بالفعل موقع ويب يحتوي على معلومات الخدمة ومحفظة ومقالات وصور ومقاطع فيديو وصفحة اتصال.

كانت المشكلة هي أن موقع الويب لم يكن جاهزًا بعد ليكون بمثابة أساس طويل المدى للتسويق وتحسين محركات البحث.

بعض المراجع المتاحة كانت أيضًا نسخًا احتياطية للواجهة الأمامية. لم أبدأ بكود مصدر كامل وقاعدة بيانات يمكن نقلها ببساطة.

ولهذا السبب، كان يجب أن تبدأ عملية إعادة البناء من خلال قراءة الهيكل الحالي والتصميم المرئي.

من مناقشاتنا الأولية، كانت حاجة MSI واضحة: يحتاج الزوار إلى فهم خدمات الشحن الخاصة بهم بسهولة أكبر.

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

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

لذلك يحتاج موقع الويب الجديد إلى تسهيل قياس التفاعلات مثل WhatsApp والمكالمات الهاتفية والنماذج.

لماذا تغيرت خطة GeneratePress؟

كان GeneratePress وGenerateBlocks لا يزالان خيارين معقولين لموقع ويب خاص بالشركة والذي يحتاج إلى أساس خفيف الوزن ومرن.

ولهذا السبب كانت خطتي الأولية.

ومع ذلك، فإن موقع HTML الذي أظهره لي فريق MSI يحتوي بالفعل على الاتجاه المرئي الذي أرادوه.

تحتوي الصفحة الرئيسية على قسم رئيسي يحتوي على صورة حاوية، وعنوان كبير، وألوان العلامة التجارية باللونين الأزرق والبرتقالي، ولوحة تتبع الشحنة، ومعلومات مكتبية بالقرب من الأسفل.

إذا واصلت اتباع النهج القائم على القالب وأعدت تصميم كل شيء من البداية، فقد كان هناك خطر من أن تبتعد النتيجة النهائية عن التصميم الذي وافقت عليه MSI بالفعل.

سيكون هناك أيضًا عمل إضافي لإعادة تفسير التخطيط والتباعد والمكونات والتسلسل الهرمي المرئي.

ولهذا السبب أوصيت بموضوع مخصص يتكيف مع موقع HTML.

لم يكن القرار لأن GeneratePress أو GenerateBlocks كانا سيئين. كان ذلك لأن متطلبات المشروع كانت بالفعل أكثر تحديدًا من مجرد اختيار موضوع جاهز.

النطاق النهائي: 13 صفحة بناءً على موقع HTML

بالنسبة للنطاق النهائي، قمت بإنشاء 13 صفحة استنادًا إلى بنية موقع HTML المقدمة من فريق MSI.

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

بالإضافة إلى تلك الصفحات، يحتاج موقع الويب أيضًا إلى العديد من أنواع المحتوى حتى لا تعود إدارة المحتوى إلى لغة HTML الأولية.

لقد قمت بإعداد هياكل للخدمات وعناصر المحفظة والمقالات وجداول التصدير والاستيراد بناءً على احتياجات MSI التشغيلية.

تحتوي قائمة الخدمات على حقول وبيانات تعريفية يمكن إدارتها من لوحة المعلومات بدلاً من HTML الخام.

يقوم محرر خدمة LCL بفصل البيانات التعريفية للبطل والرائد وSEO وإعدادات التنقل عن قالب الواجهة الأمامية.

كان هذا القرار مهمًا لأن الصفحات الثابتة والمحتوى المتكرر لهما احتياجات إدارية مختلفة.

يجب أن تحافظ الصفحات الرئيسية على تخطيطها، في حين يجب إضافة المقالات والخدمات وعناصر المحفظة والجداول الزمنية أو تحديثها بانتظام.

تحتوي المحفظة أيضًا على محرر خاص بها للصور المميزة والمعارض والفئات ومعلومات المشروع.

تسمح حقول المحفظة للفريق بإضافة مشروع جديد دون إعادة بناء التخطيط من البداية.

بناء السمة المخصصة والكتل المخصصة

لقد استخدمت السمة المخصصة للتحكم في الأساس المرئي والقوالب والرأس والتذييل والأنماط التي يجب أن تظل متسقة.

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

في العرض التوضيحي الذي قدمته لفريق MSI، بدأت الصفحة الرئيسية بمنطقة محتوى فارغة، بالإضافة إلى الرأس والتذييل والدعوة إلى اتخاذ إجراء قبل التذييل.

يمكن للفريق بعد ذلك إضافة أقسام باستخدام الكتل المتاحة، وتغيير النص، أو عناوين URL، أو الصور، أو مقاطع الفيديو، وإعادة ترتيبها بالسحب والإفلات.

يمكن تحرير الصفحة الرئيسية في محرر القوالب بينما يستمر البطل وCTA ولوحة التتبع في اتباع التصميم المتفق عليه.

وهذا فرق مهم بين الحفاظ على التصميم والحفاظ على طريقة عمل HTML. ظل التصميم هو المرجع المرئي، لكن إدارة المحتوى انتقلت إلى سير عمل WordPress أكثر عملية.

حيثما أمكن، أبقيت أيضًا وظائف موقع الويب منفصلة عن الموضوع.

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

تتعامل الطبقة الوظيفية MSI Core مع CPTs والإعدادات وكتل Gutenberg ونماذج الأسعار والمتطلبات الخاصة بموقع الويب.

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

تغطي الإعدادات العامة العلامة التجارية وعناوين المكاتب والتذييل والأقسام الأخرى المستخدمة عبر موقع الويب.

تم استخدام محرر الكتلة أيضًا لمنطقة شعار العميل والشريك. يمكن لفريق MSI إدارة ترتيب الشعار واستبدال الصور وإضافة نص بديل من نفس المحرر.

تتم إدارة سحابة الشعار ككتلة تحتوي على صورة أكثر تنظيمًا وسير عمل النص البديل.

وكانت المقايضة هي أن الموضوع المخصص يتطلب المزيد من التطوير ووقت ضمان الجودة في البداية.

في المقابل، تلقت MSI نظامًا يناسب تصميمها بشكل أوثق ولا يتطلب مجموعة من التجاوزات لإجبار سمة عامة على اتباع موقع HTML.

بناء SEO ومؤسسة المحتوى

قبل بدء التطوير الكامل، قمت بإعداد تحسين محركات البحث وبنية المحتوى للسوق الإندونيسية.

لم يكن هذا البحث يدور حول العثور على الكلمات الرئيسية ذات الحجم الأكبر فقط. كنت بحاجة للتأكد من أن الكلمات الرئيسية تتوافق مع خدمات MSI، ولها هدف بحث واضح، ويمكن تحويلها إلى صفحات مفيدة.

طريقة البحث عن الكلمات الرئيسية

لقد استخدمت Semrush كمصدر البيانات الأساسي. تم تعيين قاعدة البيانات على إندونيسيا، وتم إرسال ملحق اختيار الكلمات الرئيسية الأساسي إلى MSI في 22 يوليو 2026.

لقد استخدمت Semrush للعثور على أشكال الكلمات الرئيسية ومراجعة بيانات الحجم المتاحة. مازلت أتعامل مع الحجم كتقدير مقدم الخدمة، وليس كعدد مطلق مضمون لعمليات البحث كل شهر.

بعد الحصول على القائمة الأولية، قمت بالتحقق من صحتها يدويًا من خلال بحث Google وSERP. لقد نظرت إلى الصفحات التي ظهرت، ونوع المحتوى الذي استخدمته، والغرض من البحث، وما إذا كان Google يعرض في كثير من الأحيان صفحات الخدمة أو المقالات لاستعلام معين.

لقد قمت أيضًا بمقارنة الأنماط التي تستخدمها مواقع الويب التي تظهر في SERP مع مراجع الصناعة. لم يكن الهدف هو تقليد المنافسين، بل فهم المعلومات التي يجب الإجابة عليها لموضوعات مثل LCL، وFCL، والشحن الجوي، والتخليص الجمركي، وPPJK، وبضائع المشروع.

بالنسبة للمصطلحات المتعلقة بالاستيراد والتصدير واللوائح، قمت بمراجعة الصياغة ومقارنتها بالمصادر الرسمية. وقد ساعد هذا في التأكد من أن عملية كتابة الإعلانات لا تتبع ببساطة المصطلحات المستخدمة من قبل مواقع الويب الأخرى.

قمت بعد ذلك بالتحقق من صحة البحث مقابل ملف تعريف الشركة وإرشادات العلامة التجارية وقائمة الخدمات والمناقشات مع فريق MSI. سمح لي هذا بالتأكد من أن الكلمات الرئيسية المحددة تمثل الخدمات التي تقدمها MSI بالفعل.

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

من الكلمات الرئيسية إلى بنية الصفحة

غطى البحث عن الكلمات الرئيسية الصفحة الرئيسية والخدمات الـ 11 المدرجة في ملف تعريف الشركة. بعد ذلك، قمت بإنشاء خريطة كلمات رئيسية بحيث يكون لكل مجموعة غرضية مالك صفحة واضح.

لكل صفحة، تمت ترجمة النتيجة إلى:

• الكلمات الرئيسية الأساسية والاختلافات الداعمة؛
• عنوان SEO، H1، والوصف التعريفي؛
• توصيات الرابط الثابت.
• اتجاه المحتوى على أساس القصد من البحث؛
• خطة ربط داخلية من المقالات وصفحات الخدمات الأخرى.

أدى هذا إلى منع البحث عن الكلمات الرئيسية من الانتهاء كجدول بيانات. أصبحت النتائج الأساس لخريطة الموقع، وبنية عنوان URL، وكتابة النصوص، ونظام الارتباط الداخلي المستخدم أثناء التطوير.

وجاء قرار استخدام اللغة الإندونيسية كلغة أساسية أيضًا من هذه العملية. غالبًا ما تستخدم الكلمات الرئيسية للمعاملات ذات الصلة مصطلحات مثل “jasa” و”import” و”freight Forwarder”.

أنتج البحث الأولي 85 نوعًا مختلفًا من الكلمات الرئيسية. وكان لدى ستين منهم بيانات الحجم المتاحة.

وكان يتعين التعامل مع الباقي بعناية أكبر لأنه لم يكن لديهم ما يكفي من بيانات الحجم لدعم مطالبة الطلب.

كما أنني لم أفرض كل كلمة رئيسية ذكرها أحد البائعين سابقًا على موقع الويب.

على سبيل المثال، شاهدت MSI الصفحة الرئيسية تظهر للمصطلح “jasa LCL murah”. ومع ذلك، أظهر البحث أن “jasa import LCL” كان له حجم، في حين أن إضافة “murah” لم يكن لديها بيانات كافية.

لذلك قمت بإعداد صفحة خدمة LCL، لكنني لم أضع كلمة “مراه” في كتابة الإعلانات لمجرد أنها ظهرت في مطالبة الترتيب.

يلزم بنية الصفحة والعنوان والوصف التعريفي والارتباط الداخلي لمتابعة النية والأدلة الأكثر مصداقية.

بالإضافة إلى صفحات الخدمة، قمت بترحيل 32 مقالة من الموقع القديم مع صورها وبياناتها الوصفية لتحسين محركات البحث.

وظلت هذه المقالات مهمة لأنها يمكن أن تصبح مصادر للروابط الداخلية لصفحات الخدمة الجديدة.

الميزات التي تدعم عمليات MSI

كانت إحدى الميزات الرئيسية هي نموذج طلب عرض الأسعار.

استخدم النموذج Cloudflare Turnstile لتقليل البريد العشوائي، وتسليم البريد الإلكتروني من خلال إعادة إرسال SMTP، ورسالة تأكيد بالبريد الإلكتروني للمرسل، وإخطار لفريق MSI.

بالنسبة لمحتوى الخدمة والمحفظة، استخدمت نموذج بيانات أكثر تنظيمًا بدلاً من كتابة كل شيء كصفحة واحدة طويلة.

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

تجمع لوحة المعلومات الخدمات وعناصر المحفظة والمقالات وطلبات عروض الأسعار معًا حتى يتمكن الفريق من رؤية عمله الرئيسي من مكان واحد.

أصبحت جداول التصدير والاستيراد قابلة للتعديل أيضًا من لوحة تحكم WordPress.

يمكن عرض المعلومات التي تم إعدادها مسبقًا في ملفات كجداول على الموقع الإلكتروني، مع خيار تنزيل PDF للزوار الذين ما زالوا بحاجة إلى تنسيق المستند الرسمي.

يوفر محرر الجدول الزمني علامات تبويب التصدير والاستيراد، والطريق، والسفينة، والرحلة، والقطع، وETD، وETA، والملفات القابلة للتنزيل.

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

أثناء أحد الاختبارات، بدت بيانات الجدول وكأنها تختفي بعد حفظها.

لقد قمت باستعادتها من خلال مراجعات WordPress ثم قمت بإصلاح مشكلة الهروب في البيانات المرسلة إلى المحرر.

يعد هذا مثالًا صغيرًا على سبب ضرورة التعامل مع المراجعات وتدفقات الاسترداد كجزء من النظام، بدلاً من اعتبارها ميزات اختيارية يمكن تجاهلها.

لم يتم تضمين تتبع الشحنة عمدًا كميزة إنتاج في هذه المرحلة.

قامت MSI بالفعل بإعداد وثائق واجهة برمجة التطبيقات (API) وعرضت الصفحة الرئيسية منطقة “قريبًا”، لكن مصدر البيانات كان لا يزال متصلاً بانتقال تخطيط موارد المؤسسات (ERP) والأنظمة الداخلية.

إن إنشاء مكون إضافي للتتبع قبل أن يصبح مصدر البيانات مستقرًا لن يؤدي إلا إلى إعادة العمل.

ولهذا السبب قمت بوضع تكامل واجهة برمجة التطبيقات (API) كمرحلة تطوير لاحقة، بعد أن أصبح تخطيط موارد المؤسسات (ERP) الخاص بشركة MSI هو المصدر النهائي للحقيقة.

الهجرة: عمليات إعادة التوجيه والروابط الدائمة مهمة بقدر أهمية التصميم

لم يتم الانتهاء من ترحيل موقع الويب عندما تكون الصفحة الرئيسية الجديدة مرئية.

يجب أيضًا التحقق من عناوين URL القديمة والمقالات وخرائط المواقع والتحليلات والبريد الإلكتروني وتكوين DNS حتى لا تؤدي هذه الخطوة إلى قطع التدفق الحالي.

للحفاظ على عناوين URL القديمة، قمت بإعداد 346 301 قواعد إعادة التوجيه في Cloudflare.

تم تفعيل هذه القواعد عندما تم نقل الموقع إلى استضافة MSI وكانت عملية الإطلاق جاهزة.

كانت هناك أيضًا مشكلة كلاسيكية ما بعد الترحيل: أعاد عنوان URL الخاص بـ /artikel/ الخطأ 404. لم يكن السبب صفحة مفقودة، بل قواعد الرابط الثابت في WordPress التي كانت بحاجة إلى التحديث.

لقد قمت بحل المشكلة عن طريق إعادة حفظ الروابط الدائمة في WordPress.

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

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

تحافظ قائمة الهاتف المحمول على التسلسل الهرمي للخدمة والحث على اتخاذ إجراء أساسي في مساحة شاشة أصغر.

نتائج مرئية

يمكن رؤية تغييرات المشروع من عدة زوايا:

المنطقة	قبل	بعد
المصدر المرئي	موقع HTML كواجهة أمامية	سمة مخصصة تتبع تصميم HTML
إدارة الصفحة	يعتمد على تنفيذ الواجهة الأمامية	ووردبريس مع كتل مخصصة
نطاق الصفحة الرئيسية	موقع قديم ذو بنية محدودة	13 صفحة مبنية على موقع HTML
محتوى المقال	مخزنة في النظام القديم	تم ترحيل 32 مقالة مع الصور والبيانات الوصفية
عناوين URL القديمة	هناك حاجة إلى إعادة رسم خريطة	346 قاعدة 301 نشطة في Cloudflare
جدول التصدير والاستيراد	ملفات وعملية يدوية	تتم إدارتها من لوحة التحكم وعرضها على الموقع

لقطة PageSpeed ​​Insights لقد قمت بحفظ أداء سطح المكتب المسجل عند 100 وأداء الهاتف المحمول عند 92.

لقطة سطح المكتب: الأداء 100، FCP 0.5 ثانية، LCP 0.6 ثانية، TBT 0 مللي ثانية، وCLS 0.001.

لقطة الهاتف المحمول: الأداء 92، FCP 2.0 ثانية، LCP 3.2 ثانية، TBT 0 مللي ثانية، وCLS 0.

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

أضاف Google Tag Manager وMeta Pixel أيضًا عملاً من نصوص برمجية تابعة لجهات خارجية. ضمن نطاق المشروع هذا، اعتبرت أن النتيجة 92 معقولة دون إزالة العناصر التي تحتاجها MSI حقًا.

ومع ذلك، فإن PageSpeed ​​Insights عبارة عن اختبار معملي باستخدام جهاز وشبكة محاكاتين. لا تعني النتيجة 92 تلقائيًا أن التجربة الحقيقية أسوأ من الصفحة التي حصلت على 100 نقطة.

مع وجود أجهزة وشبكات وذاكرة تخزين مؤقت ونصوص برمجية مختلفة، يمكن للصفحة التي حصلت على درجة معملية تبلغ 92 أن تبدو أسرع في الممارسة العملية. ولهذا السبب يجب قراءة الرقم مع بيانات المستخدم الحقيقي عندما تصبح بيانات حركة المرور والبيانات الميدانية متاحة.

يجب أيضًا فصل جاهزية التتبع عن نتائج الأعمال.

تساعد GA4 وGSC وGTM وMeta Pixel وأحداث WhatsApp وأحداث الهاتف وأحداث النماذج MSI في جمع المزيد من البيانات المفيدة، ولكنها لا تثبت تلقائيًا زيادة في العملاء المحتملين أو الإيرادات.

الدروس المستفادة من المشروع

1. الاكتشاف يمكن أن يغير القرار الفني

استندت الخطة الأولية باستخدام GeneratePress وGenerateBlocks إلى المعلومات المتاحة خلال مرحلة الاقتراح.

بعد أن تم عرض موقع HTML في الاجتماع، تم تغيير القرار الأكثر منطقية إلى موضوع مخصص وكتل مخصصة.

بالنسبة لي، لم يكن هذا تغييرًا في النطاق يجب تجنبه. لقد كان نتيجة الاكتشاف جعل التنفيذ أكثر ملاءمة لأصول العميل وتوقعاته.

2. التخصيص لا يعني دائمًا الأفضل

إذا لم يكن التصميم موجودًا بعد أو لا يزال مرنًا جدًا، فيمكن أن يكون القالب الناضج ونظام الكتل خيارًا فعالاً.

تكون البنية المخصصة منطقية عندما يكون التصميم محددًا بالفعل، ويجب التحكم في سير عمل التحرير، ويجب أن تظل النتيجة المرئية متسقة.

3. الهجرة تحتاج إلى خطة إنعاش

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

ومع ذلك، تحدد هذه التفاصيل غالبًا ما إذا كان من الممكن استخدام الموقع الجديد دون فقدان الوصول إلى المحتوى القديم.

4. الميزات المؤجلة هي أيضًا جزء من النجاح

لم أفرض تتبع الشحنة على الإنتاج لمجرد أن منطقة واجهة المستخدم الخاصة بها موجودة بالفعل.

كان الانتظار حتى يصبح تخطيط موارد المؤسسات (ERP) وواجهة برمجة التطبيقات (API) أكثر استقرارًا أكثر أمانًا من شحن ميزة تحتاج إلى إعادة بنائها عند تغيير مصدر بياناتها.

خاتمة

يُظهر مشروع Exportimportdept.com أن تحويل HTML إلى WordPress ليس من الضروري التضحية بالتصميم الحالي للعميل.

كان التحدي الرئيسي هو ترجمة التنفيذ المرئي الثابت إلى نظام محتوى يظل مرنًا.

مع سمة مخصصة وكتل مخصصة، تلقت MSI 13 صفحة مستندة إلى HTML يمكن إدارتها من خلال WordPress.

وخلف ذلك تم إعداد أساس تحسين محركات البحث (SEO)، وترحيل المقالات، وعمليات إعادة التوجيه، والنماذج، والجداول الزمنية، والتتبع للمرحلة التالية من التسويق والعمليات.

إذا كان لديك بالفعل موقع HTML بتصميم تريد الاحتفاظ به، فيمكنني المساعدة في تحديد الأجزاء التي يمكن تحويلها إلى كتل.

وظيفة أكثر أمانًا حيث يمكن فصل التعليمات البرمجية المخصصة من البداية.

يمكنك البدء بـ خدمة تطوير مواقع الويب أو اتصل بنا لمناقشة تحويل كتل WordPress.