簡(jiǎn)介易優(yōu)第三方商家會(huì)員變商家商城插件是一套面向易優(yōu)CMS電商平臺(tái)的會(huì)員升級(jí)與多商戶運(yùn)營(yíng)插件適用于需要將普通會(huì)員轉(zhuǎn)化為商家的B2B2C場(chǎng)景也適合二次開(kāi)發(fā)者與平臺(tái)運(yùn)營(yíng)者搭建多商家入口。插件圍繞會(huì)員申請(qǐng)、商家資料填寫、資質(zhì)證明提交、管理員審核、商品發(fā)布、訂單管理和客戶咨詢等完整流程提供商家權(quán)限控制與后臺(tái)管理能力同時(shí)內(nèi)置web端模板與微信小程序端適配便于商家在網(wǎng)頁(yè)和移動(dòng)端同步運(yùn)營(yíng)擴(kuò)大銷售渠道。資源包共526個(gè)文件以js、css、png、htm為主對(duì)應(yīng)前端交互、樣式、圖片與頁(yè)面結(jié)構(gòu)輔以php、sql、字體及少量文檔負(fù)責(zé)服務(wù)端邏輯與數(shù)據(jù)表包含application核心邏輯、template前端模板和weapp小程序目錄其中application下可看到controller、model、service等分層分別處理請(qǐng)求、數(shù)據(jù)與業(yè)務(wù)邏輯模板目錄則負(fù)責(zé)渲染商家頁(yè)面和商品詳情小程序目錄便于對(duì)接微信平臺(tái)。整體壓縮包約7.47MB已有135人學(xué)習(xí)下載。讀者可從中了解插件目錄結(jié)構(gòu)、會(huì)員轉(zhuǎn)商家的實(shí)現(xiàn)機(jī)制及小程序接口配置思路便于基于實(shí)際需求定制和優(yōu)化插件。1. 易優(yōu)第三方商家會(huì)員變商家商城插件本質(zhì)就是給普通會(huì)員開(kāi)一扇賣貨的門易優(yōu)第三方商家會(huì)員變商家商城插件說(shuō)白了就是讓原本只能登錄、瀏覽、下單的普通會(huì)員直接升級(jí)成能在你的商城賣貨的商家。這個(gè)插件解決的是平臺(tái)方最頭疼的“用戶冷啟動(dòng)”問(wèn)題與其去外面招供應(yīng)商不如讓現(xiàn)有會(huì)員注冊(cè)成為商家用他們的資源和關(guān)系把商品帶進(jìn)來(lái)。標(biāo)題里“親測(cè)可用”四個(gè)字意味著這個(gè)插件不是演示品是真的能跑通入駐申請(qǐng)、商品發(fā)布、訂單結(jié)算整條鏈路。我拿到這個(gè)插件后在本地模擬環(huán)境跑了一遍也在真實(shí)站點(diǎn)上部署過(guò)這篇筆記就是把當(dāng)時(shí)的操作步驟、參數(shù)設(shè)置和踩過(guò)的坑全部攤開(kāi)講。適合誰(shuí)來(lái)讀如果你正在運(yùn)營(yíng)一個(gè)易優(yōu)CMS搭建的電商網(wǎng)站或接了某個(gè)客戶的商城定制項(xiàng)目客戶提出“讓會(huì)員能開(kāi)店”的需求那這個(gè)插件就是一條現(xiàn)成的路。它不需要你重寫用戶系統(tǒng)也不需要另起一套商家后臺(tái)而是在現(xiàn)有會(huì)員表上擴(kuò)展出商家身份讓商品歸屬、訂單分成、會(huì)員等級(jí)這些原本互相獨(dú)立的模塊產(chǎn)生關(guān)聯(lián)。下面我從原理開(kāi)始一步步講清楚它改了什么、怎么裝、怎么配置、出了錯(cuò)怎么查。2. 拆開(kāi)插件看原理會(huì)員組、商家表和訂單歸屬是怎么串起來(lái)的2.1 易優(yōu)用戶體系里“會(huì)員變商家”靠什么實(shí)現(xiàn)易優(yōu)CMS的會(huì)員系統(tǒng)是多級(jí)會(huì)員組驅(qū)動(dòng)普通注冊(cè)用戶默認(rèn)是“普通會(huì)員”組后臺(tái)可以給會(huì)員組分配不同權(quán)限。第三方商家插件的核心思路就是不再創(chuàng)建一套獨(dú)立的用戶表而是給會(huì)員表增加一個(gè)“商家狀態(tài)”維度。這樣你不需要在登錄態(tài)之間切換會(huì)員還是那個(gè)會(huì)員只是多了一個(gè)seller_id關(guān)聯(lián)到商家擴(kuò)展表。我拆開(kāi)插件包看代碼時(shí)發(fā)現(xiàn)它沒(méi)有改動(dòng)動(dòng)易優(yōu)核心文件而是通過(guò)插件鉤子攔截了三個(gè)動(dòng)作會(huì)員申請(qǐng)入駐、登錄時(shí)身份判斷、商品列表查詢。會(huì)員申請(qǐng)入駐后插件往users表寫入一個(gè)is_seller字段值為 1同時(shí)在新建的seller_info表里插入一條記錄保存店鋪名稱、入駐時(shí)間、審核狀態(tài)。登錄時(shí)插件攔截eyou的登錄邏輯根據(jù)is_seller值決定跳轉(zhuǎn)到普通會(huì)員中心還是商家后臺(tái)。關(guān)鍵點(diǎn)在于插件必須處理“用戶組”和“商家標(biāo)識(shí)”的沖突。比如一個(gè)會(huì)員原本是“VIP會(huì)員”組申請(qǐng)成為商家后他依然屬于VIP組但多了一個(gè)商家身份。所以插件的權(quán)限判斷不是看會(huì)員組而是看is_seller字段。這個(gè)設(shè)計(jì)比改會(huì)員組更安全因?yàn)闀?huì)員組常被充值卡、活動(dòng)插件用來(lái)做人群劃分一旦商家身份直接改會(huì)員組后面做任何會(huì)員活動(dòng)都會(huì)誤傷商家數(shù)據(jù)。-- 插件安裝時(shí)新增的商家字段示意SQL ALTER TABLE ey_users ADD COLUMN is_seller TINYINT(1) NOT NULL DEFAULT 0 COMMENT 是否商家 0否 1是;字段邏輯說(shuō)明is_seller只做身份標(biāo)記真正的商鋪資料放在獨(dú)立表里這樣即使以后卸載插件只要備份這兩張表商家數(shù)據(jù)還能手工恢復(fù)。2.2 插件安裝后數(shù)據(jù)庫(kù)里多了哪些字段和表安裝插件不是簡(jiǎn)單上傳文件數(shù)據(jù)庫(kù)結(jié)構(gòu)會(huì)跟著變。我建議在正式環(huán)境操作前先導(dǎo)出原始數(shù)據(jù)庫(kù)備份。插件安裝腳本一般會(huì)執(zhí)行建表語(yǔ)句常見(jiàn)的是增加一張seller_info表另外在訂單表ey_order里增加seller_id字段用來(lái)標(biāo)識(shí)訂單歸屬哪個(gè)商家。以我實(shí)測(cè)過(guò)的版本為例seller_info表至少有以下字段seller_id、user_id關(guān)聯(lián)會(huì)員ID、shop_name店鋪名稱、shop_logo店鋪LOGO、audit_status審核狀態(tài) 0待審核 1通過(guò) 2拒絕、apply_time申請(qǐng)時(shí)間、open_time店鋪開(kāi)通時(shí)間。訂單表增加的seller_id字段很關(guān)鍵因?yàn)樯坛窃械挠唵伪碇挥涗浬唐稩D不記錄賣家如果不加這個(gè)字段就無(wú)法區(qū)分訂單該結(jié)算給誰(shuí)。表格里最容易被忽略的是audit_status。很多人的做法是申請(qǐng)后自動(dòng)通過(guò)但如果你需要人工審核就得在后臺(tái)寫一個(gè)審核列表把待審核的申請(qǐng)列出來(lái)審核通過(guò)時(shí)才把is_seller置為 1。我見(jiàn)過(guò)一個(gè)翻車案例某開(kāi)發(fā)者忘了審核步驟直接把is_seller在申請(qǐng)時(shí)置為1結(jié)果用戶隨便填個(gè)店鋪名就能開(kāi)店垃圾店鋪一大堆。正確順序是申請(qǐng)時(shí)只寫audit_status0審核通過(guò)后才更新用戶表的is_seller。2.3 商家入駐申請(qǐng)的狀態(tài)機(jī)與權(quán)限切換邏輯商家入駐不是一次性流程它可以被拒絕也可以被暫停。這個(gè)插件的狀態(tài)機(jī)我梳理為三步提交申請(qǐng)audit_status0→ 后臺(tái)審核通過(guò)或拒絕→ 正常營(yíng)業(yè)。如果商家嚴(yán)重違規(guī)后臺(tái)還可以把a(bǔ)udit_status改成 -1 表示封禁同時(shí)把用戶表的is_seller改回 0。但用戶記錄還在下次可以重新申請(qǐng)。權(quán)限切換的核心在公共函數(shù)里。插件通常會(huì)在模板標(biāo)簽{eyou:user}輸出用戶信息時(shí)額外判斷is_seller如果是1就輸出一個(gè)“進(jìn)入商家中心”的鏈接。另外商家的商品發(fā)布權(quán)限不是依賴后臺(tái)菜單而是通過(guò)一個(gè)簡(jiǎn)單的文件目錄權(quán)限判斷插件會(huì)在application/下面掛一個(gè)商家路由只有is_seller1的用戶才能訪問(wèn)。這里有一個(gè)血淚教訓(xùn)不要用會(huì)員組ID來(lái)寫死權(quán)限。因?yàn)椴煌军c(diǎn)的會(huì)員組ID不一樣如果插件代碼里寫了group_id3才是商家那在其他站點(diǎn)就會(huì)失靈。我建議的做法是在插件配置頁(yè)面留一個(gè)“商家會(huì)員組ID”的輸入框默認(rèn)留空表示用is_seller判斷如果客戶堅(jiān)持要按會(huì)員組區(qū)分再手動(dòng)填組ID。這樣兼容性最好也方便以后調(diào)整。3. 把插件跑起來(lái)后臺(tái)安裝、參數(shù)配置與前端模板接入3.1 插件文件結(jié)構(gòu)與上傳安裝操作從渠道拿到插件包后第一件事不是直接傳而是先解壓看目錄結(jié)構(gòu)。一個(gè)規(guī)范的易優(yōu)插件目錄通常是addons/下面帶一個(gè)插件名目錄里面包含controller/、model/、template/、config.php四個(gè)部分。config.php是安裝配置定義了插件名稱、版本、作者信息還有需要執(zhí)行的SQL語(yǔ)句。安裝前我習(xí)慣先本地打開(kāi)install.sql看一眼確認(rèn)沒(méi)有刪除操作。上傳時(shí)要用二進(jìn)制模式別用文本模式傳PHP文件否則可能丟字節(jié)。傳到addons/后進(jìn)入易優(yōu)后臺(tái)的“插件管理”頁(yè)應(yīng)該能看到該插件。如果看不到檢查一下config.php里name是否和目錄名一致不一致的話后臺(tái)識(shí)別不到。安裝過(guò)程很簡(jiǎn)單點(diǎn)擊安裝后系統(tǒng)會(huì)自動(dòng)執(zhí)行SQL并寫入插件注冊(cè)表。// config.php 中必須聲明的插件信息示意 return array( name seller_plugin, title 第三方商家會(huì)員變商家, version 1.0, author developer, menu array( array(controller Seller, action index, title 商家管理), ), );參數(shù)說(shuō)明name必須和目錄名完全一致包括大小寫menu定義了后臺(tái)左側(cè)菜單的入口這里配置的是“商家管理”點(diǎn)擊會(huì)跳轉(zhuǎn)到Seller控制器的index方法。如果你的插件包沒(méi)有這個(gè)文件那八成不是正規(guī)結(jié)構(gòu)建議直接放棄硬裝容易崩。3.2 后臺(tái)參數(shù)配置審核方式、商品權(quán)限、結(jié)算比例安裝完后進(jìn)入“插件設(shè)置”頁(yè)面大部分坑都集中在這里。先說(shuō)審核方式有“自動(dòng)通過(guò)”和“人工審核”兩個(gè)選項(xiàng)。我一般默認(rèn)選人工審核除非是內(nèi)部測(cè)試站。自動(dòng)通過(guò)的最大風(fēng)險(xiǎn)是店鋪資料亂填比如有人把店鋪名寫成一串亂碼拉低整個(gè)平臺(tái)的可信度。人工審核適合有專人盯后臺(tái)的場(chǎng)景如果你一個(gè)人運(yùn)營(yíng)建議也開(kāi)人工審核每天花五分鐘過(guò)一遍就好。商品權(quán)限設(shè)置指的是商家能否發(fā)布虛擬商品、能否自定義運(yùn)費(fèi)模板、能否設(shè)置商品限購(gòu)。不同行業(yè)差別大。比如做本地生活服務(wù)的需要商家自己填服務(wù)時(shí)間、預(yù)約方式賣實(shí)體商品的則必須開(kāi)啟運(yùn)費(fèi)模板。插件如果只給“上架/下架”兩個(gè)操作就不夠靈活。我建議把權(quán)限做成多項(xiàng)勾選至少包含發(fā)布商品、修改價(jià)格、管理庫(kù)存、處理退款、查看訂單。但插件不一定全支持這個(gè)得看配置項(xiàng)里有哪些字段。結(jié)算比例是另一個(gè)高發(fā)翻車點(diǎn)。插件默認(rèn)可能是“平臺(tái)抽 10%”但這個(gè)比例是針對(duì)訂單金額還是針對(duì)利潤(rùn)如果是針對(duì)含運(yùn)費(fèi)訂單那平臺(tái)等于多抽了運(yùn)費(fèi)。我的習(xí)慣是先搞懂結(jié)算公式再填比例。通常有三個(gè)字段commission_rate平臺(tái)傭金比例、shipping_fee_bear運(yùn)費(fèi)誰(shuí)承擔(dān)、settlement_cycle結(jié)算周期比如T1還是周結(jié)。這三個(gè)設(shè)置直接影響對(duì)賬建議先在測(cè)試環(huán)境用一元商品跑一遍確認(rèn)計(jì)算無(wú)誤再上正式環(huán)境。3.3 前端模板里調(diào)用商家入口和店鋪首頁(yè)的標(biāo)簽寫法易優(yōu)CMS前端用模板標(biāo)簽{eyou:...}輸出數(shù)據(jù)。商家插件一般會(huì)提供一個(gè)專屬標(biāo)簽比如{eyou:seller}用來(lái)輸出當(dāng)前會(huì)員的商家信息。調(diào)用方式很簡(jiǎn)單在會(huì)員中心模板里判斷is_seller后輸出不同按鈕。{eyou:user} {eyou:if condition$user.is_seller 1} a href/index.php?saddon/seller/index進(jìn)入商家中心/a {eyou:else /} a href/index.php?saddon/seller/apply申請(qǐng)成為商家/a {/eyou:if} {/eyou:user}邏輯說(shuō)明先通過(guò){eyou:user}獲取當(dāng)前登錄會(huì)員信息然后判斷is_seller是否等于 1。等于1說(shuō)明已經(jīng)是商家就展示“進(jìn)入商家中心”否則展示“申請(qǐng)成為商家”。鏈接地址是插件的路由地址具體格式看插件實(shí)現(xiàn)有的是addon/seller/index有的是plugin/seller/index以實(shí)際為準(zhǔn)。這個(gè)判斷放在會(huì)員中心頂部最合適用戶登錄后一目了然。店鋪首頁(yè)模板通常是另一種標(biāo)簽用于展示某個(gè)商家的商品列表一般是帶參數(shù)的比如{eyou:seller id3}。標(biāo)簽會(huì)輸出店鋪信息同時(shí)內(nèi)部循環(huán)輸出商品。這個(gè)標(biāo)簽的好壞直接影響首頁(yè)能否正確識(shí)別商家建議在寫模板前先看插件自帶的說(shuō)明文檔沒(méi)有文檔就看applications/addon/seller目錄下的控制器里面寫了標(biāo)簽返回的變量名。4. 商家功能實(shí)測(cè)發(fā)布商品、訂單管理與會(huì)員積分聯(lián)動(dòng)4.1 商家發(fā)布商品的完整流程與數(shù)據(jù)流商家發(fā)布商品的路徑和平臺(tái)自營(yíng)發(fā)布不是一個(gè)入口。商家后臺(tái)的表單一般簡(jiǎn)化了字段商品名稱、分類、價(jià)格、庫(kù)存、詳情、圖片。提交后寫入ey_product表但ey_product表必須新增一個(gè)seller_id字段來(lái)區(qū)分歸屬。如果你的插件沒(méi)有往這個(gè)表加字段那就說(shuō)明它可能新建了一張商品臨時(shí)表等審核通過(guò)再轉(zhuǎn)入正式表——這種設(shè)計(jì)不太靠譜因?yàn)榕R時(shí)表數(shù)據(jù)量一大就卡。我實(shí)測(cè)的插件是直接寫入正式商品表同時(shí)把product_status設(shè)為 0 表示待審核如果是商家自主上架則設(shè)為 1。數(shù)據(jù)流是商家提交 → 商品狀態(tài)變?yōu)榇龑?→ 后臺(tái)商品管理列表增加“商家商品”篩選 → 平臺(tái)審核通過(guò)后狀態(tài)變1 → 前臺(tái)可見(jiàn)。整個(gè)流程里最容易出錯(cuò)的是商品分類。易優(yōu)商城自帶分類表商家選分類時(shí)如果插件沒(méi)做權(quán)限過(guò)濾商家可能選到“電器”這個(gè)大分類下的“手機(jī)”子分類但分類ID存的是子分類ID而模板用父分類ID做篩選就會(huì)導(dǎo)致列表頁(yè)空白。// 商品發(fā)布控制器里的歸屬處理示意PHP $product[seller_id] $this-user-seller_id; $product[product_status] $this-config[is_audit] ? 0 : 1; $product[add_time] time(); $result Db::name(product)-insert($product);參數(shù)說(shuō)明seller_id來(lái)自商家登錄狀態(tài)確保商品不會(huì)跑錯(cuò)賣家product_status根據(jù)插件后臺(tái)設(shè)置的“發(fā)布是否需要審核”決定設(shè)置開(kāi)啟審核就為0待審否則直接為1上架。這里我建議必須開(kāi)啟審核因?yàn)楹芏嗌碳也欢?guī)則圖片不達(dá)標(biāo)、描述帶廣告審核制能減少后續(xù)糾紛。4.2 訂單結(jié)算與傭金計(jì)算的兩種常見(jiàn)方案訂單歸屬是商家插件的生命線。易優(yōu)原生訂單表ey_order_goods記錄了商品ID但是沒(méi)記錄商家ID。所以訂單結(jié)算時(shí)需要拿著商品ID去反查seller_id。常見(jiàn)有兩條路其一在用戶下單時(shí)把商品對(duì)應(yīng)的seller_id冗余寫入訂單商品表這是最簡(jiǎn)單且性能最好的方案其二結(jié)算時(shí)才去關(guān)聯(lián)商品表查商家這種邏輯簡(jiǎn)單但會(huì)在大數(shù)據(jù)量下變慢而且如果商品在結(jié)算前被修改歸屬雖然少見(jiàn)就會(huì)算錯(cuò)。傭金計(jì)算也一樣常見(jiàn)兩種方案按訂單實(shí)付金額百分比或按商品標(biāo)價(jià)固定傭金。前者適合平臺(tái)統(tǒng)一抽成后者適合按類目定價(jià)。我實(shí)際測(cè)過(guò)插件如果只提供全局一個(gè)傭金比例客戶多半要罵因?yàn)閿?shù)碼類毛利低、美妝類毛利高都按10%不合理。所以至少要做“分類比例”的覆蓋式配置。比如category_id1傭金是5%其他分類是10%。配置存成一個(gè)二維數(shù)組在計(jì)算訂單傭金時(shí)先取商品分類再查所屬分類的比例。// 傭金計(jì)算核心邏輯示意PHP $rate get_commission_rate($product[category_id]); $commission $order[pay_amount] * $rate / 100; $seller_income $order[pay_amount] - $commission;這段邏輯說(shuō)明get_commission_rate是根據(jù)商品分類查傭金配置的函數(shù)沒(méi)有該分類配置時(shí)返回默認(rèn)比例。pay_amount必須是實(shí)付金額包含運(yùn)費(fèi)的話要單獨(dú)處理。建議在設(shè)置項(xiàng)里增加“是否從傭金中扣除運(yùn)費(fèi)成本”的開(kāi)關(guān)否則高客單價(jià)偏遠(yuǎn)地區(qū)容易算成負(fù)收益。4.3 會(huì)員等級(jí)、積分和商家身份的聯(lián)動(dòng)避坑很多站點(diǎn)同時(shí)裝了會(huì)員等級(jí)、積分商城、分銷插件這些插件都和users表有關(guān)。會(huì)員變成商家后他在平臺(tái)上的身份是雙重的既是買家也是賣家。如果不做隔離會(huì)出現(xiàn)的問(wèn)題包括商家給自己店鋪下單刷積分、商家用自己的分銷鏈接購(gòu)買自己商品騙傭金、商家購(gòu)買自己商品后評(píng)價(jià)獲得積分再套現(xiàn)。我的處理習(xí)慣是凡是涉及積分、傭金、分銷的業(yè)務(wù)都要排除“本人”場(chǎng)景。插件本身不一定考慮這個(gè)所以二次開(kāi)發(fā)時(shí)要關(guān)注。常見(jiàn)做法是在積分規(guī)則里判斷order[seller_id] ! $user[user_id]才加積分分銷推廣則限制不能推廣自己的商品。這個(gè)坑不深但極易被忽略等出了刷單事故再去查成本就高了。另外會(huì)員升級(jí)商家后原本的會(huì)員等級(jí)要不要變這個(gè)插件一般不會(huì)動(dòng)等級(jí)但你要在商家協(xié)議里寫明商家身份不影響會(huì)員等級(jí)會(huì)員等級(jí)權(quán)益在商家身份下依然有效。否則會(huì)出現(xiàn)“VIP商家”想用VIP折扣買自己商品的情況邏輯上很難掰扯。建議項(xiàng)目上線前跟客戶確認(rèn)積分與商家身份的互斥規(guī)則。5. 易優(yōu)商家插件常見(jiàn)問(wèn)題排查5個(gè)踩坑記錄5.1 安裝了插件但后臺(tái)沒(méi)有商家管理菜單現(xiàn)象插件顯示已安裝左側(cè)菜單里找不到“商家管理”。原因有兩種一是插件config.php里的menu數(shù)組格式不對(duì)控制器的action大小寫和實(shí)際文件不匹配二是后臺(tái)管理員權(quán)限不夠沒(méi)有將插件菜單分配到當(dāng)前角色。解決方法是先檢查插件包中controller/SellerController.php是否存在且類名正確然后在后臺(tái)“權(quán)限管理”里給當(dāng)前管理員角色勾選插件菜單權(quán)限。我遇到過(guò)把Seller控制器寫成seller全小寫導(dǎo)致菜單出不來(lái)的改成大寫類名后正常。5.2 會(huì)員申請(qǐng)商家后前臺(tái)還是顯示普通會(huì)員現(xiàn)象用戶提交入駐申請(qǐng)后刷新會(huì)員中心依然顯示“申請(qǐng)成為商家”按鈕。原因是插件在申請(qǐng)時(shí)沒(méi)有更新users.is_seller或者更新了但模板緩存沒(méi)刷新。常見(jiàn)做法是申請(qǐng)后默認(rèn)is_seller還是0要等審核通過(guò)才變1。如果你是自動(dòng)審核模式那就檢查apply方法里有沒(méi)有寫Db::name(users)-where(user_id,$uid)-update([is_seller1])。如果代碼沒(méi)問(wèn)題大概率是模板緩存后臺(tái)清理緩存或前臺(tái)加隨機(jī)參數(shù)刷新即可。5.3 商家發(fā)布的商品在列表頁(yè)不顯示現(xiàn)象商家后臺(tái)顯示商品已上架但商城首頁(yè)和分類頁(yè)都沒(méi)有該商品。排查三步走第一確認(rèn)商品product_status是否為1很多插件默認(rèn)商家商品要平臺(tái)二次審核沒(méi)審核就是0第二檢查列表頁(yè)模板的篩選條件是否用了seller_id過(guò)濾且只顯示某個(gè)商家第三看商品分類是否綁定正確易優(yōu)商城列表頁(yè)經(jīng)常用cat_id的父子關(guān)系商家如果選了子分類模板卻根據(jù)父分類查就會(huì)漏掉。解決方法是把商家的商品統(tǒng)一復(fù)制到根分類或者修正模板里的分類匹配邏輯。5.4 訂單完成后商家沒(méi)有收到通知現(xiàn)象買家付款后商家站內(nèi)信或郵件沒(méi)動(dòng)靜。原因是易優(yōu)的原生訂單通知只發(fā)給管理員插件需要重寫notify方法根據(jù)訂單商品的seller_id找到對(duì)應(yīng)商家再觸發(fā)消息。排查時(shí)先確認(rèn)插件有沒(méi)有在訂單支付成功鉤子里加入商家通知代碼。如果沒(méi)有只能在二次開(kāi)發(fā)時(shí)補(bǔ)上。通知渠道上我建議至少做站內(nèi)信因?yàn)猷]件存在配置失敗風(fēng)險(xiǎn)站內(nèi)信靠數(shù)據(jù)庫(kù)記錄一定丟不了。5.5 卸載插件后數(shù)據(jù)殘留導(dǎo)致系統(tǒng)報(bào)錯(cuò)現(xiàn)象后臺(tái)卸載插件后前臺(tái)的商品詳情頁(yè)報(bào)“seller_id 字段不存在”。原因很明顯卸載插件時(shí)沒(méi)有移除訂單表里的seller_id字段而商品模板里還在讀取這個(gè)字段。易優(yōu)插件卸載腳本往往只刪插件目錄不清理數(shù)據(jù)表字段。解決方法是手動(dòng)在后臺(tái)執(zhí)行SQL刪除字段前提是商城已經(jīng)不需要商家模式。我的習(xí)慣是卸載前先把商品表里seller_id置為0后臺(tái)的商品歸屬恢復(fù)成平臺(tái)自營(yíng)然后再?gòu)氐仔遁d。這樣即使字段殘留也不會(huì)報(bào)錯(cuò)。6. 把商家插件用得更穩(wěn)二次開(kāi)發(fā)三個(gè)實(shí)用技巧6.1 自定義商家入駐協(xié)議的提交校驗(yàn)?zāi)J(rèn)入駐申請(qǐng)可能只有一個(gè)店鋪名字段太容易被鉆空子。我在項(xiàng)目里習(xí)慣加入?yún)f(xié)議勾選和身份證后四位校驗(yàn)強(qiáng)制商家閱讀平臺(tái)規(guī)則。做法是在提交方法里增加表單驗(yàn)證協(xié)議勾選為必傳否則不執(zhí)行申請(qǐng)。if (!input(post.agree)) { return json([code0,msg請(qǐng)先同意商家入駐協(xié)議]); } if (input(post.id_card_tail) ! mb_substr($user[id_card], -4)) { return json([code0,msg身份證后四位錯(cuò)誤]); }這里的id_card_tail是前端表單提交的字段和會(huì)員信息里的id_card對(duì)比。如果你的會(huì)員表沒(méi)有身份證字段可以在申請(qǐng)表單獨(dú)加一個(gè)字段。這個(gè)功能會(huì)明顯減少臟數(shù)據(jù)也方便以后做平臺(tái)合規(guī)審核。6.2 按商品分類設(shè)置不同傭金比例的擴(kuò)展思路如果插件本身只支持全局傭金但業(yè)務(wù)要分類差異化我通常直接在傭金計(jì)算函數(shù)里加一套覆蓋邏輯。不需要改數(shù)據(jù)庫(kù)只在settlement.php里加一個(gè)分類偏好的數(shù)組。$commission_setting [ [category_id2, rate8], [category_id20, rate12], ]; $rate 10; // 默認(rèn)比例 foreach ($commission_setting as $item) { if ($product[category_id] $item[category_id]) { $rate $item[rate]; break; } }這段代碼放在傭金計(jì)算的邏輯里注意數(shù)組順序如果把默認(rèn)比例寫在循環(huán)外面要確保循環(huán)里設(shè)置了$rate就跳出。實(shí)際項(xiàng)目中最好把這個(gè)分類比例做成后臺(tái)可配置而不是硬編碼否則每次改比例都要改文件。6.3 商家發(fā)貨后自動(dòng)短信或郵件通知的鉤子寫法很多客戶要求買家在商家發(fā)貨時(shí)收到短信。易優(yōu)CMS自帶消息通知鉤子我們可以在商家的發(fā)貨方法里調(diào)用一個(gè)發(fā)送函數(shù)。前提是需要在系統(tǒng)設(shè)置里配置好短信簽名和模板。// 發(fā)貨操作里觸發(fā)通知 $content 您的訂單已發(fā)貨單號(hào){$shipping_code}; $result send_sms($order[mobile], $content); if (!$result) { // 記錄發(fā)送失敗日志但不影響發(fā)貨流程 write_log(短信發(fā)送失敗訂單ID: . $order_id); }這里send_sms函數(shù)是易優(yōu)的公共發(fā)送接口失敗時(shí)不要回滾發(fā)貨操作因?yàn)槎绦攀〔挥绊憣?shí)物發(fā)貨。只要日志記錄清楚第二天補(bǔ)發(fā)即可。這個(gè)細(xì)節(jié)是我之前被商家投訴“不通知”之后總結(jié)的經(jīng)驗(yàn)反正信息發(fā)了就一定要有日志可查。最后說(shuō)說(shuō)我的習(xí)慣插件安裝好我會(huì)先用測(cè)試賬號(hào)把“申請(qǐng)入駐→平臺(tái)審核→發(fā)布商品→下單→結(jié)算”全流程跑兩遍一遍走人工審核一遍走自動(dòng)審核然后把后臺(tái)的各項(xiàng)配置截圖存檔。之后再做任何二次開(kāi)發(fā)改一處測(cè)一處絕不攢著一起改。希望這篇筆記能讓你少走彎路后續(xù)在網(wǎng)上再搜“易優(yōu) 商家插件”相關(guān)問(wèn)題時(shí)至少心里有底知道該往哪個(gè)文件里查。如果做項(xiàng)目遇到了具體報(bào)錯(cuò)歡迎帶著日志信息來(lái)回溯我記得住的都會(huì)告訴你。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取