كيف تدير مجلة Smashing المحتوى: الانتقال من WordPress إلى JAMstack
نشرت: 2022-03-10تم دعم هذه المقالة من قبل أصدقائنا الأعزاء في Netlify ، وهي منصة الكل في واحد لأتمتة مشاريع الويب الحديثة. شكرا لك!
في كل مرة يتحدث فيها المطورون عن WordPress ، تتغير نسبة حصتهم في السوق. " 20٪ من جميع المواقع موجودة على WordPress! "" 40٪ من جميع المواقع موجودة على WordPress! مهما كانت النسبة المئوية ، فالرسالة هي نفسها: من حيث التبني ، فإن WordPress ضخم.
فلماذا ، مع هذا النوع من التبني ، قد يفكر موقع يستخدم WordPress في الانتقال إلى JAMstack؟ في سلسلة المقالات هذه المكونة من جزأين ، سنغطي الشكل الذي يبدو عليه الترحيل الفعلي لـ WordPress ، باستخدام دراسة حالة للموقع ذاته الذي تقرأه من الآن.
سنتحدث عن المكاسب والخسائر ، والأشياء التي كنا نتمنى أن نعرفها سابقًا ، وما الذي فاجأنا به. وبعد ذلك سنتابعه بعرض تقني لمسار ترحيل واحد محتمل - ليس من WordPress تمامًا - ولكن كيف يمكنك خدمة WordPress المنفصلة بحيث يمكنك الحصول على أفضل ما في العالمين: تطبيق JAMstack لـ WordPress الذي يمنحك كل شيء قوة لوحة القيادة والوظائف ، مع أداء وأمان أفضل.
دعونا نحفر!
لماذا ا؟
في عام 2015 ، تحدث مؤسس Netlify ماتياس بيلمان ومؤسس Smashing فيتالي فريدمان عن المتجر. عندما بدأت هندسة JAMstack في القيام بجولات ، أصبح Smashing أكثر اهتمامًا بفكرة المكدس. سأل فيتالي وماركوس (المدير الإداري السابق في Smashing) مات عما سيحدث إذا انتقل Smashing من موقع WordPress / LAMPstack التقليدي إلى بنية JAMstack.
كتجربة ، ألغى Matt كل HTML من Smashing واستضافها على Netlify ، مما أدى إلى تسليم المحتوى بشكل ثابت من CDN. كانت النتائج مقنعة - الإصدار الثابت أسرع بست مرات في المتوسط!
يعمل هذا النوع من الهندسة بشكل جيد جزئيًا لأن الصفحات لا يتم تجميعها عند الطلب أثناء زيارتك لها. نظرًا لأنك تقدم محتوى تم إنشاؤه مسبقًا مباشرةً من شبكة توصيل المحتوى ، فإن الموقع موجود بالفعل وجاهزًا للمستخدم.
نظرًا لأنك تخدم عبر CDN ، يمكنك أيضًا توزيع المحتوى في جميع أنحاء العالم - بالقرب من الزوار المحتملين. لا توجد نقطة منشأ مركزية ، وهو أمر حيوي في حالة أي منشور عبر الإنترنت يريد أن يكون سريعًا لجميع قرائه.
لذلك تم تمهيد المسرح. انتقلت مجلة Smashing إلى JAMstack - إلى Netlify كمنصة على وجه الخصوص. في 10 سنوات من التشغيل ، نمت Smashing من منشور صغير عبر الإنترنت إلى مدونة WordPress ضخمة ، لبيع أشياء مثل الكتب وتذاكر المؤتمرات وورش العمل.
كانت هناك أجزاء قليلة من هذا الموقع:
- مدونة ووردبريس
- لوحة وظائف القضبان
- Shopify متجر
- CMS آخر لموقع المؤتمر
عندما بدأت Netlify الترحيل لأول مرة ، كان الموقع يعاني من بعض المشكلات المتعلقة بالأداء ، وأثقل كاهله بـ 20 ألف تعليق وآلاف المقالات. كان Smashing مهتمًا أيضًا بالمصادقة كجزء من خطة اشتراك جديدة ، بالإضافة إلى إعادة تصميم لمظهر أكثر حداثة.
الموثوقية
يحقق Smashing بانتظام ما تحلم به الأنظمة الأساسية الأخرى: المقالات التي يتم مشاركتها على نطاق واسع من خلال مجتمع هائل. ومع ذلك ، عندما تم الوصول إلى نقطة تحول في حركة المرور لأحد المنشورات ، كان Smashing يعاني بانتظام من مشكلات في حالات الانقطاع. للتخفيف من ذلك ، تم إدخال الاستخدام المكثف لمكونات WordPress الإضافية في مكدسهم ، لكنهم ما زالوا يكافحون من أجل الاحتفاظ بمقاييس وقت التشغيل الجيدة.
أتاح الانتقال إلى Netlify لفريق Smashing تجنب حدوث أخطاء في الاتصال بقاعدة البيانات وعدم القلق بشأن وقت التوقف عن العمل حتى عندما شهدت إحدى المقالات قدرًا هائلاً من حركة المرور. لماذا ا؟ لأنه عند الخدمة بدون خادم ، لا يلزم إنشاء المحتوى المُعد مسبقًا وتقديمه - فهو موجود بالفعل وجاهز للعرض. لا يتم طلب أي شيء على الفور باستثناء الصفحة الثابتة بأكملها.
أتاح الخدمة عبر CDN أيضًا لـ Smashing النوم بشكل أسهل قليلاً من حيث الأمان. لطالما كان ملف wp-login.php مصدرًا للثغرات الأمنية ونواقل الهجوم. لا يمكن الوصول إلى المحتوى الذي تم إنشاؤه مسبقًا بنفس الطريقة كما أن الثغرات الأمنية ليست موجودة في كل مكان.
إبطال ذاكرة التخزين المؤقت
كان Smashing يتنقل عبر كل مكون إضافي للتخزين المؤقت في WordPress ، مع نتائج متنوعة والكثير من المشاكل. يذكر فيتالي فريدمان من Smashing ،
"كانت المشكلات الرئيسية التي واجهتنا تتعلق بـ" خطأ في إنشاء اتصال قاعدة البيانات "الذي ظللنا نواجهه كل أسبوعين ، وقد جربنا حرفيًا كل مكون إضافي للتخزين المؤقت في WordPress. كان الأداء جيدًا (بشكل عام) ، لكننا كنا نتطلع إلى تحسينه بشكل أكبر. بالإضافة إلى ذلك ، أردنا إطلاق العضوية وربط جميع العروض المختلفة - المؤتمرات ومنشورات الوظائف والمقالات والكتب والكتب الإلكترونية - بمنصة واحدة ، وكان من الصعب جدًا تحقيقها باستخدام WordPress أثناء اللعب. "
أتاح الانتقال إلى Netlify لفريق Smashing رؤية إبطال ذاكرة التخزين المؤقت الفوري أثناء تقديم محتوى مخبأ وعالي الأداء ، بدون أي نفقات إضافية.
عند نشر موقع ، تتم استضافة ملفات HTML على شبكة CDN الخاصة بـ Netlify. لقد تم تحسينه للحصول على معدل مرتفع لضربة ذاكرة التخزين المؤقت ، ووقت سريع للبايت الأول ، مع القدرة على إبطال جميع ملفات HTML التي تم تغييرها على الفور . يقوم Netlify أيضًا ببصمات أصابع جميع الارتباطات إلى الأصول مثل ملفات CSS أو الصور أو الخطوط أو ملفات JS ، ويقدم التحطيم باستخدام رؤوس التخزين المؤقت التي تخزنها مؤقتًا إلى الأبد. تضمن البصمات أنها فريدة من نوعها ، وأنه إذا قمت بتحديث إصدار جديد ، فسيتم تقديم الإصدار الأحدث بدلاً من ذلك.
سير العمل
بالنظر إلى الإعداد الحالي ، كان أحد الأسباب الرئيسية للترحيل ببساطة هو توحيد الخصائص الحالية. أصبح الاضطرار إلى تغيير السياق بين كل هذه المجموعات والإعدادات التقنية المختلفة مشكلة صيانة صعبة كلفت المهندسين.
عندما تم تقسيم البنية التحتية الخاصة بهم سابقًا بين العديد من الأنظمة المختلفة ، قامت عملية الترحيل هذه أيضًا بتوحيد كل شيء ، مع الحفاظ على الموقع الرئيسي وموقع المؤتمر وقسم الاشتراكات والتجارة الإلكترونية يعملون معًا بدلاً من الاحتفاظ بها بشكل منفصل مع مجموعات مختلفة. ساعد هذا في الحفاظ على انخفاض تكاليف التطوير وتجربة المطور في العمل على جميع العقارات باستمرار.
ثبت أن قطعة ترحيل WordPress هي الأكبر والأكثر حساسية. حاول Netlify تصدير البيانات من مُصدِّر WP ، فقط لتجد أن المحتوى يحتوي على تضمينات يجب الحفاظ عليها ، أو تم تغييرها في بعض الأحيان بواسطة المكونات الإضافية. من أجل الحفاظ على التكافؤ مع ما كان موجودًا على الموقع ، تمت كتابة سلسلة من أدوات الكشط ، مقسمة حسب المقالات والأصول والتعليقات والصفحة الرئيسية.
بمجرد كتابة ذلك وتحويله ، تم تحميله في مستودع جديد في GitHub ، وتم استخدام Netlify CMS بدلاً من ذلك. ما يجعل Netlify CMS فريدًا هو أنه خفيف الوزن ، ويدمج محرري المحتوى في سير عمل Git - مما يعني أنه سوف يسحب ويخدم ملفات تخفيض السعر من git repo بدلاً من قاعدة البيانات. بالإضافة إلى ذلك ، يعد Netlify CMS حياديًا للنظام الأساسي ويعمل مع (تقريبًا) جميع مولدات المواقع الثابتة والمواقع المخزنة في GitHub.
في ذلك الوقت ، عملت سارة سويدان في Smashing كمطور مستقل للواجهة الأمامية عند إعادة تصميمها. أنشأت مكتبة من المكونات لبناء بنية الواجهة الأمامية ولاحظت مدى سهولة العمل معها لأنها كانت تعمل مباشرة في git ، حتى عند العمل مع CMS.
"كل شيء دفعته إلى المستودع يتم تطبيقه مباشرة على مكتبة الأنماط مما يعني أنه ليس عليك الاحتفاظ بمجموعتين مختلفتين من المكونات ... كان هذا النوع من الاستمرارية رائعًا! كل ما علي فعله هو كتابة HTML و CSS وجافا سكريبت والدفع إلى الريبو وكل شيء يعمل مثل السحر. كان سير العمل رائعًا ".
كل هذا قيل ، قد يكون Netlify CMS خفيفًا جدًا في بعض الأحيان لمثل هذه الحالة المرورية المرتفعة وحالة الاستخدام على نطاق واسع. تحطيم بانتظام الكتاب الضيوف وطاقم التحرير الكامل. بعض الميزات الغنية التي يقدمها WordPress مفيدة حقًا لهذه الأنواع من البيئات التعاونية للغاية.
لهذا السبب في البرنامج التعليمي التالي ، سنوجهك عبر نموذج بدون رأس ، حيث لا يزال بإمكانك جني فوائد لوحة معلومات WordPress لمنشئي المحتوى ، ولكن استخدم WordPress عبر API واعتماد التطوير على سير عمل مركزي بهذه السهولة للمطورين للحفاظ عليها أيضًا. ابقوا متابعين!
خيارات الإطار
في النموذج الأولي الذي ابتكره Matt Biilmann ، كتب كل شيء في الحد الأدنى من Preact ، مقترنًا بـ Hugo ، حيث كان يركز بشدة على الأداء. لقد استخدم فقط الدعائم وأبقى كل شيء خفيف الوزن للغاية. أثناء إجازته للمشروع ليتم صيانته بواسطة مطور Smashing ، Ilya Pukhalski ، وجد أن Preact كانت تفتقر إلى بعض الميزات التي كانت مفقودة للاستفادة من النظام البيئي لـ React. في النهاية ، فاقت فوائد Redux والمكتبات الأخرى التكلفة.
بعد التفكير الآن ، يقول مات إنه كان سيستخدم Vue ، التي لم تكن تمتلك حصة السوق تمامًا في ذلك الوقت (أقسم أنني لم أطالبه بقول ذلك). سألت السؤال الواضح: لماذا لا Svelte؟ نظرًا لأن الأشخاص المهتمين بالأداء يميلون إلى الوصول إلى تلك المكتبة. وذكر أن Svelte لا تمتلك النظام البيئي Vue تمامًا حتى الآن.
عندما يفكر مات في ما إذا كان سيظل يستخدم Hugo أم لا ، قال إنه يحب Hugo ، لكن ما وجده صعبًا بالنسبة لهذا المشروع على وجه الخصوص هو أنه لم يكن به نظام مكون إضافي كافٍ - إنشاء إعلانات لافتة وأشياء من لم تكن الطبيعة قابلة للبرمجة بدرجة كافية مع Hugo وكان بحاجة إلى حقن البرامج النصية لإنجازها. تميل هذه البرامج النصية إلى إبطاء عملية الإنشاء. ومع ذلك ، ما زلنا نستخدم Hugo لموقعنا الخاص على netlify.com ونحبه - هذا التحذير خاص للغاية باحتياجات موقع Smashing على وجه الخصوص.
إذا كان بإمكانه فعل ذلك مرة أخرى ، فقد يختار إما Eleventy ، الذي يتمتع بقدرات غنية من حيث إنشاء المكونات الإضافية والنصوص البرمجية الأخرى القابلة للتمديد. أو ، إذا كان يستخدم Vue ، لكان Nuxt قد قدم له بعض إمكانات البرنامج المساعد اللطيفة مع السماح بكونه اختيارًا جيدًا لهذا الإطار ، حيث يقدم عرضًا من جانب الخادم وتوجيه وتوليد ثابت.
بناء مواقع كبيرة
كانت هناك مشكلة واحدة ظهرت أثناء العمل مع موقع كبير مثل Smashing وربما يمكنك بالفعل معرفة ما هو عليه ، لقد تطرقنا إليه للتو. من الصحيح أنه مع أي موقع كبير للصفحات المنشأة مسبقًا يتم عرضه على شبكة CDN ، لا يزال الأداء رائعًا لأننا لا نبني أي شيء سريعًا للمستخدمين.
لكن هذه الميزة لا يمكن أن تحدث إلا إذا كان الموقع مبنيًا مسبقًا ، ويمكن أن تستغرق هذه العملية وقتًا طويلاً. في حين أن المزيد من المواقع التقليدية ستنشئ الصفحات عندما تطلبها ، فإننا ننشئ كل صفحة على حدة مسبقًا في حالة احتياج المستخدم إليها. يجعل الأداء فائق السرعة! ولكن هذا الوقت أصبح الآن مخصصًا لوقت التطوير والنشر - فقد يستغرق إنشاء كل صفحة وقتًا.
هذه ليست مشكلة كبيرة مع المواقع الأصغر ، ولكن على نطاق Smashing Magazine ، نحتاج إلى التفكير في ذلك الوقت أكثر قليلاً ، خاصة حتى يتمكن الأشخاص من الحفاظ على الإنتاجية عالية أثناء إنشاء المحتوى بشكل نشط يوميًا.
ما فعله Netlify هو إنشاء مجلد كبير /production-articles والذي حمل الجزء الأكبر من آلاف المقالات التي كانوا يستضيفونها بالفعل. بعد ذلك ، قم بإنشاء دليل عمل منفصل يسمى content/articles حيث يمكن وضع المقالات التي تم إنشاؤها وتحريرها بنشاط.
تعني عملية البناء هذه أن كل شخص كان يعمل على الموقع كان يعمل مع مجموعة أصغر من المقالات من أجل التنمية المحلية ، دون عوائق بانتظار الإنشاء بالكامل. تمت إدارة هذه العملية من خلال مهمة gulp لإعداد مقالات الإنتاج ، وتم تحرير Hugo للتعامل فقط مع ما كان يتم العمل عليه بنشاط.
أحد سلبيات هذا النهج هو أنه لا يزال يتطلب تشغيل البناء بالكامل ، مما يجعل العملية بطيئة. في منشور أصغر ، من المحتمل أن يكون هذا أقل أهمية ولكن على نطاق Smashing ، فإنه يبطئ عملية النشر.
واجهات برمجة التطبيقات مفتوحة المصدر
في البداية ، ذكرنا أنه من بين أمور أخرى ، كان Smashing مهتمًا بترحيل حل التجارة الإلكترونية الحالي ، والتعامل مع التعليقات خارج WordPress ، وإضافة وظائف للمصادقة. تم إنشاء كل هذه الوظائف باستخدام حلول مفتوحة المصدر تحتفظ بها Netlify ، مما أدى إلى تقسيمها إلى واجهات برمجة تطبيقات عديمة الحالة:
- GoTell
أداة إنشاء وواجهة برمجة تطبيقات للتعامل مع كميات كبيرة من التعليقات. - GoCommerce
واجهة برمجة تطبيقات صغيرة تعتمد على Go لمواقع التجارة الإلكترونية التي تتعامل مع الطلبات والمدفوعات. - GoTrue
واجهة برمجة تطبيقات صغيرة مفتوحة المصدر مكتوبة بلغة Golang يمكنها العمل كخدمة واجهة برمجة تطبيقات قائمة بذاتها للتعامل مع تسجيل المستخدم والمصادقة للمشاريع. يعتمد على OAuth2 و JWT وسيعالج تسجيل المستخدم والمصادقة وبيانات المستخدم المخصصة.
تتطلب كل واحدة من هذه القطع الترحيل وعوامل فريدة خاصة بها ، وعلى الرغم من أنها خارج نطاق هذه المقالة ، إلا أنها تمت تغطيتها جميعًا في كتاب مجاني شارك مات في كتابته بعنوان " Modern Web Development on the JAMstack ". سنقوم أيضًا ببعض الغوص العميق مثل هذا - مع أمثلة قابلة للاستخدام - في البحث والمصادقة في المنشورات اللاحقة.
خاتمة
ذهبت الهجرة بهدوء. بشكل محطم؟ حسنًا ... سارت الأمور على ما يرام. لم يتم معاقبة Smashing على نجاحها الخاص - عندما ظهرت مقالة شهيرة ، كان بإمكانهم خدمة المحتوى باستمرار ، ولم يعد ينفقوا على كميات كبيرة. إلى جانب ذلك ، أدى الانتقال إلى البنية التحتية لـ JAMstack إلى تحسين الأداء والأمان.
لاحظ ماركوس سيفيرث ، الرئيس التنفيذي السابق لمجلة Smashing:
"وقت التحميل الأول أسرع بكثير من ذي قبل ... قبل أن نضطر إلى انتظار تقديم ملف HTML لمدة 800 مللي ثانية والآن أصبح 80 مللي ثانية."
كانت هذه العملية ناجحة ومثل أي مشروع هندسي عظيم ، تم تعلم الدروس على طول الطريق. في هذه المقالة التالية من هذه السلسلة ، سنعرض برنامجًا تعليميًا وعرضًا توضيحيًا لما نوصي به في ضوء ما تعلمناه. إذا كنت ترغب في تحديث تطوير WordPress الخاص بك وجني مزايا الأداء والأمان لـ JAMstack ، فتابع القراءة!