בניתי תוסף לניהול metadata של תמונות ב-3 שעות. לא תוסף צעצוע — תוסף עם bulk processing, חיבור ל-OpenAI ול-Claude, ועמוד הגדרות באדמין. לפני שנה זה היה לוקח שבוע עבודה לפחות. אבל לפני שרצים לספר כמה AI מדהים, צריך להגיד את האמת: מתוך 3 השעות האלה, שעה וחצי הלכה על דיבאג של קוד שה-AI כתב לא נכון.
זה המציאות של פיתוח תוספי וורדפרס עם AI ב-2026. ה-AI כותב קוד שעובד 80% מהזמן. את ה-20% הנותרים אתה צריך לדעת לתקן, ואם אתה לא מפתח, אתה תקוע. המאמר הזה לא רשימת כלים ולא סקירה כללית. הוא על טכניקות פרקטיות שגיליתי אחרי חודשים של עבודה יומיומית עם Claude Code ו-Cursor על פרויקטים אמיתיים של וורדפרס.
לפני שנצלול לטכניקות עצמן, צריך לסדר את הבסיס. סביבת עבודה וניהול גרסאות, ואחרי זה הבנה של מה בכלל מנסים לבנות. כי וורדפרס זה לא React, וזה משנה את כל הגישה.
למה וורדפרס + AI זה סיפור אחר
ההבדל שכל התכנים על AI ופיתוח לא מדברים עליו: וורדפרס זה PHP. רוב המודלים של AI אומנו בעיקר על JavaScript ו-Python. כש-Claude או GPT כותבים React, הם על הקרקע שלהם. כשהם כותבים PHP עם WordPress hooks, הם מגששים.
אם מישהו אומר לך שאפשר לבנות תוסף וורדפרס ב-Lovable או Base44 או Bolt, הוא לא בנה תוסף וורדפרס. הכלים האלה מצוינים לפרונט-אנד, אבל הם לא מספקים סביבת PHP. אין שם Apache, אין MySQL, אין WordPress שרץ. אי אפשר לפתח תוסף בכלי שלא יכול להריץ אותו.
כתוצאה מזה, העבודה על וורדפרס עם AI היא דרך טרמינל בלבד. Claude Code שרץ בתיקיית הפרויקט, Cursor שפתוח על תיקיית התוסף, או Copilot שעושה autocomplete ב-VS Code. אין ממשק ויזואלי שמייצר לך תוסף עובד בלחיצת כפתור. מי שרגיל לפיתוח ע"י בינה מלאכותית דרך כלים ויזואליים צריך לשנות גישה כשהוא עובר לפיתוח תוספים של ממש.
ויש עוד דבר שספציפי לוורדפרס: כל הרעיון של פיתוח לוורדפרס הוא בבסיסו reverse engineering, בשונה בפיתוח פלטפורמות NATIVE, בוורדפרס אנחנו מתממשקים לתוספים אחרים, תבניות אחרות ואנחנו צריכים להתאים את עצמינו לאקוסיסטם.
לפני שכותבים שורת קוד, צריך לחקור: איזה hook קיים, מה הוא מקבל, מתי הוא נקרא. זה מחקר, לא רק כתיבת קוד. ואם לא נותנים ל-AI את ה-context הזה, הוא ימציא hooks שלא קיימים. ראיתי את זה עשרות פעמים.
הכנת סביבת עבודה לוקאלית
בלי סביבה לוקאלית אין פיתוח תוספים עם AI. ה-AI צריך לראות קבצים, לקרוא קוד קיים, ולהריץ את מה שהוא כתב. אי אפשר לפתח באוויר.
איזה כלי להשתמש
יש כמה אפשרויות:
WP Local (ההמלצה שלי). מתקין PHP, MySQL ו-WordPress מוכנים להרצה. ממשק פשוט, לא צריך להגדיר כלום ידנית. לוחצים "Create Site" ותוך דקה יש אתר וורדפרס שרץ.
MAMP סביבת Apache/MySQL/PHP למק ול-Windows. יותר שליטה על הגדרות, אבל יותר עבודה ידנית.
WAMP אותו רעיון, ל-Windows בלבד.
אני עובד עם WP Local כי הוא חוסך את כל שלב ההגדרות. כשעובדים עם AI ורוצים לבדוק קוד מהר, כל דקה שמבזבזים על הגדרת סביבה זו דקה מיותרת.
למה סביבה לוקאלית הכרחית דווקא עבור AI
כש-Claude Code או Cursor עובדים על תוסף, הם צריכים גישה לקבצים של הפרויקט. הם קוראים את wp-content/plugins, מבינים את מבנה התיקיות, רואים אילו hooks כבר בשימוש. בלי זה הם כותבים קוד בחלל ריק, וזה כמעט תמיד נכשל.
אבל הסיבה הכי חשובה היא הלופ של דיבאג. ככה זה עובד בפועל: ה-AI כותב קוד, אתה מרפרש את הדף בדפדפן, רואה שגיאה, מעתיק אותה בחזרה ל-AI, הוא מתקן, ושוב. הלופ הזה הוא הבסיס של פיתוח וורדפרס עם AI. בלי סביבה שרצה, אי אפשר להריץ אותו, ובלי הלופ הזה אי אפשר לפתח תוסף עם AI שעובד באמת.
טיפ מעשי: להתקין WP Local, ליצור אתר חדש, ולפתוח את תיקיית wp-content/plugins ב-VS Code עם Cursor. זהו. אפשר להתחיל לפתח.
עבודה עם מנהל גרסאות – Git
זה אם אתם לא יודעים אז חבל להתחיל, זה הבסיס של פיתוח עם AI, אין לי מאמר שלי בנושא, אבל אם לא יצא לכם לעבוד עם GIT הייתי עושה זום אאוט, ואז חוזר לפיתוח אתרים ע"י AI.
מה זה Git בקצרה
מערכת שמנהלת גרסאות של קוד. כל שינוי שאתה עושה נשמר כ-commit, עם תאריך והודעה. אם משהו נשבר, חוזרים לגרסה שעבדה. לא צריך להיות מומחה. שלוש פקודות מספיקות להתחלה:
git init # יצירת repository חדש
git add . # הוספת כל הקבצים
git commit -m "initial version" # שמירת גרסה
כשעובדים עם AI הקוד משתנה מהר. לפעמים AI משכתב פונקציה שלמה כשביקשת ממנו לתקן שורה אחת. בלי Git, אתה מגלה את זה רק כשמשהו נשבר ואין לך מושג מה השתנה.
למה .gitignore זה הדבר הראשון שעושים
כמו בפיתוח ב-JS גם בוורדפרס יש את מה שלא צריך לקלוט במנהל גרסאות. וורדפרס מגיעה עם אלפי קבצים שלא רלוונטיים לפיתוח שלך: קבצי core, uploads, תוספים של צד שלישי. בלי .gitignore מתאים, ה-repository מתנפח עם קבצים מיותרים ו-Git הופך לבלתי שמיש.
נקצר את העניין פה, ופשוט הנה .gitignore מוכן ל-copy paste:
# WordPress core
/wp-admin/
/wp-includes/
/wp-content/uploads/
/wp-content/upgrade/
/wp-content/themes/twenty*/
wp-config.php
.htaccess
# Dependencies
/node_modules/
/vendor/
# OS files
.DS_Store
Thumbs.db
# IDE
.idea/
.vscode/
*.code-workspace
# Logs
*.log
debug.log
# Compiled
*.css.map
*.js.map
איפה עושים git init
זה תלוי במה שמפתחים:
תוסף בודד: git init בתוך wp-content/plugins/my-plugin/. זו הגישה הכי נפוצה בפיתוח עם AI וזו הגישה שאני ממליץ עליה.
תבנית: git init בתוך תיקיית התבנית. על פיתוח תבניות עם AI כתבתי בנפרד בבניית ערכות עיצוב מותאמות לוורדפרס עם AI.
אתר שלם: git init ב-root של הפרויקט, עם ה-.gitignore שלמעלה. שימו לב שה-.gitignore הזה בנוי בדיוק למצב כזה: הוא מסנן את ה-core ומשאיר רק את הקוד שלכם.
הכלל שלי פשוט: commit לפני שה-AI משנה קוד, ו-commit אחרי שהקוד עובד. ככה תמיד יש נקודה בטוחה לחזור אליה. אם ה-AI שבר משהו, git diff מראה בדיוק מה השתנה, ו-git checkout . מחזיר הכל למצב הקודם.
מטרות פיתוח: מה בעצם בונים?
לפני שמדברים על טכניקות, שאלה פשוטה: מה המטרה? כי הגישה משתנה לגמרי לפי התשובה. ה-prompt שאתה כותב ל-AI, מבנה הקבצים, ואפילו הכלי שאתה בוחר, כל זה נגזר מהסוג של פיתוח.
יש ארבע מטרות עיקריות בפיתוח וורדפרס:
תבנית (theme) עיצוב, לייאאוט, ואיך האתר נראה. פה העבודה היא בעיקר PHP templates, CSS, ולפעמים JavaScript. מי שרוצה לבנות תבנית עם AI, כתבתי על זה במאמר נפרד על ערכות עיצוב.
תוסף (plugin) פונקציונליות חדשה שוורדפרס לא מספקת מהקופסה. טופס מותאם, חיבור ל-API חיצוני, לוגיקה עסקית. פה ה-AI הכי שימושי כי מדובר בקוד PHP "נקי" שלא תלוי בעיצוב.
פיצ'ר ספציפי יכולת אחת בתוך מערכת גדולה יותר. למשל, שדה מותאם בעמוד checkout של WooCommerce. זה בדרך כלל תוסף קטן עם קובץ PHP אחד או שניים.
אתר חדש מאפס כולל הכל. תבנית, תוספים, תוכן, הגדרות. זה פרויקט אחר לגמרי, וה-AI שם עוזר בחלקים ספציפיים אבל לא בונה את הכל.
מכאן והלאה המאמר מתמקד בפיתוח תוספים. זו הצורה הכי נפוצה של פיתוח וורדפרס עם AI, וגם הצורה שבה קיבלתי את התוצאות הכי טובות. על תבניות ואתרים שלמים יש מאמרים נפרדים בסדרה. אם מה שאתם צריכים זה פרונט-אנד, שווה להסתכל על Vibe Coding לפרונט-אנד Headless של וורדפרס.
פיתוח בגישת "תוסף לכל פיצ'ר"
אני חושב שלפצל כל פיצ'ר לתוסף נפרד זה חובה, לא המלצה. ראיתי פרויקטים שקרסו כי שינוי קטן שה-AI עשה בפונקציה אחת שבר חצי מהמערכת. כשהכל יושב בתוסף אחד גדול, אין דרך לבודד את הנזק.
בפיתוח ידני רגיל, הגישה הזו אופציונלית. אפשר לשמור על קוד מסודר בתוך תוסף אחד גדול אם יודעים מה עושים. אבל עם AI המשחק שונה. ה-AI לא שומר על conventions באותה רמה שאתה שומר. הוא לא זוכר שהסכמת על naming convention מסוים, הוא לא מכבד גבולות בין מודולים, ולפעמים הוא פשוט משכתב קוד שלא ביקשת ממנו לגעת בו.
למה דווקא עם AI זה קריטי
קוד שנוצר על ידי AI צריך דיבאג נפרד. הוא צריך גרסאות נפרדות. הוא צריך יכולת rollback בלי להשפיע על שאר המערכת. כשה-AI כותב פונקציה שלמה מחדש במקום לתקן שורה (וזה קורה הרבה), אתה רוצה שהנפילה תהיה מוגבלת לתוסף אחד ולא לכל האתר.
דוגמה מציאותית: נניח שבונים מערכת e-commerce מותאמת. לא לשים הכל בתוסף אחד. תוסף אחד לניהול מלאי, תוסף נפרד לקופונים, תוסף נפרד לדוחות. כל אחד עם git repo משלו, כך שאפשר לעקוב אחרי מה AI שינה, מתי, ולחזור אחורה בלי לגעת בשאר. בפרויקט כזה שעבדתי עליו, ה-AI שבר את מנגנון הקופונים שלוש פעמים. בזכות זה שהוא היה תוסף נפרד, עשיתי rollback בלי שהלקוח הרגיש שמשהו השתנה בשאר האתר.
תקשורת בין תוספים דרך hooks
תוסף A לא צריך לדעת מה קורה בקוד הפנימי של תוסף B. התקשורת ביניהם עוברת דרך WordPress hooks בלבד: actions ו-filters. ככה שומרים על הפרדה נקייה.
דוגמה: תוסף מלאי שולח action כשה-stock משתנה, ותוסף התראות מאזין ושולח מייל:
// בתוסף המלאי
do_action( 'my_stock_changed', $product_id, $new_qty );
// בתוסף ההתראות
add_action( 'my_stock_changed', 'send_stock_alert', 10, 2 );
function send_stock_alert( $product_id, $new_qty ) {
if ( $new_qty < 5 ) {
wp_mail( get_option('admin_email'), 'מלאי נמוך', "מוצר $product_id: נשארו $new_qty" );
}
}
ככה, אם ה-AI שובר את תוסף ההתראות, המלאי ממשיך לעבוד כרגיל. ואם צריך לכבות פיצ'ר, פשוט מכבים תוסף אחד. אותו עיקרון עובד גם עם filters: תוסף אחד יכול לשנות את מחיר המוצר דרך filter, ותוסף אחר מאזין לאותו filter ומוסיף מע"מ. כל אחד עצמאי.
טיפ: לשמור בכל תוסף קובץ CHANGELOG.md שמתעד מה AI יצר ומה נערך ידנית. כשחוזרים לקוד אחרי שבועיים, זה חוסך שעות של ניחושים. אני מוסיף שורה אחרי כל סשן עבודה עם AI, משהו כמו "2026-04-08: Claude Code יצר פונקציית export_to_csv, תוקן ידנית sanitization ו-file headers". פשוט, אבל שווה זהב כשצריך לדבג.
הרחבה מלאה על הגישה הזו, כולל מקרים מורכבים יותר, בBest Practices: תוסף נפרד לכל פיצ'ר.
עבודה עם LLM בפועל
מה לא עובד
כבר הזכרתי את זה בחלק 1, אבל שווה לחדד: Lovable, Base44, v0, Bolt וכלים דומים לא מתאימים לפיתוח תוספי וורדפרס. הם לא מספקים סביבת PHP. אפשר לבנות בהם ממשק React יפה, אבל לא תוסף שרץ בתוך וורדפרס.
גם ממשקי chat רגילים (ChatGPT web, Claude web) מוגבלים. מקבלים קוד, אבל ה-AI לא רואה את הפרויקט שלכם. הוא לא יודע איזה hooks כבר בשימוש, מה מבנה התיקיות, או מה גרסת ה-PHP. הקוד שהוא נותן עובד "בתיאוריה" אבל נשבר כשמנסים להכניס אותו לפרויקט אמיתי. ניסיתי לבקש מ-ChatGPT web תוסף שמשנה את ה-admin columns ב-WooCommerce, וקיבלתי קוד שמתייחס ל-hooks שהשתנו בגרסה 8. הוא פשוט לא ידע באיזו גרסה אני עובד כי לא היה לו גישה לקבצים.
מה כן עובד
Claude Code דרך טרמינל. הוא קורא את הקבצים בתיקייה, מבין מבנים, כותב קוד ויכול לבדוק אותו. מבין הכלים שניסיתי, זה הכי יעיל לפיתוח תוספי וורדפרס עם AI. הוא לא מושלם, אבל הוא מבין context.
Cursor. זה VS Code fork שרואה את כל הפרויקט ויכול לערוך קבצים ישירות. טוב לעבודה שדורשת שינויים במקביל בכמה קבצים.
GitHub Copilot. autocomplete טוב, פחות טוב ביצירת מבנים שלמים. משתמש בו כהשלמה, לא ככלי ראשי.
(השוואה מפורטת בין כל הכלים, כולל מתי לבחור במה, בכלי ה-AI הכי טובים לפיתוח וורדפרס ב-2026.)
הגישה: מחקר לפני קוד
זה הדבר הכי חשוב שלמדתי. רוב העבודה על וורדפרס היא reverse engineering. המערכת ענקית, עם אלפי hooks, ואין AI שמכיר את כולם. לפני שאני כותב prompt, אני חוקר: מה ה-hooks הרלוונטיים, מה הדוקומנטציה אומרת, מה כבר קיים.
טכניקה שעובדת לי טוב: להעתיק ל-AI את ה-source code של תוסף קיים שעושה משהו דומה למה שאני צריך, ולבקש ממנו לבנות על הבסיס הזה. ככה הוא לא ממציא hooks, הוא משתמש במה שבאמת קיים.
עוד דבר שעושה הבדל: לתקשר hooks ספציפיים עם ה-LLM. לא "תבנה לי תוסף שמוסיף שדה ב-checkout" אלא "הנה רשימת ה-actions שזמינים ב-WooCommerce checkout: woocommerce_after_order_notes, woocommerce_checkout_process, woocommerce_checkout_update_order_meta. אני צריך תוסף שמוסיף שדה מותאם ושומר את הערך ל-order meta." ככל שה-context מדויק יותר, כך ה-AI מייצר קוד שעובד בפעם הראשונה במקום שלוש.
גיליתי שגם לתת ל-AI דוגמה של הפלט הרצוי עוזר. אם אני צריך תוסף שמוסיף עמודה בטבלת ההזמנות באדמין, אני מראה לו קוד של תוסף שכבר מוסיף עמודה (למשל מתוך WooCommerce עצמו) ואומר "תבנה לי משהו דומה שמציג X". הוא מבין את הפטרן ומשכפל אותו נכון.
גם לציין גרסאות עוזר. "אני עובד עם WordPress 6.5 ו-WooCommerce 8.7, PHP 8.2" זה context שמונע מה-AI להציע פתרונות שעבדו ב-WordPress 4 אבל לא רלוונטיים היום.
הכותרת "בניתי תוסף שלם בלי לכתוב שורת קוד" היא כותרת של מאמר שיווקי. במציאות, אתה חוקר שעתיים, כותב prompts חצי שעה, ואז מתקן באגים שעה. זה עדיין מהיר יותר ממה שהיה לפני שנתיים. אבל זה לא קסם.
שני סוגי פיתוח תוספים: ההבדלים בגישה
לפני שמתחילים לפתח, שאלה אחת משנה את כל הגישה: האם התוסף הזה ישרת משתמשים רבים, או לקוח ספציפי?
סוג 1: תוסף לספריית תוספים (WordPress.org או שוק)
כשבונים תוסף שמשתמשים אחרים יתקינו, כל דבר שהמשתמש צריך להגדיר חייב להיות בעמודי אדמין. לא hardcoded. זה אומר Settings API, או frameworks כמו CMB2 ו-Carbon Fields.
לא להתחיל מאפס. יש boilerplate מוכנים:
WordPress Plugin Boilerplate מבנה מסודר עם הפרדת concerns, מוכן להרחבה.
WPPB Generator מייצר boilerplate מותאם עם שם התוסף, namespace, ו-slug שלכם.
AI יודע לעזור ביצירת עמודי הגדרות, readme.txt, ו-headers תקינים. אבל הקוד צריך לעמוד בסטנדרטים של WordPress.org: sanitization מלאה של כל input, escaping של כל output, ותמיכה בתרגום (i18n). ביקורת ב-WordPress.org קפדנית, והם בודקים כל שורה. ביקשתי פעם מ-Claude Code לכתוב עמוד הגדרות שלם, וב-review הראשון נפלתי על sanitization חסר בשלושה מקומות שה-AI פספס. הוא השתמש ב-$_POST ישירות בלי sanitize_text_field(). דברים כאלה נראים תקינים בהרצה לוקאלית אבל נדחים ב-review. תמיד לבדוק.
בנוסף, כדאי להכיר את WordPress Plugin Handbook ולהפנות את ה-AI לדוקומנטציה כשהוא כותב קוד לתוסף ציבורי. ככה הוא לא ממציא פתרונות יצירתיים כשיש דרך מקובלת.
סוג 2: תוסף ללקוח ספציפי
כאן יש יותר חופש. אפשר לכתוב קוד ספציפי בלי להתעסק עם הגדרות דינמיות לכל פרמטר. חלק מהדברים יכולים להיות hardcoded או להישמר ב-wp-config.php. לא צריך readme.txt ולא צריך i18n אם הלקוח עובד בשפה אחת.
אפשר גם לשקול child theme במקום תוסף, אם הפיצ'ר קשור לעיצוב ולא ללוגיקה. שינוי ב-header, עיצוב מותאם של ארכיון, template מיוחד לדף מסוים. אבל גם ללקוח, הגישה של תוסף נפרד לכל פיצ'ר עדיפה כשמדובר בלוגיקה. כשהלקוח רוצה לכבות פיצ'ר אחד, פשוט מכבים תוסף. לא צריך לגעת בקוד.
אם התוסף צריך לחשוף API לפרונט-אנד או לשירות חיצוני, שווה גם לקרוא על WordPress REST API + AI.
ההבדל העיקרי הוא רמת ה-abstraction. תוסף לשוק צריך לתמוך בכל תרחיש אפשרי. תוסף ללקוח צריך לפתור בעיה אחת ספציפית. מניסיוני, AI טוב יותר בסוג השני. ה-scope מוגדר, ה-prompt קצר וממוקד, והפלט קל לבדיקה. כשביקשתי מ-AI לבנות תוסף שמוסיף שדה בודד ל-order ב-WooCommerce עבור לקוח, קיבלתי קוד עובד תוך דקות. כשביקשתי ממנו לבנות תוסף גנרי שתומך בסוגי שדות שונים עם UI להגדרות, נדרשו שעות של תיקונים.
סיכום פרקטי
התהליך שעובד לי: סביבה לוקאלית עם WP Local, git init לפני שנוגעים בקוד, הגדרת מטרה ברורה (תוסף, לא "מערכת"), פיצול לתוסף נפרד לכל פיצ'ר, עבודה עם Claude Code או Cursor דרך הטרמינל, ומחקר של hooks לפני כל prompt.
מתי AI חוסך זמן אמיתי? ב-boilerplate, בקוד חוזר, בכתיבת Settings API ו-meta boxes, ובחיבורים ל-APIs חיצוניים. הדברים האלה לוקחים הרבה זמן כשכותבים ידנית והם בדיוק הסוג של קוד ש-AI כותב טוב. גם יצירת readme.txt ו-headers של תוספים, שזה עבודה משעממת ומועדת לטעויות, AI עושה את זה ברגע.
מתי עדיף לכתוב ידנית? לוגיקה עסקית מורכבת, קוד שתלוי בהתנהגות ספציפית של תוסף אחר, וכל דבר שקשור לאבטחה: sanitization, nonces, capability checks. AI נוטה לפספס את הדברים האלה, ופה הטעויות כואבות.
דבר אחרון: פיתוח ע"י בינה מלאכותית לא מחליף ידע בוורדפרס. הוא מאיץ אותו. מי שמבין hooks, filters, ואת מבנה הנתונים של וורדפרס, ידע לתת prompt טוב ולזהות כשה-AI טועה. מי שלא, יקבל קוד שנראה תקין ונשבר בפרודקשן.
המאמר הזה חלק מסדרת מאמרים על AI ווורדפרס. אם עבדתם עם AI על תוספים ויש לכם טכניקות שעובדות, אשמח לשמוע בתגובות.
