אינטגרציית PrestaShop (גישה מוקדמת)

גישה מוקדמת

אינטגרציית PrestaShop נמצאת בגישה מוקדמת. היא עדיין לא אומתה על חנות פעילה בסביבת ייצור. סנכרון הנתונים, המעקב בחזית החנות, הודעות in-app, Web Push, קודי קופון וטפסים באתר בנויים; הרישום ב-Addons marketplace יגיע בהמשך - ראו עדיין לא זמין.

חברו חנות PrestaShop 8 או 9 באמצעות המודול של Joryio. לקוחות, הזמנות, החזרים, מוצרים ועגלות מסתנכרנים ל-Joryio, עגלות נטושות מקבלות קישור שחזור, ההסכמה לניוזלטר עוקבת אחרי החנות, הביקורים של הקונים נמדדים ומיוחסים לקמפיינים שלכם, הודעות in-app ו-Web Push מגיעות לחזית החנות, ותוכניות קופונים יוצרות קודים אישיים בחנות.

מה מסתנכרן

נתונים	פרטים
לקוחות	לקוחות רשומים, ורכישות כאורח לפי כתובת האימייל. אורח לעולם לא נשמר כמספר לקוח PrestaShop על איש קשר.
הזמנות	סטטוס, סכומים, מוצרים, כתובות, כל קוד קופון עם ההנחה שהוא נתן, ייחוס לקמפיין ומטבע. הזמנות במצב מבוטל או שגיאת תשלום שולחות Order Cancelled אחד; כל זיכוי (credit slip) שולח Order Refunded אחד עם הסכום שלו.
מוצרים	שם, תיאור, מחיר (כולל מס, עם מחיר מבצע), מותג, GTIN, קטגוריות, תמונות, מאפיינים, צירופים (combinations) ומלאי. שינויי מלאי ומחיר מזינים טריגרים מבוססי קטלוג.
עגלות	עגלות בזמן שהלקוחות קונים, ועגלות נטושות עם קישור שחזור חתום.
הסכמה לניוזלטר	המינוי של הלקוח לניוזלטר. ראו הסכמה לשיווק.
אירועי חזית החנות	צפיות בדפים, במוצרים, בקטגוריות, בחיפוש ובעגלה, הוספה לעגלה והסרה ממנה, התחלת checkout והאימייל שהקונה מקליד. ראו מעקב בחזית החנות.
טפסים באתר	טופס יצירת הקשר וטפסים של מודולים אחרים, ממופים בדף המודול (מודול 1.2.0). ראו טפסים באתר.

בעת החיבור Joryio מייבא לקוחות, מוצרים והזמנות קיימים (90 הימים האחרונים כברירת מחדל) דרך ה-Webservice של PrestaShop. לאחר מכן המודול שולח שינויים בזמן שהם קורים.

עדיין לא זמין

הרישום ב-PrestaShop Addons marketplace יגיע בגרסה מאוחרת יותר. עד אז, התקינו את המודול מקובץ ה-zip שב-Joryio.

דרישות

• PrestaShop 8.0 ומעלה, או 9.x (PrestaShop 1.7 אינו נתמך)
• גרסת ה-PHP שגרסת ה-PrestaShop שלכם דורשת (PrestaShop 8: PHP 7.2.5 עד 8.1; PrestaShop 9: PHP 8.1 ומעלה)
• החנות נגישה מהאינטרנט ב-https בכתובת ציבורית, הכתובת הסופית שלה (ללא הפניה). Joryio תמיד פונה ל-https:// ודוחה כתובות פרטיות או פנימיות והפניות
• גישת HTTPS יוצאת מהשרת שלכם ל-Joryio
• מומלצת משימת cron בשרת - ראו Cron

הגדרה

שלב 1: קבלת כתובת השרת ומפתח ה-API

1. ב-Joryio, עברו אל Integrations → PrestaShop
2. העתיקו את כתובת השרת
3. לחצו יצירת מפתח API והעתיקו את המפתח (הוא מתחיל ב-jry_ps_)

שלב 2: התקנת המודול

1. הורידו את המודול עם הורדת המודול בעמוד PrestaShop ב-Joryio (joryio-prestashop.zip)
2. בממשק הניהול של PrestaShop עברו אל Modules → Module Manager → Upload a module והעלו אליו את קובץ ה-zip

שלב 3: חיבור

1. פתחו את המודול (Configure)
2. הדביקו את כתובת השרת ואת מפתח ה-API
3. לחצו Connect

המודול מפעיל את ה-Webservice של PrestaShop ויוצר עבור Joryio מפתח Webservice - אין צורך ליצור מפתח ידנית. לפני החיבור Joryio בודק שהמפתח באמת שייך לחנות שלכם: המפתח חייב לפתוח נתוני חנות מוגנים, ואותה בקשה בלי המפתח חייבת להידחות. לאחר מכן מתחיל הייבוא הראשוני.

המודול יוצר מפתח Webservice חדש בכל Connect. המפתח יכול רק לקרוא (GET) את הנתונים ש-Joryio מסנכרן - לעולם לא את הגדרות החנות - ומגרסה 1.1.0 של המודול גם ליצור, לשנות ולמחוק כללי עגלה (cart rules), שבאמצעותם Joryio יוצר את הקודים של תוכניות הקופונים שלכם. אי אפשר לכתוב בו שום דבר אחר. אם Joryio דוחה את החיבור, המודול מוחק את המפתח שוב, ואם המודול הוא שהפעיל את ה-Webservice, הוא מכבה אותו בחזרה.

ריבוי חנויות

ב-Multistore, כל חנות מתחברת בנפרד. פתחו את המודול כשהחנות הזו נבחרה בהקשר החנות, והשתמשו במפתח ה-API של סביבת העבודה ב-Joryio שאליה החנות שייכת. אפשר לחבר חנות לסביבת עבודה אחת בלבד: חיבור לסביבה נוספת מציג "This store is already connected to another Joryio workspace." נתקו אותה שם קודם.

