دمج إدارة المحتوى
دمج نظام محتوى بلا واجهة
Contentful أو Sanity أو Strapi أو Payload أو ووردبريس مصدرًا بلا واجهة - موصولًا بـApp Router بمحتوى محدَّد الأنواع، وتخزين يناسب عمل المحرّرين، ومعاينة لا تكلّفك الذاكرة المؤقّتة.
يتعثّر دمج نظام المحتوى بلا واجهة في المواضع الثلاثة نفسها كل مرّة، ولا واحد منها هو النظام. المحتوى بلا أنواع، فتصير إعادة تسمية حقلٍ خطأ وقت تشغيل في الإنتاج. والتخزين المؤقّت خاطئ، فينشر المحرّرون وينتظرون. والمعاينة إمّا لا تعمل، وإمّا تعمل بجعل كل مسار ديناميكيًا.
ما نبنيه
محتوى محدَّد الأنواع من طرفه إلى طرفه. مخطّط النظام يولّد أنواع TypeScript،
وطبقة الجلب تحلّل ما يعود لا تدّعيه. عندها يفشل الحقل المُعاد تسميته عند البناء
أو عند الحافة برسالة تسمّيه - لا بعد ثلاثة مكوّنات على هيئة
undefined is not a function.
تخزين مؤقّت يناسب طريقة عمل المحرّرين. يُوسَم المحتوى ولا يُعاد التحقّق منه
بالوقت. خطّاف من نظام المحتوى يمسح وسم ما تغيّر، فتتحدّث الصفحة خلال ثوانٍ دون
جعل المسار ديناميكيًا. أما البديل - revalidate: 60 في كل مكان - فيعني أن
المحرّرين ينتظرون دقيقة وأن أصلك يتلقّى زيارات لم يكن بحاجة إليها.
معاينة لا تكلّفك الذاكرة المؤقّتة. وضع المسوّدة على مسار المعاينة وحده، محصورًا بجلسة المحرّر، كي يبقى المسار المنشور ثابتًا لبقيّة الناس. المحرّرون يرون غير المنشور، والزوّار يحصلون على شبكة التوزيع.
نموذج كتل يصمد. تنمذج معظم المشاريع المحتوى صفحاتٍ بحقول ثابتة، ثم يطلب التسويق تخطيطًا لا يستطيع النموذج التعبير عنه. نحن ننمذج كتلًا قابلة للتركيب من البداية، مع عارض محدَّد النوع في مقابل اتّحاد الكتل، فتصير الكتلة غير المعالَجة خطأ ترجمة لا فراغًا في الصفحة.
أي نظام
لسنا مرتبطين بواحد، وسنخبرك إن كان الذي اخترته غير مناسب لما تفعله - لكن هذا نادرًا ما يكون السؤال المهم. الدمج هو معظم العمل، وشكله واحد تقريبًا أيًّا كان اختيارك.
وإن كنت ترحّل عن ووردبريس وتُبقيه سطحًا للتحرير، فذلك ينجح: ووردبريس مصدرًا بلا واجهة مع Next.js للعرض معماريّةٌ مشروعة وغالبًا أرخص الطرق، لأن المحرّرين يحتفظون بالأداة التي يعرفونها.
ما نحتاجه منك
وصولًا إلى نظام المحتوى، وشخصًا يستطيع الإجابة عن «فيمَ هذا الحقل؟». والثاني أهم من الأول - فنموذج محتوى يعكس قالبًا قديمًا بدل المحتوى الفعلي هو ما يجعل إعادة البناء مكلفة، وساعة حوار قبل أي شيفرة تستحقّ العناء.
كيف تُحدَّد
امنحونا صلاحية قراءة لنظام إدارة المحتوى ونصف ساعة مع من يستطيع أن يقول لماذا يوجد كل حقل. هذا الحوار يقدّر المشروع بدقة أكبر من عدّ الصفحات.
يعود النطاق ومعه نموذج المحتوى، مؤكَّدًا أو مُعاد رسمه، إضافةً إلى قائمة القوالب ومقاربة المعاينة وإعادة التحقق وسعر. ويُوقَّع قبل بدء البناء. وحيث يلزم إعادة تشكيل النموذج فتلك مرحلة مستقلة برقمها، لأنها الجزء الذي يضاعف المشروع بصمت إن تُرك ضمنيًا.
ثم البناء، منشورًا لكل مرحلة، والمحررون يستخدمون المعاينة قبل اكتمال الواجهة الأمامية.
ما الذي تحصلون عليه
الواجهة الأمامية، وطبقة المحتوى محددة الأنواع بينها وبين نظام إدارة المحتوى، ومسار المعاينة عاملًا للمحررين، وإعادة التحقق موصولة بخطافات النظام كي يظهر النشر دون أن يعيد أحد النشر البرمجي.
ما يُستهان به هو نموذج المحتوى. وحيث لزم إعادة تشكيله تتسلّمون النموذج الجديد موثَّقًا، مع الترحيل الذي نقل المدخلات القائمة إليه، لأن نموذجًا لم يكتبه أحد ينحرف عائدًا خلال سنة.
متى يُجلب المحتوى وكم يُحتفظ به هو ما يقرر إن كان التكامل سريعًا أم هشًّا، وهو قرار عن نموذج المحتوى بقدر ما هو عن التخزين المؤقت. والموقع المدفوع بنظام إدارة محتوى يولّد عناوينه بنفسه أيضًا، فالروابط المعيارية وخريطة الموقع تُنتَج لا تُصان. وحيث يكون الموقع مصنَّفًا أصلًا ولا يحتمل الانتقال، يسير السيو التقني بالتوازي.
