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

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

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

נקודה אחת שחוזרת לאורך כל המדריך: מנוע הקונטיינרים צריך לרוץ ברקע. גם כשכל העבודה שלכם היא בשורת הפקודה, היא רק מדברת עם המנוע ולא מחליפה אותו. אם 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

פעולות שגרתיות רבות מלוח הבקרה אפשר לבצע כאן בשורה אחת, וחשוב מזה, אפשר לחזור עליהן. דוגמה שימושית היא להפעיל את כל התוספים בבת אחת אחרי ייבוא 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. לפני שינוי אמיתי מריצים בדיקה עם --dry-run, ומדלגים על עמודת guid:

ddev wp search-replace \
  'https://example.com' \
  'https://example.ddev.site' \
  --skip-columns=guid \
  --dry-run

ddev wp search-replace \
  'https://example.com' \
  'https://example.ddev.site' \
  --skip-columns=guid

הריצו אותו אחרי ייבוא DB מסביבה בעלת כתובת אחרת. בדקו את דוח ה-dry-run לפני ההרצה השנייה, במיוחד כשמדובר ב-Multisite או בטבלאות של תוספים.

צילום מסך של פלט הפקודה ddev wp search-replace בטרמינל, עם סיכום הטבלאות וכמות ההחלפות בכל אחת — פלט ddev wp search-replace, סיכום הטבלאות וכמה החלפות בוצעו בכל אחת.

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

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

ddev composer install
ddev npm install
ddev npm run build

זה משמעותי במיוחד אם אתם עובדים עם Bedrock או בונים ערכת בלוקים. ב-Bedrock הנוכחי, למשל, מתקינים תוסף מספריית WordPress.org כך:

ddev composer require wp-plugin/query-monitor

הגרסאות שרצות בתוך הקונטיינר נקבעות בהגדרות DDEV והפרויקט, ולא לפי מה שמותקן במקרה במחשב המארח.

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

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

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' \
  --skip-columns=guid \
  --dry-run

ddev wp search-replace \
  'https://example.com' \
  'https://example.ddev.site' \
  --skip-columns=guid

עברו על דוח ה-dry-run ורק אז הריצו את הפקודה השנייה.

קובץ dump עשוי להכיל פרטי משתמשים, הזמנות וסודות שנשמרו במסד הנתונים. אל תכניסו אותו ל-Git, שמרו אותו במקום מוגן ומחקו אותו כשהוא כבר לא נחוץ.

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

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

ddev snapshot
ddev snapshot --list
ddev snapshot restore --latest
# או: ddev snapshot restore <snapshot-name>

snapshot שומר את מצב מסד הנתונים. אפשר להציג את הרשימה ולשחזר snapshot בשם, או להשתמש ב---latest כדי לשחזר את האחרון. ההבדל הפרקטי מ-export-db הוא ש-snapshot מיועד לרשת ביטחון מקומית ומהירה, ואילו export הוא dump נייד שנוח להעביר או לאחסן במערכת גיבוי נפרדת.

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

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

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

ddev describe

צילום מסך של פלט הפקודה ddev describe בטרמינל, עם טבלת כתובות ה-URL, פרטי מסד הנתונים וסטטוס השירותים — פלט ddev describe, טבלת ה-URLs, פרטי ה-DB וסטטוס השירותים של הפרויקט.

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, דורשות הקשר של פרויקט. מחוץ לתיקייה DDEV לא יידע מול איזה פרויקט להריץ אותן.

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

ddev poweroff

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

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

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

מנוע הקונטיינרים לא רץ

אם ddev start נכשל עם שגיאת התחברות, בדקו שמנוע הקונטיינרים שבחרתם פעיל. זה יכול להיות Docker Desktop, OrbStack, Colima או Docker CE בתוך WSL2, בהתאם להתקנה שלכם. שורת הפקודה של DDEV מדברת עם המנוע, ולכן אינה יכולה להפעיל פרויקט כשהוא כבוי.

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

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

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

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

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

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

לסיכום

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

כדי לחבר את הסביבה לניהול גרסאות, המשיכו למדריך Git לפרילנסרים בוורדפרס. אם אתם רוצים שגם ליבת WordPress והתוספים ינוהלו כתלויות, עברו למדריך Bedrock.