כמו כן, סביבת עבודה מחזיקה חנות אחת: חיבור חנות שנייה עם המפתח של אותה סביבת עבודה נדחה ("This Joryio workspace is already connected to another PrestaShop shop..."). תנו לכל חנות סביבת עבודה משלה והשתמשו במפתח של אותה סביבה.

Cron

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

* * * * * curl -fsS "<cron URL from the module page>" > /dev/null

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

מסירה וניסיונות חוזרים

אירוע לא הולך לאיבוד כש-Joryio לא זמין לזמן מה:

• Joryio לא זמין או עמוס - התור עוצר ומנסה שוב אחרי הפסקות שהולכות וגדלות (דקה, ומוכפלות עד פעם בשעה) עד 7 ימים, תוך שמירה על סדר האירועים של כל הזמנה, עגלה ולקוח.
• אירוע ש-Joryio דוחה (למשל נתונים לא תקינים) מוצא מהתור מיד, כך שהוא לא מעכב את האחרים.
• Joryio דוחה את מפתח ה-API - המסירה נעצרת ועמוד המודול מציג הודעה. האירועים נשמרים: הדביקו את המפתח הנוכחי ולחצו Connect.
• אירועים שלא נמסרו נשמרים 30 יום. עמוד המודול מציג כמה אירועים ממתינים וכמה לא נמסרו, עם השגיאה האחרונה, ו-Retry now שולח אותם שוב.

התאמה מתוזמנת

עדכונים חיים (המודול) עלולים ללכת לאיבוד - למשל כשהחנות לא זמינה, או כשמשלוח נכשל יותר מדי פעמים. כל 6 שעות Joryio בודקת בחנות מה השתנה מאז הבדיקה הקודמת ומשלימה את מה שהעדכונים החיים פספסו: הזמנות, תעודות זיכוי (החזרים), שינויי סטטוס של הזמנות, לקוחות, מוצרים, ועגלות מ-24 השעות האחרונות.

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

• הזמנה חסרה שבוצעה ב-24 השעות האחרונות נרשמת כאילו הגיעה בזמן אמת, כך שמסעות שאחרי רכישה עדיין מתחילים. הזמנה חסרה ישנה יותר, והחזר או ביטול של הזמנה ש-Joryio כבר הכירה, נרשמים בלי להתחיל מסעות; Order Refunded ו-Order Cancelled עדיין נרשמים פעם אחת בלבד כל אחד.
• כל חנות נבדקת בזמן משלה, כך שהחנויות לא נקראות כולן בבת אחת, ובדיקה אחת קוראת מספר מוגבל של שינויים; חנות עם יותר שינויים ממשיכה בתוך חצי שעה.
• חנויות מנותקות, בשגיאה או באמצע סנכרון מדולגות עד שהן מחוברות שוב.

התוצאה מוצגת ב-הגדרות → אינטגרציות → PrestaShop: התאמה אחרונה: 22/10/2026 12:00 - פריטים שהושלמו: 3. אם הבדיקות ממשיכות למצוא שינויים שלא הגיעו בזמן אמת, Joryio מעלה התראה Live updates from PrestaShop may be failing (פעמון, לוגים וניטור, ומייל למנהלי סביבת העבודה). הנתונים החסרים מושלמים בכל מקרה, אבל כדאי לבדוק את חיבור החנות: מסעות שמגיבים לשינויים האלה מתחילים באיחור.

באותו עמוד מוצגים האירוע האחרון שהתקבל - מתי עדכון חי מהחנות הגיע לאחרונה ל-Joryio (באיחור של דקה לכל היותר) - וסנכרון אחרון, המאוחר מבין הסנכרון המלא האחרון וההתאמה האחרונה. בחנות ששולחת עדכונים חיים, האירוע האחרון שהתקבל מתעדכן גם כשלא רץ סנכרון.

החזרים וביטולים

כל זיכוי (credit slip) על הזמנה הופך לאירוע Order Refunded אחד עם סכום הזיכוי. הזמנה שעוברת למצב מבוטל (או שגיאת תשלום) הופכת ל-Order Cancelled אחד. Joryio קורא בעת החיבור אילו מצבים בחנות שלכם פירושם "מבוטל" ו"הוחזר", כך שגם מצבים ששמם שונה נספרים. ראו אירועי החזר וביטול.

הסכמה לשיווק

המינוי של הלקוח לניוזלטר ב-PrestaShop חל על המינוי לאימייל של איש הקשר:

ב-PrestaShop	ב-Joryio
רשום (תיבת הניוזלטר בהרשמה או בחשבון, בלוק הניוזלטר, ממשק הניהול)	רשום לאימייל, עם התאריך ש-PrestaShop רשם.
הסיר את עצמו אחרי שהיה רשום	מוסר מרשימת האימייל - אלא אם Joryio רשם שינוי מאוחר יותר לאיש הקשר.

הוכחה שנרשמת (מודול 1.2.17): תיבת ניוזלטר בהזמנה או בטופס ההרשמה רושמת גם את כתובת ה-IP של הקונה ואת העמוד (הקופה או עמוד ההרשמה) ברשומת ההסכמה - בהזמנה, הכתובת ש-PrestaShop רשם לביקור של הקונה. כתובת ה-IP מוצגת רק לחברי צוות שמורשים לראות מידע אישי, נכללת כשהאדם מבקש את המידע שלו, ונמחקת כשהמידע שלו נמחק.

הייבוא הראשוני רושם לקוחות ש-PrestaShop מציג כרשומים; הוא לעולם לא מסיר אף אחד, כי "לא רשום" יכול גם לומר "מעולם לא נרשם". תיבת הצעות השותפים (optin) אינה הסכמה לשיווק עבור Joryio ואינה נלקחת בחשבון.

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

מתי סימון נחשב

התיבה "Sign up for our newsletter" של PrestaShop עצמה היא חלק משלב הפרטים האישיים בקופה. PrestaShop שומרת אותה על הלקוח כשהקונה ממשיך מעבר לשלב הזה, ולכן המודול שולח אותה ל-Joryio באותו רגע - לפני ביצוע ההזמנה. אין אפשרות "רק כשההזמנה מבוצעת", ושום דבר לא נשלח כשהדף נטען. התיבה והטקסט שלה שייכים ל-PrestaShop; המודול אף פעם לא מסמן אותה מראש.

