DDEV ביום-יום: wp-cli, ייבוא DB וניהול כמה אתרים

במדריך להקמת סביבת DDEV הקמנו אתר וורדפרס מקומי מאפס, סביבה תואמת-ייצור, נקייה, שעולה בפקודה אחת. עכשיו לעבודה היומיומית בה. להריץ wp-cli, לייבא ולייצא מסד נתונים, להחליף דומיין בלי לשבור כלום, לנהל כמה פרויקטים במקביל, ולטפל בתקלות הנפוצות כשהן מגיעות.

זה פוסט 2 מתוך 2. אם עוד לא הקמתם סביבה, התחילו שם וחזרו לכאן. ומה שכתוב כאן עובד גם על macOS וגם על Windows. ב-Windows ההנחה היא שאתם עובדים מתוך טרמינל WSL2 (סביבת הלינוקס שבתוך Windows), שם DDEV רץ, ולא ב-PowerShell או ב-CMD. כל הפקודות זהות בשתי המערכות; ההבדל הוא רק מאיפה אתם מריצים אותן.

נקודה אחת שחוזרת לאורך כל המדריך: Docker Desktop צריך לרוץ ברקע. גם כשכל העבודה שלכם היא בשורת הפקודה, שורת הפקודה רק מדברת עם המנוע ולא מחליפה אותו. אם DDEV מתלונן שהוא לא מצליח להתחבר, הדבר הראשון לבדוק הוא שהמנוע פעיל.

ddev wp: wp-cli בלי להתקין כלום

הדבר שאני משתמש בו הכי הרבה הוא ddev wp. זה ה-wp-cli הרשמי של וורדפרס, רץ בתוך הקונטיינר, מול ה-PHP ומסד הנתונים הנכונים, בלי שהתקנתם אותו ובלי להקליד פרטי התחברות ל-DB.

ddev wp plugin list
ddev wp user list
ddev wp option get blogname
ddev wp cache flush

כל מה שהייתם עושים ב-wp-admin בכמה קליקים, אתם עושים כאן בשורה אחת, וחשוב מזה, אפשר לחזור על זה. דוגמה שאני אוהב: להפעיל את כל התוספים בבת אחת אחרי ייבוא DB טרי:

ddev wp plugin activate --all

search-replace: להחליף דומיין בלי לשבור serialized data

כשמעבירים אתר בין סביבות, מהשרת למקומי, או הפוך, הדומיין משתנה, וה-URL הישן מפוזר בכל מסד הנתונים. find/replace ידני על קובץ ה-SQL ישבור לכם נתונים, כי וורדפרס שומר הרבה ערכים כ-serialized data (הגדרות תוסף, שדות ACF, widgets), והפורמט הזה מקודד בתוכו את אורך כל מחרוזת. אם תחליפו example.com ב-example.ddev.site בטקסט גולמי, האורך כבר לא תואם, והערך הופך לזבל.

wp search-replace יודע לפרק את ה-serialized data, להחליף נכון, ולהרכיב מחדש:

ddev wp search-replace 'https://example.com' 'https://example.ddev.site'

הריצו אותו אחרי כל ייבוא של DB מהשרת. בלעדיו תקבלו אתר עם קישורים שבורים, תמונות שלא נטענות, ולוח בקרה שמנסה לדבר עם הדומיין החי.

ddev composer ו-ddev npm: הכלים אפויים בפנים

אותו עיקרון חל על שאר כלי הפיתוח. Composer ו-Node כבר מותקנים בתוך הקונטיינר, אז אין צורך בגרסה תואמת על המחשב שלכם:

ddev composer require wpackagist-plugin/some-plugin
ddev composer install
ddev npm install
ddev npm run build

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

ייבוא וייצוא מסד נתונים

שתי פקודות מטפלות בהעברת מסד הנתונים בין מכונות:

ddev export-db --file=mysite.sql.gz
ddev import-db --file=mysite.sql.gz

export-db יוצר dump דחוס ונייד, הקובץ שאתם מעבירים לעמית או מעלים לשרת. import-db טוען אותו לפרויקט הנוכחי. הזרימה הקלאסית להוריד עותק טרי מהשרת לעבודה מקומית היא: מייצאים מהשרת, מייבאים מקומית, ומיד מריצים search-replace להחלפת הדומיין:

ddev import-db --file=production.sql.gz
ddev wp search-replace 'https://example.com' 'https://example.ddev.site'

