WordPress Lifecycle

בגסות, מחזור חיים של אפליקציית ווב הוא בקשת HTTP שמורכבת מכתובת וממידע נוסף שמגיע בצמוד אליה. כשהבקשה היא מסוג GET, המידע יכול להתלוות לשורת הכתובת, והוא גלוי לעיני כל. אפליקציות מודרניות מבצעות Routing על ידי ניתוח שורת הכתובת שמתקבלת, ושליחה של העמוד המתאים למה שנתבקש. יש כמה סוגים של אפליקציות אך בכולם מתבצע ראוטינג שמחליט מה לעשות ואיזה פלט לתת בהתאם לתוכן הבקשה. וורדפרס נחשבת לאפליקציה מסורתית. כלומר, אפליקציה שבה הן עיבוד המידע המוקדם והן הפלט מחושבים בצד השרת ונפלטים אל המשתמש בצורה מוגמרת פחות או יותר. כמובן שהיא לא חייבת להיות כזו, ניתן לפלוט אל המשתמש מידע פחות מוגמר ולתת לקליינט להמשיך ולעבד את המידע. במקרה כזה מחזור החיים של האפליקציה ייחתך בשלב ה"רינדור", כלומר מה שייפלט למסך הוא לא קובץ html ובקשות נוספות אלא פשוט מידע.

במחזור החיים של וורדפרס יש בדרך כלל 5 שלבים:

1. ה-URL מתקבל. וורדפרס מפגיש אותו עם תבניות הקישורים שיש אצלו, ועל פיהן באמצעות Regex הוא מחלץ את מה שייקרא בהמשך משתני השאילתא, query vars.

לדוגמה, אם הוגדר לו מבנה הקישורים הקישורים הרגיל, והכתובת שהוא קיבל היא

www.domain.com/author/avi

הוא ניגש למודול WP_Rewrite ומתחיל לעבור על כל ה"כללים" שיש לו. באיזה שהוא שלב הוא יגיע אל הכלל הזה

[author/([^/]+)/?$] => index.php?author_name=$matches[1]

שיתפרש לו בצורה הזו: אם יש לך בכתובת author ואז דבר כלשהוא וסלאש, טען את הקובץ index.php עם משתנה בשם author name שערכו "הדבר". כלומר, משתנה הקוורי שיועבר הלאה ייקרא author name, במקרה שלנו עם הערך avi.

2. בשלב זה הוא מרכיב שאילתא לדאטהבייס. על פי המשתנים שחולצו משורת הכתובת ועל פי כללים נוספים שהוגדרו לו, חלקם על ידי המתכנת, הוא בונה מערך ארגומנטים שבונה שאילתא לדאטהבייס.

בדוגמה דלעיל, הארגומנטים שיועברו יהיו:

array(
	'posts_per_page'   => 5,
	'offset'           => 0,
	'category'         => '',
	'category_name'    => '',
	'orderby'          => 'date',
	'order'            => 'DESC',
	'include'          => '',
	'exclude'          => '',
	'meta_key'         => '',
	'meta_value'       => '',
	'post_type'        => 'post',
	'post_mime_type'   => '',
	'post_parent'      => '',
	'author'	   => '',
	'author_name'	   => 'avi',
	'post_status'      => 'publish',
	'suppress_filters' => true 
)

שזה בעצם הערכים הדיפולטיביים של הקונסטרקטור של האובייקט WP_Query שנרמסים במידה והוא מקבל ערכים אחרים. הערכים הדפולטיביים כפי שהוגדרו על ידי הפונקציה get_posts שבמקרה הזה author name שבדפולט הוא ריק, קיבל את הערך avi. הארגומנטים הללו נכנסים לקונסטרקטור של WP_Query וייצרו שאילתא, במקרה הזה:

SELECT SQL_CALC_FOUND_ROWS wp_posts.*
FROM wp_posts 
WHERE 1=1 
AND wp_posts.post_author IN (1) 
AND wp_posts.post_type = 'post'
AND (wp_posts.post_status = 'publish') 
ORDER BY wp5k_posts.post_date DESC
LIMIT 0, 20