מודול 1.2.8 ואילך - אותו כלל כמו Record consent immediately ב-Magento וב-WooCommerce:

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

• ההזמנה נושאת את התיבה כפי שהייתה כשההזמנה בוצעה. מסומנת: הקונה נרשם, פעם אחת. לא מסומנת: שום דבר לא משתנה - הזמנה בלי סימון לעולם לא רושמת ולעולם לא מסירה, וסימון בהמתנה נשאר בהמתנה. כשההגדרה האופציונלית תיבה לא מסומנת מבטלת הרשמה פעילה, תיבה לא מסומנת בהזמנה שבוצעה רושמת במקום זאת ביטול הרשמה.
• אם הקונה חוזר לשלב הפרטים האישיים ומבטל את הסימון, הסימון של אותה קופה מבוטל - רק הוא: מינוי שנתן בכל מקום אחר נשאר.
• טופס ההרשמה, עמוד החשבון, בלוק הניוזלטר של לקוח מחובר והייבוא הראשוני פועלים לפי אותו כלל: גם שם PrestaShop לא מאמתת כתובת אימייל, ולכן הרשמה לניוזלטר נספרת מיד רק עבור קונה מוכר או מי שכבר רשום. כל אחד אחר ממתין עד שילחץ על מייל האישור (הפעילו את לשלוח לאורחים חדשים קישור אישור במייל). רק הרשמה בבלוק הניוזלטר שאושרה במייל האימות של PrestaShop עצמה נספרת מיד. הסרה מרשימה חלה תמיד מיד. כדי לספור אותם מיד במקום זאת, ראו הסכמות של קונים חדשים. סימון בהרשמה שנשמר בהמתנה נרשם עם הסיבה registration_tick_pending_confirmation.

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

שתי הגנות באינטגרציות → PrestaShop → הגדרות (מנהלים בלבד; כל שינוי נרשם ביומן הביקורת):

• לשלוח לאורחים חדשים קישור אישור במייל - כבוי כברירת מחדל, כי הכתובת הוקלדה בקופה ואף אחד עוד לא אימת אותה. כשהוא פועל, אורח חדש שנשמר בהמתנה מקבל מייל אחד; הקישור בו רושם אותו (מקור double_opt_in). נעשה שימוש בתבנית אישור ההרשמה הכפולה שלכם אם בחרתם אחת.
• סימוני הסכמה לקונה בשעה - ברירת מחדל 3, נספרים לכל כתובת IP, לכל קופה ולכל כתובת אימייל. סימונים מעבר למגבלה לא נלקחים בחשבון; ההזמנה עדיין שומרת את הבחירה. למודול אותה מגבלה (Opt-in ticks per shopper per hour בהגדרות המודול, ברירת מחדל 3) והוא לא שולח סימון כזה בכלל.

המודול סופר את כתובת ה-IP של החיבור עצמו. אם החנות שלכם יושבת מאחורי proxy או CDN שקובעים את כתובת המבקר (X-Forwarded-For), הפעילו את Behind a trusted proxy בהגדרות המודול; אחרת השאירו אותה כבויה, כי מבקר יכול לקבוע את הכותרת הזו בעצמו.

במודול 1.2.7 ומטה גם סימון של אורח חדש נשמר בהמתנה, אבל ההזמנה שלו לא יכולה לרשום אותו (הגרסאות האלה לא שולחות את התיבה עם ההזמנה) - רק מייל האישור יכול. עדכנו את המודול ל-1.2.8.

מוצג ב-Joryio

ב-PrestaShop אין הגדרה של "מתי סימון נספר", והכרטיס Store checkout opt-in (set in your store) ב-אינטגרציות → PrestaShop → הגדרות אומר זאת, לקריאה בלבד: תיבת הניוזלטר היא של PrestaShop עצמה (המודול Newsletter subscription, ps_emailsubscription, תחת Modules → Module Manager) והיא נשלחת לפני ההזמנה, ולכן אמצעי ההגנה באותו עמוד חלים עליה. Joryio לא משנה שום דבר ב-PrestaShop.

הסכמות של קונים חדשים

ההגדרה הסכמות של קונים חדשים (שעוד לא קנו) ב-אינטגרציות → PrestaShop → הגדרות (מנהלים בלבד; כל שינוי נרשם ביומן הביקורת) קובעת מה עושה הסכמה של מי שעוד לא קנה:

אפשרות	מה קורה
להמתין עד שיזמינו או יאשרו במייל (ברירת מחדל, מומלץ)	הסכמה של קונה חדש נשמרת בהמתנה עד ההזמנה שלו עם התיבה מסומנת או לחיצה על מייל האישור (אם הפעלתם את לשלוח לאורחים חדשים קישור אישור במייל).
לספור מיד (פחות מחמיר - כל מבקר יכול להזין כל כתובת מייל)	היא נספרת מיד. כל מבקר יכול להקליד כל כתובת מייל, כך שמישהו יכול לרשום אדם אחר; האדם הזה יכול להסיר את עצמו בלחיצה אחת. כך Joryio ספרה אותן לפני מודול 1.2.8.

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

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

תיבה לא מסומנת מבטלת הרשמה (אופציונלי)

לחנויות עם מדיניות הסכמה מחמירה, במודול 1.2.15 ואילך יש הגדרה אופציונלית בהגדרות ההסכמה של המודול: An unticked opt-in box at checkout or registration unsubscribes the person. היא כבויה כברירת מחדל.

הגדרה	מה תיבה לא מסומנת עושה
כבויה (ברירת מחדל)	כלום. תיבה לא מסומנת לעולם לא משנה סטטוס של אף אחד.
פעילה	תיבה שהוצגה ונשלחה לא מסומנת - עם הזמנה שבוצעה, או בטופס ההרשמה - רושמת ביטול הרשמה לערוץ של אותה תיבה (אימייל או SMS). רק ללקוחות מחוברים, שהחנות אימתה.
פעילה, עם Also for guest checkouts	אותו דבר גם בקופה כאורח ובהרשמה לחשבון חדש. בקופה כאורח כל אחד יכול להקליד אימייל של מישהו אחר - אורח יכול לבטל הרשמה של אדם אחר. הרשמה לחשבון חדש נחשבת כאורח: החנות לא מאמתת את כתובת האימייל.

