וורדפרס היא אמנם מערכת שלמה לניהול תוכן אבל נדמה שכל כולה מתרכזת במחלקה אחת. מרגע שהבנתם את התפקיד של המחלקה הזאת, הבנתם את פעולתה של המערכת. המחלקה היא WP_Query.
כשעובדים עם וורדפרס (ולמעשה כל אתר אינטרנט) למעשה עובדים מול מסד נתונים (להלן: דאטה-בייס, DB). כל פעולה שעושים מעל גבי האתר דורשת שאילתא מהדאטהבייס. המידע ששמור בדאטהבייס “נשאל” אל זכרון המחשב, עובר מניפולציות כלשהן ואז מוצג או נשמר בחזרה לאחר העיבוד בדאטהבייס.
תפקידה של המחלקה WP_Query הוא לתווך בין מערכת הוורדפרס לדאטהבייס. ליתר דיוק, תפקידה של המחלקה הוא להגדיר את סוג השאילתא באמצעות שימוש ב-PHP, במקום להתעסק ב-SQL. לאחר מכן, שואלת המערכת מהדאטהבייס את הפוסטים ומאחסנת אותם במערך (או ליתר דיוק רשימה, List, כלומר מערך ללא מספר מוגדר של רכיבים). כל אחד מרכיבי המערך הינו כעת פוסט, וניתן לגשת אליו בצורה סידורית ובעיקר להשתמש בשדות שלו למטרות תצוגה.
הגישה אל השאילתא נקראת בעגת וורדפרס “הלולאה”, the loop. לאחר הגדרת האובייקט WP_Query, והזנת הפוסטים אליו באמצעות הגדרת פרמטרים מסויימים לשאילתא, הוא כולל כאמור מערך פוסטים. ה”ריצה” על המערך הזה נעשית באמצעות לולאות פשוטות while, foreach וכו’.
מרגע זה, כל התעסקות שלנו עם תוכן באתר (פוסט או קבוצת פוסטים) תהיה דרך הפונקציות שקשורות למחלקה הזאת והנגזרות ממנה – פונקציות העוסקות בשאילתות כשלהן, או בפוסטים כשלהם, שהם למעשה רכיבים במערכים שנוצרים על ידי השאילתות הללו.
כדי לעזור לנו לסווג את השאילתות, כל שאילתא שמתבצעת בתיווך המערכת מזינה את האובייקט גם במידע המדווח לנו באיזה סוג שאילתא מדובר. המידע הזה מתגלם במה שנקרא בתוכנה “דגלים” flags. הדגלים האלה הם למעשה משתנים בינאריים שמסמנים לנו אם השאילתא היא מסוג מסוים או לא. לדוגמה:
- האם מדובר בפוסטים שנכתבו בתאריך מסוים
- האם מדובר בפוסטים שנכתבו על ידי כותב מסוים
- האם הם שייכים לקטגוריה מסויימת (ולה בלבד)
- האם מדובר בתוצאות חיפוש
- וכן הלאה
בעזרת הדגלים הללו אנו יכולים “למיין” את השאילתות, ולפעול כלפי כל אחת בצורה אחרת. כך לדוגמה אנו מגדירים דפים מיוחדים שבהם יוצגו תוצאות חיפוש (שאילתות שהתבצעו דרך תיבת החיפוש של האתר), דפים אחרים עבור בלוג (פוסטים מסוג post), דפים עבור ארכיון וגם איזה סוג של ארכיון זה (ארכיון פוסטים מתאריך מסוים, משנה מסויימת וכו’), וכן הלאה. הדרך לבנות דפים כאלה היא להתנות ביצוע פונקציות מסויימות והצבת תגיות מסויימות של html באופי השאילתא. אנו מורים לדפדפן להציג בעמוד מידע מסויים רק אם הדגל הספציפי שאליו אנו רוצים להתייחס מונף. אם לא, אנו מורים לו לבצע משהו אחר.
אפשר למשול את הדבר למחסן ציוד. הוצאנו הזמנה לספק מסוים, על מנת שישלח לנו למחסן אספקה מסוג מסוים. בתעודת המשלוח שמביא נהג המשאית, מופיע סיכום המשלוח. אנו כמנהלי הרכש שמוציאים את הבקשה ולפעמים גם מקבלים אותה, אמנם יודעים מה מהות המשלוח, ובכל זאת כדאי שהדברים יהיו רשומים, כדי שכאיש רכש אחר יטפל בהזמנה, הוא יידע מה היא כוללת. כשהוא יקבל אותה, יהיו לו כמה כללי אצבע שיאפשרו לו לדעת במהירות באיזה סוג של אספקה מדובר. האם מדובר במכנסיים או בחולצות? האם מדובר בצבע ירוק או אדום? האם מדובר בפירמה מסויימת או לא? אם מדובר בסוג מסוים של ציוד צריך לפעול בצורה מסויימת ואם מדובר בסוג אחר, צריך לפעול אחרת. הכל על פי נהלים מסויימים. את הנהלים האלה אנו למעשה קובעים כשאנו מתכנתים את האתר. אנשי הרכש, הסדרנים שמטפלים במשלוח, הוא הדפדפן עצמו שמקבל את המשלוח מ”ספק התוכן” שלו, הדאטהבייס.
רמת הפרטיות של השדות האלה של הדגלים היא כזו שלנו כמשתמשים אין גישה לשינוי (set) שלהם, אלא רק לבדיקה (get) שלהם. מי שמבצעת את ה-set היא כאמור המערכת עצמה, בזמן שהיא מבצעת את השאילתא על פי הבקשה שלנו. רק אם נרצה לאתחל את השאילתא ולבצע שאילתא חדשה, נוכל להורות לאובייקט “לאפס” את הדגלים הללו. הם יונפו מחדש, עם השאילתא הבאה.
לעיתים השאילתא שנבקש תהיה “כללית” מדי. כלומר, מדובר אמנם על פוסטים שכולם עונים על התנאים שהצבנו כשביקשנו את השאילתא, אבל עדיין ניתן למיין את המידע שקיבלנו עוד יותר. אנו יכולים להגדיר את הקריטריונים למיון הנוסף הזה באמצעות מה שנקרא “משתני שאילתא” query_vars.
למשל: ביקשנו את כל הפוסטים מהקטגוריה “מאמרים” שנכתבו בשנת 2012 ואחסנו אותם במשתנה שנקרא $query1. אלא שכעת אנו רוצים להציג רק את הפוסטים שנכתבו על ידי הכותב משה. ניקח את $query1 ונבקש ממנו להתמקד ספציפית שבהם author_name=moshe.
נשאלת השאלה, למה לא להיות ספציפיים יותר בשאילתא הראשונית? למה לבקש הרבה יותר תוצאות כדי שנצטרך למיין אותן מאוחר יותר שוב? מסתבר שהדבר הזה נותן לנו גמישות בהצגת התכנים. עדיף לנו לפעמים לחסוך בזמן טעינה של נתונים, או לחסוך בשורות קוד (שמיתרגמות לפעולות מחשב), בכך שנבקש בהתחלה יותר מידע ממה שאנו צריכים ואחר כך נתמודד עם זה כשהמידע כבר ברשותנו. ניקח שוב את הדוגמה של מחסן הציוד. במקום שעל כל דרישה מצד הלקוח נשלח משאית שתביא מהספקים שלנו את הציוד הספציפי, עדיף לנו להזמין מלכתחילה יותר ציוד ואחר כך למיין את מה שקיבלנו כדי להוציא את ההזמנה ללקוח הספציפי.
לסיכום: דוגמת מחסן הציוד יכולה להבהיר לנו גם את תפקיד האתר שלנו. מדובר למעשה ברשת חנויות בגדים, שמוציאות הזמנות מלאי למחסן המרכזי של הרשת. כל חנות ברשת היא למעשה עמוד באתר האינטרנט שלנו. כל מחלקה בחנות היא אלמנט http בעמוד – header, footer, container, aside וכו’. כל חנות מוציאה הזמנות מסודרות של מלאי עבור כל מחלקה בעזרת לופ מיוחד בעבורה. הלופ הזה משתמש ברכיבים שנלקחו מהמערך שנתקבל בעזרת השאילתא – מפני שהוא בעצם מתייחס לשדות מסויימים של פוסט שהינו חלק מהשאילתא הכללית. השאילתא הזו, שנמצאת ב”מחסן המרכזי”, היא אותו האובייקט מסוג WP_Query שהוגדר מראש. אם במחסן חסר ציוד, מתבצעת הזמנה מהספק בעזרת שאילתא חדשה שמוגדרת. ואת כל המבצע הלוגיסטי הזה מנהלים אתם, המפתחים של האתר.