snapshots: רשת ביטחון מקומית מהירה

לפני שאתם עושים משהו מסוכן למסד הנתונים, מיגרציה גדולה, ניסוי בתוסף חדש, search-replace שאתם לא בטוחים לגביו, קחו snapshot. זה גיבוי מקומי מהיר שיושב ב-volume, ולא קובץ שאתם צריכים לנהל:

ddev snapshot
ddev snapshot restore-select

snapshot תופס את המצב הנוכחי תוך שניות. restore-select נותן לכם לבחור מהרשימה לאיזה מצב לחזור. אני לוקח snapshot כהרגל לפני כל ניסוי, זה זול, מהיר, ומחזיר אתכם בקלות למצב תקין. ההבדל הפרקטי מ-export-db: ה-snapshot הוא הגנה מקומית מהירה שנשארת בפרויקט; ה-export הוא הקובץ הנייד שמעבירים החוצה.

להציץ פנימה: describe, logs, launch

כשמשהו לא ברור, שלוש פקודות נותנות תמונת מצב.

ddev describe מציג הכול על הפרויקט הנוכחי, כתובות, פורטים, פרטי מסד הנתונים, סטטוס השירותים:

ddev describe

ddev logs מראה מה קורה בתוך הקונטיינרים, שימושי כשהאתר מחזיר 500 ואתם רוצים לראות את שגיאת ה-PHP האמיתית:

ddev logs
ddev logs -f          # מעקב חי
ddev logs -s db       # logs של שירות ספציפי

ו-ddev launch פשוט פותח את האתר בדפדפן, או ישר ללוח הבקרה:

ddev launch
ddev launch /wp-admin

ddev ssh: כשצריך להיכנס פנימה

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

לפעמים צריך להיכנס לתוך הקונטיינר עצמו, להריץ רצף פקודות בלי prefix, לבדוק את הסביבה האמיתית, או לדבר ישירות עם מסד הנתונים:

ddev ssh           # shell לתוך קונטיינר ה-web
ddev ssh -s db     # shell לתוך קונטיינר ה-DB

בתוך ddev ssh אתם בסביבת לינוקס של הקונטיינר, עם ה-PHP והכלים שלו, ו-wp רץ ישירות בלי prefix. מתי זה שימושי: לבדוק אילו extensions של PHP מותקנים (php -m), לדבג מקרה של “עובד אצלי אבל לא באתר”, או להתחבר ישירות ל-DB דרך הרשת הפרטית. למשימה חד-פעמית אפשר גם בלי shell מלא:

ddev exec wp option get blogname

Mailpit: כל המיילים נלכדים מקומית

וורדפרס שולח מיילים כל הזמן, איפוס סיסמה, קבלות, התראות תוספים, טפסי יצירת קשר. בסביבה מקומית אתם לא רוצים שהם ייצאו באמת. DDEV מגיע עם Mailpit: שירות שלוכד כל מייל יוצא ומציג אותו בתיבת דואר בדפדפן, בלי שאף הודעה עוזבת את המחשב.

ddev launch -m

זה הופך בדיקה של זרימת מיילים לפשוטה, מפעילים תהליך ששולח מייל, פותחים את Mailpit, ורואים בדיוק מה נשלח ואיך זה נראה. בלי לזהם תיבות אמיתיות, בלי לשלוח בטעות לקוחות אמיתיים מתוך עותק מקומי.

לנהל כמה פרויקטים במקביל

זה אחד הדברים שבזכותם עברתי ל-DDEV. כל פרויקט נרשם ב-registry גלובלי כשמקימים אותו, ולכן חלק מהפקודות עובדות מכל מקום, לפי שם:

ddev list                  # כל הפרויקטים: שם, סטטוס, סוג, URL
ddev start mysite
ddev describe mysite
ddev stop mysite

אתם יכולים להריץ כמה אתרים בו-זמנית בלי התנגשות. כל פרויקט מקבל hostname יציב משלו (mysite.ddev.site, client-b.ddev.site), וקונטיינר router אחד מנתב את כולם דרך אותם פורטים 80/443. אתם פותחים שני אתרים בשתי לשוניות, וכל אחד חי בקופסה משלו, גרסאות PHP שונות, מסדי נתונים נפרדים, אפס דליפה ביניהם.