• ביטול ההרשמה נרשם כמו כל ביטול אחר: בהיסטוריית המינויים של איש הקשר (מקור prestashop_checkout / prestashop_registration, סיבה checkout_box_unticked, עם הטקסט שהוצג ליד התיבה) וכאירוע message.unsubscribed.
• גם מי שמעולם לא נרשם: כשההגדרה פעילה, תיבה לא מסומנת מבטלת את ההרשמה של האדם גם אם הוא מעולם לא נרשם (Not Set הופך ל־Unsubscribed). כמו כל ביטול הרשמה, היא חלה על כל איש קשר עם אותו דוא"ל או טלפון בסביבת העבודה, וביטול שלה דורש הסכמה חדשה.
• לעולם לא עבור תיבה שלא הוצגה (תיבת ה-SMS רק היכן שהיא מוצגת), לעולם לא מסנכרון של הזמנות קודמות, ולעולם לא עבור תיבה שהסימון שלה הוסר לפני ביצוע ההזמנה - הסרת סימון במהלך הקופה רק מבטלת את הסימון של אותה קופה. היא לעולם לא רושמת או רושמת מחדש אף אחד, ולעולם לא משנה חסימה בגלל החזרה (bounce) או תלונה.
• Integrations → PrestaShop → Settings מציג את ההגדרה לקריאה בלבד. גרסאות ישנות יותר לא מדווחות עליה, ו-Joryio מתייחס אליה ככבויה.

בלוק הניוזלטר

בלוק הניוזלטר (המודול ps_emailsubscription) הוא טופס ציבורי: כל אחד יכול להקליד בו כל כתובת אימייל. לכן Joryio מתייחס אליו אחרת מאשר לחשבון של הלקוח עצמו:

• הרשמה נחשבת הסכמה רק כאשר PrestaShop מוכיח שהכתובת שייכת לאדם: או שהקונה מחובר לחשבון הרשום עם האימייל הזה, או שאימות אימייל מופעל בהגדרות בלוק הניוזלטר וקישור האישור נלחץ (Joryio מקבל את ההרשמה אחרי האישור, בהרצת ה-cron הבאה). כל דבר אחר לא נשלח ל-Joryio. הפעילו אימות אימייל בהגדרות בלוק הניוזלטר כדי שהרשמות של אורחים יגיעו ל-Joryio.
• אישור נחשב רק לכתובת שלא הייתה רשומה כשהטופס נשלח, ורק כאשר PrestaShop רושם את המינוי אחרי שליחת הטופס. כתובת שכבר הייתה רשומה לא נשלחת שוב; אם אימות האימייל מכובה לפני לחיצה על הקישור, ההרשמה נמחקת. Joryio מקבל את תאריך המינוי ש-PrestaShop רשם (עבור אורח, PrestaShop שומר את מועד ההרשמה ולא את מועד האישור).
• הסרה מהבלוק תמיד מיושמת, לפי כתובת האימייל - בקשת הסרה היא הכיוון הבטוח. היא לעולם לא מקשרת את הבקשה לחשבון לקוח.
• הייבוא הראשוני וסנכרון עכשיו רושמים לקוח ש-PrestaShop מציג כרשום רק אם איש הקשר מעולם לא הסיר את עצמו; הם לעולם לא רושמים מחדש אף אחד. כשאימות האימייל כבוי, PrestaShop עצמו מסמן לקוח רשום כמנוי כשמישהו מקליד את הכתובת שלו בבלוק, והייבוא לא יכול להבחין בכך.
• שינוי ניוזלטר שנשמר על הלקוח מחזית החנות על ידי מי שאינו מחובר כאותו לקוח יכול להסיר, אך לעולם לא לרשום.

מעקב בחזית החנות

מגרסה 1.1.0 המודול מוסיף לחזית החנות את סניפט המעקב של Joryio (מופעל כברירת מחדל - Storefront tracking בעמוד המודול). כל אירוע נשמר בשמו הסטנדרטי, כמו ב-WooCommerce, ב-Shopify וב-Magento:

אירוע	נשמר בשם	מתי הוא נשלח
Page View	Page Viewed	כל דף
Product Viewed	Product Viewed	דף מוצר, עם הצירוף שנבחר, המחיר, המותג, הקטגוריה ומצב המלאי: in_stock (true או false) ו-stock_status (in_stock, backorder או out_of_stock)
Category Viewed	Product List Viewed	דף קטגוריה, עם category_id, category_name וכתובת הדף
Search	Products Searched	דף תוצאות החיפוש, עם ה-query
Add to Cart	Product Added	כל הוספה: כפתור ההוספה לעגלה, טופס מוצר שטוען את הדף מחדש, כמות שהוגדלה בעגלה. PrestaShop רושם את ההוספה והדפדפן של הקונה שולח אותה פעם אחת
Remove from Cart	Product Removed	כמות שהוקטנה או מוצר שהוסר מהעגלה
Cart Viewed	Cart Viewed	דף העגלה
Checkout Started	Checkout Started	דף ה-checkout, פעם אחת לכל עגלה. רענון של דף ה-checkout אינו התחלה שנייה
Identify	$identify	הלקוח המחובר, האימייל שהוקלד בטפסי ההתחברות, ההרשמה, ה-checkout או הניוזלטר, ואימייל ההזמנה בדף אישור ההזמנה

ההזמנה עצמה אינה אירוע של חזית החנות: Order Completed מגיע מההזמנה שהמודול שולח, כך שההכנסה נספרת פעם אחת.

