دعنا نعترف بأن التطوير لـ WordPress أمر غريب الآن. سواء كنت جديدًا على WordPress أو كنت قد عملت معه على مدى دهور ، فإن تقديم ميزات "Full-Site Editing" (FSE) ، بما في ذلك محرر القوالب (WordPress 5.0) و محرر الموقع (WordPress 5.9) ، قلبت الطريقة التقليدية التي نبني بها قوالب WordPress والإضافات.
على الرغم من مرور خمس سنوات منذ أن التقينا بـ Block Editor لأول مرة ، إلا أن تطويره صعب لأن الوثائق إما غير متوفرة أو قديمة. هذا أكثر من بيان حول مدى سرعة تحرك ميزات FSE ، شيء ما رثى جيف في وظيفة حديثة.
مثال على ذلك: في عام 2018 ، أ سلسلة تمهيدية حول الدخول في تطوير Gutenberg تم نشره هنا حول CSS-tricks. لقد تغير الزمن منذ ذلك الحين ، وعلى الرغم من أن أسلوب التطوير هذا لا يزال يعمل ، فهو كذلك لا ينصح بعد الآن (إلى جانب ملف create-guten-block المشروع الذي يعتمد عليه أيضًا لم يعد يتم صيانته).
في هذه المقالة ، أعتزم مساعدتك في البدء في تطوير قوالب WordPress بطريقة تتبع المنهجية الحالية. لذا ، نعم ، يمكن أن تتغير الأمور جيدًا بعد نشر هذا. لكنني سأحاول التركيز عليها بطريقة آمل أن تجسد جوهر تطوير الكتلة ، لأنه على الرغم من أن الأدوات قد تتطور بمرور الوقت ، فمن المرجح أن تظل الأفكار الأساسية كما هي.
محرر جوتنبرج: (1) أداة إدراج الكتلة ، (2) منطقة المحتوى ، (3) الشريط الجانبي للإعدادات الائتمان: دليل محرر قوالب ووردبريس
ما هي قوالب ووردبريس بالضبط؟
لنبدأ بتوضيح بعض الالتباس مع ما نعنيه بمصطلحات مثل كتل. كل التطوير الذي تم إدخاله على هذه الميزات التي أدت إلى إصدار WordPress 5.0 كان الاسم الرمزي "غوتبورغ"- كما تعلم ، مخترع مطبعة.
منذ ذلك الحين ، تم استخدام "Gutenberg" لوصف كل شيء متعلق بالكتل ، بما في ذلك محرر الكتلة ومحرر الموقع ، لذا فقد أصبح معقدًا لدرجة أن بعض الأشخاص يخبئ الاسم. وفوق كل ذلك ، هناك ملف البرنامج المساعد جوتنبرج حيث يتم اختبار الميزات التجريبية لإدراجها المحتمل. وإذا كنت تعتقد أن استدعاء كل هذا "تحرير الموقع بالكامل" من شأنه أن يحل المشكلة ، هناك مخاوف من ذلك أيضًا.
لذلك ، عندما نشير إلى "الكتل" في هذه المقالة ، فإننا نعني مكونات إنشاء المحتوى في محرر قوالب WordPress. يتم إدراج الكتل في صفحة أو منشور وتوفر الهيكل لنوع معين من المحتوى. يأتي WordPress مزودًا بعدد قليل من الكتل "الأساسية" لأنواع المحتوى الشائعة ، مثل الفقرة والقائمة والصورة والفيديو والصوت ، على سبيل المثال لا الحصر.
بصرف النظر عن هذه الكتل الأساسية ، يمكننا أيضًا إنشاء كتل مخصصة. هذا هو ما يدور حوله تطوير قوالب WordPress (هناك أيضًا تصفية للكتل الأساسية لتعديل وظائفها ، ولكن من المحتمل أنك لن تحتاج إلى ذلك بعد).
ما تفعله الكتل
قبل أن نتعمق في إنشاء الكتل ، يجب أن نفهم أولاً كيفية عمل الكتل داخليًا. سيوفر لنا ذلك بالتأكيد الكثير من الإحباط لاحقًا.
الطريقة التي أحب أن أفكر بها في الكتلة هي مجردة إلى حد ما: بالنسبة لي ، الكتلة هي كيان ، مع بعض الخصائص (تسمى السمات) ، والتي تمثل بعض المحتوى. أعلم أن هذا يبدو غامضًا جدًا ، لكن ابق معي. تتجلى الكتلة أساسًا بطريقتين: واجهة رسومية في محرر الكتلة أو كقطعة من البيانات في قاعدة البيانات.
عند فتح محرر قوالب WordPress وإدراج كتلة ، على سبيل المثال كتلة Pullquote ، ستحصل على واجهة رائعة. يمكنك النقر فوق تلك الواجهة وتعديل النص المقتبس. توفر لوحة الإعدادات الموجودة على الجانب الأيمن من واجهة مستخدم Block Editor خيارات لضبط النص وتعيين مظهر الكتلة.
عند الانتهاء من إنشاء اقتباس سحب خيالي والضغط على نشر ، يتم تخزين المنشور بأكمله في قاعدة البيانات في ملف wp_posts الطاولة. هذا ليس شيئًا جديدًا بسبب جوتنبرج. هكذا عملت الأشياء دائمًا - يخزن WordPress محتوى المنشور في جدول مخصص في قاعدة البيانات. لكن الجديد هو ذلك تمثيل كتلة Pullquote هو جزء من المحتوى الذي يتم تخزينه فيه post_content مجال wp_posts الجدول.
كيف يبدو هذا التمثيل؟ الق نظرة:
It is not an exaggeration to say that peas can be described as nothing less than perfect spheres of joy.
The Encyclopedia of world peas
يبدو مثل HTML عادي ، أليس كذلك؟! هذه ، في اللغة التقنية ، هي الكتلة "المتسلسلة". لاحظ بيانات JSON في تعليق HTML ، "textAlign": "right". هذا هو ينسب - خاصية مرتبطة بالكتلة.
لنفترض أنك أغلقت محرر الكتلة ، ثم فتحته مرة أخرى في وقت لاحق. المحتوى من ذات الصلة post_content يتم استرداد الحقل بواسطة محرر الكتلة. ثم يوزع المحرر المحتوى المسترجع ، وحيثما يصادف هذا:
...
... تقول بصوت عالٍ لنفسها:
حسنًا ، يبدو هذا وكأنه كتلة Pullquote بالنسبة لي. حسنًا .. لقد حصلت على سمة أيضًا ... لدي ملف JavaScript يخبرني بكيفية إنشاء الواجهة الرسومية لكتلة Pullquote في المحرر من سماتها. يجب أن أفعل ذلك الآن لأجعل هذه الكتلة بكل مجدها.
بصفتك مطورًا للكتل ، فإن مهمتك هي:
أخبر WordPress أنك تريد تسجيل نوع معين من الحظر ، بتفاصيل فلان وفلان.
قم بتوفير ملف JavaScript لمحرر البلوك الذي سيساعده في عرض الكتلة في المحرر بينما "تسلسل" أيضًا لحفظه في قاعدة البيانات.
قم بتوفير أي موارد إضافية تحتاجها الكتلة لوظائفها المناسبة ، مثل الأنماط والخطوط.
شيء واحد يجب ملاحظته هو أن كل هذا التحويل من البيانات المتسلسلة إلى الواجهة الرسومية - والعكس صحيح - يحدث فقط في Block Editor. في الواجهة الأمامية ، يتم عرض المحتوى بالطريقة التي تم بها تخزينه بالضبط. لذلك ، بمعنى ما ، تعتبر الكتل طريقة رائعة لوضع البيانات في قاعدة البيانات.
نأمل أن يمنحك هذا بعض الوضوح فيما يتعلق بكيفية عمل الكتلة.
الشروع في تطوير قوالب ووردبريس
الكتل هي مجرد ملحقات
الكتل هي مجرد ملحقات. حسنًا ، تقنيًا ، أنت يمكن ضع الكتل في السمات وأنت يمكن وضع كتل متعددة في البرنامج المساعد. ولكن ، في كثير من الأحيان ، إذا كنت تريد إنشاء كتلة ، فستقوم بإنشاء مكون إضافي. لذلك ، إذا كنت قد أنشأت مكونًا إضافيًا لبرنامج WordPress ، فأنت بالفعل جزء من الطريق لتتحكم في إنشاء كتلة WordPress.
لكن دعنا نفترض للحظة أنك لم تقم أبدًا بإعداد مكون إضافي لبرنامج WordPress ، ناهيك عن كتلة. من أين تبدأ؟
إنشاء كتلة
لقد غطينا ما هي الكتل. لنبدأ في إعداد الأشياء لصنع واحدة.
تأكد من تثبيت Node لديك
هذا سوف يمنحك الوصول إلى npm و npx أوامر أين npm يقوم بتثبيت تبعيات الكتلة الخاصة بك ويساعد في تجميع الأشياء ، بينما npx يدير الأوامر على الحزم دون تثبيتها. إذا كنت تستخدم macOS ، فمن المحتمل أن يكون لديك بالفعل Node ويمكنك استخدامه nvm لتحديث الإصدارات. إذا كنت تستخدم نظام Windows ، فستحتاج إلى ذلك قم بتنزيل وتثبيت Node.
قم بإنشاء مجلد المشروع
الآن ، قد تصادف برامج تعليمية أخرى تقفز مباشرة إلى سطر الأوامر وترشدك إلى تثبيت حزمة تسمى @wordpress/create-block. هذه الحزمة رائعة لأنها تنشر مجلد مشروع كامل التكوين مع جميع التبعيات والأدوات التي تحتاجها لبدء التطوير.
أنا شخصياً أذهب إلى هذا الطريق عند إعداد الكتل الخاصة بي ، لكن دعني للحظة لأنني أريد أن أتطرق إلى الأشياء ذات الرأي التي يقدمها والتركيز فقط على الأجزاء المطلوبة من أجل فهم بيئة التطوير الأساسية.
هذه هي الملفات التي أود ذكرها على وجه التحديد:
readme.txt: هذا يشبه إلى حد ما الوجه الأمامي لدليل البرنامج المساعد ، وعادة ما يستخدم لوصف المكون الإضافي وتقديم تفاصيل إضافية حول الاستخدام والتثبيت. إذا قمت بإرسال الحظر الخاص بك إلى دليل البرنامج المساعد ووردبرس]، يساعد هذا الملف في ملء صفحة البرنامج المساعد. إذا كنت تخطط لإنشاء GitHub repo للمكوِّن الإضافي للكتلة ، فيمكنك أيضًا التفكير في ملف README.md الملف يحتوي على نفس المعلومات بحيث يتم عرضه بشكل جيد هناك.
package.json: هذا يحدد حزم العقدة المطلوبة للتطوير. سنقوم بفتحه عندما نصل إلى التثبيت. في تطوير ملحق WordPress الكلاسيكي ، قد تكون معتادًا على العمل مع Composer و composer.json بدلاً من ذلك. هذا هو ما يعادل ذلك.
plugin.php: هذا هو ملف البرنامج المساعد الرئيسي ، ونعم ، إنه PHP كلاسيكي! سنضع رأس البرنامج المساعد والبيانات الوصفية هنا ونستخدمه لتسجيل المكون الإضافي.
بالإضافة إلى هذه الملفات ، يوجد أيضًا ملف src الدليل ، الذي من المفترض أن يحتوي على الكود المصدري للكتلة الخاصة بنا.
وجود هذه الملفات و src الدليل هو كل ما تحتاجه للبدء. خارج تلك المجموعة ، لاحظ ذلك فنحن نحتاج فقط إلى ملف واحد من الناحية الفنية (plugin.php) لعمل البرنامج المساعد. الباقي إما يوفر المعلومات أو يستخدم لإدارة بيئة التطوير.
ما سبق ذكره @wordpress/create-block حزمة سقالات هذه الملفات (وأكثر) بالنسبة لنا. يمكنك التفكير في الأمر على أنه أداة أتمتة بدلاً من كونه ضرورة. بغض النظر ، فإنه يجعل المهمة أسهل ، لذلك يمكنك أن تأخذ حرية إنشاء سقالة بها من خلال تشغيل:
npx @wordpress/create-block
تثبيت تبعيات الكتلة
بافتراض أن لديك الملفات الثلاثة المذكورة في القسم السابق جاهزة ، فقد حان الوقت لتثبيت التبعيات. أولاً ، نحتاج إلى تحديد التبعيات التي سنحتاجها. نقوم بذلك عن طريق تحرير ملف package.json. أثناء استخدام ملف @wordpress/create-block الأداة المساعدة ، يتم إنشاء ما يلي لنا (تمت إضافة التعليقات ؛ لا يدعم JSON التعليقات ، لذا أزل التعليقات إذا كنت تنسخ الرمز):
{
// Defines the name of the project
"name": "block-example",
// Sets the project version number using semantic versioning
"version": "0.1.0",
// A brief description of the project
"description": "Example block scaffolded with Create Block tool.",
// You could replace this with yourself
"author": "The WordPress Contributors",
// Standard licensing information
"license": "GPL-2.0-or-later",
// Defines the main JavaScript file
"main": "build/index.js",
// Everything we need for building and compiling the plugin during development
"scripts": {
"build": "wp-scripts build",
"format": "wp-scripts format",
"lint:css": "wp-scripts lint-style",
"lint:js": "wp-scripts lint-js",
"packages-update": "wp-scripts packages-update",
"plugin-zip": "wp-scripts plugin-zip",
"start": "wp-scripts start"
},
// Defines which version of the scripts packages are used (24.1.0 at time of writing)
// https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/
"devDependencies": {
"@wordpress/scripts": "^24.1.0"
}
}
• @wordpress/scripts الحزمة هي التبعية الرئيسية هنا. كما ترون ، إنه ملف devDependency مما يعني أنه يساعد في التنمية. كيف ذلك؟ يفضح wp-scripts ثنائي يمكننا استخدامه لتجميع الكود الخاص بنا ، من ملف src دليل ل build الدليل ، من بين أمور أخرى.
هناك عدد من الحزم الأخرى التي يحتفظ بها WordPress لأغراض مختلفة. على سبيل المثال ، ملف @wordpress/components توفر الحزمة عدة الجاهزة UI مكونات لمحرر قوالب WordPress الذي يمكن استخدامه لإنشاء تجارب مستخدم متسقة لحجبتك التي تتوافق مع معايير تصميم WordPress.
أنت لا تفعل ذلك في الواقع حاجة لتثبيت هذه الحزم ، حتى إذا كنت ترغب في استخدامها. هذا لأن هؤلاء @wordpress التبعيات غير مجمعة مع كود الحظر الخاص بك. بدلا من ذلك ، أي import عبارات تشير إلى رمز من حزم المرافق - مثل @wordpress/components - تُستخدم لإنشاء ملف "أصول" أثناء التجميع. علاوة على ذلك ، يتم تحويل عبارات الاستيراد هذه إلى عبارات تقوم بتعيين الواردات إلى خصائص كائن عام. فمثلا، import { __ } from "@wordpress/i18n" إلى نسخة مصغرة من const __ = window.wp.i18n.__. (window.wp.i18n كونه كائنًا مضمونًا ليكون متاحًا في النطاق العالمي ، بمجرد أن يكون مطابقًا i18n ملف الحزمة في قائمة الانتظار).
أثناء تسجيل الحظر في ملف البرنامج المساعد ، يتم استخدام ملف "الأصول" ضمنيًا لإخبار WordPress بتبعيات الحزمة الخاصة بالكتلة. يتم إدراج هذه التبعيات تلقائيًا في قائمة الانتظار. يتم الاعتناء بكل هذا من وراء الكواليس ، نظرًا لأنك تستخدم ملف scripts حزمة. ومع ذلك ، لا يزال بإمكانك اختيار تثبيت التبعيات محليًا لإكمال التعليمات البرمجية ومعلومات المعلمة في ملف package.json ملف:
والآن بعد أن package.json تم إعداده ، يجب أن نكون قادرين على تثبيت كل تلك التبعيات من خلال الانتقال إلى مجلد المشروع في سطر الأوامر والتشغيل npm install.
الشروع في تطوير قوالب ووردبريس
أضف رأس البرنامج المساعد
إذا كنت قادمًا من تطوير المكون الإضافي الكلاسيكي لـ WordPress ، فمن المحتمل أنك تعلم أن جميع المكونات الإضافية تحتوي على مجموعة من المعلومات في ملف المكون الإضافي الرئيسي الذي يساعد WordPress في التعرف على المكون الإضافي وعرض معلومات عنه على شاشة الملحقات الخاصة بمسؤول WordPress.
وهنا ما @wordpress/create-block تم إنشاؤه لي في مكون إضافي يسمى "Hello World":
<?php
/**
* Plugin Name: Block Example
* Description: Example block scaffolded with Create Block tool.
* Requires at least: 5.9
* Requires PHP: 7.0
* Version: 0.1.0
* Author: The WordPress Contributors
* License: GPL-2.0-or-later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Text Domain: css-tricks
*
* @package create-block
*/
هذا موجود في ملف البرنامج المساعد الرئيسي ، والذي يمكنك استدعاء أي شيء تريده. قد تسميها شيئًا عامًا مثل index.php or plugin.php. create-block تسميها الحزمة تلقائيًا كل ما تقدمه كاسم مشروع عند تثبيته. نظرًا لأنني أطلقت على هذا المثال "Block Example" ، فقد أعطتنا الحزمة ملف block-example.php ملف مع كل هذه الأشياء.
سترغب في تغيير بعض التفاصيل ، مثل جعل نفسك المؤلف وغير ذلك. وليس كل هذا ضروريًا. إذا كنت أقوم بتدوير هذا من "نقطة الصفر" ، فقد يبدو الأمر أقرب إلى هذا:
<?php
/**
* Plugin Name: Block Example
* Plugin URI: https://css-tricks.com
* Description: An example plugin for learning WordPress block development.
* Version: 1.0.0
* Author: Arjun Singh
* License: GPL-2.0-or-later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Text Domain: css-tricks
*/
build/: تلقى هذا المجلد الأصول المجمعة عند معالجة الملفات لاستخدامها في الإنتاج.
node_modules: هذا يحمل جميع تبعيات التطوير التي قمنا بتثبيتها عند التشغيل npm install.
src/: يحتوي هذا المجلد على الكود المصدري للمكوِّن الإضافي الذي يتم تجميعه وإرساله إلى ملف build الدليل. سننظر في كل ملف من الملفات هنا بعد قليل.
.editorconfig: يحتوي هذا على تكوينات لتكييف محرر الكود الخاص بك مع تناسق التعليمات البرمجية.
.gitignore: هذا ملف ريبو قياسي يحدد الملفات المحلية التي يجب استبعادها من تتبع التحكم في الإصدار. لك node_modules بالتأكيد يجب تضمينها هنا.
package-lock.json: هذا ملف تم إنشاؤه تلقائيًا ويحتوي على تتبع تحديثات الحزم المطلوبة التي قمنا بتثبيتها معها npm install.
كتلة البيانات الوصفية
أريد أن أحفر في src الدليل معك ولكنك ستركز أولاً على ملف واحد فقط بداخله: block.json. إذا كنت قد استخدمت create-block ، إنه موجود بالفعل من أجلك ؛ إذا لم يكن كذلك ، فابدأ وقم بإنشائه. يميل WordPress بشدة لجعل هذه الطريقة القياسية والمتعارف عليها لتسجيل كتلة من خلال توفير البيانات الوصفية التي توفر سياق WordPress للتعرف على الكتلة وعرضها في Block Editor.
هناك في الواقع ملف مجموعة من المعلومات المختلفة يمكننا تضمينها هنا ، ولكن كل ما هو مطلوب بالفعل هو name و title. قد تبدو النسخة المصغرة للغاية كما يلي:
$schema يحدد تنسيق المخطط المستخدم للتحقق من صحة المحتوى في الملف. يبدو أنه شيء مطلوب ، لكنه اختياري تمامًا لأنه يسمح لمحرري التعليمات البرمجية الداعمين بالتحقق من صحة البنية وتوفير إمكانيات إضافية أخرى ، مثل تلميحات تلميحات الأدوات والإكمال التلقائي.
apiVersion يشير إلى أي إصدار من كتلة API يستخدم البرنامج المساعد. اليوم ، الإصدار 2 هو الأحدث.
name هي سلسلة فريدة مطلوبة تساعد في تحديد المكون الإضافي. لاحظ أنني سبقت هذا بـ css-tricks/ الذي أستخدمه كمساحة اسم للمساعدة في تجنب التعارض مع المكونات الإضافية الأخرى التي قد تحمل الاسم نفسه. قد تختار استخدام شيء مثل الأحرف الأولى من اسمك بدلاً من ذلك (على سبيل المثال as/block-example).
title هو الحقل الآخر المطلوب ، ويقوم بتعيين الاسم المستخدم أينما يتم عرض المكون الإضافي.
category يقوم بتجميع الكتلة مع الكتل الأخرى وعرضها معًا في محرر الكتلة. تشمل الفئات الحالية الحالية text, media, design, widgets, themeو embed، ويمكنك حتى إنشاء فئات مخصصة.
icon يتيح لك اختيار شيء من مكتبة Dashicons لتمثيل حظرك بشكل مرئي في محرر الكتلة. أنا أستخدم ال format-quote icon] (https://developer.wordpress.org/resource/dashicons/#format-quote) نظرًا لأننا نصنع نوعًا من اقتباس السحب الخاص بنا في هذا المثال. من الجيد أن نتمكن من الاستفادة من الرموز الموجودة بدلاً من الاضطرار إلى إنشاء أيقونات خاصة بنا ، على الرغم من أن هذا ممكن بالتأكيد.
editorScript هو مكان ملف JavaScript الرئيسي ، index.js، الأرواح.
سجل الكتلة
شيء واحد أخير قبل أن نصل إلى الكود الفعلي ، وهو تسجيل المكون الإضافي. لقد قمنا فقط بإعداد كل تلك البيانات الوصفية ونحتاج إلى طريقة يستخدمها WordPress لاستهلاكها. بهذه الطريقة ، يعرف WordPress مكان العثور على جميع أصول البرنامج المساعد حتى يمكن وضعها في قائمة الانتظار لاستخدامها في Block Editor.
يعد تسجيل الكتلة عملية ذات شقين. نحتاج إلى تسجيله في كل من PHP و JavaScript. من جانب PHP ، افتح ملف البرنامج المساعد الرئيسي (block-example.php في هذه الحالة) وأضف ما يلي مباشرةً بعد رأس المكون الإضافي:
هذا هو ما create-block تم إنشاء الأداة من أجلي ، ولهذا السبب تم تسمية الوظيفة على هذا النحو. يمكننا استخدام اسم مختلف. المفتاح ، مرة أخرى ، هو تجنب التعارض مع المكونات الإضافية الأخرى ، لذلك من الجيد استخدام مساحة الاسم هنا لجعلها فريدة قدر الإمكان:
لماذا نشير إلى build الدليل إذا كان الملف block.json مع وجود كل البيانات الوصفية للكتلة src؟ هذا لأن الكود لا يزال بحاجة إلى تجميع. ال scripts تعالج الحزمة التعليمات البرمجية من الملفات الموجودة في src الدليل ويضع الملفات المترجمة المستخدمة في الإنتاج في ملف build الدليل ، بينما أيضًا نسخ ملفblock.jsonملف في هذه العملية.
حسنًا ، دعنا ننتقل إلى جانب JavaScript لتسجيل الكتلة. افتح src/index.js وتأكد من أنها تبدو كالتالي:
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";
const { name } = metadata;
registerBlockType(name, {
edit: Edit,
save: Save,
});
نحن ندخل إلى أرض React و JSX! هذا يخبر WordPress بما يلي:
قم باستيراد ملف registerBlockType وحدة من @wordpress/blocks الحزمة.
استيراد البيانات الوصفية من block.json.
قم باستيراد ملف Edit و Save المكونات من الملفات المقابلة لها. سنضع رمزًا في هذه الملفات لاحقًا.
قم بتسجيل الكتلة ، واستخدم ملف Edit و Save مكونات لعرض الكتلة وحفظ محتواها في قاعدة البيانات.
ما الأمر مع edit و save المهام؟ تتمثل إحدى الفروق الدقيقة في تطوير قوالب WordPress في التمييز بين "النهاية الخلفية" و "الواجهة الأمامية" ويتم استخدام هذه الوظائف لعرض محتوى الكتلة في تلك السياقات ، حيث edit يتعامل مع عرض النهاية الخلفية و save يكتب المحتوى من Block Editor إلى قاعدة البيانات لعرض المحتوى على الواجهة الأمامية للموقع.
اختبار سريع
يمكننا القيام ببعض الأعمال السريعة لرؤية الكتلة الخاصة بنا تعمل في محرر الكتلة ويتم عرضها في الواجهة الأمامية. دعونا فتح index.js مرة أخرى واستخدم edit و save لعرض بعض المحتوى الأساسي الذي يوضح كيفية عملها:
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
const { name } = metadata;
registerBlockType(name, {
edit: () => {
return (
"Hello from the Block Editor"
);
},
save: () => {
return (
"Hello from the front end"
);
}
});
هذه في الأساس نسخة مجردة من نفس الكود الذي كان لدينا من قبل ، فقط نحن نشير مباشرة إلى البيانات الوصفية في block.json لجلب اسم الكتلة ، وترك Edit و Save المكونات لأننا نقوم بتشغيل الوظائف مباشرة من هنا.
يمكننا تجميع هذا عن طريق التشغيل npm run build في سطر الأوامر. بعد ذلك ، يمكننا الوصول إلى كتلة تسمى "Block Example" في Block Editor:
إذا أسقطنا الكتلة في منطقة المحتوى ، فسنحصل على الرسالة التي نرجعها من edit وظيفة:
الشروع في تطوير قوالب ووردبريس
إذا قمنا بحفظ المنشور ونشره ، فيجب أن نحصل على الرسالة التي نعود إليها من save الوظيفة عند عرضها على الواجهة الأمامية:
الشروع في تطوير قوالب ووردبريس
خلق كتلة
يبدو أن كل شيء مرتبط! يمكننا العودة إلى ما كان لدينا فيه index.js قبل الاختبار الآن بعد أن تأكدنا من أن الأمور تعمل:
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";
const { name } = metadata;
registerBlockType(name, {
edit: Edit,
save: Save,
});
لاحظ أن edit و save وظائف مرتبطة بملفين موجودين في ملف src دليل ذلك @wordpress/create-block تم إنشاؤه لنا ويتضمن جميع عمليات الاستيراد الإضافية التي نحتاجها في كل ملف. والأهم من ذلك ، أن هذه الملفات تنشئ ملف Edit و Save المكونات التي تحتوي على ترميز الكتلة.
ترميز الخلفية (src/edit.js)
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Edit() {
return (
{__("Hello from the Block Editor", "block-example")}
);
}
انظر ماذا فعلنا هنا؟ نحن نستورد الدعائم من @wordpress/block-editor الحزمة التي تتيح لنا إنشاء فئات يمكننا استخدامها لاحقًا للتصميم. نحن أيضًا نستورد ملف __ وظيفة التدويل للتعامل مع الترجمات.
الشروع في تطوير قوالب ووردبريس
ترميز الواجهة الأمامية (src/save.js)
هذا يخلق Save المكون وسنستخدم نفس الشيء مثل src/edit.js بنص مختلف قليلاً:
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Save() {
return (
{__("Hello from the front end", "block-example")}
);
}
مرة أخرى ، نحصل على فصل دراسي لطيف يمكننا استخدامه في CSS الخاص بنا:
الشروع في تطوير قوالب ووردبريس
كتل التصميم
لقد غطينا للتو كيفية استخدام دعائم الكتلة لإنشاء فئات. أنت تقرأ هذه المقالة على موقع كل شيء عن CSS ، لذلك أشعر أنني سأفتقد شيئًا ما إذا لم نتناول على وجه التحديد كيفية كتابة أنماط الكتلة.
التفريق بين الأنماط الأمامية والخلفية
إذا ألقيت نظرة على block.json في ال src ستجد في الدليل حقلين مرتبطين بالأنماط:
editorStyle يوفر المسار إلى الأنماط المطبقة على النهاية الخلفية.
style هو مسار الأنماط المشتركة التي يتم تطبيقها على كل من الواجهة الأمامية والخلفية.
كيف كويرك لديه مقال مفصل هذا يوضح منهجه في جعل محرر الواجهة الخلفية يشبه واجهة المستخدم الأمامية.
أذكر أن @wordpress/scripts نسخ الحزمة block.json ملف عندما يقوم بمعالجة التعليمات البرمجية في ملف /src الدليل ويضع الأصول المجمعة في /build الدليل. انها build/block.json الملف المستخدم لتسجيل الكتلة. هذا يعني أي مسار نقدمه فيه src/block.json يجب أن تكتب نسبة إلى build/block.json.
باستخدام Sass
يمكننا إسقاط ملفين من ملفات CSS في ملف build الدليل ، قم بالإشارة إلى المسارات بتنسيق src/block.json، قم بتشغيل البناء ، واسمه يومًا. لكن هذا لا يستفيد من القوة الكاملة لـ @wordpress/scripts عملية تجميع قادرة على تحويل Sass إلى CSS. بدلاً من ذلك ، نضع ملفات الأنماط الخاصة بنا في ملف src الدليل واستيرادها في JavaScript.
أثناء القيام بذلك ، يجب أن نكون مدركين لكيفية القيام بذلك @wordpress/scripts أنماط العمليات:
ملف اسمه style.css or style.scss or style.sass، المستوردة في كود JavaScript ، يتم تجميعها إلى style-index.css.
يتم تجميع كافة ملفات الأنماط الأخرى وتجميعها في حزم index.css.
• @wordpress/scripts يستخدم حزمة webpack لتجميع و @wordpress/scripts يستخدم المكون الإضافي PostCSS للعمل لأنماط المعالجة. يمكن تمديد PostCSS بمكونات إضافية. ال scripts تستخدم الحزمة تلك الخاصة بـ Sass و SCSS و Autoprefixer ، وكلها متاحة للاستخدام دون تثبيت حزم إضافية.
في الواقع ، عندما تقوم بتدوير الكتلة الأولية الخاصة بك مع @wordpress/create-block، ستحصل على بداية جيدة مع ملفات SCSS التي يمكنك استخدامها لبدء التشغيل:
editor.scss يحتوي على جميع الأنماط التي يتم تطبيقها على محرر الواجهة الخلفية.
style.scss يحتوي على جميع الأنماط المشتركة بين كل من الواجهة الأمامية والخلفية.
دعنا الآن نرى هذا النهج قيد التنفيذ من خلال كتابة القليل من Sass الذي سنقوم بتجميعه في CSS لمجموعتنا. على الرغم من أن الأمثلة لن تكون Sass-y جدًا ، ما زلت أكتبها إلى ملفات SCSS لإثبات عملية التجميع.
جبهة و أنماط النهاية الخلفية
حسنًا ، لنبدأ بالأنماط المطبقة على كل من الواجهة الأمامية والخلفية. أولاً ، نحن بحاجة إلى الإبداع src/style.scss (إنه موجود بالفعل إذا كنت تستخدم ملفات @wordpress/create-block) وتأكد من استيراده ، وهو ما يمكننا القيام به فيه index.js:
import "./style.scss";
فتح src/style.scss وقم بإسقاط بعض الأنماط الأساسية هناك باستخدام الفئة التي تم إنشاؤها لنا من دعائم الكتلة:
ثم قم باستيراده بتنسيق edit.js، وهو الملف الذي يحتوي على ملف Edit المكون (يمكننا استيراده في أي مكان نريد ، ولكن نظرًا لأن هذه الأنماط مخصصة للمحرر ، فمن المنطقي استيراد المكون هنا):
import "./editor.scss";
الآن عندما نجري npm run build، يتم تطبيق الأنماط على الكتلة في كلا السياقين:
الشروع في تطوير قوالب ووردبريسالشروع في تطوير قوالب ووردبريس
الإشارة إلى الأنماط بتنسيق block.json
قمنا باستيراد ملفات التصميم في ملف edit.js و index.js، ولكن تذكر أن خطوة الترجمة تنشئ ملفين CSS لنا في ملف build دليل: index.css و style-index.css على التوالى. نحتاج إلى الإشارة إلى هذه الملفات التي تم إنشاؤها في البيانات الوصفية للكتلة.
دعنا نضيف بضع عبارات إلى ملف block.json البيانات الوصفية:
يجري npm run build مرة أخرى ، قم بتثبيت وتنشيط المكون الإضافي على موقع WordPress الخاص بك ، وأنت على استعداد لاستخدامه!
يمكنك استخدام npm run start لتشغيل جهازك في وضع الساعة ، وتجميع التعليمات البرمجية تلقائيًا في كل مرة تقوم فيها بإجراء تغيير في الرمز الخاص بك وحفظه.
نحن نخدش السطح
تستفيد الكتل الفعلية من الشريط الجانبي لإعدادات Block Editor والميزات الأخرى التي يوفرها WordPress لإنشاء تجارب مستخدم ثرية. علاوة على ذلك ، حقيقة وجود نسختين أساسيتين من الكتلة الخاصة بنا - edit و save - تحتاج أيضًا إلى التفكير في كيفية تنظيم الكود الخاص بك لتجنب تكرار الكود.
ولكن نأمل أن يساعد هذا في إزالة الغموض عن العملية العامة لإنشاء كتل WordPress. هذا حقًا حقبة جديدة في تطوير WordPress. من الصعب تعلم طرق جديدة لفعل الأشياء ، لكنني أتطلع إلى رؤية كيف تتطور. أدوات مثل @wordpress/create-block المساعدة ، ولكن حتى ذلك الحين ، من الجيد أن تعرف بالضبط ما الذي تفعله ولماذا.
هل الأشياء التي غطيناها هنا ستتغير؟ على الأرجح! ولكن على الأقل لديك أساس للعمل منه بينما نستمر في مشاهدة قوالب WordPress وهي ناضجة ، بما في ذلك أفضل الممارسات لصنعها.
مراجع حسابات
مرة أخرى ، هدفي هنا هو تحديد مسار فعال للدخول في تطوير الكتلة في هذا الموسم حيث تتطور الأشياء بسرعة وتواجه وثائق WordPress صعوبة في اللحاق بالركب. فيما يلي بعض الموارد التي استخدمتها لجمع هذا معًا:
