פיתוח מודול אזור אישי ל-1C-Bitrix

ל-Bitrix יש רכיב מוכן system.auth.registration ודפי אזור אישי בחבילה הסטנדרטית, אבל הם מספיקים רק למקרה הפשוט ביותר: שינוי שם וצפייה בהזמנות. ברגע שעולה המשימה "להציג נקודות בונוס, היסטוריית צבירה, כרטיסי נאמנות מקושרים, מספר כתובות משלוח עם מפה ומסמכי חוזה B2B" — האזור הסטנדרטי הופך לנקודת התחלה לעיבוד מחדש, לא לפתרון מוכן. אנו מפתחים מודול אזור אישי במפתח מלא: אנו מנתחים תהליכים עסקיים, מתכננים את הארכיטקטורה ומיישמים את כל הסעיפים מאפס. הניסיון שלנו הוא 5+ שנים ו-50+ פרויקטים על Bitrix, ולכן אנו מבטיחים פעילות יציבה גם בעומס גבוה. יתרון לגודל — חיסכון של עד 40% בהשוואה להתאמה אישית לפי שעה של כל רכיב בנפרד.

איך לפתח אזור אישי ב-Bitrix שלא יגמגם?

האזור המוגדר כברירת מחדל ב-Bitrix הוא אוסף של רכיבים מפוזרים, שכל אחד מהם פונה למסד הנתונים באופן עצמאי ללא שכבת נתונים משותפת. כתוצאה מכך, דף הפרופיל יכול לבצע 15–20 שאילתות SQL בעת הטעינה. מודול אזור אישי בנוי אחרת: שירות מצרף אחד אוסף את נתוני המשתמש בעת התחברות, שומר אותם במטמון בסשן ומספק אותם לכל הרכיבים ממקור אחד. זה מפחית את מספר השאילתות ל-2–3 — עלייה של פי 5–10 במהירות בהשוואה לגישה הסטנדרטית.

ארכיטקטורה: שכבות האזור

שירות פרופיל (UserProfileService) — מחלקה מרכזית המכילה את כל הלוגיקה של נתוני המשתמש:

class UserProfileService { private int $userId; private array $cache = []; public function getOrders(array $filter = [], int $page = 1): OrderCollection { return \Bitrix\Sale\OrderTable::getList([ 'filter' => array_merge(['=USER_ID' => $this->userId], $filter), 'order' => ['DATE_INSERT' => 'DESC'], 'limit' => 10, 'offset' => ($page - 1) * 10, ]); } public function getLoyaltyBalance(): int { if (!isset($this->cache['loyalty'])) { $this->cache['loyalty'] = LoyaltyTable::getBalanceForUser($this->userId); } return $this->cache['loyalty']; } } 

רכיבי האזור מקבלים את השירות דרך מיכל DI class UserProfileService { private int $userId; private array $cache = []; public function getOrders(array $filter = [], int $page = 1): OrderCollection { return \Bitrix\Sale\OrderTable::getList([ 'filter' => array_merge(['=USER_ID' => $this->userId], $filter), 'order' => ['DATE_INSERT' => 'DESC'], 'limit' => 10, 'offset' => ($page - 1) * 10, ]); } public function getLoyaltyBalance(): int { if (!isset($this->cache['loyalty'])) { $this->cache['loyalty'] = LoyaltyTable::getBalanceForUser($this->userId); } return $this->cache['loyalty']; } } . כל רכיב אחראי על סעיף אחד: הזמנות, כתובות, הגדרות התראות, מסמכים.

ניתוב. לכל סעיף יש כתובת URL משלו (Bitrix\Main\DI\ServiceLocator, /cabinet/orders/, /cabinet/addresses/). מיושם באמצעות handler מותאם אישית ב-/cabinet/documents/ או דרך מודול urlrewrite.php עם רישום כללים באמצעות main.

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

כברירת מחדל, Bitrix שומר כתובת אחת בפרופיל המשתמש. עבור מספר כתובות, יש צורך בטבלה מותאמת אישית:

CREATE TABLE myvendor_user_address ( id SERIAL PRIMARY KEY, user_id INT NOT NULL, label VARCHAR(100), -- "Дом", "Работа" city VARCHAR(100), street VARCHAR(200), building VARCHAR(20), apartment VARCHAR(20), lat DECIMAL(10, 7), lng DECIMAL(10, 7), is_default BOOLEAN DEFAULT false, created_at TIMESTAMP DEFAULT NOW() ); 

השדות UrlRewriter::setRule / CREATE TABLE myvendor_user_address ( id SERIAL PRIMARY KEY, user_id INT NOT NULL, label VARCHAR(100), -- "Дом", "Работа" city VARCHAR(100), street VARCHAR(200), building VARCHAR(20), apartment VARCHAR(20), lat DECIMAL(10, 7), lng DECIMAL(10, 7), is_default BOOLEAN DEFAULT false, created_at TIMESTAMP DEFAULT NOW() ); ממולאים באמצעות Yandex Geocoder בעת שמירת הכתובת. במהלך התשלום, המשתמש בוחר כתובת מהרשימה — הנתונים מוכנסים ל-lat ללא הזנה ידנית.

סעיף מסמכי B2B

משתמשי B2B מבקשים לעתים קרובות חשבוניות, אישורי ביצוע, UPD. המודול מקשר מסמכים (שנוצרו על ידי מודול טופס ההדפסה) לפרופיל המשתמש דרך טבלת lng. באזור — סינון לפי סוג מסמך, תקופה, סטטוס, כפתור הורדת PDF. הרשאות צפייה נבדקות דרך קבוצות משתמשים.

התראות

המשתמש מנהל את מינויי ההתראות: דוא"ל, SMS, push. כל ערוץ הוא רשומה נפרדת ב-b_sale_order_props. בעת שליחת התראה מהלוגיקה העסקית, היישום בודק תחילה את העדפות המשתמש, ולאחר מכן בוחר את ערוץ המשלוח.

למה מודול אזור אישי יעיל יותר מרכיבים סטנדרטיים?

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

אבטחת האזור

• כל פעולות שינוי הנתונים (דוא"ל, סיסמה, כתובת) דורשות אישור באמצעות קוד בדוא"ל/SMS
• הגנת CSRF באמצעות מנגנון Bitrix הסטנדרטי (myvendor_user_document)
• הגבלת קצב על ניסיונות שינוי סיסמה דרך טבלת myvendor_notification_pref
• מיסוך מספר טלפון בתצוגה (הצגת 4 הספרות האחרונות בלבד)

מה כלול בפיתוח מודול במפתח מלא

אנו מספקים חבילה מלאה: תיעוד ארכיטקטורה, קוד מקור של המודול, הוראות התקנה, הדרכה למנהלים שלכם, אחריות לתיקון תקלות ל-30 יום. לאחר המסירה, אנו מספקים שבועיים של תמיכה חינם. צרו קשר כדי להעריך את הפרויקט שלכם — נשלח הערכה משוערת תוך 1–2 ימי עסקים. התקציב נקבע לאחר בדיקת דרישות ולעתים קרובות יוצא נמוך יותר מהתאמה אישית של רכיבים סטנדרטיים על ידי מפתח פנימי.

לוח זמנים לפיתוח

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

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

פיתוח מודול אזור אישי הוא עבודה שיטתית הדורשת ניסיון עם אינפובלוקים, HL-בלוקים ותהליכים עסקיים. הפקידו אותו בידי צוות עם הסמכות 1C-Bitrix.