אינטגרציית Magento

חברו את חנות ה-Magento 2 שלכם באמצעות התוסף Joryio Connect. סנכרנו מוצרים, הזמנות, לקוחות ועגלות, עקבו אחר התנהגות המשתמשים בחנות ושחזרו עגלות נטושות.

יכולות

• תוסף מותקן דרך Composer - מודול Magento 2 מקורי, ללא צורך ב-OAuth
• סנכרון אוטומטי - מוצרים, הזמנות, לקוחות ועגלות מוזרמים ל-Joryio מדי דקה
• ייבוא היסטורי - מוצרים, לקוחות והזמנות קיימים (90 הימים האחרונים כברירת מחדל) מיובאים בעת החיבור
• שחזור עגלות נטושות - זיהוי עגלות נטושות ושליחת קישורי שחזור שמחזירים את העגלה
• מעקב בחנות - צפיות בדפים, במוצרים ובקטגוריות, הוספה לעגלה ואירועי checkout
• זיהוי לקוחות - זיהוי אוטומטי של לקוחות בעת התחברות, הרשמה לניוזלטר ו-checkout
• ייחוס הכנסות - הזמנות מיוחסות לקמפיין או למסע שהוביל אליהן
• טריגרים בקטלוג - עדכוני מלאי ומחיר מזינים טריגרים של חזרה למלאי וירידת מחיר

דרישות מקדימות

• Magento Open Source או Adobe Commerce 2.4.x
• גישה לשורת הפקודה בשרת ה-Magento שלכם עם Composer
• Magento cron מוגדר ופועל - התוסף שולח אירועים באמצעות cron, ולכן זו דרישה הכרחית
• גישת HTTPS יוצאת משרת ה-Magento שלכם אל Joryio

שלבי הגדרה

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

1. ב-Joryio, עברו אל הגדרות → אינטגרציות → Magento
2. העתיקו את כתובת השרת (Server URL). זו הכתובת של האזור שבו נמצא חשבון ה-Joryio שלכם, למשל https://api-eu1.joryio.com. מגרסה 1.4.1 של התוסף אין ערך ברירת מחדל, לכן הדביקו בדיוק את הערך הזה
3. לחצו על צור מפתח API והעתיקו את המפתח (מתחיל ב-jry_mg_). כשתפתחו את העמוד שוב בהמשך, יוצג אותו מפתח, מוסתר - לחצו על סמל העין כדי לראות אותו. המפתח נשאר זהה עד שהחנות מנותקת

שלב 2: התקנת התוסף

הורידו את קובץ ה-zip של התוסף (joryio-connect-magento2.zip) באמצעות כפתור הורד תוסף בעמוד אינטגרציית Magento בלוח הבקרה, חלצו אותו, ואז הריצו את הפקודות הבאות מתיקיית השורש של Magento:

composer config repositories.joryio path /path/to/joryio-connect
composer require joryio/module-connect
bin/magento module:enable Joryio_Connect
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush

לחלופין (ללא composer): חלצו את ה-zip לתיקייה app/code/Joryio/Connect והריצו את אותן פקודות bin/magento.

שלב 3: חיבור

1. בממשק הניהול של Magento, עברו אל Stores → Configuration → Joryio
2. הדביקו את כתובת השרת ואת מפתח ה-API משלב 1
3. לחצו על התחבר (Connect)

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

בסיום, הסטטוס מחובר מוצג גם בעמוד הניהול של Magento וגם בלוח הבקרה של Joryio.

הרשאה לטוקני גישה של OAuth כטוקני Bearer

Joryio קוראת את ה-REST API של החנות באמצעות טוקן הגישה של האינטגרציה "Joryio", שנשלח כטוקן Bearer. מגרסה 2.4.4, Magento מקבלת זאת רק כאשר Stores → Configuration → Services → OAuth → Consumer Settings → Allow OAuth Access Tokens to be used as standalone Bearer tokens מוגדר ל-Yes (ברירת המחדל היא No). כשההגדרה על No, הלחיצה על התחבר (תוסף בגרסה 1.4.1 ואילך) מסבירה זאת ושואלת לפני שהיא מפעילה אותה - שום דבר לא נוצר לפני שתאשרו. זו הגדרה ברמת החנות כולה: היא חלה על טוקני הגישה של כל האינטגרציות בחנות. אפשר גם להגדיר אותה ל-Yes בעצמכם ואז ללחוץ על התחבר.

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

מה מסתנכרן

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

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

מחיקת לקוח בחנות שלכם לא מוחקת את איש הקשר ב-Joryio. כדי למחוק את הנתונים של אדם, השתמשו במחיקת נתונים באיש הקשר.

מוצרים, מלאי וקטגוריות

• מוצרים ניתנים להגדרה (configurable) הם מוצר אחד ב-Joryio. מוצרי הבן שלהם (למשל כל מידה או צבע) הופכים לווריאנטים שלו כשהם מוגדרים Not Visible Individually; בן שמוצג גם בפני עצמו נשאר גם מוצר. המוצר מציג את מחיר הבן הנמוך ביותר, נמצא במלאי כשאחד הבנים במלאי, והכמות שלו היא סך הכמויות של הבנים. כל ווריאנט נושא את האפשרויות שלו (למשל Color: Red), ומחיקת בן מסירה אותו מהמוצר.
• המלאי נקרא מהמקורות שלכם כשהחנות משתמשת ב-Multi-Source Inventory ‏(MSI), ואחרת מהגדרות המלאי של המוצר; עם MSI, כמויות ששמורות להזמנות שעוד לא נשלחו מופחתות (עד 2,000 מוצרים בכל סנכרון - השאר מציגים את כמות המקור עד העדכון הבא שלהם). מוצר שהמלאי שלו לא מנוהל מוצג במלאי, בלי כמות.
• קטגוריות מסתנכרנות לפי שם (קטגוריית השורש של החנות לא).
• שורות הזמנה של מוצר ניתן להגדרה נושאות את שם המוצר ואת ה-SKU של הווריאנט שהלקוח קנה.
• סכומי קופונים: Magento מדווח הנחה אחת לכל כללי המחיר של העגלה בהזמנה. כשהקופון היה הכלל היחיד, סכום הקופון הוא ההנחה של ההזמנה. כשיש כמה כללים, Joryio מציגה את סכום הקופון רק כשכל שורה שקיבלה הנחה קיבלה אותה מכלל אחד; אחרת ההזמנה מציינת שהחנות לא דיווחה עליו.