שימו לב להבחנה: פקודות לפי שם פרויקט (ddev start mysite, ddev describe mysite) עובדות מכל תיקייה. אבל פקודות שרצות בתוך הקונטיינר, ddev wp, ddev composer, ddev ssh, דורשות שתהיו בתוך תיקיית הפרויקט עצמו. מחוצה לה תקבלו “unknown command”.

וכשסיימתם ליום, או שהמחשב מתחיל לעבוד קשה מדי עם כמה פרויקטים פתוחים:

ddev poweroff

זה עוצר את כל פרויקטי DDEV ואת ה-router בבת אחת, ומשחרר משאבים. אני מריץ אותו כשאני מסיים לעבוד, מתוך הרגל. מחר בבוקר ddev start בפרויקט שאני צריך, והכול חוזר, ה-volumes שורדים, הדאטה במקומה.

תקלות נפוצות ואיך לפתור אותן

רוב התקלות ב-DDEV נופלות לכמה דליים מוכרים. הנה אלה שתפגשו.

Docker Desktop לא רץ

התקלה הנפוצה ביותר, והראשונה לבדוק. אם ddev start נתקע או נכשל עם שגיאת התחברות, ודאו ש-Docker Desktop פעיל ברקע. כפי שאמרנו, שורת הפקודה רק מדברת עם המנוע, והמנוע חייב לרוץ. ב-Windows זה אומר ש-Docker Desktop צריך לרוץ ושאתם מריצים את ddev מתוך טרמינל WSL2, לא מ-PowerShell.

התנגשות פורטים

לפעמים ddev start נכשל כי משהו אחר כבר תופס את פורט 80 או 443, אפליקציית פיתוח אחרת, שרת מקומי ישן, או Apache שעלה ברקע. הפתרון הפשוט הוא ddev poweroff כדי לשחרר את ה-router, ואז להפעיל מחדש רק את מה שאתם צריכים. אם משהו מחוץ ל-DDEV תופס את הפורט, תצטרכו לסגור אותו או להגדיר ל-DDEV פורטי router חלופיים בהגדרות הפרויקט.

ביצועים איטיים ב-Mac

ב-macOS, גישה לקבצים בין המחשב לקונטיינר חוצה את הגבול בין macOS למכונת הלינוקס שמתחת ל-Docker, וזה איטי. בשביל זה קיים Mutagen, מנגנון שמסנכרן ברקע עותק מהיר של הקבצים בתוך Docker עם תיקיית הפרויקט שלכם. אתם עורכים במחשב כרגיל, הקונטיינר קורא מהעותק המהיר, וההפרש מורגש. ב-DDEV החדש Mutagen פעיל כברירת מחדל בפרויקטים מסוג וורדפרס. אם הביצועים מרגישים איטיים ב-Mac, ודאו שהוא דולק, וברוב המקרים זה פותר את הבעיה. ב-Windows עם WSL2 הסיפור שונה: שם המהירות תלויה בכך שהקבצים יושבים בתוך מערכת הקבצים של ה-WSL2, ולא בתיקיית Windows שממופה פנימה, שמירת הפרויקט בתוך ה-WSL2 היא ההבדל בין מהיר לאיטי.

בעיות הרשאות קבצים

לפעמים נתקלים בקבצים שנוצרו בתוך הקונטיינר ושייכים למשתמש לא נכון, וקשה לערוך אותם מהמחשב. DDEV ממפה את המשתמש שלכם לתוך הקונטיינר בדיוק כדי שזה לא יקרה, קבצים שאתם יוצרים מבפנים שייכים לכם מבחוץ. אם בכל זאת נתקעתם בקובץ עקשן, ddev restart מסדר את ההרשאות, ובלאו הכי עדיף ליצור ולערוך קבצים מצד המחשב מלכתחילה.

לסיכום

זה הליבה של העבודה היומיומית ב-DDEV. בפועל אני נוגע בחלק קטן מהפקודות רוב הזמן: ddev start בבוקר, ddev wp להרבה דברים, ddev import-db ו-search-replace כשמושכים עותק מהשרת, ddev snapshot לפני כל ניסוי מסוכן, ו-ddev poweroff כשמסיימים. כל השאר נמצא שם כשצריך אותו.

הצעד הבא הטבעי הוא לקחת את הסביבה הזו ולהפוך אותה לזרימת deploy מסודרת לשרת, גרסאות, staging, והעלאה שאינה “גרירת קבצים ב-FTP”. אבל זה כבר מדריך נפרד.

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