זהות והסכמה. עבור לקוח רשום מחובר (מודול 1.2.2 ואילך), המודול חותם על מספר הלקוח של PrestaShop בשרת של החנות; Joryio בודק את ההוכחה הזו ומצרף את הגלישה של המבקר לאיש הקשר שכבר מחזיק במספר הלקוח הזה - לעולם לא לאיש קשר שנמצא לפי אימייל. כל identify אחר (אורח, אימייל שהוקלד) רק מוסיף את האימייל לפרופיל האנונימי של המבקר עצמו ב-Joryio (הוא לעולם לא מחליף אימייל שכבר קיים בפרופיל, ולעולם לא ממזג שני אנשי קשר לפי אימייל). גרסאות קודמות של המודול זיהו לקוח מחובר לפי אימייל בלבד, ולכן יכול היה להיווצר איש קשר שני עם האימייל בלבד; אחרי העדכון הוא מצורף לאיש הקשר של הלקוח בפעם הבאה שהלקוח מתחבר באותו דפדפן. אירוע identify לעולם לא רושם אף אחד - הסכמה מגיעה רק מהמינוי של הלקוח לניוזלטר, ראו הסכמה לשיווק.

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

ערכות עיצוב. הסניפט משתמש ב-hooks הסטנדרטיים של PrestaShop (displayHeader, actionFrontControllerSetMedia, displayOrderConfirmation) ובאירועי העגלה ש-PrestaShop עצמו רושם, ולכן הוא עובד עם ערכות העיצוב Classic ו-Hummingbird ועם רוב האחרות. ערכת עיצוב שמסירה את ה-hook displayHeader, או מודול checkout בעמוד אחד שמחליף את הדף order, יכולים לעצור אירועים ספציפיים לדף (למשל Checkout Started); צפיות בדפים, אירועי עגלה וייחוס ממשיכים לעבוד. מודול מטמון דפים שומר מהסניפט רק נתונים כלליים לדף: האימייל של הלקוח המחובר ואירועי העגלה נשלפים על ידי הדפדפן של כל מבקר ולעולם לא נשמרים במטמון.

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

ייחוס לקמפיין

הסניפט מעתיק את מזהי הקליקים של Joryio (jr_cid לקמפיין, jr_jid למסע) ואת פרמטרי ה-UTM של הקישור שדרכו הקונה הגיע לעוגיות צד ראשון (joryio_jr_cid, joryio_jr_jid, joryio_utm_*, ל-30 יום). המודול מצרף אותם להזמנה, כך שהמכירה מיוחסת לקמפיין או למסע - ראו ייחוס הכנסות. הוא גם שומר אותם עם העגלה של הקונה, כך שהזמנה שמאושרת מאוחר יותר בקריאה חוזרת (callback) של ספק תשלומים (בלי הדפדפן של הקונה) עדיין מיוחסת. הזמנות מהייבוא הראשוני לא נושאות ייחוס.

זיהוי מבקרים לפי האימייל שהם מקלידים

מגרסת מודול 1.2.10, בדף התצורה של המודול יש את Recognise visitors by the email they type. ההגדרה מופעלת כברירת מחדל, ומודול ישן יותר מתנהג כאילו היא מופעלת.

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

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

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

כשכמה אנשי קשר חולקים אימייל

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

הודעות in-app ו-Web Push

מגרסה 1.1.0 של המודול, הסניפט טוען בחזית החנות גם את ה-SDK של Joryio לווב, מהכתובת https://sdk.joryio.com/web/1/joryio.min.js (הגרסה העדכנית ביותר של 1.x). קריאות הנתונים שלו נשלחות לכתובת השרת שאיתה התחברתם. ההגדרות נמצאות בעמוד המודול:

הגדרה	ברירת מחדל	מה היא עושה
In-app messages	Yes	מציג בחנות את הודעות ה-in-app שלכם מ-Joryio
Allow HTML in-app messages	Yes	מציג גם הודעות שנבנו בעורך ה-HTML. הן מוצגות במסגרת מוגנת: סקריפטים שנכתבו בהן לא רצים, וההודעה לא יכולה לגשת לדפי החנות או לשלוח בקשות רשת משלה
Web push	No	מאפשר לקונים להירשם להתראות דפדפן

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

הגדרת Web Push

דפדפן מקבל את ה-service worker של ההתראות רק מהכתובת של החנות עצמה, ב-https://your-shop/joryio-sw.js. הפעילו את Web push ושמרו, ואז פתחו את הלוח Web push בעמוד המודול:

1. חנות אחת בשורש הדומיין שלה: המודול כותב את הקובץ joryio-sw.js לתיקיית PrestaShop. הלוח מציין זאת - אין צורך לעשות דבר נוסף. (אם אין הרשאת כתיבה לתיקייה, או שכבר קיים בה joryio-sw.js שהמודול לא כתב, הלוח מציין זאת במקום.)
2. אחרת (Multistore, תיקייה לקריאה בלבד): המודול עונה בעצמו על /joryio-sw.js כשהשרת שלכם מעביר כתובות לא מוכרות ל-PrestaShop, מה שה-.htaccess של PrestaShop עושה כשכתובות ידידותיות (friendly URLs) מופעלות. לחצו Check the service worker address בלוח: הבדיקה חייבת להציג סקריפט שמתחיל ב-// Joryio web push.
3. אם הבדיקה מציגה דף 404, הוסיפו להגדרות השרת את השורה האחת שהלוח מציג:
   • Apache, ב-.htaccess מעל הכללים של PrestaShop: RewriteRule ^joryio-sw\.js$ index.php?fc=module&module=joryio&controller=sw [QSA,L]
   • nginx: location = /joryio-sw.js { rewrite ^ /index.php?fc=module&module=joryio&controller=sw last; }