קטגוריות, מלאי MSI ועדכוני ווריאנטים מהתוסף דורשים את גרסה 1.4.4 של התוסף - ראו שדרוג לגרסה 1.4.4.

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

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

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

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

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

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

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

החזר בהזמנת Magento הופך לאירוע Order Refunded אחד עם הסכום שהוחזר, וכל הזמנה שבוטלה לאירוע Order Cancelled אחד, כך שמסע יכול להגיב להם. ההרחבה מדווחת על ביטולים ועל החזרים מלאים (סטטוס closed) ברגע שהם קורים; זיכוי (credit memo) חלקי נקלט בפעם הבאה שההזמנות מסונכרנות. ראו אירועי החזר וביטול.

איך נתוני החנות מעדכנים איש קשר

הזמנות, checkouts ועדכוני לקוחות מהחנות שלכם מעדכנים את איש הקשר המתאים ב-Joryio:

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

מעקב בחנות

התוסף מוסיף קטע מעקב קל לחנות שלכם (פעיל כברירת מחדל - אפשר לכבות אותו ב-Stores → Configuration → Joryio). כל אירוע נשמר בשמו הסטנדרטי (העמודה נשמר בשם) - אותו שם שבו משתמשות האינטגרציות של WooCommerce ו-Shopify וה-SDK:

אירוע	נשמר בשם	מתי הוא נשלח
Page View	Page Viewed	כל ביקור בדף
Product Viewed	Product Viewed	דף מוצר. כולל את מצב המלאי: in_stock (true או false) ו-stock_status (in_stock או out_of_stock)
Category Viewed	Product List Viewed	דף קטגוריה, עם category_id, category_name וכתובת הדף (תוסף v1.1.1 ומעלה)
Add to Cart	Product Added	כל הוספה: כפתור ה-AJAX, טופס מוצר שטוען את הדף מחדש, והעברה מרשימת המשאלות לעגלה. Magento רושם את ההוספה והדפדפן של הקונה שולח אותה פעם אחת (תוסף v1.1.1 ומעלה). הזמנה חוזרת מ-My Account אינה נספרת
Checkout Started	Checkout Started	דף ה-checkout, פעם אחת לכל עגלה. רענון של דף ה-checkout אינו התחלה שנייה
Identify	$identify	לכידת אימייל

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

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

אירועי מוצר כוללים product_id, variant_id (האפשרות שנבחרה במוצר configurable), quantity, price, currency ואת מצב המלאי.

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

Content Security Policy

מגרסה 1.4.6 של התוסף, סניפט המעקב לא מכיל סקריפט inline: הוא קובץ שמוגש מהחנות שלכם (Joryio_Connect/js/tracking.js), וההגדרות שלו הן בלוק נתונים בדף. Magento 2.4.7 ואילך אוכפת Content Security Policy מחמיר בדפי הקופה והתשלום, והוא חוסם סקריפטים inline - בגרסה 1.4.5 ומטה, הקופה לא שלחה Checkout Started, לא זיהוי (identify) משדה האימייל ולא Page View. שום דבר לא דורש 'unsafe-inline'. התוסף מוסיף למדיניות את *.joryio.com ואת sdk.joryio.com עבור סקריפטים וקריאות API; אם כתובת השרת (Server URL) שלכם אינה תחת joryio.com, הוסיפו את הדומיין שלה למדיניות בעצמכם. אחרי שדרוג חנות במצב production, הריצו bin/magento setup:static-content:deploy כדי שהקובץ החדש יפורסם.

אחרי שינוי הגדרות

ההגדרות של הסניפט - כתובת השרת (Server URL), Inject Tracking Snippet והגדרות הודעות ה-in-app וה-Web Push - הן חלק מכל דף, ולכן מטמון הדפים המלא (full-page cache) של Magento שומר את הערכים שהיו כשהדף נשמר במטמון. מגרסה 1.4.6 של התוסף, Save Config, התחבר ו-Disconnect מנקים בדיוק את הדפים במטמון שמכילים את הסניפט, במטמון הדפים של Magento וב-Varnish, ולא נוגעים בשאר המטמון. בגרסה 1.4.5 ומטה, הריצו bin/magento cache:flush אחרי שינוי ההגדרות האלה. מטמון CDN או proxy שנמצא לפני Magento לא מתנקה על ידי Magento: נקו אותו אחרי שינוי כתובת השרת. עד אז, דף ישן מהמטמון לא שולח דבר בדפדפן שכבר טען דף עדכני - הוא אף פעם לא שולח לכתובת הישנה. ייתכן ש-Magento עדיין יציג One or more of the Cache Types are invalidated: Page Cache אחרי Save Config: Magento מסמן כך את מטמון הדפים אחרי כל שמירת הגדרות, בכל מקטע. הדפים עם הסניפט כבר נוקו; רעננו את Page Cache ב-System > Cache Management כשנוח לכם.

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

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

מגרסת הרחבה 1.4.21, ב-Stores → Configuration → Joryio יש את Recognise visitors by the email they type. ההגדרה מופעלת כברירת מחדל, והרחבה ישנה יותר מתנהגת כאילו היא מופעלת. מדווח הערך של Default Config.

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

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

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

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

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

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

מגרסה v1.3.0 של התוסף, סניפט המעקב טוען בחנות גם את ה-SDK של Joryio לווב, מהכתובת https://sdk.joryio.com/web/1/joryio.min.js (הגרסה העדכנית ביותר של 1.x). קריאות הנתונים שלו נשלחות ל-Server URL שהגדרתם, כמו הסניפט. ההגדרות נמצאות ב-Stores → Configuration → Joryio → In-app messages and web push:

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