שמשמעותה: אנא הבא לי את כל הפוסטים הציבוריים מסוג "פוסט", שגם הכותב שלהם הוא משתמש מס' 1 (שזה avi). בשלב זה או בשלב הבא, שהוא טרם הגשת השאילתא לדאטהבייס, ניתן עוד לקסטם את השאילתא לפי בקשתינו, להוסיף מה שרוצים או להשמיט מה שרוצים. השאילתא הסופית היא שזו שתועבר לדאטהבייס.

3. השאילתא עוברת לדאטהבייס, הדאטהבייס מחשב את מה שצריך ומקבל תוצאות. התוצאות נכנסות לתוך פרופרטי בשם posts באובייקט WP_Query. כעת ניתן להשתמש בתוצאות, בין באמצעות גישה ישירה לפרופרטי, או באמצעות מעבר עליהן אחת אחרי אחת באמצעות Iterator – מה שנקרא בוורדפרס The Loop. אלא שהדבר ייעשה בשלב 5.

4. אל כל שאילתא נלווים עוד כמה משתנים שנותנים עוד כמה פרטים אודות השאילתא. במקרה שלנו, אם מסרתי query var שזהותו author name, מן הסתם אני מעוניין בכל הפוסטים ששייכים לאותו הכותב שיוצגו ב"עמוד כותב". וורדפרס מסייעים לי, על ידי שמסמנים ב"דגל" את השאילתא הזאת. מעתה השאילתא תסומן כ- is_author כי מדובר בעמוד כותב, וכ- is_archive כי מדובר באוסף פוסטים המסווג כארכיון. וורדפרס מספיק משוכללת כדי לנחש לבד באיזה סוג של עמוד מדובר, והניחוש הזה, הדגלים הללו, יעזרו לי לנווט לאיזה View ארצה לגשת. במקרה שלנו, מאחר שאני מעוניין בעמוד author, אבדוק האם יש טמפלייט מפורט ואטען את מה שאמצא. ה- fallback שלי ילך על הראשון שמופיע ברשימה זו:
א. author-avi.php
ב. author-1.php
ג. author.php
ד. archive.php
ה. index.php

החלק הזה הוא למעשה ה- Controller. יכולנו לחסוך את ריבוי הקבצים אילו היינו משתמשים ב- index.php כקונטרולר יחיד, ומנווטים דרכו בשאלה באיזה עמוד אנחנו (לאובייקט מסוג WP_Query יש פרופרטיז שמספרים, וקיימות גם פונקציות גלובליות שיכולות לענות על זה) ועל פי התשובה היינו בוחרים מה לטעון ואיך. אך וורדפרס הופכים את החיים שלנו לקלים יותר ומאפשרים לנו לפתוח View לכל אחד מסוגי השאילתות (לעיל: ב'-ה').

5. לאחר שהסקנו איפה אנחנו נמצאים, אנו יכולים לרוץ על הלופ. באמצעות לופ מפורש, כלומר for/foreach או באמצעות פונקציות העזר של ה- Loop. וורדפרס עוזרים לנו כשמציעים כמה פונקציות נוחות שפועלות רק בכפוף לשימוש ב- Loop, אך כל מה שאפשרי במסגרתו אפשרי גם שלא במסגרתו בסינטקס אחר. ראוי לזכור זאת.

כאן ראוי לציין שאם אנחנו לא מעוניינים להציג תוצאות בפרונט, כמו לדוגמה במקרים שאנו רוצים להציג תוצאות בממשק האדמין או ב- ajax, שלב 5 יהיה אחר. כלומר, לא ה- Views של הפרונט, אלא Views אחרים שעליהם ידובר בזמן ובמקום המתאים. בעקרון, שלבים 1 עד 4 הם השלבים שנטענים בקובץ wp-load.php בתיקיה הראשית של וורדפרס, ושלב 5 נטען בשלב שנקרא template_redirect. על השלב הזה, ועל שמות השלבים הקודמים, נדון בהזדמנות אחרת. הם נקראים hooks, וניתן להתמקד בהם באמצעות actions.

טיפים ומאמרים lifecycle, וורדפרס

בחזרה למאמרים