בואו נודה שפיתוח עבור וורדפרס הוא מוזר כרגע. בין אם אתה חדש בוורדפרס או שעבדת איתה עידנים, ההקדמה של תכונות "עריכת אתר מלא" (FSE), כולל עורך בלוק (WordPress 5.0) וה- עורך אתרים (WordPress 5.9), שיפרו את הדרך המסורתית שבה אנו בונים ערכות נושא ותוספים של וורדפרס.
למרות שחלפו חמש שנים מאז שפגשנו את עורך הבלוק בפעם הראשונה, הפיתוח עבורו קשה כי התיעוד חסר או מיושן. זו יותר הצהרה על כמה מהר תכונות FSE זזות, משהו ג'וף התבכיין בפוסט האחרון.
מקרה לדוגמא: בשנת 2018, an סדרת היכרות על כניסה לפיתוח גוטנברג פורסם ממש כאן ב-CSS-tricks. הזמנים השתנו מאז, ולמרות שסגנון הפיתוח הזה עדיין עובד, הוא כן לא מומלץ יותר (חוץ מזה, ה create-guten-block הפרויקט שעליו הוא מבוסס גם אינו מתוחזק יותר).
במאמר זה, אני מתכוון לעזור לך להתחיל בפיתוח בלוקים של וורדפרס באופן שעוקב אחר המתודולוגיה הנוכחית. אז כן, דברים עשויים להשתנות לאחר פרסום זה. אבל אני הולך לנסות ולהתמקד בזה בצורה שתופס בתקווה את המהות של פיתוח בלוקים, כי למרות שהכלים עשויים להתפתח עם הזמן, סביר להניח שרעיונות הליבה יישארו זהים.
עורך גוטנברג: (1) מוסיף הבלוק, (2) אזור התוכן ו-(3) סרגל ההגדרות אשראי: מדריך עורך בלוק וורדפרס
מהן בלוקים של וורדפרס, בדיוק?
בואו נתחיל בלשדר קצת בלבול עם מה שאנחנו מתכוונים במונחים כמו אבני. כל הפיתוח שנכנס לתכונות הללו עד לוורדפרס 5.0 קיבל את שם הקוד "גוטנברג" - אתה יודע, הממציא של דפוס.
מאז, "גוטנברג" שימש לתיאור כל מה שקשור לחסימות, כולל עורך החסימות ועורך האתר, כך שזה נהיה מפותל עד כדי כך שחלק מהאנשים מתעבים את השם. לסיום הכל, יש א תוסף גוטנברג שבו נבדקות תכונות ניסיוניות להכללה אפשרית. ואם אתה חושב שקורא לכל זה "עריכת אתר מלא" יפתור את הבעיה, יש דאגות גם עם זה.
לכן, כאשר אנו מתייחסים ל"בלוקים" במאמר זה, אנו מתכוונים לרכיבים ליצירת תוכן בעורך החסימות של וורדפרס. בלוקים מוכנסים לדף או לפוסט ומספקים את המבנה לסוג מסוים של תוכן. וורדפרס נשלחת עם קומץ בלוקים "ליבה" לסוגי תוכן נפוצים, כמו פסקה, רשימה, תמונה, וידאו ואודיו, למנות כמה.
מלבד בלוקים הליבה הללו, אנו יכולים ליצור גם בלוקים מותאמים אישית. זה מה שעוסק בפיתוח בלוקים של וורדפרס (יש גם סינון בלוקי ליבה כדי לשנות את הפונקציונליות שלהם, אבל סביר להניח שלא תזדקק לזה עדיין).
מה בלוקים עושים
לפני שנצלול ליצירת בלוקים, עלינו לקבל תחילה תחושה של איך בלוקים פועלים באופן פנימי. זה בהחלט יחסוך לנו המון תסכול בהמשך.
הדרך שבה אני אוהב לחשוב על בלוק היא מופשטת למדי: בשבילי, בלוק הוא ישות, עם כמה מאפיינים (הנקראים תכונות), שמייצגת תוכן כלשהו. אני יודע שזה נשמע די מעורפל, אבל תישאר איתי. בלוק מתבטא בעצם בשני אופנים: כממשק גרפי בעורך הבלוק או כגוש נתונים במסד הנתונים.
כשאתה פותח את עורך בלוק וורדפרס ומכניס בלוק, נגיד בלוק Pullquote, אתה מקבל ממשק נחמד. אתה יכול ללחוץ לתוך הממשק הזה ולערוך את הטקסט המצוטט. חלונית ההגדרות בצד ימין של ממשק המשתמש של Block Editor מספקת אפשרויות להתאמת הטקסט והגדרת מראה הבלוק.
כשתסיים ליצור את הציטוט המפואר שלך ותלחץ על פרסם, הפוסט כולו נשמר במסד הנתונים ב- wp_posts שולחן. זה לא משהו חדש בגלל גוטנברג. כך הדברים תמיד עבדו - וורדפרס מאחסנות תוכן בטבלה ייעודית במסד הנתונים. אבל מה שחדש זה ייצוג של בלוק 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". זה an תכונה - נכס המשויך לבלוק.
נניח שאתה סוגר את עורך החסימה, ואז זמן מה לאחר מכן, פותח אותו שוב. התוכן מהרלוונטי post_content השדה מאוחזר על ידי עורך החסימה. לאחר מכן העורך מנתח את התוכן שאוחזר, ובכל מקום שהוא נתקל בזה:
...
...זה אומר לעצמו בקול:
בסדר, זה נראה לי כמו בלוק Pullquote. הממ... יש לו גם תכונה... יש לי קובץ JavaScript שאומר לי איך לבנות את הממשק הגרפי לבלוק Pullquote בעורך מהתכונות שלו. אני צריך לעשות את זה עכשיו כדי להפוך את הבלוק הזה במלוא הדרו.
כמפתח בלוק, התפקיד שלך הוא:
אמור לוורדפרס שאתה רוצה לרשום סוג מסוים של בלוק, עם פרטים על כך וכך.
ספק את קובץ ה-JavaScript ל-Block Editor שיעזור לו לעבד את הבלוק בעורך ובמקביל "תבצע" אותו בסידרה כדי לשמור אותו במסד הנתונים.
ספק כל משאב נוסף שהגוש צריך לצורך הפונקציונליות התקינה שלו, למשל. סגנונות ופונטים.
דבר אחד שיש לציין הוא שכל ההמרה הזו מנתונים מסודרים לממשק גרפי - ולהיפך - מתרחשת רק בעורך הבלוקים. בקצה הקדמי, התוכן מוצג בדיוק כפי שהוא מאוחסן. לכן, במובן מסוים, בלוקים הם דרך מהודרת להכניס נתונים למסד הנתונים.
אני מקווה שזה נותן לך קצת בהירות לגבי אופן הפעולה של בלוק.
תחילת העבודה עם פיתוח בלוק וורדפרס
בלוקים הם רק תוספים
בלוקים הם רק תוספים. ובכן, טכנית, אתה יכול לשים בלוקים בעיצובים ואתה יכול לשים מספר בלוקים בתוסף. אבל, לעתים קרובות יותר מאשר לא, אם אתה רוצה לעשות חסימה, אתה הולך ליצור תוסף. לכן, אם אי פעם יצרת תוסף וורדפרס, אז אתה כבר בחלק מהדרך כדי לקבל שליטה ביצירת חסימת וורדפרס.
אבל בואו נניח לרגע שמעולם לא הגדרתם תוסף וורדפרס, שלא לדבר על חסימה. מאיפה בכלל מתחילים?
הקמת בלוק
סקרנו מה הם בלוקים. בואו נתחיל להגדיר דברים כדי ליצור אחד.
ודא שמותקן אצלך Node
זה ייתן לך גישה ל npm ו npx פקודות, איפה npm מתקין את התלות של הבלוק שלך ועוזר להדר דברים, תוך כדי npx מריץ פקודות על חבילות מבלי להתקין אותן. אם אתה משתמש ב-macOS, כנראה שכבר יש לך Node ואתה יכול להשתמש בו nvm לעדכון גרסאות. אם אתה ב-Windows, תצטרך הורד והתקן את Node.
צור תיקיית פרויקט
כעת, אתה עלול להיתקל במדריכים אחרים שקופצים ישר לשורת הפקודה ומורה לך להתקין חבילה בשם @wordpress/create-block. החבילה הזו נהדרת מכיוון שהיא פולטת תיקיית פרויקטים מעוצבת במלואה עם כל התלות והכלים שאתה צריך כדי להתחיל לפתח.
אני אישית הולך בדרך הזו כשאני מקים בלוקים משלי, אבל משעשע אותי לרגע כי אני רוצה לחתוך דרך הדברים הדעתניים שהוא מציג ולהתמקד רק בקטעים הנדרשים למען הבנת סביבת הפיתוח הבסיסית.
אלה הקבצים שאני רוצה לקרוא במיוחד:
readme.txt: זה בערך כמו החזית הקדמית של ספריית הפלאגין, המשמשת בדרך כלל לתיאור התוסף ולספק פרטים נוספים על שימוש והתקנה. אם תגיש את החסימה שלך ל- ספריית תוספים של וורדפרס, קובץ זה עוזר לאכלס את דף הפלאגין. אם אתה מתכנן ליצור ריפו של GitHub עבור תוסף החסימה שלך, אתה יכול גם לשקול א README.md קובץ עם אותו מידע כך שהוא יוצג שם יפה.
package.json: זה מגדיר את חבילות ה-Node הנדרשות לפיתוח. נפצח אותו כשנגיע להתקנה. בפיתוח פלאגין וורדפרס קלאסי, ייתכן שאתה רגיל לעבוד עם Composer ו-a 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 תלות לא מצורפת עם קוד החסימה שלך. במקום זאת, כל import הצהרות המתייחסות לקוד מחבילות שירות - כמו @wordpress/components - משמשים לבניית קובץ "נכסים", במהלך ההידור. יתרה מכך, הצהרות ייבוא אלו מומרות להצהרות הממפות את הייבוא למאפיינים של אובייקט גלובלי. לדוגמה, import { __ } from "@wordpress/i18n" מומר לגרסה ממוזערת של const __ = window.wp.i18n.__. (window.wp.i18n בהיותו אובייקט שמובטח שיהיה זמין בהיקף הגלובלי, ברגע המקביל i18n קובץ החבילה נמצא בתור).
במהלך רישום החסימה בקובץ הפלאגין, נעשה שימוש בקובץ "נכסים" באופן מרומז כדי לספר לוורדפרס את התלות בחבילה של החסימה. התלות הללו ממוקמות באופן אוטומטי בתור. כל זה מטופל מאחורי הקלעים, בתנאי שאתה משתמש ב- scripts חֲבִילָה. עם זאת, אתה עדיין יכול לבחור להתקין באופן מקומי תלות עבור השלמת קוד ופרמטרים שלך package.json קובץ:
עכשיו package.json מוגדר, אנו אמורים להיות מסוגלים להתקין את כל התלות הללו על ידי ניווט לתיקיית הפרויקט בשורת הפקודה והפעלה npm install.
תחילת העבודה עם פיתוח בלוק וורדפרס
הוסף את כותרת הפלאגין
אם אתה מגיע מפיתוח תוסף וורדפרס קלאסי, אז אתה בוודאי יודע שלכל התוספים יש גוש מידע בקובץ התוסף הראשי שעוזר לוורדפרס לזהות את התוסף ולהציג מידע עליו במסך התוספים של אדמין וורדפרס.
הנה מה @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.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 , זה כבר שם בשבילך; אם לא, קדימה, צור אותו. וורדפרס נשענת קשה כדי להפוך זאת לדרך הקנונית והסטנדרטית לרשום בלוק על ידי אספקת מטא נתונים המספקים הקשר של וורדפרס לזהות את החסימה וגם לעבד אותו בעורך החסימות.
$schema מגדיר את עיצוב הסכימה המשמש לאימות התוכן בקובץ. זה נשמע כמו דבר נדרש, אבל זה לגמרי אופציונלי מכיוון שהוא מאפשר לעורכי קוד תומכים לאמת את התחביר ולספק יתרונות נוספים, כמו רמזים לכלי והשלמה אוטומטית.
apiVersion מתייחס לאיזו גרסה של חסימת API התוסף משתמש. כיום, גרסה 2 היא העדכנית ביותר.
name היא מחרוזת ייחודית נדרשת שעוזרת לזהות את הפלאגין. שים לב שהקדמתי לזה css-tricks/ שבו אני משתמש כמרחב שמות כדי למנוע התנגשויות עם תוספים אחרים שעשויים להיות בעלי אותו שם. ייתכן שתבחר להשתמש במשהו כמו ראשי התיבות שלך במקום זאת (למשל. as/block-example).
version זה משהו וורדפרס מציעה להשתמש כמנגנון שיבוץ מטמון כאשר יוצאות גרסאות חדשות.
title הוא השדה הנדרש הנוסף, והוא מגדיר את השם שבו נעשה שימוש בכל מקום שבו התוסף מוצג.
category מקבץ את הבלוק עם בלוקים אחרים ומציג אותם יחד בעורך הבלוקים. קטגוריות קיימות נוכחיות כוללות text, media, design, widgets, theme, ו embed, ואתה אפילו יכול ליצור קטגוריות מותאמות אישית.
icon מאפשר לך לבחור משהו מתוך ספריית דאשיקונס כדי לייצג חזותית את הבלוק שלך בעורך החסימות. אני משתמש ב- format-quote סמל](https://developer.wordpress.org/resource/dashicons/#format-quote) מכיוון שאנו יוצרים ציטוט משיכה משלנו בדוגמה זו. זה נחמד שאנחנו יכולים למנף אייקונים קיימים במקום ליצור משלנו, אם כי זה בהחלט אפשרי.
editorScript הוא המקום שבו קובץ ה-JavaScript הראשי, index.js, חיים.
רשום את החסימה
דבר אחרון לפני שנפגע בקוד בפועל, וזה לרשום את התוסף. פשוט הגדרנו את כל המטא נתונים ואנחנו צריכים דרך ל-WordPress לצרוך אותם. בדרך זו, וורדפרס יודעת היכן למצוא את כל נכסי התוספים כך שניתן יהיה להעמידם בתור לשימוש בעורך החסימה.
רישום החסימה הוא תהליך כפול. אנחנו צריכים לרשום אותו גם ב-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! זה אומר לוורדפרס:
ייבא את registerBlockType מודול מה- @wordpress/blocks חֲבִילָה.
ייבא מטא נתונים מ block.json.
ייבא את Edit ו Save רכיבים מהקבצים המתאימים להם. אנחנו נכניס קוד לקבצים האלה מאוחר יותר.
רשום את הבלוק, והשתמש ב- Edit ו Save רכיבים לעיבוד הבלוק ושמירת התוכן שלו במסד הנתונים.
מה נסגר עם ה edit ו save פונקציות? אחד הניואנסים של פיתוח בלוק וורדפרס הוא הבחנה בין ה"קצה האחורי" ל"הקצה הקדמי" ופונקציות אלו משמשות לעיבוד תוכן הבלוק בהקשרים אלה, שבהם edit מטפל בעיבוד אחורי ו save כותב את התוכן מעורך החסימה למסד הנתונים לצורך רינדור התוכן בקצה הקדמי של האתר.
מבחן מהיר
אנחנו יכולים לעשות עבודה מהירה כדי לראות את הבלוק שלנו עובד בעורך החסימות ומעובד בקצה הקדמי. בואו נפתח 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 בשורת הפקודה. לאחר מכן, יש לנו גישה לבלוק שנקרא "דוגמה לחסימה" בעורך החסימה:
אם נשאיר את הבלוק לאזור התוכן, נקבל את ההודעה שנחזיר מה- 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 עבור הבלוק שלנו. למרות שהדוגמאות לא הולכות להיות מאוד חצויות, אני עדיין כותב אותן לקבצי SCSS כדי להדגים את תהליך ההידור.
חזית ו סגנונות אחורי
אוקיי, בואו נתחיל עם סגנונות המוחלים הן בחלק הקדמי והן בקצה האחורי. ראשית, עלינו ליצור src/style.scss (זה כבר שם אם אתה משתמש @wordpress/create-block) ולוודא שאנחנו מייבאים אותו, מה שנוכל לעשות בו index.js:
import "./style.scss";
פתח את src/style.scss ושחרר שם כמה סגנונות בסיסיים באמצעות המחלקה שנוצרה עבורנו מהאביזרים של הבלוק:
זהו לעת עתה! כאשר אנו מפעילים את ה-build, זה נקלט לתוך build/style.css ומתייחסים אליו הן על ידי עורך הבלוק והן על ידי הקצה הקדמי.
סגנונות אחורי
ייתכן שיהיה עליך לכתוב סגנונות ספציפיים לעורך החסימות. בשביל זה, צור src/editor.scss (שוב, @wordpress/create-block עושה את זה בשבילך) ושחרר שם כמה סגנונות:
לאחר מכן ייבא אותו פנימה edit.js, שהוא הקובץ שמכיל את שלנו Edit רכיב (אנחנו יכולים לייבא אותו בכל מקום שנרצה, אבל מכיוון שהסגנונות האלה מיועדים לעורך, זה הגיוני יותר לייבא את הרכיב לכאן):
import "./editor.scss";
עכשיו כשאנחנו רצים npm run build, הסגנונות מוחלים על הבלוק בשני ההקשרים:
תחילת העבודה עם פיתוח בלוק וורדפרסתחילת העבודה עם פיתוח בלוק וורדפרס
הפניה לסגנונות ב block.json
ייבאנו את קבצי הסטיילינג ב- edit.js ו index.js, אך נזכיר ששלב הקומפילציה יוצר עבורנו שני קבצי CSS ב- build Directory: index.css ו style-index.css בהתאמה. אנחנו צריכים להתייחס לקבצים שנוצרו במטא נתונים של הבלוק.
הפעלה npm run build שוב, התקן והפעל את הפלאגין באתר הוורדפרס שלך, ואתה מוכן להשתמש בו!
אתה יכול להשתמש npm run start להפעיל את המבנה שלך במצב שעון, קומפילציה אוטומטית של הקוד שלך בכל פעם שאתה מבצע שינוי בקוד שלך ושומר.
אנחנו מגרדים את פני השטח
בלוקים בפועל עושים שימוש בסרגל הצד של עורך החסימות ובתכונות אחרות ש-WordPress מספקת כדי ליצור חוויות משתמש עשירות. יתרה מכך, העובדה שיש בעצם שתי גרסאות של הבלוק שלנו - edit ו save - אתה גם צריך לחשוב איך אתה מארגן את הקוד שלך כדי למנוע כפילות קוד.
אבל אני מקווה שזה עוזר לבטל מיסטיקה של התהליך הכללי ליצירת בלוקים של וורדפרס. זהו באמת עידן חדש בפיתוח וורדפרס. זה קשה ללמוד דרכים חדשות לעשות דברים, אבל אני מצפה לראות איך זה יתפתח. כלים כמו @wordpress/create-block לעזור, אבל גם אז זה נחמד לדעת בדיוק מה זה עושה ולמה.
האם הדברים שסיקרנו כאן עומדים להשתנות? ככל הנראה! אבל לפחות יש לך קו בסיס לעבוד ממנו כשאנחנו ממשיכים לראות בלוקים של וורדפרס מתבגרים, כולל שיטות עבודה מומלצות להכנתם.
הפניות
שוב, המטרה שלי כאן היא למפות דרך יעילה לכניסה לפיתוח בלוקים בעונה הזו שבה דברים מתפתחים במהירות ותיעוד וורדפרס קצת מתקשה להדביק את הקצב. הנה כמה משאבים שהשתמשתי בהם כדי לחבר את זה ביחד:
