תוסף וורדפרס משלכם ב-3 דקות, בלי לכתוב שורת קוד

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

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

תוסף וורדפרס הוא לא בהכרח פרויקט גדול

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

מבחינה בסיסית, תוסף וורדפרס הוא תיקייה שמכילה קובץ PHP עם כותרת שמאפשרת לוורדפרס לזהות אותו. מאותו רגע אפשר להפעיל ולכבות אותו דרך מסך התוספים, בדיוק כמו כל תוסף אחר.

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

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

הדוגמה שלנו: תוסף קטן למעקב אחר הפניות

כדי להמחיש את התהליך, נבנה תוסף בסיסי שעונה על צורך ברור: לדעת איזה שותף או ממליץ הביא ליד לאתר.

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

הדוגמה משתמשת בטפסים של Elementor Pro. בבונה טפסים אחר התהליך דומה, אבל נקודת החיבור בקוד תהיה שונה.

לפני שמבקשים מה-AI לכתוב קוד

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

לפני פתיחת הצ'אט, כדאי לענות על כמה שאלות פשוטות:

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

הסעיף האחרון חשוב במיוחד. הגדרה ברורה של גבולות מונעת מהתוסף להתנפח ומקלה מאוד על הבדיקה.

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

העיקרון החשוב: קודם אפיון, אחר כך קוד

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

1. הסביבה: גרסאות המערכת והרכיבים הרלוונטיים.
2. ההתנהגות: מה קורה ומתי, לפי סדר פעולות ברור.
3. הממשק: אילו מסכים, שדות ודוחות נדרשים.
4. כללי איכות: הרשאות, אבטחה, טיפול בקלט, תאימות ושגיאות.

הנה הפרומפט ששימש לדוגמה. אין צורך להעתיק אותו מילה במילה; המבנה שלו הוא החלק שכדאי לאמץ:

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

סביבת האתר:
- WordPress 6.X
- PHP 8.X
- Elementor + Elementor Pro בגרסאות המותקנות באתר
- האתר בעברית ובכיוון RTL

מטרת התוסף:
לאפשר למנהל האתר להגדיר שותפים ידנית ולראות כמה שליחות טופס
הגיעו דרך קישור ההפניה של כל שותף.

התנהגות נדרשת:
1. במסך הניהול יהיה תפריט בשם "שותפים". לכל שותף יישמרו שם
   וקוד באנגלית. יהיה אפשר להוסיף, לערוך ולמחוק שותף.
2. כניסה לכתובת עם הפרמטר ?ref=CODE תשמור עוגייה ל-30 יום,
   רק אם הקוד קיים במערכת. קוד חדש יחליף את הקוד הקודם.
3. לאחר שליחת טופס Elementor Pro, ואם קיימת עוגייה תקינה,
   תישמר רשומה עם קוד השותף, שם הטופס, תאריך וכתובת העמוד.
4. במסך הדוח יוצגו מספר הלידים לכל שותף וטבלה מפורטת עם עימוד.

גבולות הגרסה הראשונה:
- ללא הרשמה עצמית של שותפים
- ללא אזור אישי
- ללא חישוב עמלות או תשלומים

דרישות טכניות:
- Plugin Header תקין וגרסה ברורה
- שימוש ב-register_activation_hook וב-dbDelta ליצירת הטבלה
- שימוש בקידומת הטבלאות של האתר
- Hook לטפסים: elementor_pro/forms/new_record
- בדיקת manage_options בכל פעולת ניהול
- nonce בכל פעולה שמשנה מידע
- sanitization לקלט ו-escaping לפלט לפי ההקשר
- שימוש ב-$wpdb->prepare בשאילתות שמכילות ערכים דינמיים
- תמיכה ב-UTF-8, בעברית וב-RTL
- טיפול בכשלי שמירה והצגת הודעה מתאימה למנהל

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

הבקשה לסיכום לפני כתיבת הקוד מוסיפה נקודת בקרה חשובה. קל יותר לתקן אי-הבנה בפסקת אפיון מאשר בתוך מאות שורות קוד.

איך עוברים מהצ'אט לתוסף מותקן

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

את התוסף מעלים דרך לוח הבקרה: תוספים > הוספת תוסף > העלאת תוסף. בוחרים את קובץ ה-ZIP, מתקינים ומפעילים.

את כל הפעולות האלה מבצעים בסביבת בדיקה בלבד: אתר Staging, התקנה מקומית או אתר צדדי שאינו מקבל תנועה אמיתית. לפני ההתקנה בצעו גיבוי וודאו שיש לכם דרך לכבות את התוסף גם דרך מנהל הקבצים של האחסון, למקרה שלא תוכלו להיכנס ללוח הבקרה.

התקנה מוצלחת עדיין לא אומרת שהתוסף עובד

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

בדוגמה שלנו מוסיפים שותף ראשון ומוודאים שנוצר עבורו קישור הפניה.

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

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

השלב שהופך הדגמה לתהליך עבודה אחראי

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

למה שיחה חדשה? לא מפני שמודל בהכרח "מגן" על הקוד שלו, אלא כדי לתת לבודק הקשר נקי ומשימה אחת ברורה: לחפש בעיות, לא להמשיך את תהליך הבנייה.

אפשר להשתמש בפרומפט הבא:

בצע סקירת קוד ביקורתית לתוסף וורדפרס המצורף.
אל תשכתב עדיין את הקוד ואל תניח שהוא תקין.

בדוק במיוחד:
- הרשאות לפני כל פעולת ניהול
- nonce בכל פעולה שמשנה מידע
- פעולות שינוי שאפשר להפעיל בטעות דרך GET
- שאילתות SQL וערכים דינמיים
- sanitization של קלט ו-escaping של פלט
- אימות מחדש של מידע מעוגיות ומכתובת URL
- תמיכה ב-UTF-8 ובעברית
- אזורי זמן ותאריכים
- טיפול בכשלי מסד נתונים ושגיאות שקטות
- תאימות לגרסאות WordPress, PHP והתוספים שצוינו

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

בבדיקה של התוסף לדוגמה לא נמצאו פרצות קלאסיות כמו SQL Injection או XSS, אבל נמצאו בעיות תפעוליות משמעותיות: טיפול לא עקבי באזורי זמן, חיתוך מחרוזות שעלול לפגוע בעברית והיעדר טיפול מספק בכשלי שמירה למסד הנתונים. נמצאו גם נקודות הקשורות לכפילויות ולשמירה על הקשר בין שותף ללידים היסטוריים.

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

תהליך קצר שאפשר ליישם כמעט על כל תוסף קטן

אם מזקקים את המדריך, מתקבל תהליך בן שבעה שלבים:

1. בוחרים בעיה אחת קטנה ומוגדרת.
2. כותבים מה התוסף צריך לעשות ומה לא ייכלל בגרסה הראשונה.
3. מוסיפים לפרומפט את סביבת האתר ואת כללי האיכות.
4. מאשרים את האפיון לפני יצירת הקוד.
5. מתקינים בסביבת בדיקה ומבצעים בדיקה מקצה לקצה.
6. מבצעים סקירת קוד נפרדת ומתקנים לפי סדר חומרה.
7. בודקים שוב, ורק לאחר מכן מחליטים אם נדרשת בדיקה של מפתח אנושי.

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

טיפים שיחסכו זמן ותקלות

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

בקשו קובץ ZIP מוכן. כך מצמצמים טעויות בתיקיות, בשמות קבצים ובקידוד UTF-8.

ציינו את הרכיב שאליו מתחברים. ל-Elementor Pro, ל-Contact Form 7 ול-WPForms יש נקודות חיבור שונות. המילה "טופס" לבדה אינה מספיקה.

בקשו טיפול מפורש בשגיאות. הודעה ברורה בממשק או רישום ללוג עדיפים על כשל שקט שאי אפשר לגלות בזמן.

בדקו גם קאש. באתר עם קאש ברמת עמוד, פרמטרים בכתובת או קוד PHP שמגדיר עוגייה עלולים להתנהג אחרת מהצפוי. יש לבדוק את התרחיש האמיתי עם הגדרות הקאש של האתר.

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

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

רעיונות טובים לתוסף ראשון

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

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

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

מה לא כדאי לבחור כפרויקט ראשון

יש תחומים שבהם טעות קטנה עלולה לגרום נזק גדול. בהם לא כדאי להסתפק בקוד שנוצר בצ'אט ובבדיקה עצמית:

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

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

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

אז עד כמה באמת קל לבנות תוסף בעזרת AI?

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

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

התחילו ממשהו קטן שמפריע לכם בעבודה השוטפת. הגדירו פעולה אחת, בנו אותה בסביבת בדיקה ושפרו אותה בהדרגה. אם תרצו להעמיק בשיטת העבודה, תוכלו להמשיך אל המדריך לעבודה נכונה מול כלי פיתוח מבוססי AI, לקרוא מדריכים נוספים בנושא וייב קודינג או ללמוד בצורה מסודרת במסגרת קורס Claude Code וסביבת Anthropic.

השאלה כבר אינה רק אם אפשר לבנות תוסף בעזרת AI. השאלה הטובה יותר היא: איזו פעולה קטנה באתר שלכם שווה להפוך לתוסף ראשון?