EShop is a Joomla commerce extension with its own catalog, Customer, Order, pricing, discount, tax, shipping, payment, and checkout records. Joomla supplies the surrounding identity, routing, module, language, template, and site context. A successful data translation must preserve the boundary between those two layers while also distinguishing historical commercial records from live configuration.
When EShop is the Target Platform, similarly named source fields can require different representations. A source “attribute” may be a buyer-selectable Product option, an informational attribute, a custom Product field, a Product tab, a checkout field, or an external identifier. A source Customer group may control price rather than permission. A source page path may depend on Joomla Menu Items instead of belonging directly to the Product. Article 3 decisions therefore begin with meaning and ownership, not labels.
EShop Combines Commerce Records with Joomla Site Structure
EShop owns the primary store records. Joomla owns general site identity, navigation, modules, templates, languages, access, and extension infrastructure. Payment, shipping, import, reporting, and integration plugins can introduce additional data or references.
| Ownership layer | Typical records | Translation consequence |
|---|---|---|
| EShop catalog | Products, Categories, manufacturers, options, attributes, custom fields, attachments, prices, stock | Preserve Product relationships and distinguish sellable choices from descriptive information. |
| EShop commercial history | Customers, groups, addresses, Orders, Order lines, coupons, vouchers, tax, shipping, payment, statuses | Keep historical snapshots and the relationships that explain each transaction. |
| Joomla core | Users, Menu Items, modules, languages, aliases, templates, access | Maintain route, identity, and presentation context without treating it as EShop catalog data. |
| EShop and Joomla plugins | Payment, shipping, imports, modules, specialized fields, integrations | Identify the plugin owner and whether the record is historical, operational, or external. |
| External systems | ERP, CRM, POS, fulfillment, accounting, product information | Preserve stable identifiers on the EShop entity recognized by the external system. |
This ownership map keeps a Product record separate from the Joomla page that exposes it and keeps an Order’s payment reference separate from the payment plugin configuration used for future transactions.
Products, Categories, Manufacturers, and Catalog Relationships
An EShop Product can participate in several catalog relationships: Category placement, manufacturer identity, media, pricing, stock, tax class, measurements, options, attributes, custom fields, tabs, attachments, related Products, metadata, aliases, and language-specific values. A source platform may combine or separate those concepts differently.
Categories can form a hierarchy and receive Product assignments. Manufacturers provide a separate brand-like entity. Related Products, comparison data, wishlists, filters, modules, and search can all depend on Product identity without becoming Product fields.
| Source concept | Possible EShop representation | Relationship to preserve |
|---|---|---|
| Product family with separate child SKUs | Parent Product with options, or separate Products connected by merchandising relationships | Sellable identity, stock, price, media, and external IDs at the correct level |
| Brand or vendor | Manufacturer | Product-to-manufacturer relationship without merging the manufacturer into Category taxonomy |
| Department tree | EShop Category hierarchy | Parent-child structure, Product assignment, aliases, metadata, and language context |
| Related or complementary item | Related Product relationship | Direction and purpose of the Product-to-Product association |
| Download, manual, or specification sheet | Product attachment or Product tab | File ownership, Product relationship, title, language, and visibility |
| Technical Product facts | Attribute, custom field, or Product tab | Descriptive meaning without creating unnecessary buyer selections |
The destination representation should preserve the source catalog’s management logic. Two Products with different SKUs and warehouse identities should not be merged merely because they share a title. Conversely, a source system that creates one record per size may be better represented through EShop Product options when the combinations belong to one merchandising parent.
Product Options, Attributes, Custom Fields, and Tabs Are Not Interchangeable
EShop distinguishes buyer choices from descriptive Product information. Product options represent selections a Customer makes before adding a Product to the cart, such as size or color. Product attributes describe information used for Product detail and comparison. Custom fields can hold additional Product-specific information. Product tabs and attachments can provide extended content, videos, documentation, or files.
| EShop structure | Primary meaning | Source examples |
|---|---|---|
| Product option | Buyer-selectable choice that can affect the purchased line | Size, color, packaging, finish, service level |
| Option value | Allowed selection within an option | Small, medium, blue, gift box |
| Product attribute | Informational characteristic used for description or comparison | Material, processor, capacity, compatibility |
| Custom Product field | Additional structured value not covered by ordinary Product fields | Regulatory code, internal classification, external reference |
| Product tab | Extended content section on the Product page | Specifications, warranty, video, care instructions |
| Attachment | File relationship to a Product | Manual, certificate, datasheet, downloadable document |
A source option should become an EShop option only when the Customer’s selection is part of the purchased Product line. A technical specification that does not alter the sellable choice belongs in an attribute, custom field, or content section. Flattening these structures can create impossible option combinations, duplicate Product pages, or Order lines that no longer show what the buyer selected.
Option-level commercial meaning also requires attention. Where source selections affect price, SKU, weight, image, stock, or availability, the destination representation must keep those relationships together. A label without the associated commercial behavior is not an equivalent data model.
Customers, Joomla Users, Customer Groups, and Addresses Carry Different Meaning
EShop Customers can be connected to Joomla User identities, but Customer data includes commerce-specific relationships such as addresses, Orders, wishlists, reward context, and group assignment. Guest checkout can create historical buyer and address data without a durable registered account.
Customer groups are especially important because EShop can use them for differentiated Product pricing. A Joomla User group, by contrast, normally represents permission or access. A source “group” must therefore be classified before it is translated.
| Source record | EShop or Joomla destination meaning |
|---|---|
| Registered login | Joomla User identity linked to the appropriate EShop Customer where supported |
| Commerce Customer | EShop buyer profile, addresses, Order relationships, and commercial group context |
| Guest buyer | Historical identity and address stored with Orders without inventing a permanent account |
| Wholesale or price tier | EShop Customer group when it governs commercial pricing or eligibility |
| Administrator or content role | Joomla User group and permission structure rather than an EShop Customer group |
| Organization and contacts | Separate organization/contact design when a simple Customer record cannot preserve the relationship |
Address translation should also distinguish reusable Customer addresses from Order snapshots. A Customer may update an address after purchase, but the historical Order still needs the billing and shipping details recorded at transaction time.
Orders Preserve Product Choices, Checkout Data, and Commercial History
An EShop Order can preserve Customer or guest identity, billing and shipping addresses, Product lines, selected option values, quantities, prices, discounts, coupons, vouchers, taxes, shipping, payment references, currency, statuses, custom checkout fields, notes, and timestamps. These records explain what happened; they are not instructions for how the destination should calculate future transactions.
| Order element | Historical meaning |
|---|---|
| Product line | Purchased Product identity and description at the time of sale |
| Selected option values | The buyer’s actual configuration of the Product |
| Custom checkout field | VAT number, delivery instruction, pickup detail, company reference, or other collected value |
| Price, discount, coupon, voucher, and tax | Monetary snapshot that should not be recalculated under new rules |
| Shipping method and amount | Fulfillment choice and charge recorded for the Order |
| Payment method and transaction reference | Historical payment context, not active gateway configuration |
| Currency | Currency used for the transaction and its recorded totals |
| Status history | Operational lifecycle evidence used for service and reporting |
Custom checkout fields deserve their own mapping. Some values describe the Customer, some describe an address, some apply only to one Order, and others identify an external company or delivery workflow. Placing every checkout value on the Customer profile can create stale or incorrect data; keeping every value only as text on an Order can make reusable business identifiers inaccessible.
Pricing, Discounts, Tax, Shipping, and Payment Have Record and Configuration Sides
EShop supports Product prices, Customer-group pricing, quantity discounts, coupons, vouchers, tax rates, geographic zones, currencies, shipping plugins, and payment plugins. These concepts have two different data-model roles.
First, historical Orders contain the commercial result: prices charged, discounts applied, tax recorded, shipping selected, payment references, and currency totals. Second, the destination store contains live rules and plugin configuration that determine future behavior.
| Commercial area | Historical record | Live operational structure |
|---|---|---|
| Customer-group price | Price or discount reflected on past Order lines | Current Product-to-group pricing relationship |
| Coupon or voucher | Code and discount effect recorded on an Order | Coupon or voucher definition, eligibility, dates, and remaining use |
| Tax | Tax amount and label on the historical Order | Tax class, tax rate, geo zone, and current calculation rules |
| Shipping | Method label, charge, address, and tracking context | Enabled shipping plugin and current rate conditions |
| Payment | Method label, transaction reference, and status | Enabled payment plugin, credentials, and current processing configuration |
| Currency | Recorded Order currency and totals | Published currencies and current exchange behavior |
Separating these sides prevents historical data from being overwritten by current rules and prevents an old Order from being mistaken for a complete operational configuration.
Multilingual Commerce Data and Joomla Routes Form a Combined Model
EShop supports multilingual store data, while Joomla supplies broader content-language, Menu, module, and route relationships. Products, Categories, manufacturers, options, attributes, custom fields, labels, and storefront text may carry language-specific values. Joomla Menu Items and modules can expose different routes or supporting content for each language.
A source platform that stores all translations on one Product may need language-specific EShop values. A source that uses separate Product records may need association or identifier logic to preserve equivalence. Interface translations and language overrides should remain separate from translated business content.
| Language or route record | Meaning in the destination |
|---|---|
| Translated Product or Category field | Shopper-facing commerce content for a specific language |
| Joomla content language | Language assignment used by site and component records |
| Language-specific Menu Item | Public entry point, alias, and navigation context for one language |
| Language-specific module | Supporting storefront block shown in selected language contexts |
| Interface language string | Extension or template text rather than Product or Category content |
| Product alias and metadata | SEO and route-related values attached to the relevant commerce record |
The Product record and the route that exposes it should remain distinguishable. A Joomla Menu Item can point to an EShop view and influence the public path, while the Product alias and EShop router contribute their own route meaning. Translating only the Product title does not preserve that combined structure.
Modules, Templates, Themes, and Layout Overrides Are Presentation Relationships
EShop can display Products through component pages, Joomla modules, Joomla Articles, search, filters, and custom layouts. Templates and overrides can change Product, Category, cart, checkout, and account output without changing the underlying commerce records.
| Presentation object | Data-model interpretation |
|---|---|
| Product or Category module | Reusable display that queries EShop records |
| Joomla Article embedding Product output | Content record containing or invoking an EShop relationship |
| Template override | Rendering logic rather than a portable Product field |
| Theme or layout setting | Presentation configuration separate from catalog ownership |
| Filter or search module | Discovery interface using Product attributes, Categories, manufacturers, or other indexed data |
| Custom landing page | Joomla or builder content that references EShop Products and Categories |
This separation allows catalog data to remain authoritative even when the destination uses a different page builder, template, or storefront layout.
Plugins, Imports, Custom Tables, and External Systems Extend the Core Model
EShop supports payment and shipping plugins, imports and exports, modules, integrations, custom fields, and custom layouts. Long-running stores may also contain modified tables, direct SQL integrations, scheduled synchronization, custom reports, or identifiers from ERP, CRM, POS, accounting, and fulfillment systems.
| Extension-owned signal | Required interpretation |
|---|---|
| Payment transaction reference | Historical Order/payment relationship that may be needed for support or reconciliation |
| Carrier or fulfillment identifier | Shipment or Order relationship used by an external system |
| Product import key | Stable Product or option identifier used for repeat synchronization |
| Custom checkout table | Order-, Customer-, address-, or organization-level values that need explicit ownership |
| External Product or Customer ID | Identifier that must remain attached to the destination entity recognized by the connected system |
| Plugin-created status or metadata | Meaning defined by the plugin rather than an ordinary EShop field |
The destination does not need to copy every source table. It does need an explicit owner for each business-critical value and a deliberate decision about whether the value becomes a native EShop field, a plugin-owned record, a Joomla relationship, or an external-system reference.
Conclusion
EShop migration is a translation among catalog, transaction, Joomla, presentation, plugin, and external-system layers. Products, options, attributes, custom fields, Customers, groups, addresses, Orders, checkout fields, pricing, tax, shipping, payment, languages, Menu routes, and modules each carry different ownership and relationship meaning.
A coherent destination model preserves those distinctions before records are transformed. That keeps buyer choices attached to Product lines, historical totals attached to Orders, commercial groups separate from Joomla permissions, translations connected to the correct commerce records, and external identifiers attached to the entities used by connected systems.
Common Questions
Are EShop Product options and attributes the same?
No. Options represent buyer-selectable choices that can appear on the purchased line. Attributes describe Product information used for details or comparison. Custom fields, tabs, and attachments serve additional descriptive roles.
Should every source Product variation become an EShop option?
Only when the source records are choices within one merchandising Product. Separate SKUs with independent URLs, lifecycle, inventory, media, or external identities may need to remain separate Products or require a more deliberate parent-child design.
Are Joomla User groups equivalent to EShop Customer groups?
No. Joomla User groups normally control permissions and access. EShop Customer groups can represent commercial segmentation such as differentiated pricing. A source group should map according to what it governs.
Where should custom checkout fields be stored?
Their destination depends on meaning. Reusable identity values may belong to a Customer or organization, address values to an address, and transaction-specific instructions or references to the Order.
Do historical Orders define future tax, shipping, and payment behavior?
No. Orders preserve the amounts, labels, references, and choices recorded at purchase time. Future calculations and processing depend on the destination’s current rules and enabled plugins.
How should Joomla Menu Items be handled around EShop Products and Categories?
Menu Items should remain route and navigation records that point to EShop views. They can influence aliases, hierarchy, language, access, and template context, but they do not replace the underlying EShop Product or Category.