10 تحديات عند العمل مع WordPress كمنصة لإدارة المحتوى في عام 2026

لقد كنت أعمل وأطور مع WordPress منذ إنشائه. نظام إدارة المحتوى (المركز الطبي) البساطة ظاهرة رائعة، ولا يعد تبنيها على نطاق واسع أمرًا مفاجئًا. هناك من يكرهونها، ولكنني غالبًا ما أذكر الناس بأن معظم المشكلات المتعلقة بـ WordPress تتركز عادةً حول السمات والمكونات الإضافية التي تم تنفيذها، وليس حول المنصة الأساسية.
التشبيه الذي أستخدمه غالبًا مع الناس هو قطع غيار السيارات بعد البيع ... بعضها لا يصدق ، والبعض الآخر يمكن أن يدمر سيارتك. ووردبريس لا يختلف. مثال على ذلك أرغب في مشاركته هو هذا الموقع ، Martech Zone. قبل بضع سنوات ، وجدت موضوعًا رائعًا يحتوي على جميع الميزات والوظائف التي كنت أرغب في مشاركة المحتوى الخاص بي بها في واجهة مستخدم سهلة الاستخدام وجميلة وأنيقة. على مر السنين ، واصلت تحسين المظهر الفرعي الذي قمت بإنشائه وكنت سعيدًا لأن مطوري المظهر الأصلي الأصلي استمروا في دعم كل إصدار من إصدارات WordPress.
حتى الان.
واجهت مشكلة في الموقع ولم أتمكن من معرفة كيفية تطوير الكود، لذا ذهبت إلى منتدى المطورين... وكان موقعهم معطلاً. لذا، ذهبت إلى المكان الذي اشتريت منه السمة... ولم أجدها. ثم بحثت عن مطوري السمة... ولم أجدهم.
كنت بمفردي!
قبل عقود من الزمان، عندما كنت تشتري منتجًا، كنت تتوقع استخدامه مدى الحياة. في عالم التكنولوجيا السريع الخطى والمنخفض التكلفة اليوم، اعتدنا على التخلص من تكنولوجيتنا عندما تتعطل أو تصبح قديمة. هذا جيد... لا أمانع في شراء محمصة خبز جديدة. ولكن عندما يكون البرنامج هو الذي يدير موقع الويب الخاص بك، فإن الأمر يسبب صداعًا كبيرًا. للعودة إلى تشبيهي، فإن الأمر ليس مثل مجموعة من الحافات غير الأصلية بل أشبه بتعطل ناقل الحركة. إنها تكلفة كبيرة وتحدي كبير في نظام WordPress البيئي.
النزاعات القانونية المتعلقة بـ WordPress
أضف إلى هذا عدم الاستقرار الدراما التي تكشفت في عام 2024 عبر النزاع القانوني بين WordPress و WP Engineأنا بصراحة لست من محبي هذا الخلاف العام... فهو ليس جيدًا للمجتمع على الإطلاق. عندما تم إطلاق WP Engine، كان بمثابة نقطة تحول في استضافة WordPress. إن مشكلات الأداء الشديدة المتأصلة في WordPress تزداد سوءًا في حالة عدم إجراء الكثير من التحسينات التي يجب القيام بها. WP المحرك أحدث ثورة، وأجرؤ على القول، أنه اخترع مفهوم استضافة WordPress المُدارة.
بفضل التخزين المؤقت المضمّن والأمان والنسخ الاحتياطية الآلية والدعم الرائع، أصبح نشر WordPress أسهل كثيرًا للشركات. ومن المخيب للآمال أن أوتوماتيك لا يدركون أن هذا التقدم ساعد WordPress في اكتساب حصة سوقية كبيرة... خاصة مع الوكالات التي تسعى إلى إدارة عملائها بشكل فعال. إن قيامهم بفصل كل موقع WordPress المستضاف على WP Engine كان أمرًا غير مقبول... مما أضر بعملاء WordPress الذين لم يلعبوا أي دور في ممارسات WP Engine التجارية.
كما تولت شركة Automattic أيضًا السيطرة على الحقول المخصصة متقدم، وهو مكون إضافي تم شراؤه بواسطة WP Engine. وقد أدى هذا السرقة المزعومة لمشروع مفتوح المصدر إلى دفع المطورين مثلي إلى التخلي عن دفع الكود الخاص بي إلى مستودع المكونات الإضافية، والذي هو ملك مؤسس Automattic وليس المجتمع. لا أذكر سرقة لقد كان الأمر مختلفًا تمامًا لو قامت Automattic بتقسيم الكود وإنتاج البرنامج الإضافي الخاص بها. ومع ذلك، فقد تولت ملكية المستودع والمراجعات الخاصة بـ ACF جنبًا إلى جنب مع الكود، وهو ما أعتقد أنه انتهاك لشروط الخدمة الخاصة بها.
إن عدم اليقين يضر بالأعمال التجارية لأنه يعطل عملية اتخاذ القرار والتخطيط للاستثمار وثقة العملاء. تزدهر الشركات في ظل الاستقرار والظروف المتوقعة التي تسمح لها بوضع الاستراتيجيات بشكل فعال وتخصيص الموارد بكفاءة وبناء الثقة مع أصحاب المصلحة. عندما تكون الأسواق أو البيئات متقلبة، تواجه الشركات مخاطر متزايدة وتكاليف أعلى وترددًا من العملاء والشركاء، وكل هذا يعيق النمو. أخشى أن هذا هو الاتجاه الذي يتجه إليه WordPress.
لا يزال WordPress رائعًا
هدفي من هذه المقالة ليس الشكوى من WordPress؛ فهي منصة مرنة يمكن تحديثها أو تحويلها أو تخصيصها بجهد بسيط. إن النظام البيئي للمطورين والموضوعات والمكونات الإضافية يتجاوز الخيال. لقد ساعدت الشركات على القيام بعمليات تكامل وأتمتة مبتكرة بشكل لا يصدق مع WordPress APIوأنا أظل متفائلاً بشأن مستقبلها.
هدفي من هذه المقالة هو مشاركة ما أعتقد أنه بعض أوجه القصور المهمة في المنصة حتى يكون الناس على دراية ببعض التحديات المتأصلة في المنصة الأساسية. لاحظ أنني قلت الأساسية... أدرك أن هناك سمات وإضافات وهندسة بدون واجهة يمكنها التغلب على هذه التحديات. أود من مهندسي WordPress الابتكار في بعض أوجه القصور هذه.
مخصص إلى Martech Zone
عندما فشل الدعم لموضوعي، لم يكن لدي الوقت الكافي للتطوير لمدة شهر، لذلك كان عليّ تحويل الموقع إلى موضوع جديد ثم حل المشكلات.
- التطبيقات: ابني التطبيقات كان إنشاء موقع ويب خاص بي مهمة شاقة. فكل تطبيق له أسلوبه الخاص، وترميزه الخاص على جانب الخادم، وترميزه الخاص على جانب العميل، لذا كان عليّ إنشاء إطار عمل لدمج التخصيصات في موضوعي.
- الرموز القصيرة: أستخدم رموزًا مختصرة مخصصة في جميع محتوياتي. هذه الرموز المختصرة ليست شائعة، ولكنها لا تتجاوز القالب تلقائيًا لتشمل أدوات مثل AMP. لذلك، اضطررتُ إلى إنشاء إضافة مخصصة لموقعي تتضمن جميع رموزي المختصرة وتعزز وظائفها. كما أن تحويلها إلى إضافة يعني أنني أستطيع تحديث القالب دون الإضرار بالمحتوى.
- الكاتب الأرشيف:باعتباري موقعًا يضم مئات المؤلفين، كان عليّ تطوير أرشيف المؤلف كان الأمر معقدًا للغاية، حيث تم الترويج للمؤلفين حسب شعبيتهم وحداثتهم.
- Custom Post Type:لقد قمت ببناء مجموعة من الأغاني الشعبية المختصرات للموقع. حتى أنني قمت بتضمين أحدث المنشورات باستخدام الاختصار في كل صفحة من صفحات الاختصار. للقيام بذلك، كان عليّ إنشاء أرشيف مخصص وأرشيف تصنيف ونموذج منشور واحد لنوع المنشور المخصص لعرضه بشكل صحيح.
- تعليقات: لكي أتمكن من إزالة التعليقات من موقعي، وخلاصة الأخبار، وخريطة الموقع، وما إلى ذلك، كان عليّ كتابة التعليمات البرمجية.
هذا ليس كل شيء... لدي كود مخصص لمسؤولي، وAMP، ووضع الإعلانات، والتطبيقات، والمؤلفين، والتعليقات، والخلاصة، والترجمات متعددة اللغات، تحسين محركات البحث، والأدوات المساعدة، والكثير لتحسين الأداء. في مرحلة ما، ربما كان من المفيد إنشاء سمة مخصصة من البداية ثم إجراء جميع التعديلات اللازمة لهذا الموقع.
عشرة تحديات شائعة تواجهها ووردبريس
فيما يلي بعض المشكلات الأخرى التي واجهتها والتي لا تزال تشكل تحديًا وتكلف الوقت والموارد سواءً مع موقعي أو مواقع شركتي وعملائي السابقين. سأضعها حسب الأهمية.
- الأداء:إن أداء WordPress سيئ للغاية، وخاصةً مع استمرارك في تخصيصه باستخدام مكونات إضافية وميزات للموضوع. إن المشكلة الأكثر تعقيدًا التي نتعامل معها هي سرعة الموقع. إن أداء قاعدة البيانات، وتخزين الاستعلامات، وتخزين الكائنات، وتقليص الكود، وتخزين الصفحات، والتحميل البطيء، وحجم الصور، وضغط الملفات كلها غير كافية على الإطلاق وتتطلب الكثير من العمل. وهذا حتى قبل دمج CDN.
- SEO:إذا كنت تنشر محتوى لجهود الاستحواذ على علامتك التجارية أو منتجك أو خدمتك، فإن تحسين البحث العضوي ليس خيارًا - بل هو أمر ضروري. إلى جانب مشكلات الأداء المذكورة أعلاه، فإن خيارات تحسين محرك البحث الفنية الأصلية لـ WordPress غير كافية... حتى إذا كنت تدفع مقابل Jetpack ل لموقعك. يعد تحسين العلامات والمقتطفات المنسقة وخرائط الموقع والميزات الأخرى ضرورية لتحسين موقعك لمستخدمي محرك البحث. هذا هو السبب في أننا لن ننفذ موقعًا بدون رانكماث.
- AMP:على الرغم من أن هذا ليس خطأ WordPress، AMP الدعم سيئ للغاية. Jetpack ل يحتوي على إمكانيات AMP، ولكن لسببٍ غير مفهوم، يُعطّل دعم الرموز المختصرة من القالب الرئيسي لعرض AMP. وكما أن القالب الفرعي يكتسب ميزات ووظائف من القالب الرئيسي، يبدو أن AMP يجب أن يكون قالبًا فرعيًا. أحد أسباب اختياري للقالب الجديد هو دعم AMP المتأصل.
- WooCommerce: WooCommerce تم تطويره في البداية للاستفادة من واجهة برمجة تطبيقات WordPress، لذا فهو يستخدم جدول المنشورات الأساسية لتخزين معلومات المنتج ويعامل المنتجات والفئات مثل نوع المنشور المخصص. ومع ذلك، فإن الطلبات والمنتجات ليست منشورات أو صفحات. مشاركة معرفات قاعدة البيانات الأصلية للمنتجات (بدلاً من رقم المنتج في جدول علاقات) ورقم الطلب المنفصل عن معرف wp_posts هو إغفال كبير.
- النماذج والبيانات:يتطلب الأمر مكونًا إضافيًا للنماذج أو منصة خارجية متكاملة لإدارة النماذج والبيانات على موقعك. أشعر بالدهشة لأن WordPress لم يدمج النماذج والبيانات كميزة أساسية - خاصة وأن WooCommerce يستخدم كليهما. رائع يؤدي عملاً رائعًا ولديه أيضًا قدرات webhook التي تجعل من السهل دمجه.
- الاسبام:كنت أدفع مقابل أكيسميت، لكنها كانت عديمة الفائدة ضد البريد العشوائي عبر النماذج ولم تتطور على مر السنين. ما زلت أتلقى الكثير من البريد العشوائي، في المقام الأول من خلال النماذج على موقعي. يجب على فريق WordPress التخلص منها وشراء ودمجها CleanTalk، حل متفوق وموسع مع تكاملات المكونات الإضافية للنماذج الأصلية.
- انطلاق: تحتوي كل استضافة WordPress المُدارة الآن على بيئات إعداد مقابل بيئات إنتاج حيث يمكنك التطوير والاختبار، ثم دفع التغييرات إلى الإنتاج. إن الدفعات من الإعداد إلى الإنتاج لها قيود مروعة بسبب بنية WordPress. بينما نقوم بالتطوير على الإعداد، لا يزال عملاؤنا ينتجون المحتوى في الإنتاج. غالبًا ما يؤدي تطوير السمات إلى تحرير قواعد البيانات. نتيجة لذلك، لا يمكننا دفع الإعداد إلى الإنتاج فقط... يتعين علينا دفع التغييرات يدويًا إلى الإنتاج. إذا قام WordPress بعمل أفضل في عزل إعدادات السمات والمكونات الإضافية عن المحتوى والطلبات والمنتجات، فسيكون من السهل مزامنة الاثنين.
- مهام سير العملتتطلب معظم الشركات القدرة على توفير تدفقات عمل للمحتوى مع أشخاص يكتبون المحتوى ويحررونه ثم يوافقون عليه قبل جدولة نشره. وفي حين أن WordPress يحتوي على أدوار رائعة مدمجة، إلا أنه لا يوجد إدارة لتدفق العمل لتعيين هذه الأدوار وإخطارها. ونتيجة لذلك، تبحث الشركات عن جهات خارجية لتطوير المحتوى وتحريره والموافقة عليه ثم تستخدم WordPress فقط لنشره.
- رحلات المحتوى:تتمتع منصات تجربة المحتوى التي تدخل السوق بقدرات ديناميكية مع تدفقات تعتمد على القواعد أو الذكاء والتي تقود الزوار خلال التجربة. وهذا تغيير جذري وقد لا يتمكن WordPress من استيعابه أبدًا.
- وردبريس الحاجيات:أستمتع بمحرر جوتنبرج وأقدر مرونته أثناء دعم هياكل المحتوى السابقة. ومع ذلك، عندما قرر ووردبريس محاولة تكييف واجهة المستخدم للأدوات بحيث تبدو وتعمل مثل جوتنبرج، كانت كارثة. واجهة المستخدم فظيعة... وإذا كان لديك الكثير من الأدوات، فهي بطيئة. كانت إحدى ميزات السمة الجديدة الخاصة بي خيارًا لتعطيل هذه الواجهة، وكنت سعيدًا للغاية. إذا كنت تريد تعطيل محرر الكتلة للأدوات، هناك كود يمكنك إضافته إلى قالب طفلك أو مكون إضافي رسمي يمكنك تثبيته.
أعلم أنني سأواجه قدرًا هائلاً من المعارضة لتطبيقات الطرف الثالث والتكاملات والمكونات الإضافية والموضوعات. نستمر في الحفاظ على قائمتنا والترويج لها يوصى بإضافات لـ WordPress. مرة أخرى ، وجهة نظري هي أن الميزات المذكورة أعلاه أصبحت أساسية لإستراتيجية المحتوى ، وليست ميزة أو وظيفة خارجها.







