Khi chọn Zen Cart làm Nền tảng đích, dữ liệu không chỉ được chuyển sang một cơ sở dữ liệu Self-hosted mới mà còn phải được đặt vào đúng các mối quan hệ mà Zen Cart dùng để diễn giải dữ liệu. Định danh Products, vị trí trong Categories, option names, option values, attributes đã gán, các lớp tính giá, modules tổng tiền của Orders, vị trí nội dung, plugins và cấu hình đều có thể thay đổi ý nghĩa của một bản ghi. Một bản ghi Products hoặc Orders có thể trông đầy đủ trong cơ sở dữ liệu nhưng vẫn mất quan hệ cần thiết để khách hàng mua được hoặc để nhân viên hiểu đúng giao dịch.
Điểm cần phân biệt là bản ghi đã được di chuyển và cấu trúc giúp Zen Cart hiểu bản ghi đó. Một lựa chọn của Products có thể cần option name, option value, quan hệ gán attribute vào Products, điều chỉnh giá hoặc trọng lượng, cờ bắt buộc lựa chọn và cách lựa chọn đó được ghi lại trong chi tiết Orders. Một bản ghi Products xuất hiện trong nhiều collections ở Cửa hàng nguồn có thể phù hợp hơn với một bản ghi Products duy nhất được liên kết tới nhiều Categories trên Zen Cart, thay vì tạo nhiều Products trùng nhau. Một CMS Page có thể cần trở thành EZ-Page, define page, mô tả Categories, mô tả Products hoặc một vị trí nội dung khác tùy mục đích.
Ý nghĩa dữ liệu trong Zen Cart phụ thuộc chặt vào cấu hình và quan hệ
Zen Cart cho phép doanh nghiệp trực tiếp quản lý catalog, giá, modules, templates và phần mở rộng cơ sở dữ liệu. Vì vậy, dữ liệu có nhiều quan hệ phụ thuộc. Products liên kết với Categories, loại Products, attributes, hình ảnh, manufacturers, tax classes, Specials, quantity discounts, download, metadata và cấu hình. Orders liên kết với attributes khách hàng đã chọn, địa chỉ, các dòng tổng tiền, Coupons, gift certificates, lịch sử trạng thái, nhãn thanh toán/vận chuyển, comments và mã tham chiếu bên ngoài.
| Nhóm dữ liệu nguồn | Cách Zen Cart diễn giải | Quyết định về quan hệ trên đích |
|---|---|---|
| Products | Bản ghi bán hàng liên kết với vị trí trong Categories, trạng thái, model, giá, số lượng, Tax, hình ảnh, loại Products và attributes | Xác định giá trị nào thuộc Products và giá trị nào thuộc attributes, giá, nội dung hoặc plugins |
| Vị trí trong Categories | Cấu trúc phân cấp kết hợp với liên kết Products-Categories | Giữ một định danh Products duy nhất trong khi biểu diễn đầy đủ các vị trí duyệt catalog có chủ đích |
| Options và attributes | Option names, option values, attributes được gán cho Products, cờ lựa chọn, ảnh hưởng đến giá/trọng lượng và có thể cả download | Khôi phục toàn bộ quan hệ lựa chọn thay vì chỉ sao chép nhãn |
| Customers | Tài khoản, sổ địa chỉ, trạng thái newsletter, ngữ cảnh nhóm và quan hệ với Orders | Tách danh tính tài khoản hiện tại khỏi bản chụp giao dịch lịch sử |
| Orders | Chi tiết Products đã mua, attributes đã chọn, tổng tiền, trạng thái, địa chỉ, comments và mã tham chiếu | Giữ lịch sử giao dịch dễ hiểu mà không ngụ ý modules đang hoạt động đã được cấu hình |
| Nội dung | EZ-Pages, define pages, mô tả Products/Categories, links, banners và metadata | Đặt nội dung vào vị trí Zen Cart có cùng vai trò điều hướng và sử dụng |
| Dữ liệu plugin/tùy chỉnh | Trường riêng, bảng riêng, thay đổi quản trị, templates, tích hợp và phép tính đã sửa | Chỉ giữ dữ liệu khi xác định được bản ghi cha và thành phần trên đích tiếp tục sử dụng dữ liệu đó |
Một mô hình đích tốt phải làm rõ các quan hệ này trước khi dữ liệu được di chuyển. Cấu hình, modules, templates và plugins không phải các loại bản ghi thông thường, nhưng dữ liệu do những thành phần đó sở hữu cũng không thể bị bỏ qua nếu còn giá trị vận hành.
Products được liên kết tới nhiều Categories vẫn cần giữ một định danh thống nhất
Một bản ghi Products trong Zen Cart có thể được liên kết tới một hoặc nhiều Categories. Cơ chế linked Products cho phép cùng một định danh Products xuất hiện tại nhiều vị trí Categories mà không cần tạo các bản ghi Products trùng nhau. Điều này đặc biệt quan trọng khi Nền tảng nguồn dùng collections, departments, nhóm theo brand, nhiều đường điều hướng hoặc các nhóm merchandising tự động.
| Cấu trúc ở Nền tảng nguồn | Câu hỏi khi biểu diễn trên Zen Cart | Kết quả cần giữ |
|---|---|---|
| Nhóm phân cấp lâu dài | Có nên trở thành cây Categories không? | Khách hàng và nhân viên quản trị vẫn hiểu được vị trí Products |
| Một bản ghi Products xuất hiện ở nhiều đường duyệt | Có nên dùng một bản ghi Products liên kết tới nhiều Categories không? | Giá, tồn kho, attributes và định danh Products vẫn được quản lý tập trung |
| Collection theo brand/vendor | Nên là Categories, quan hệ với manufacturer, tiêu chí tìm kiếm hay trang nội dung? | Cấu trúc đích phục vụ cách duyệt và quản trị thực tế thay vì sao chép tên gọi nguồn |
| Collection theo mùa/chiến dịch | Đây là cấu trúc lâu dài hay merchandising tạm thời? | Tránh biến chiến dịch ngắn hạn thành Categories cố định gây rối catalog |
| Bản ghi cha có variants con | Variants nên thành attributes, Products độc lập hay cấu trúc khác? | Định danh, giá, tồn kho và ý nghĩa trong Orders vẫn rõ ràng |
| Products số | Cần loại Products, download, attribute và quan hệ quyền truy cập nào? | File vẫn gắn đúng Products đã mua và trạng thái Orders tương ứng |
Tạo nhiều Products để giữ nhiều vị trí nguồn có thể làm tách tồn kho, giá, Reviews và công việc quản trị. Linked Products giữ được một định danh trung tâm, nhưng chỉ phù hợp khi các nhóm nguồn thực sự là nhiều vị trí duyệt của cùng một mặt hàng thương mại, không phải các mặt hàng độc lập.
Loại Products cũng quan trọng. Products vật lý, tài liệu, âm nhạc, donation hoặc Products dạng download có thể sử dụng trường và cách hiển thị storefront khác nhau. Nền tảng đích không nên ép tất cả dữ liệu nguồn vào một biểu diễn Products chung nếu cách bán thực tế của chúng khác nhau.
Option names, option values và attributes tạo thành một mô hình lựa chọn ba phần
Lựa chọn Products trong Zen Cart được tạo từ ba cấu trúc liên quan: option name, một hoặc nhiều option values, và attributes dùng để gán cặp option-name/value cho một bản ghi Products cụ thể. Attribute đã gán có thể chứa thông tin như kiểu hiển thị, lựa chọn mặc định/bắt buộc, điều chỉnh giá, điều chỉnh trọng lượng, thứ tự, quan hệ với file download và các thiết lập riêng của Products.
| Lớp quan hệ | Ý nghĩa | Rủi ro khi chuyển đổi |
|---|---|---|
| Option name | Chiều lựa chọn, ví dụ Color hoặc Size | Tạo các chiều lựa chọn trùng hoặc không nhất quán giữa Products |
| Option value | Giá trị có thể tái sử dụng như Red hoặc Large | Gộp nhầm giá trị khác nhau hoặc tạo nhiều giá trị tương đương |
| Gán attribute cho Products | Cặp option name/value áp dụng cho Products cụ thể | Mất thông tin lựa chọn nào thuộc Products nào và ảnh hưởng thương mại đi kèm |
| Cờ của attribute | Bắt buộc/mặc định/hiển thị và cách khách hàng phải lựa chọn | Tạo mặc định không hợp lệ hoặc bỏ mất lựa chọn bắt buộc |
| Ảnh hưởng đến giá/trọng lượng | Điều chỉnh thương mại gắn với giá trị đã chọn | Nhãn vẫn đúng nhưng tổng giỏ hàng hoặc ý nghĩa vận chuyển thay đổi |
| Text/file/download | Dữ liệu khách hàng nhập hoặc quan hệ phân phối nội dung số | Biến dữ liệu tương tác/quyền truy cập thành văn bản mô tả đơn thuần |
Nền tảng nguồn có thể lưu một variant như bản ghi con với SKU và tồn kho riêng. Attributes trên Zen Cart có thể biểu diễn lựa chọn cho người mua, nhưng mô hình đích vẫn phải quyết định cách giữ định danh của variant, tồn kho, hình ảnh và ý nghĩa liên quan đến xử lý đơn hàng. Chỉ giữ tên lựa chọn là chưa đủ.
Một số nguồn còn có modifiers phụ thuộc lẫn nhau. Không nên giả định quan hệ phụ thuộc này sẽ tự xuất hiện từ các attributes thông thường. Zen Cart đích cần một cấu trúc hoặc phần mở rộng có khả năng diễn giải đúng quan hệ đó.
Giá, Specials, discounts, Coupons và tổng tiền Orders là những lớp khác nhau
Zen Cart có thể tính giá qua nhiều lớp: giá cơ bản của Products, điều chỉnh giá từ attributes, Products được định giá theo attributes, Specials, Sales, quantity discounts, giá theo nhóm Customers, Coupons, gift certificates, shipping, Tax, fees và các modules tổng tiền của Orders. Mỗi lớp tác động ở một giai đoạn khác nhau của phép tính storefront và có vai trò khác khi đọc lịch sử đơn hàng.
| Quy tắc thương mại ở nguồn | Câu hỏi cần giải quyết trên mô hình Zen Cart |
|---|---|
| Giá riêng theo variant | Giá thuộc Products, điều chỉnh attribute, mô hình priced-by-attribute hay Products độc lập? |
| Giá khuyến mãi tạm thời | Nên thành Special, quy tắc sale hay chỉ được giữ như dữ liệu lịch sử? |
| Chiết khấu theo số lượng | Thuộc quantity discount của Products, xử lý theo nhóm, module hay hệ thống giá bên ngoài? |
| Giá theo nhóm Customers | Quan hệ Customers-to-group nào quyết định mức giá? |
| Coupons hoặc gift certificate | Đây là quy tắc đang hoạt động, số dư, lịch sử sử dụng hay chỉ là bối cảnh trong Orders cũ? |
| Dòng phí, Tax, shipping hoặc credit | Quan hệ tổng tiền nào giải thích phép tính từ subtotal đến grand total của giao dịch lịch sử? |
Một đơn hàng đã phát sinh trước đây có thể chứa dòng Coupons hoặc gift certificate nhưng không đồng nghĩa quy tắc tương lai hoặc số dư còn lại đã được tái tạo. Một bản ghi Products có thể từng có giá Special nhưng chương trình đó không còn phù hợp ở Cửa hàng đích. Mô hình đích nên giữ đủ thông tin thương mại để Orders vẫn có thể giải thích được, đồng thời xây dựng cấu trúc giá và khuyến mãi tương lai theo nhu cầu hiện tại.
Customers, địa chỉ, nhóm và định danh bên ngoài cần có chủ sở hữu riêng
Customers trong Zen Cart có thể bao gồm danh tính tài khoản, sổ địa chỉ, trạng thái newsletter, lịch sử đơn hàng, nhóm giá, trạng thái phê duyệt và dữ liệu do plugin hoặc hệ thống ngoài quản lý. Địa chỉ billing/shipping tại thời điểm giao dịch trong Orders cần được giữ riêng với địa chỉ hiện tại trong sổ địa chỉ của Customers.
| Dữ liệu Customers | Câu hỏi về quan hệ trên đích |
|---|---|
| Danh tính tài khoản | Email, tên, trạng thái và kết quả xử lý mật khẩu nào định nghĩa tài khoản trên đích? |
| Sổ địa chỉ | Địa chỉ billing/shipping hiện tại nào vẫn hợp lệ và được bản địa hóa đúng? |
| Địa chỉ trong đơn hàng đã phát sinh trước đây | Bản chụp địa chỉ nào thuộc chính giao dịch đã phát sinh? |
| Nhóm Customers | Nhóm quyết định giá, quyền truy cập, phê duyệt, giao tiếp hay chức năng nào khác? |
| Newsletter và consent | Tùy chọn hiện tại hoặc hồ sơ chấp thuận nào là nguồn đáng tin để tiếp tục sử dụng? |
| Định danh hệ thống ngoài | CRM, ERP, Tax, marketplace hoặc hệ thống hỗ trợ nào tiếp tục sở hữu định danh đó? |
| Trường của plugin | Thành phần nào trên đích sẽ tiếp tục đọc giá trị sau di chuyển dữ liệu? |
Tên nhóm không thể thay thế toàn bộ quy tắc thương mại. Ví dụ, một tài khoản Customers thuộc nhóm wholesale hoặc đã được phê duyệt vẫn cần quan hệ rõ với giá, quyền truy cập hoặc cơ chế phê duyệt sẽ tiếp tục trên đích. Nếu chức năng nằm trong plugin hoặc hệ thống ngoài, bản ghi Customers cần giữ đúng khóa liên kết mà không giả định tài khoản cốt lõi của Zen Cart tự tái tạo toàn bộ chức năng đó.
Orders phải giữ được attributes đã chọn và các dòng tính toán dễ hiểu
Orders trong Zen Cart giữ lịch sử giao dịch thông qua thông tin đầu Orders, chi tiết Products, attributes đã chọn, bản chụp địa chỉ, lịch sử trạng thái, comments, Tax, shipping, discounts, Coupons, gift certificates và các dòng tổng tiền. Attributes được khách hàng chọn đặc biệt quan trọng vì tên Products cha có thể không cho biết khách đã mua kích cỡ, màu sắc, nội dung cá nhân hóa hoặc file download nào.
| Quan hệ trong Orders | Ý nghĩa cần giữ |
|---|---|
| Chi tiết Products đã mua | Tên, model, số lượng, giá, Tax và liên hệ với định danh Products nguồn |
| Attributes đã chọn | Cặp option-name/value chính xác cùng text khách hàng nhập hoặc tham chiếu file nếu có |
| Các dòng tổng tiền | Subtotal, discounts, Coupons, gift certificates, fees, shipping, Tax và grand total |
| Trạng thái và comments | Lịch sử xử lý và bối cảnh chăm sóc khách hàng |
| Nhãn thanh toán/vận chuyển | Dữ liệu về giao dịch ban đầu, không phải bằng chứng modules tương ứng đang hoạt động trên đích |
| Mã tham chiếu ngoài | Khóa từ marketplace, kế toán, ERP, cổng thanh toán, vận chuyển hoặc hệ thống hỗ trợ còn giá trị sử dụng |
Orders phải còn dễ hiểu ngay cả khi hệ thống trạng thái hoặc cách modules xử lý ở nguồn không có đối tượng tương đương hoàn toàn trên Zen Cart. Liên kết trạng thái theo ý nghĩa vận hành tốt hơn việc sao chép nhãn khiến nhân viên dễ hiểu sai.
Tên Products và thông tin options tại thời điểm mua cũng cần đủ ổn định để giải thích giao dịch ngay cả khi Products đang bán sau này thay đổi. Orders là dữ liệu cho biết khách hàng đã mua gì tại thời điểm đó, không chỉ là con trỏ đến bản ghi catalog hiện tại.
Nội dung có thể thuộc EZ-Pages, define pages, catalog hoặc templates
Nội dung trên Zen Cart được phân bố ở nhiều vị trí. EZ-Pages có thể tạo liên kết nội bộ/bên ngoài và xuất hiện ở header, footer hoặc sideboxes. Define pages chứa một số nội dung cố định của cửa hàng. Mô tả Products và Categories chứa nội dung catalog. Banners, sideboxes, language files, templates và plugins có thể bổ sung nội dung hoặc điều hướng khác.
| Nội dung nguồn | Vị trí có thể dùng trên Zen Cart | Quan hệ cần duy trì |
|---|---|---|
| Trang chính sách/thông tin | EZ-Page, define page hoặc cấu trúc nội dung khác | Định danh trang, route, ngôn ngữ và vị trí điều hướng |
| Nội dung landing của Categories | Mô tả Categories hoặc trang nội dung riêng | Quan hệ với Categories và mục đích duyệt catalog của khách hàng |
| Hướng dẫn mua Products | Mô tả Products, EZ-Page hoặc nội dung được liên kết | Internal links và quan hệ với Products liên quan |
| Link ở header/footer | Vị trí EZ-Page, điều hướng trong template hoặc cấu hình sidebox | Tách việc nội dung tồn tại khỏi vị trí hiển thị |
| Landing page chiến dịch | EZ-Page, custom page hoặc route do plugin quản lý | Tách nội dung lâu dài khỏi markup riêng của template nguồn |
| Metadata SEO | Trường của Products, Categories, EZ-Page hoặc plugin | Metadata vẫn gắn đúng đối tượng và route |
Chỉ chuyển phần text của Pages không duy trì được mô hình điều hướng. Một trang có thể tồn tại nhưng biến mất khỏi header, footer, sidebox, sitemap hoặc mạng internal links. Ngược lại, markup trình bày sao chép từ nguồn có thể không còn sử dụng được nếu template đích không diễn giải theo cách tương tự.
Dữ liệu plugins và bảng tùy chỉnh cần xác định bản ghi cha và thành phần tiếp tục sử dụng
Các cửa hàng Zen Cart hoạt động lâu năm thường có plugins, core files đã sửa, bảng tùy chỉnh, template overrides, language overrides, phần mở rộng báo cáo, trình tạo feed, modules SEO, tích hợp thanh toán/vận chuyển và quy trình quản trị đã thay đổi. Những thành phần này có thể lưu dữ liệu kinh doanh lâu dài, dữ liệu được tính ra, cấu hình hoặc dữ liệu kỹ thuật không còn giá trị.
| Dạng dữ liệu tùy chỉnh | Quyết định cần xác định trên mô hình đích |
|---|---|
| Trường tùy chỉnh trên Products, Customers hoặc Orders | Xác định ý nghĩa kinh doanh, bản ghi cha, trường đích và thành phần tiếp tục sử dụng |
| Loại bản ghi do plugin sở hữu | Chỉ giữ bản ghi và các quan hệ khi plugin hoặc quy trình trên đích tiếp tục sử dụng |
| Bảng tùy chỉnh | Phân biệt dữ liệu gốc có giá trị với logs, cache, index và dữ liệu trung gian đã lỗi thời |
| Phép tính đã sửa | Xây lại quy tắc/module; không xem kết quả tính sẵn là toàn bộ quy tắc kinh doanh |
| Template hoặc language override | Tách nội dung cần giữ khỏi phần trình bày phải dựng lại trên template đích |
| Khóa hệ thống ngoài | Giữ định danh liên hệ hệ thống ổn định trên đúng quan hệ Products, Customers hoặc Orders |
Cấu trúc cơ sở dữ liệu cho biết một giá trị đang được lưu ở đâu, nhưng không tự cho biết giá trị đó có còn là nguồn dữ liệu chính hay không. Bảng plugin có thể chứa dữ liệu subscription, shipping, marketplace hoặc reporting rất quan trọng. Cũng có thể đó chỉ là cache đã cũ không nên đưa vào mô hình đích. Quyền sở hữu và nhu cầu sử dụng trên đích mới quyết định sự khác biệt này.
Cần xác định quyền sở hữu dữ liệu trước khi liên kết các trường nguồn và đích
Một mô hình Zen Cart rõ ràng nên đưa từng giá trị nguồn quan trọng vào một trong các kết quả sau:
- quan hệ gốc của Zen Cart như Products, Categories, options, attributes, Customers, Orders, Coupons, Reviews, nội dung hoặc media;
- dữ liệu tùy chỉnh/plugin được quản lý rõ với thành phần trên đích tiếp tục sử dụng;
- định danh ổn định của hệ thống ngoài được gắn đúng bản ghi cha;
- cấu hình hoặc phần trình bày trên đích cần dựng lại thay vì sao chép như dữ liệu;
- logs, cache, dữ liệu tính ra hoặc dữ liệu cũ có giá trị thấp nên được lưu trữ riêng hoặc loại khỏi di chuyển dữ liệu.
| Hạng mục quyết định | Câu hỏi cần trả lời trên mô hình đích |
|---|---|
| Định danh Products | Đây là một bản ghi Products, một linked Products xuất hiện ở nhiều Categories, một tập lựa chọn attributes hay nhiều Products độc lập? |
| Lựa chọn Products | Option name, option value, quan hệ gán attribute, flags và ảnh hưởng đến giá/trọng lượng nào tạo nên lựa chọn đầy đủ? |
| Phép tính thương mại | Giá trị nào là dữ liệu Products, điều chỉnh giá attribute, quy tắc khuyến mãi, xử lý theo nhóm Customers hay dữ liệu lịch sử trong Orders? |
| Customers và Orders | Danh tính hiện tại, địa chỉ hiện tại, bản chụp lịch sử, attributes đã chọn và tổng tiền nào cần được giữ riêng? |
| Nội dung | Đối tượng và vị trí điều hướng nào trong Zen Cart mang đúng ý nghĩa của nội dung? |
| Plugins và tích hợp | Thành phần trên đích hoặc hệ thống ngoài nào tiếp tục sở hữu bản ghi? |
Cách tiếp cận dựa trên quan hệ này tránh hai cực đoan: đưa mọi bảng nguồn vào các trường tùy chỉnh không rõ mục đích, hoặc bỏ dữ liệu ngoài core dù dữ liệu đó vẫn hỗ trợ vận hành. Khi quyền sở hữu và quan hệ được xác định, Zen Cart có thể diễn giải các bản ghi di chuyển dữ liệu thành một cửa hàng nhất quán thay vì chỉ trở thành kho lưu các dòng dữ liệu từ hệ thống cũ.
Kết luận
Khác biệt mô hình dữ liệu của Zen Cart tập trung ở quan hệ Products-Categories, mô hình option name/option value/attribute, các lớp tính giá, quyền sở hữu dữ liệu Customers và địa chỉ, attributes/tổng tiền trong Orders, vị trí của EZ-Pages và nội dung, plugins, bảng tùy chỉnh cùng các định danh hệ thống ngoài.
Một di chuyển dữ liệu đạt yêu cầu phải giữ toàn bộ quan hệ đứng sau từng giá trị quan trọng. Products duy trì một định danh qua các vị trí duyệt có chủ đích. Lựa chọn của khách hàng vẫn tạo đúng tác động thương mại. Orders tiếp tục dễ hiểu như giao dịch lịch sử. Nội dung có vị trí phù hợp trên Zen Cart. Dữ liệu tùy chỉnh có thành phần tiếp tục sở hữu và sử dụng.
Câu hỏi thường gặp
Vì sao option names, option values và attributes trong Zen Cart được tách riêng?
Option name xác định chiều lựa chọn, option value xác định một giá trị có thể chọn, còn attribute gán cặp đó vào Products cụ thể. Quan hệ gán có thể kèm thông tin riêng của Products như giá, trọng lượng, thứ tự, lựa chọn bắt buộc hoặc cấu hình download.
Products xuất hiện trong nhiều collections ở nguồn có nên trở thành nhiều Products trên Zen Cart không?
Thông thường không, nếu các bản ghi nguồn vẫn đại diện cho cùng một mặt hàng thương mại. Một bản ghi Products trong Zen Cart có thể được liên kết tới nhiều Categories để giá, tồn kho, attributes và quản trị vẫn tập trung. Chỉ nên dùng Products riêng khi các mặt hàng thực sự có định danh thương mại độc lập.
Mọi variant ở nguồn có thể trở thành attribute trên Zen Cart không?
Không phải mọi variant đều phù hợp để trở thành attribute. Variant nguồn có thể sở hữu SKU, tồn kho, hình ảnh, chi phí, barcode hoặc định danh liên quan đến xử lý đơn hàng vượt quá cấu trúc attribute dự kiến. Mô hình đích phải giữ những quan hệ đó bằng cấu trúc phù hợp, Products độc lập hoặc phần mở rộng có khả năng hỗ trợ.
Tổng tiền trong đơn hàng đã phát sinh trước đây nên được biểu diễn như thế nào?
Subtotal, discounts, Coupons, gift certificates, fees, shipping, Tax và grand total cần được giữ thành các dòng tính toán dễ hiểu gắn với Orders. Các dòng này giúp giải thích giao dịch đã phát sinh nhưng không tự tái tạo quy tắc khuyến mãi hoặc modules sẽ vận hành trong tương lai.
CMS Pages ở nguồn nên được đặt ở đâu trên Zen Cart?
Mỗi trang cần được đặt theo vai trò: EZ-Page, define page, nội dung Products/Categories, custom page hoặc cấu trúc khác. Route, ngôn ngữ, internal links, metadata và vị trí điều hướng cần được giữ riêng với phần nội dung trang.
Dữ liệu plugin và bảng tùy chỉnh nên được phân loại như thế nào?
Mỗi bản ghi cần được truy về bản ghi cha, mục đích kinh doanh, thành phần trên đích tiếp tục sử dụng và người/hệ thống chịu trách nhiệm. Nên giữ dữ liệu gốc có giá trị cùng các khóa tích hợp, xây lại quy tắc đang hoạt động trên đích và loại logs, cache, indexes hoặc dữ liệu cũ không còn giá trị lâu dài.