חנויות שמשדרגות מגרסה ישנה של התוסף מקבלות את אותן ברירות מחדל. ה-SDK נטען על ידי סניפט המעקב, ולכן השאירו את Inject Tracking Snippet מופעל. התוסף מתיר את *.joryio.com ב-Content Security Policy של Magento עבור סקריפטים וקריאות API.

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

Web Push. דפדפן מקבל את ה-service worker של ההתראות רק מהכתובת של החנות עצמה. כש-Web push מופעל, התוסף עונה על https://your-store/joryio-sw.js (נתיב של Magento שמכסה את כל החנות), שטוען את ה-worker המאוחסן של Joryio. הגדרות ה-nginx וה-Apache הסטנדרטיות של Magento מעבירות את הכתובת הזו ל-Magento; אם השרת שלכם מגיש קובצי .js ישירות מהדיסק, הוסיפו הפניה (rewrite) מ-/joryio-sw.js ל-/joryio/sw/index. הקונים מתבקשים להירשם דרך הודעת in-app של בקשת הרשמה להתראות, לכן השאירו את הודעות ה-in-app מופעלות, והפעילו Web Push לאפליקציה גם ב-Joryio. כיבוי Web Push גורם לאותה כתובת להגיש worker שמסיר את עצמו מהדפדפנים של המבקרים.

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

הסכמה לשיווק

המינוי לניוזלטר של Magento נשלח ל-Joryio (התוסף בגרסה v1.1.0 ומעלה) ומוחל על מינוי האימייל של איש הקשר:

ב-Magento	ב-Joryio
Subscribed	נרשם לאימייל. מי שביטל את המינוי נרשם מחדש רק במקרים שבמה עושים הסכמה או ביטול מחנות; אחרת הוא יכול להירשם מחדש בעצמו דרך מרכז ההעדפות.
Unsubscribed	המינוי לאימייל מבוטל - אלא אם Joryio רשם שינוי מאוחר יותר לאיש הקשר.
Not Activated, Unconfirmed	אין שינוי.

כל דרך שבה הסטטוס משתנה נספרת: התיבה "Sign Up for Newsletter" בטופס ההרשמה ובדף החשבון, ממשק הניהול של החנות, ה-API וקישור ביטול המינוי בניוזלטרים שלך. הייבוא ההיסטורי רושם לקוחות ש-Magento מסמנת כרשומים; הוא לא מבטל מינוי לאף אחד, כי ה-API של Magento לא מבדיל בין "מעולם לא נרשם" ל"ביטל". כל שינוי נרשם בהיסטוריית המינוי של איש הקשר (מקור magento_newsletter), עם רמת ההסכמה (מאושרת כשההגדרה Need to Confirm של Magento פעילה) והזמן ש-Magento רשמה את השינוי.

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

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

תיבת הסכמה בקופה

ל-Magento אין תיבת ניוזלטר בקופה. כדי לשאול שם, הפעילו את Stores → Configuration → Joryio → Marketing Consent Checkbox → Show the Checkbox at Checkout. התיבה מופיעה מתחת לאמצעי התשלום.

הגדרה	ברירת מחדל	הערות
Show the Checkbox at Checkout	No
Checkbox Text	"Yes, I'd like to receive news and offers by email"	הטקסט המדויק שהקונה ראה נרשם יחד עם הבחירה שלו.
Ticked by Default	No	לא מומלץ - לפי ה-GDPR (האיחוד האירופי ובריטניה) תיבה מסומנת מראש אינה הסכמה תקפה.
SMS Consent Checkbox	No	תיבה שנייה להודעות טקסט, עם טקסט משלה. טלפון החיוב נרשם.

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

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

תוסף 1.4.14 ואילך: Stores → Configuration → Joryio → Marketing Consent Checkbox → When a Shopper Ticks the Checkout Opt-In.

אפשרות	מה קורה
Only when the order is placed (ברירת המחדל)	הבחירה מגיעה ל-Joryio עם ההזמנה. קונה שמסמן ונוטש לא נרשם.
Record consent immediately	הסימון מגיע ל-Joryio ברגע שהקונה מסמן, לפני ההזמנה. קונים ומנויים מוכרים נספרים מיד; אורח חדש נספר אחרי ההזמנה שלו או אחרי שאישר במייל (ראו למטה). אם הקונה מבטל את הסימון שוב באותה קופה, הסימון הזה מבוטל - רק הוא: מינוי שנתן בכל מקום אחר נשאר. גם אירוע העגלה הנטושה נושא את התיבה כפי שהקונה השאיר אותה.

מי נספר מיד עם Record consent immediately (1.4.16 ואילך):

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

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

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

• לשלוח לאורחים חדשים קישור אישור במייל - כבוי כברירת מחדל, כי הכתובת הוקלדה בקופה ואיש עוד לא אימת אותה. כשההגדרה פועלת, אורח חדש שנמצא בהמתנה מקבל מייל אחד; הקישור בו רושם אותו (מקור double_opt_in). המייל משתמש בתבנית האישור של double opt-in אם בחרתם כזו.

• סימוני הסכמה לקונה בשעה - ברירת מחדל 3, לפי כתובת IP, לפי קופה ולפי כתובת אימייל. סימונים מעבר למגבלה לא נרשמים, ואירוע העגלה הנטושה של אותה קופה לא נושא הסכמה; ההזמנה עדיין רושמת את הבחירה. לתוסף יש אותה מגבלה (Opt-In Ticks per Shopper per Hour, ברירת מחדל 3), והוא עוצר סימון כזה לפני שהוא נשלח.

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

• כל שינוי נשלח פעם אחת; פתיחה או רענון של הקופה לא שולחים דבר.

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

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

ניסוח ההסכמה וה-GDPR