PrestaShop שמותקן בתת-תיקייה (https://example.com/shop/) לא יכול להשתמש ב-Web Push: דפדפנים מקבלים את ה-worker רק בשורש הדומיין.

הקונים מתבקשים לאשר התראות דרך הודעת in-app של בקשת הרשמה להתראות שאתם יוצרים ב-Joryio, לכן השאירו את In-app messages מופעל, והפעילו Web Push לאפליקציה גם ב-Joryio. כיבוי Web push גורם לאותה כתובת להגיש worker שמסיר את עצמו מהדפדפנים של המבקרים.

הפעילו Web Push גם ב-Joryio. חיבור החנות יצר עבורה אפליקציה ב-Joryio (הגדרות → אפליקציות, בשם החנות). פתחו אותה, לחצו על הפעמון (Push) ועל הפעלת Web Push: כך נוצרים מפתחות ה-Web Push של החנות, שה-SDK בחנות קורא בעצמו - אין מה להעתיק. אחר כך צרו הודעת In-App עם כפתור שמוגדר ל-בקשה להפעלת התראות והציגו אותה באפליקציה הזו; קונים שמאשרים יכולים לקבל את קמפייני ה-Push ושלבי המסע שלכם.

תוכניות קופונים

מגרסה 1.1.0 של המודול, תוכניות קופונים יכולות להשתמש בחנות: Joryio יוצר את הקוד של כל אדם ככלל עגלה (cart rule) של PrestaShop באמצעות מפתח ה-Webservice (בשם Joryio - <program> (<variable> v<version>), והתיאור שלו מציין שהוא נוצר על ידי Joryio).

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

קישור החלה. {{ coupons.<variable>.apply_url }} פותח את index.php?fc=module&module=joryio&controller=coupon&code=... בחנות שלכם: הקוד נכנס לעגלה של הקונה, עם הבדיקות של PrestaShop עצמו (תאריכים, שימושים, מינימום, מוצרים, הנעילה לחשבון). כשהעגלה ריקה הקוד נשמר ומוחל כשמוצר נוסף; קוד נעול מבקש מהקונה להתחבר קודם.

מימושים. כל קוד בהזמנה נשלח עם ההנחה שהוא נתן, כך שמימושים והכנסות מגיעים לדוח התוכנית. גם הייבוא הראשוני ו-Sync now קוראים את הקודים (מודול 1.1.0 ומעלה).

שדרוג מגרסה 1.0.0. העלו את קובץ ה-zip של המודול החדש מעל הישן (Module Manager → Upload a module). השדרוג נותן למפתח ה-Webservice הקיים את ההרשאה לכללי עגלה - החיבור שלכם נשאר כפי שהוא. עד אז Joryio מדווח "PrestaShop refused coupon access" על התוכנית.

טפסים באתר

ממודול 1.2.0, טפסים בחנות שלכם יכולים לשלוח את ההגשות שלהם ל-Joryio, בדיוק כמו טפסים בוורדפרס: כל הגשה יוצרת או מעדכנת את איש הקשר ורושמת אירוע Form Submitted, ולכל טופס אתם בוחרים אם הוא גם רושם את איש הקשר לרשימות.

טופס	מתי הוא נשלח
טופס יצירת הקשר (המודול contactform של PrestaShop)	כש-PrestaShop שומר את ההודעה של המבקר. באיש הקשר שנבחר בטופס צריך להפעיל Save messages (Customers → Contacts); הודעה לאיש קשר בלי ההגדרה הזו נשלחת רק במייל של PrestaShop ולא מגיעה ל-Joryio
טפסים אחרים	כשמודול או ערכת העיצוב קוראים ל-hook actionJoryioFormSubmit אחרי שהגשה התקבלה (ראו בהמשך). הטופס מופיע בדף המודול בפעם הראשונה שהוא נשלח, או שאתם מוסיפים אותו שם לפי המזהה שלו

הגדרת טופס. בדף המודול, תחת טפסי אתר, סמנו שליחת הטופס הזה ל-Joryio ומפו את הטופס:

• שדה מייל, שדה טלפון, שדה שם פרטי, שדה שם משפחה - השם של שדה הטופס. שדה המייל של טופס יצירת הקשר הוא from. מפו לפחות שדה מייל או טלפון: הגשה בלי אף אחד מהם לא נשלחת.
• מאפיינים מותאמים - אחד בכל שורה, attribute_key = שם השדה (למשל company = company).
• רשימות - הרשימות שהטופס רושם אליהן. בלי רשימה, איש הקשר רק נשמר.
• הרשמה לרשימות - רק כשתיבת הסכמה מסומנת (ברירת המחדל; הזינו את שם התיבה), או זה טופס הרשמה - תמיד לרשום.
• נוסח ההסכמה (מודול 1.2.17) - הטקסט המדויק שמוצג ליד תיבת ההסכמה. המודול לא יכול לקרוא את התווית של ערכת העיצוב שלכם, לכן הקלידו אותו כאן. כשהמבקר מסמן את התיבה, Joryio רושם את הנוסח הזה ברשומת ההסכמה כמה שהוא הסכים לו.

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

מה נשלח. רק השדות שמיפיתם - ההודעה עצמה לא נשלחת אלא אם מיפיתם אותה למאפיין. המייל הוא זה שהמבקר הקליד: הוא לעולם לא מקושר לחשבון לקוח בחנות, וטופס של מבקר לעולם לא משנה את המייל או הטלפון של איש קשר קיים. לקוח מחובר יכול לעדכן את הטלפון שלו (מודול 1.2.18): כשלקוח רשום שמחובר לחנות שלכם שולח טופס והאימייל בטופס שייך לאיש הקשר שלו עצמו, הטלפון שהקליד מחליף את הטלפון של איש הקשר. המודול מוכיח מי מחובר באמצעות הוכחה חתומה שנוצרת בשרת של החנות, ורק עבור טופס שנשלח בחנות שלכם; האימייל אף פעם לא משתנה בדרך הזו. רשימה שדורשת אישור כפול שולחת קודם מייל אישור; איש הקשר נרשם כשהוא מאשר. Form Submitted נרשם בין אם המבקר הסכים ובין אם לא (מאפיינים: source - prestashop_contact או prestashop_form, formId, formName, pageUrl, consentGiven, consentText, listsSubscribed, listsPending, וה-email וה-phone של הטופס עצמו (בפורמט שבו איש הקשר שומר אותם, כך שטלפון אחר שמבקר הקליד לא הולך לאיבוד) ו-phoneUpdated כשהטלפון בטופס שונה מזה של איש הקשר - true כשאיש הקשר מחזיק בו עכשיו, false כשאיש הקשר שמר את שלו. חברי צוות שאינם מורשים לראות מידע אישי לא רואים את ערכי האימייל והטלפון, והם נמחקים יחד עם האדם). כשהטופס רושם את איש הקשר לרשימה, רשומת ההסכמה בהיסטוריית המינויים שומרת את הוכחת ההסכמה: הנוסח של התיבה שסומנה (נוסח ההסכמה, או ה-consent_text שהטופס העביר), העמוד שבו נשלח הטופס (pageUrl), השעה וכתובת ה-IP של המבקר (מוצגת רק לחברי צוות שמורשים לראות מידע אישי). תיבה שלא סומנה לעולם לא שולחת את הנוסח שלה. בלי רשימה אף אחד לא נרשם, ולכן לא נכתבת רשומת הסכמה: הנוסח נשאר רק באירוע Form Submitted (כתובת ה-IP לעולם לא נכתבת לאירוע).

הסכמה בטופס יצירת הקשר. בטופס יצירת הקשר של PrestaShop אין תיבת סימון לשיווק. כדי לרשום מבקרים שמסכימים, הוסיפו תיבת סימון לא מסומנת, למשל <input type="checkbox" name="joryio_consent" value="1">, לעותק של טופס יצירת הקשר בערכת העיצוב שלכם, והזינו joryio_consent כשדה ההסכמה. תיבת GDPR בטופס יצירת הקשר היא הסכמה לטיפול בהודעה, לא לשיווק - אל תשתמשו בה כשדה ההסכמה.

טפסים אחרים. מפתח מוסיף קריאה אחת במקום שבו הטופס מתקבל:

Hook::exec('actionJoryioFormSubmit', [
    'form_id' => 'quote',            // letters, digits and _ . : -
    'form_name' => 'Quote request',
    'values' => ['email' => $email, 'company' => $company, 'consent' => $consentTicked],
    'consent_text' => 'Email me news and offers', // optional (1.2.17): the text next to the consent checkbox
]);

consent_text הוא אופציונלי; כשהוא מועבר, הוא משמש במקום נוסח ההסכמה של הטופס, ורק כשתיבת ההסכמה סומנה.

שליחה. ההגשות נכנסות לתור ונשלחות על ידי ה-cron כמו כל אירוע אחר, עם אותם ניסיונות חוזרים; הגשה שנשלחת שוב לעולם לא נרשמת פעמיים.

שדרוג מגרסה 1.1.0. העלו את קובץ ה-zip של המודול החדש מעל הישן (Module Manager → Upload a module). השדרוג רושם את שני ה-hooks החדשים; החיבור וההגדרות שלכם נשארים כפי שהם.

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

שחזור עגלות נטושות

1. המודול עוקב אחר עגלות בזמן שהלקוחות קונים
2. אחרי פרק זמן ללא פעילות (נקבע בעמוד המודול), העגלה מדווחת ל-Joryio כנטושה
3. Joryio מקבל את העגלה עם קישור שחזור חתום
4. השתמשו במסע כדי לשלוח הודעות שחזור עם הקישור הזה

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

פתיחת הקישור: עמוד שחזור, עגלה אחת לכל קישור

החל ממודול 1.2.9, פתיחת הקישור לבדה לא משנה דבר. תצוגות מקדימות של קישורים באפליקציות צ'אט וסורקי אבטחה של דואר (Outlook Safe Links, Gmail ואחרים) פותחים קישורים לפני הקונה, וכל פתיחה כזו העתיקה בעבר עגלה של אורח פעם נוספת - קישור אחד יכול היה להשאיר כמה עותקים.

• פתיחת הקישור מציגה עמוד קצר בערכת העיצוב שלכם, "משחזרים את העגלה השמורה שלכם...", שלעולם לא נשמר במטמון ולא נסרק למנועי חיפוש. כשהעגלה בדפדפן הזה ריקה, הסקריפט שלו משחזר את העגלה השמורה וממשיך לעמוד העגלה; בלי סקריפט הקונה לוחץ שחזור העגלה שלי. כשבעגלה בדפדפן הזה כבר יש מוצרים, העמוד שואל קודם, כי השחזור מחליף את העגלה המוצגת בדפדפן הזה: שחזור העגלה שלי או השארת העגלה הנוכחית שלי. תצוגה מקדימה או סורק שלא מריצים סקריפט לא משחזרים דבר.
• עגלה אחת לכל קישור, בכל דפדפן - בעגלה של אורח, העותק שהקישור יצר נשמר יחד עם הדפדפן שבו הוא נוצר (עוגיית המבקר של החנות). פתיחה חוזרת של אותו קישור באותו דפדפן (למשל אחרי שהעגלה שלו אבדה) מחזירה את אותו עותק במקום עותק חדש, למשך 7 ימים (קישור שחזור משתמש שוב בעגלה שלו (ימים) בעמוד המודול, 1-30), אלא אם כבר יש בו כתובת. דפדפן או מכשיר אחר - או סורק שכן הריץ את העמוד - לעולם לא מקבלים את העותק הזה, גם כשלקוח מחובר שם: הם מקבלים עותק חדש עם המוצרים של העגלה השמורה בלבד, כך ששום דבר שמישהו הקליד בקופה בדפדפן אחד לא מופיע בדפדפן אחר. מאותו רגע הקישור זוכר את העותק של הדפדפן האחרון. שני העותקים עדיין נחשבים לאותה עגלה שמורה: הזמנה מכל אחד מהם היא שחזור אחד, ונשלחת רק תזכורת אחת על "ננטשה שוב" לכל עגלה מקורית.
• כבר הוזמן - "כבר בוצעה הזמנה מהעגלה הזו.", ושום דבר לא משוחזר.
• לכל היותר 10 שחזורים לקישור בשעה - אחר כך, "יותר מדי ניסיונות עם קישור העגלה הזה. נסו שוב מאוחר יותר."

לעותק משוחזר של אורח אין מייל (הקישור אף פעם לא מעתיק אותו); מ-1.2.9 הוא בכל זאת מדווח, בלי מייל, ו-Joryio שולח את התזכורת האחת לאיש הקשר של העגלה המקורית - ראו עגלות.

מגרסה 1.2.11, כל אירוע עגלה של עותק משוחזר מציין מאיזו עגלה הוא שוחזר (restoredFromSessionId), כך שעותק של אורח מוצג ב־E-Commerce → עגלות כעותק משוחזר של העגלה של איש הקשר המקורי ולא כעגלה ללא איש קשר, ולא נספר כעגלה נטושה נוספת - ראו עגלות.

ממודול 1.2.12, כל אירוע עגלה נושא את קישור השחזור של העגלה (בתוקף 30 יום מאותו עדכון עגלה) ואת המידע אם זו עגלה של אורח, והמודול מדווח על Track guest carts ועל זמן הנטישה בכל בקשה, כך שעגלה ש־Joryio מסמנת כנטושה בעצמה פועלת לפיהם - ראו עגלות. כש־Track guest carts כבוי, המודול כבר לא שולח בכלל עגלות של תשלום כאורח (1.2.11 שלח אותן אבל לא דיווח עליהן כנטושות). כתובת האימייל של אורח מגיעה לעגלה כששלב הפרטים האישיים נשלח; אימייל שהוקלד לפני כן מזהה את הדפדפן בלבד.

ייחוס של הזמנות משוחזרות

החל ממודול 1.2.6, קישור השחזור שומר את פרמטרי הייחוס שמעקב ההקלקות של Joryio מוסיף (jr_cid, jr_jid, utm_*) כשהוא מעביר את הקונה לעגלה, כך שההזמנה מיוחסת להודעה ששלחה את הקישור. רק הפרמטרים האלה מועברים, וכל אחד נבדק לפי הפורמט שלו - לעולם לא האסימון של הקישור או כל דבר אחר. כשהקונה פותח את הקישור ומשלים את הרכישה עם מייל אחר, Joryio מייחס את ההזמנה להקלקה של איש הקשר שאליו נשלחה ההודעה. ראו עגלות.

ניתוק והסרה

• ניתוק בעמוד המודול מסיים את החיבור ומוחק את מפתח ה-Webservice שהמודול יצר. מפתח ה-API נשאר בתוקף - לחצו שוב על Connect עם אותו מפתח (מודול 1.2.1 ואילך).
• ניתוק ב-Joryio מבטל את מפתח ה-API מיד: בפעם הבאה שהמודול שולח אירוע הוא נעצר ומציג הודעה, וחיבור עם המפתח הזה אומר "This key was revoked when the store was disconnected in Joryio". צרו מפתח חדש כדי להתחבר שוב. Joryio מוחקת את העותק שלה של מפתח ה-Webservice; המפתח עצמו נשאר ב-PrestaShop עד שתלחצו על Disconnect בעמוד המודול או תסירו את המודול.
• הסרה של המודול ב-Module Manager. היא מנתקת את החנות, מבטלת את מפתח ה-API (מודול 1.2.1 ואילך), מוחקת את מפתח ה-Webservice שהמודול יצר ומסירה את הטבלאות של המודול, את הקובץ joryio-sw.js ואת ההגדרות. קודי קופון ש-Joryio יצרה נשארים בחנות ככללי עגלה.

פתרון בעיות

החיבור נכשל: Webservice

• המודול מפעיל את ה-Webservice בעת החיבור. אם הוא מכובה שוב (Advanced Parameters → Webservice), הייבוא הראשוני ו-Sync now מפסיקים לעבוד.
• יש ספקי אחסון שמסירים את כותרת Authorization לפני שהיא מגיעה ל-PHP. במקרה כזה Joryio שולח את המפתח כפרמטר ws_key, ש-PrestaShop מקבל גם הוא. אם שניהם נדחים, בדקו את כללי השרת או תוסף האבטחה עבור /api/.

החיבור נכשל: כתובת החנות

• השתמשו בכתובת ה-https הסופית של החנות. כתובת חנות שמפנה הלאה (למשל מ-http:// או ל-www.) נדחית.
• הכתובת חייבת להיות ציבורית. כתובות מקומיות, של רשת פרטית ו-.local נדחות.

שום דבר לא מגיע ל-Joryio

• בדקו את התור בעמוד המודול: אירועים ממתינים, אירועים שלא נמסרו והשגיאה האחרונה.
• הגדירו את משימת ה-cron, במיוחד בחנות שקטה.

Web Push: לא מופיעה בקשת הרשאה

• פתחו את https://your-shop/joryio-sw.js: הכתובת חייבת להציג סקריפט שמתחיל ב-// Joryio web push. אם לא, פעלו לפי הגדרת Web Push.
• השאירו את Storefront tracking ואת In-app messages מופעלים, וצרו ב-Joryio הודעת in-app של בקשת הרשמה להתראות.

קודי קופון לא נוצרים

• "PrestaShop refused coupon access": עדכנו את המודול לגרסה 1.1.0 ומעלה, או לחצו Connect שוב.
• תוכנית למוצרים או קטגוריות נבחרים צריכה מודול בגרסה 1.1.0 ומעלה בחנות.

הגשת טופס לא מגיעה

בדקו שהטופס מופעל ושמופה בו שדה מייל או טלפון בשם המדויק של השדה, שבאיש הקשר שנבחר בטופס יצירת הקשר מופעל Save messages, ושה-cron רץ (ראו שום דבר לא מגיע ל-Joryio). הרשמה לרשימה דורשת גם הסכמה: במצב הסכמה, התיבה צריכה להיות מסומנת.

"מפתח API לא תקין"

• המפתח חייב להתחיל ב-jry_ps_ ולהתאים למפתח שמוצג בעמוד PrestaShop ב-Joryio.
• Disconnect בעמוד המודול שומר על המפתח (מודול 1.2.1 ואילך): לחצו שוב על Connect איתו. ניתוק ב-Joryio, או הסרת המודול, מבטלים אותו - והחיבור אומר זאת; צרו מפתח חדש והדביקו אותו לפני שתלחצו שוב על Connect.