פיתוח מקומי באמצעות zinnector dev

הפקודה zinnector dev מריצה WordPress אמיתי במחשב שלכם, ומגישה את התוספים ואת ערכות הנושא שבפרויקט שלכם, עם גרסת PHP לבחירתכם. מאמר זה מסביר על שתי סביבות הריצה שבהן היא יכולה להשתמש, כיצד לבחור גרסאות, מה מוגש ומאיפה, והיכן סביבת הריצה נשמרת בדיסק — כך שמה שאתם בודקים מקומית הוא בדיוק מה שאתם פורסים.

שתי סביבות הריצה, ומדוע שתיהן אמיתיות

Playground היא ברירת המחדל. WordPress Playground מקמפל PHP ל-WebAssembly ומריץ אותו בתוך Node, כך שמחשב נייד שמותקן עליו רק Node מפעיל WordPress תוך שניות. כל גרסת PHP מ-5.2 עד 8.5 זמינה לשימוש. היא כוללת קבוצה קטנה של הרחבות PHP (intl, redis, memcached כפי שנמדד בגרסת ה-build הנוכחית), אשר מספיקה לרוב עבודות הפיתוח של תוספים וערכות נושא.

Docker מריץ קונטיינרים מקוריים של php-fpm ושל MariaDB. הוא איטי יותר, דורש daemon של Docker וכ-1.2 ג"ב של תמונות (images), ותומך ב-PHP מ-7.4 עד 8.5 — אך הוא מריץ PHP מקורי עם חבילת ההרחבות המלאה, כולל imagick ו-gd. זהו הפתרון הנכון כאשר מה שעליכם לבדוק הוא הרחבה שאינה כלולה ב-build של WebAssembly.

zinnector dev                       # playground
zinnector dev --runtime docker      # native PHP + MariaDB

המעבר ל-Docker לעולם אינו מתבצע כנסיגה שקטה (fallback). מפתח שחושב שהוא נמצא על WebAssembly אך בפועל נמצא על Docker קיבל מענה שגוי מכלי שניסה לעזור, ולכן יש לבקש זאת במפורש לפי שם.

בחירת גרסאות PHP ו-WordPress

zinnector dev --php 8.1 --wp 6.7    # develop against a specific pair
zinnector dev --port 9401           # when 9400 is taken
zinnector dev --no-login            # do not sign in to wp-admin automatically
zinnector dev --verbose             # show the runtime's own output

ערכי ברירת המחדל מגיעים מהקובץ zinnector.json שבפרויקט — php, wordpress, runtime ו-port — שנוצר על ידי zinnector new ושמומלץ לבצע עליו commit, כדי שכל מי שעובד על הפרויקט יריץ את אותן הגרסאות. דגל בשורת הפקודה גובר על הגדרות הקובץ עבור אותה הרצה.

הגרסה שאתם מצהירים עליה והגרסה שרצה בפועל הן שתי עובדות שונות. הפקודה zinnector dev --once מפעילה את סביבת הריצה, מדפיסה את מה שהיא מדווחת עליו בפועל — גרסת PHP, גרסת WordPress, הרחבות שנטענו — ועוצרת. הפקודה zinnector check --probe משתמשת באותה המדידה כשהיא משווה את הפרויקט שלכם מול משבצת אחסון.

מה מוגש מתוך הפרויקט שלכם

סביבת הריצה מחברת (mounts) את הספריות wp-content/plugins, wp-content/themes ו-wp-content/mu-plugins של הפרויקט שלכם ישירות, כך שקובץ שאתם שומרים מתעדכן בזמן אמת בטעינה מחדש הבאה. ספריות שקיימות אך אינן מכילות תוכן ממשי אינן מחוברות באופן מכוון: חיבור של ספריית themes/ ריקה מעל ערכות הנושא של סביבת הריצה עצמה היה מותיר את WordPress ללא שום ערכת נושא, מה שיוביל לשגיאת 500 ריקה במקום להצגת האתר שלכם. זו הסיבה שהתבנית הבסיסית (scaffold) שומרת ספריות ריקות עם קובץ .gitkeep, וזו הסיבה שהן אינן דורסות דבר עד שתשימו בתוכן ערכת נושא.

היכן סביבת הריצה נמצאת

סביבת הריצה של WordPress מורדת בשימוש הראשון במקום להישלח מובנית עם ה-CLI — החבילה שמכילה את כל גרסאות ה-PHP שוקלת כ-570 מ"ב, ומפתח שרק רוצה להציג רשימת אתרים אינו אמור לשלם על כך במשאבים. היא נשמרת במטמון (cache) הייעודי של Zinnector®, בנתיב ~/.cache/zinnector/runtimes/playground/<version> (או בכל מקום שאליו מצביע ZINNECTOR_CACHE_DIR), ולעולם לא בתוך הפרויקט שלכם, כך שהיא לא יכולה להגיע למאגר שלכם או לעץ הקבצים ש-zinnector push מודד. ההורדה מתבצעת על ידי ה-npm שלכם, המופעל כ-node npm-cli.js — לעולם לא דרך מעטפת (shell).

גרסת סביבת הריצה מוצמדת לגרסת ה-CLI, כך ששני מפתחים באותו פרויקט מריצים את אותן גרסאות PHP. הפקודה zinnector dev --reset-runtime מוחקת את סביבת הריצה המותקנת ומתקינה אותה מחדש, וזהו הפתרון עבור סביבת ריצה שהותקנה אך אינה מצליחה לעלות.

ב-Node 26 ומעלה

ה-CLI עצמו רץ על כל גרסה של Node החל מ-24 ומעלה. עם זאת, המודול המקורי של סביבת הריצה מספק קבצים בינאריים שנבנו מראש רק עבור Node 24 ו-25 (נכון לספטמבר 2026). במקום לקמפל דבר — מה שב-Windows דורש התקנה של Visual Studio — Zinnector® מוריד Node 24 עבור סביבת הריצה בלבד, במשקל של כ-30 מ"ב, המאומת מול סכומי הביקורת (checksums) שמפרסם nodejs.org, לתוך אותו המטמון. הודעת ההתקנה מציינת זאת כאשר הדבר רלוונטי. שום דבר בהתקנת ה-Node שלכם אינו משתנה.

תוכן קשור

• תחילת העבודה · פריסה · מדריך פקודות · פתרון בעיות