עם Record consent immediately, סימון הוא הסכמה לשיווק בפני עצמו - הוא לא קשור לרכישה. ודאו שטקסט התיבה אומר מה הקונה מסכים לקבל ובאיזה ערוץ (למשל "Yes, I'd like to receive news and offers by email"), השאירו את התיבה לא מסומנת כברירת מחדל ונפרדת מאישור התנאים שלכם, והזכירו אותה במדיניות הפרטיות. Joryio רושם עם כל סימון את הטקסט שהוצג, את הזמן, את החנות, את הקופה ואת כתובת ה-IP של הקונה. סימון של אורח חדש נשאר בהמתנה עד ההזמנה שלו או האישור שלו, כך שאף אחד לא מקבל שיווק כי מישהו אחר הקליד את הכתובת שלו; מייל האישור נשלח רק אם הפעלתם אותו. תזכורת העגלה הנטושה מגיעה אז לקונה רשום כהודעה שיווקית.

מוצג ב-Joryio, מוגדר בהרחבה

אינטגרציות → Magento → הגדרות מציג את הגדרות ההסכמה בקופה של ההרחבה בכרטיס Store checkout opt-in (set in your store), לקריאה בלבד: Show the Checkbox at Checkout, Ticked by Default ו-When a Shopper Ticks the Checkout Opt-In, עם גרסת ההרחבה ומתי דיווחה עליהן לאחרונה. משנים אותן רק ב-Magento, תחת Stores → Configuration → Joryio → Marketing Consent Checkbox; Joryio אף פעם לא משנה אותן. מוצגים ערכי Default Config - store view שדורס אחד מהם לא מוצג. עם Record consent immediately, הכרטיס מציג גם את הגדרות Joryio שקובעות אז מה סימון עושה: Opt-ins from new shoppers, אימייל האישור והמגבלה לשעה.

הרחבה בגרסה 1.4.17 ומעלה מדווחת עליהן עם כל בקשה שהיא שולחת ל-Joryio - עגלות, עגלות נטושות, הזמנות, לקוחות, מוצרים וכל השאר - ופעם נוספת כששומרים אחת מהן. שינוי, כמו גרסת הרחבה חדשה אחרי עדכון, מוצג מהבקשה הבאה; דיווח שלא השתנה נרשם מחדש לכל היותר פעם בשעה, כך שזמן הדיווח האחרון יכול להיות בן עד שעה. עם הרחבה ישנה יותר הכרטיס מציג Not reported yet - update the plugin.

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

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

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

היא חלה על כל הסכמה שמגיעה בלי הזמנה: ההרשמה לניוזלטר מטופס ההרשמה, מדף החשבון, מממשק הניהול ומה-API, הייבוא ההיסטורי, ועם Record consent immediately - גם הסימון בקופה. בכל מקרה:

• קונה מוכר או מי שכבר רשום נספר מיד, וכך גם הרשמה ש-Magento אישרה (Need to Confirm);
• סימון שמגיע עם ההזמנה של הקונה עצמו תמיד נספר;
• הסרה מרשימת התפוצה תמיד חלה מיד;
• המגבלה סימוני הסכמה לקונה בשעה נשארת בתוקף.

זו לא אותה הגדרה כמו When a Shopper Ticks the Checkout Opt-In בתוסף: ההגדרה ההיא קובעת מתי סימון בקופה נשלח - עם ההזמנה או ברגע שהוא נעשה; ההגדרה הזו קובעת מה עושה הסכמה מוקדמת של קונה חדש. עם Only when the order is placed, סימון בקופה מגיע עם ההזמנה ותמיד נספר, ולכן ההגדרה הזו חלה רק על הסכמות בהרשמה ובחשבון.

מה עושים הסכמה או ביטול מחנות

מה החנות שולחת	מה Joryio עושה
סימון הסכמה ב-checkout של אורח	רושם איש קשר שעדיין אין לו מינוי בערוץ הזה. אלא אם ההגדרה של החנות שלמטה מופעלת, לעולם לא רושם מחדש מי שביטל את המינוי - ב-checkout כאורח כל אחד יכול להקליד כל כתובת אימייל.
הסכמה של לקוח מחובר (הזמנה של לקוח מחובר, לא אורח), עם תאריך מאוחר מהביטול האחרון של איש הקשר	רושם מחדש גם איש קשר שביטל את המינוי דרך קישור הסרה או כפתור ההסרה בלחיצה אחת, דף ההעדפות, ה-API, חבר צוות, או ביטול שנעשה באותה חנות.
הסכמה ב-checkout או ברשומת הלקוח, כשההגדרה לאפשר לסימון הסכמה בקופה לרשום מחדש אנשים שהסירו את עצמם מופעלת (כבויה כברירת מחדל)	רושם מחדש איש קשר שביטל את המינוי - גם אחרי checkout כאורח - כשהזמן שהחנות רשמה להסכמה מאוחר מהביטול האחרון שלו. הסיכון: ב-checkout כאורח Magento לא יכולה לומר ל-Joryio מי הקונה, כך שמי שמקליד בקופה את האימייל של אדם אחר יכול לרשום אותו מחדש; תמיד אפשר לבטל שוב בלחיצה אחת. המקרים שלמטה שלעולם לא מתבטלים עדיין חלים.
תיבה לא מסומנת	אין שינוי - זה אף פעם לא ביטול מינוי. אלא אם הפעלתם בחנות את תיבה לא מסומנת מבטלת הרשמה (כבויה כברירת מחדל).
ביטול בחנות	מבטל את המינוי, אלא אם Joryio תיעדה שינוי מאוחר יותר לאיש הקשר הזה.
לעולם לא מתבטל בהסכמה מחנות, כשההגדרה מופעלת או כבויה	תלונת ספאם, החזרה קשה (hard bounce), חסימה ברמת הארגון, סביבת עבודה אחרת, ביטול שנרשם באיש קשר אחר עם אותו אימייל או טלפון, ו-STOP ב-SMS.

• ההגדרה נמצאת ב-אינטגרציות → Magento → הגדרות, אחת לכל חיבור חנות, כבויה כברירת מחדל. רק מנהלים יכולים לשנות אותה, וכל שינוי נרשם ביומן הביקורת.
• רישום מחדש חל רק על איש הקשר הזה; אנשי קשר אחרים עם אותו אימייל או טלפון נשארים ללא מינוי. היסטוריית איש הקשר מציינת מדוע, למשל נרשם מחדש ב-checkout של החנות (לקוח מחובר) אחרי שביטל דרך דף ההעדפות.
• SMS: כשאישור כפול (double opt-in) ל-SMS פעיל, רישום מחדש שולח הודעה אחת "השיבו YES" ואיש הקשר נשאר בהמתנה עד שישיב. איש קשר ששלח STOP חוזר רק בדרך הזו - כשאישור כפול ל-SMS כבוי, הסכמה מחנות לעולם לא רושמת אותו מחדש.
• הסכמה מחנות רושמת לערוץ, לא לרשימה: רשימה שדורשת אישור כפול עדיין שולחת את אימייל האישור כשהאדם מצטרף אליה.

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

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

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

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

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

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

• Joryio אינה זמינה או עמוסה - התור נעצר ומנסה שוב אחרי הפסקות הולכות וגדלות: 1, 2, 4, 8, 16 ו-32 דקות, ואחר כך פעם בשעה, עד 7 ימים. כש-Joryio חוזרת, האירועים הממתינים מגיעים, לפי הסדר שבו קרו לכל הזמנה, עגלה ולקוח.
• אירוע ש-Joryio דוחה (למשל נתונים לא תקינים) מוצא מיד מהתור, כך שאינו מעכב את האחרים.
• Joryio דוחה את מפתח ה-API (החנות נותקה ב-Joryio, או שנוצר מפתח חדש) - המסירה נעצרת וממשק הניהול של Magento מציג הודעה. האירועים נשמרים: הדביקו את המפתח העדכני ולחצו על התחבר, והמסירה ממשיכה.
• אירועים שלא נמסרו נשמרים 30 ימים.

Stores → Configuration → Joryio → Event Queue מציג כמה אירועים ממתינים, בניסיון חוזר ולא נמסרו, את השגיאה האחרונה ואת המסירה המוצלחת האחרונה. Retry now שולח שוב כל אירוע ממתין או שלא נמסר. מגרסה 1.4.4, שמירה של Server URL או API key חדשים, התחבר שהצליח או Test Connection שעבר מסיימים את ההשהיה מיד: אירועים ממתינים נשלחים בריצה הבאה (תוך דקה) והשגיאה הישנה נמחקת.

ניתוק והסרה

• ניתוק בממשק הניהול של Magento מסיים את החיבור: Joryio מפסיקה לסנכרן, טוקן הגישה של האינטגרציה "Joryio" ב-Magento מבוטל, ואירועים שעדיין ממתינים נשמרים בצד (אחרי חיבור מחדש, Retry now שולח אותם). מפתח ה-API נשאר בתוקף - לחצו שוב על התחבר עם אותו מפתח (תוסף בגרסה 1.4.3 ואילך; גרסאות קודמות ביטלו אותו).
• ניתוק ב-Joryio (הגדרות → אינטגרציות → Magento) מבטל את מפתח ה-API מיד: בפעם הבאה שהתוסף שולח אירוע הוא נעצר ומציג הודעה. חיבור עם המפתח הזה מציג אז "This key was revoked when the store was disconnected in Joryio", ועמוד Magento ב-Joryio מסביר למה אין מפתח. צרו מפתח חדש כדי להתחבר שוב. כדי לבטל גם את טוקן הגישה של Magento, לחצו על Disconnect בממשק הניהול של Magento.
• חנות אחת, סביבת עבודה אחת. חנות שמחוברת לסביבת עבודה אחת ב-Joryio אינה יכולה להתחבר לאחרת: החיבור מציג "This store is already connected to another Joryio workspace." נתקו אותה קודם בסביבת העבודה האחרת.
• הסרה באמצעות bin/magento module:uninstall Joryio_Connect (כשהותקן עם composer) או bin/magento module:uninstall --non-composer Joryio_Connect (כשהותקן ב-app/code). היא מנתקת את החנות, מבטלת את מפתח ה-API (גרסה 1.4.3 ואילך), מוחקת את האינטגרציה "Joryio" ומסירה את הטבלאות וההגדרות של התוסף. מחיקת הקבצים בלי module:uninstall לא עושה דבר מזה - לחצו קודם על Disconnect.

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

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

מה שקישור השחזור (https://your-store.com/joryio/cart/restore?token=...) עושה תלוי במי שפותח אותו (גרסת התוסף 1.4.8 ואילך). Magento שומרת עגלה של חשבון לקוח רק כשהלקוח הזה מחובר, ולכן:

• הלקוח עצמו, מחובר - העגלה השמורה שלו חוזרת.
• אף אחד לא מחובר (המקרה הרגיל: הקישור נפתח ממייל במכשיר אחר) - המוצרים, עם האפשרויות, הכמויות וקוד ההנחה אם הוא עדיין תקף, מועתקים לעגלה בדפדפן הזה, עם ההודעה "Sign in to use your saved details at checkout." התחברות לאחר מכן משאירה עגלה אחת; הכמויות לעולם לא מוכפלות.
• עגלה של אורח - גם כאן המוצרים מועתקים. השם, המייל והכתובות של האורח לא מועתקים, כך שקישור שהועבר לא חושף פרטים של אף אחד.
• לקוח אחר מחובר - נדחה עם ההודעה "This cart belongs to a different account. Sign out to open it as a guest." שום דבר לא נוסף לעגלה שלו ואף אחד לא מוזכר בשמו.
• לקוח מחובר פותח עגלה של אורח, או שבעגלה בדפדפן הזה כבר יש מוצרים - עמוד שואל "Add these products from your saved cart to your current cart?"; שום דבר לא נוסף עד שלוחצים Add to my cart.
• העגלה כבר הוזמנה - "You already completed this order."
• נפתח שוב - אותו דפדפן מגיע לעגלה שכבר יש בו; דפדפן או מכשיר אחר מקבלים עגלה חדשה עם המוצרים השמורים (למטה). עגלה של לקוח שכבר הועברה אליו בהתחברות מציגה "This link was already used - sign in to see your cart."

קישור לעולם לא משנה עגלה קיימת של מישהו אחר: כשאתר אחר טוען אותו כתמונה או כמסגרת הוא לא עושה כלום, והוספה לעגלה קיימת תמיד דורשת את האישור. אם האישור נשלח אחרי שתוקף הסשן של העמוד פג, הקונה רואה "Your session has expired. Please open the cart link again." ושום דבר לא משתנה.

קישור נפתח רק בתצוגת החנות (store view) שבה העגלה נשמרה (תוסף 1.4.10 ואילך): בתצוגת חנות אחרת של אותה חנות הוא מציג "This cart was saved in another of our stores. Please open the link from your email again." ולא משנה כלום. קישורים שנשלחו מגרסה 1.4.9 ומטה ממשיכים לעבוד, עם אותה בדיקה, עד 31 בינואר 2027.

"Your cart has been restored." מוצג רק כשדף העגלה מציג את המוצרים. מוצרים שכבר אי אפשר לקנות לא מועתקים, ושמם מופיע בהודעה. הזמנה שבוצעה מעגלה מועתקת נספרת ב-Joryio כשחזור של אותה עגלה, גם כשהקונה משלים כאורח עם מייל אחר.

גרסה 1.4.7 ומטה של התוסף הציגה "Your cart has been restored." מעל עגלה ריקה כשהלקוח לא היה מחובר - יש לעדכן לגרסה 1.4.8.

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

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

• פתיחת הקישור מציגה עמוד קצר, "Restoring your saved cart...", שלעולם לא נשמר במטמון ולא נסרק למנועי חיפוש. הסקריפט שלו משחזר את העגלה וממשיך לעמוד העגלה; בלי סקריפט הקונה לוחץ Restore my cart. תצוגה מקדימה או סורק שלא מריצים סקריפט לא משחזרים דבר. עמוד האישור שלמעלה עדיין מחכה ללחיצה של הקונה.
• עגלה אחת לכל קישור, בכל דפדפן - העגלה שהקישור שחזר נשמרת יחד עם הדפדפן שבו היא שוחזרה (עוגייה). פתיחה חוזרת של אותו קישור באותו דפדפן (למשל אחרי שהסשן שלו הסתיים) מחזירה את אותה עגלה במקום עותק חדש, למשך 7 ימים: Stores > Configuration > Joryio > Tracking > Recovery Link Reuses Its Cart For (days), 1-30. דפדפן או מכשיר אחר - או סורק שכן הריץ את העמוד - לעולם לא מקבלים את העגלה הזו: הם מקבלים עגלה חדשה עם המוצרים וקוד ההנחה של העגלה השמורה בלבד, כך ששום דבר שמישהו הקליד בקופה בדפדפן אחד לא מופיע בדפדפן אחר. מאותו רגע הקישור זוכר את העגלה של הדפדפן האחרון. שתי העגלות עדיין נחשבות לאותה עגלה שמורה: הזמנה מכל אחת מהן היא שחזור אחד, ונשלחת רק תזכורת אחת על "ננטשה שוב" לכל עגלה מקורית.
• כבר הוזמן - כשהעגלה שהקישור שחזר הפכה להזמנה, הקישור מציג "You already completed this order." ולא משחזר דבר.
• לכל היותר 10 שחזורים לקישור בשעה - אחר כך, "Too many attempts with this cart link. Please try again later."

עותקים שגרסאות קודמות כבר יצרו עדיין מקבלים לכל היותר תזכורת אחת לכל עגלה מקורית (עגלה משוחזרת שננטשה שוב). bin/magento setup:upgrade ל-1.4.18 גם מסיר את הסימונים שנשארו על עגלות משוחזרות שכבר הוזמנו ומשלים את העגלה המקורית שלהן; הספירה נכתבת ל-var/log/joryio.log.

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

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

עגלה משוחזרת שננטשה שוב

החל מתוסף 1.4.13, שחזור עגלה אינו מסמן דבר כנטוש. עותק משוחזר שהקונה עוזב שוב מדווח פעם נוספת אחרי זמן הנטישה הרגיל, עם reabandonedAfterRecovery: true ו-originalSessionId באירוע Cart Abandoned; עותק נוסף של אותה עגלה מקורית שנשאר ללא פעילות בתוך 30 יום אינו מדווח. עגלה שכבר היו בה מוצרים וקיבלה את המוצרים השמורים היא עגלה רגילה. הזמנה מכל עותק נספרת כשחזור אחד של העגלה המקורית. ראו עגלות.

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

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

מהרחבה 1.4.23, כל אירוע עגלה נושא את קישור השחזור של העגלה ואת המידע אם זו עגלה של אורח, וההרחבה מדווחת על Track Guest Carts ועל זמן הנטישה בכל בקשה, כך שעגלה ש־Joryio מסמנת כנטושה בעצמה פועלת לפיהם - ראו עגלות. כתובת אימייל שאורח מקליד בשלב האימייל של התשלום מגיעה לעגלה רק כשהקונה ממשיך לשלב המשלוח (Magento שומרת אותה אז); לפני כן היא מזהה את הדפדפן בלבד, והעגלה לא מדווחת.

תוסף 1.4.8 עד 1.4.12 סימן עגלה משוחזרת כמדווחת כבר ברגע השחזור, ולכן קונה שעזב אותה שוב לא קיבל תזכורת. bin/magento setup:upgrade ל-1.4.13 מסיר את הסימונים האלה (רק את אלה שנוצרו ברגע השחזור, בלי אירוע נטישה מאחוריהם) וכותב את הספירה ל-var/log/joryio.log.

פתרון בעיות

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

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

• ודאו ש-cron מוגדר: bin/magento cron:install (או בדקו את ה-crontab שלכם)
• הריצו אותו ידנית לבדיקה: bin/magento cron:run
• בדקו את var/log/joryio.log בתיקיית השורש של Magento כדי לאתר שגיאות בשליחה
• בדקו את Stores → Configuration → Joryio → Event Queue (תוסף v1.4.0 ואילך): שם מוצגים האירועים הממתינים ואלה שלא נמסרו, עם השגיאה האחרונה. ראו מסירה וניסיונות חוזרים

החיבור נכשל

מגרסה 1.4.2 של התוסף, התחבר בודק קודם את טוקן הגישה החדש בחנות, כמו שה-REST API של Magento יבדוק אותו: הגדרת ה-Bearer של OAuth עבור תצוגת החנות ש-Joryio פונה אליה, הבדיקה של Magento עצמה לטוקן, ההרשאות של האינטגרציה "Joryio", ובקשה מהשרת שלכם לכתובת החנות שלו. אם אחת מהן נכשלת, החיבור נעצר לפני ש-Joryio מעורבת ומציין את הסיבה; לא נשאר שום דבר מאחור. התוצאה נכתבת גם ל-var/log/joryio.log (השורה שמתחילה ב-Joryio connect self-test). ליד הכפתורים, עמוד ההגדרות מציג אם הגדרת ה-Bearer כבר מופעלת.

ההודעה אומרת	מה לעשות
"Allow OAuth Access Tokens to be used as standalone Bearer tokens" מוגדר ל-No עבור תצוגת החנות ש-Joryio פונה אליה	הגדירו ל-Yes - בדקו גם את רמות האתר ותצוגת החנות, ערך שם גובר על Default Config. ראו הרשאה לטוקני גישה של OAuth כטוקני Bearer
לאינטגרציה "Joryio" חסרות ההרשאות האלה	הריצו bin/magento setup:upgrade ו-bin/magento cache:flush, ואז לחצו שוב על התחבר. בדקו ב-System → Extensions → Integrations → Joryio → API שהמשאבים המפורטים מסומנים
כתובת החנות שלכם נענית על ידי התקנת Magento אחרת	כתובת הבסיס ב-Stores → Configuration → General → Web מפנה לעותק אחר של החנות (למשל סביבת staging). תקנו אותה ואז התחברו
שרת האינטרנט מסיר את הכותרת Authorization	ראו "הכותרת Authorization מוסרת" בהמשך
בקשה עם הטוקן החדש ל-rest/V1/store/storeConfigs נדחתה	מודול אבטחה, חומת אש או כלל בשרת האינטרנט שלפני ה-REST API של Magento דוחים אותה. אפשרו בקשות ל-/rest/ עם הכותרת Authorization
החנות מקבלת את הטוקן מהשרת שלה, אבל דחתה אותו כש-Joryio פנתה	משהו שלפני החנות מטפל אחרת בבקשות מבחוץ (חומת אש, CDN, WAF, הגנה מבוטים). אפשרו בקשות ל-/rest/ עם הכותרת Authorization
עדכנו את התוסף Joryio Connect לגרסה 1.4.2 ואילך	התוסף שלכם ישן יותר. שדרגו (בהמשך) ולחצו שוב על התחבר
Joryio לא הצליחה להגיע לחנות	כתובת החנות חייבת להיות ציבורית ופעילה, עם תעודת HTTPS תקפה. כתובות פרטיות ופנימיות נדחות
This store is already connected to another Joryio workspace	נתקו אותה קודם בסביבת העבודה האחרת - ראו ניתוק והסרה
מפתח API לא תקין	העתיקו שוב את מפתח ה-API וגם את כתובת השרת מ-הגדרות → אינטגרציות → Magento ב-Joryio. מפתח מוכר רק לשרת של האזור שלו

הכותרת Authorization מוסרת. החיבור מדווח על כך רק כשהבקשה שלו עצמו לחנות הגיעה בלי הכותרת. לרוב Apache שמריץ PHP כ-CGI או FastCGI מסיר אותה. קובץ ה-.htaccess של Magento עצמה מעביר אותה; אם הקובץ שלכם הוחלף, או שהאחסון מתעלם ממנו, הוסיפו את השורות הבאות ל-.htaccess בתיקיית השורש של Magento (וגם ב-pub/ אם זו תיקיית השורש של האתר):

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

שדרוג לגרסה 1.4.2: החליפו את קבצי התוסף בקובץ ה-zip של גרסה 1.4.2 מלוח הבקרה של Joryio, ואז הריצו bin/magento setup:upgrade, bin/magento setup:di:compile (במצב production) ו-bin/magento cache:flush. גרסאות 1.4.0 ו-1.4.1 איבדו את ההרשאות של האינטגרציה "Joryio" בכל פעם שהפעילו או השביתו אותה; setup:upgrade מחזיר אותן, והתחבר משתמש באינטגרציה הקיימת, מנפיק טוקן חדש ומפעיל אותה - אין צורך למחוק אותה. ב-Stores → Configuration → Joryio בדקו את Server URL, לחצו על Save Config ואז על התחבר.

שדרוג לגרסה 1.4.4

החליפו את קבצי התוסף בקובץ ה-zip של גרסה 1.4.4 מלוח הבקרה של Joryio, ואז הריצו bin/magento setup:upgrade, bin/magento setup:di:compile (במצב production) ו-bin/magento cache:flush. setup:upgrade מאפשר לאינטגרציה "Joryio" לקרוא קטגוריות ומלאי (כולל מקורות ה-MSI, כשהחנות משתמשת בהם) - אין צורך להתחבר מחדש. אחר כך, ב-Joryio, פתחו את הגדרות → אינטגרציות → Magento ולחצו על סנכרן הכל: הסנכרון מאחד את מוצרי הבן לתוך המוצרים הניתנים להגדרה שלהם ומשלים מלאי, קטגוריות וסכומי קופונים למה שכבר סונכרן.

"מפתח API לא תקין" / חוסר התאמה במפתח

• המפתח חייב להתחיל ב-jry_mg_ ולהתאים למפתח המוצג כעת ב-הגדרות → אינטגרציות → Magento ב-Joryio
• פתיחה מחדש של עמוד ההגדרה ב-Joryio לא משנה את המפתח - רק ניתוק מבטל אותו. אם המפתח ב-Magento שונה מזה שמוצג ב-Joryio, הדביקו את המוצג ב-Joryio ולחצו שוב על התחבר
• ודאו שוב שכתובת השרת הועתקה במדויק
• ניתוק בממשק הניהול של Magento שומר על המפתח (גרסה 1.4.3 ואילך): לחצו שוב על התחבר איתו. ניתוק ב-Joryio, או הסרת התוסף, מבטלים אותו - והחיבור אומר זאת; צרו מפתח חדש ב-הגדרות → אינטגרציות → Magento והדביקו אותו לפני שתלחצו שוב על התחבר. אם החיבור מציג "This store is already connected to another Joryio workspace", נתקו אותה קודם בסביבת העבודה האחרת - ראו ניתוק והסרה

נתונים היסטוריים חסרים

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

המעקב לא עובד

• בדקו שסקריפט המעקב מופעל ב-Stores → Configuration → Joryio
• מגרסה 1.4.6 ואילך התוסף מנקה בעצמו את הדפים במטמון כשאתם שומרים את ההגדרה; בגרסה ישנה יותר הריצו bin/magento cache:flush (ראו אחרי שינוי הגדרות)
• ודאו שהסקריפט נטען בכלי הפיתוח של הדפדפן

הוספה לעגלה חסרה, מטמון דפים מלא ו-Varnish

• מטמון דפים מלא ו-Varnish תקינים: הקטע נושא רק נתוני דף, וההוספה לעגלה מגיעה לדפדפן דרך נתוני הלקוח של Magento עצמו (customer/section/load), שלעולם אינם נשמרים במטמון. אל תוסיפו כלל ששומר את הכתובת הזו במטמון
• ערכות נושא מבוססות Luma ו-Hyva נתמכות. חזית headless או PWA אינה טוענת את הקטע - שלחו אירועים עם Web SDK במקום
• אחרי שדרוג התוסף הריצו bin/magento setup:upgrade ו-bin/magento cache:flush כדי שה-section החדש של נתוני הלקוח יירשם

הקופה נתקעת על סמל טעינה, "Mismatched anonymous define()"

• בגרסה 1.4.6 של התוסף, הקופה בחנות מבוססת Luma יכלה להישאר על סמל הטעינה עד לטעינה מחדש של הדף. בקונסולת הדפדפן הופיעו Mismatched anonymous define() module (מקובץ ה-Web SDK של Joryio) ו-templateEngine must inherit from ko.templateEngine. הסניפט טען את ה-Web SDK בתגית script רגילה, ובדף שמשתמש ב-RequireJS קובץ ה-SDK נרשם באופן ש-RequireJS שייך לאחד ממודולי הקופה של Magento עצמו
• גרסה 1.4.7 של התוסף טוענת את ה-Web SDK דרך RequireJS בכל דף שיש בו RequireJS (Luma וערכות נושא שמבוססות עליה), ובתגית script רגילה רק כשאין (Hyva). שדרגו, הריצו bin/magento setup:upgrade, ‏bin/magento setup:static-content:deploy במצב production ו-bin/magento cache:flush
• לבדיקה: פתחו את הקופה עם הקונסולה פתוחה - אף אחת מההודעות לא מופיעה, ו-window.joryio.sdk קיים אחרי שהדף נטען (כשהודעות in-app או Web Push מופעלות)

עגלות של אורחים לא מסומנות כנטושות

• Magento שומר את האימייל של אורח על כתובת החיוב (או המשלוח) של העגלה בזמן שהוא בקופה, ומעתיק אותו לעגלה עצמה רק כשההזמנה מבוצעת. גרסה 1.4.6 של התוסף ומטה בדקה רק את העגלה עצמה, ולכן אורח שהזין אימייל בקופה ויצא אף פעם לא סומן כנוטש. מגרסה 1.4.7 גם האימייל שעל כתובת החיוב או המשלוח נחשב (השאירו את Track Guest Carts מופעל)
• עגלות אורחים נספרות מרגע התקנת גרסה 1.4.9 של התוסף (bin/magento setup:upgrade רושם אותו); עגלות אורחים שעמדו ללא שינוי לפני כן לא נשלחות בבת אחת. בגרסאות 1.4.7 ו-1.4.8 אף עגלת אורח לא דווחה דרך האימייל שעל הכתובת (זמן ההתחלה לא נשמר) - שדרגו ל-1.4.9. לבדיקה: התחילו קופה חדשה כאורח, הזינו אימייל, צאו, וחכו את זמן הנטישה ועוד עד 15 דקות (מרווח ה-cron)
• עגלה מסומנת כנטושה פעם אחת. קונה שלא הקליד אימייל (ואינו מחובר) אינו בר השגה ולא נשלח
• מגרסה 1.4.11 הקובץ var/log/joryio.log מציג זאת: Joryio: guest-cart start time set to <date> UTC (...) (או already set (<date> UTC), kept.) בזמן setup:upgrade, ו-Joryio: cart abandon queued: quote <id>, store <id>. לכל קישור שחזור שנוצר (מזהים בלבד - בלי אימייל, קישור או טוקן)

הוספה לעגלה או מעקב שנחסמים על ידי הגנת בוטים

חלק מכלי האבטחה של האחסון - למשל הגנת הבוטים של Imunify360 - עלולים לחסום את הבקשות של החנות עצמה (הוספה לעגלה, קריאות המעקב) עם "Access denied by Imunify360 bot-protection". אז Joryio לא מקבל אירועי הוספה לעגלה או צפייה בדפים, וקונים עלולים לראות שההוספה לעגלה נכשלת. בלוח הבקרה של האחסון, אפשרו את נתיבי ה-AJAX של החנות ואת הנתיבים של Joryio (/joryio/..., /customer/section/load, /checkout/cart/add), או הורידו את רגישות הגנת הבוטים לדומיין של החנות. חברת האחסון יכולה לומר איזה כלל הופעל.