A source attribute named size may describe a Product, offer a buyer choice or identify a separately stocked item. EShop by Ossolution Team gives those meanings different owners, while Joomla contributes account and route context. Translation must preserve what each value does for the catalog or transaction before deciding where it belongs.
EShop is a Joomla commerce extension with catalog and commercial records surrounded by Joomla identity, routing, modules, languages, templates and access. The selected EShop build, enabled fields and installed plugins define the actual destination model. Features described for the component or an import add-on do not establish arbitrary schema compatibility or support for a specific migration path.
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. Data-model 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 independent stock, lifecycle, URLs or warehouse identities should not be merged merely because they share a title. Separate source size records can become choices under one merchandising parent only if EShop’s actual option and inventory relationships preserve their commercial identity. The presence of an option selector does not establish independently stocked combinations.
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 defined and enabled for the selected Product model | 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. A selected value can affect the purchased line without becoming a separately stocked combination. Where the selected build derives a purchased SKU from a Product code and option-value codes, that composed code still differs from a native Product key or a source variant ID. For a source size-and-color matrix, the destination must preserve which combinations actually exist and which stock record owns each quantity; labels or composed codes alone do not supply that relationship.
Customers, Joomla Users, Customer Groups, and Addresses Carry Different Meaning
EShop Customers can be connected to Joomla User identities, with addresses, Orders, group assignment and other commerce relationships according to the selected implementation. A historical guest transaction can contain buyer details without a reusable registered account. The destination should preserve that distinction rather than infer a login, reward entitlement or permission from the presence of an email address.
Customer groups are especially important because EShop can use them for differentiated pricing, Product visibility and tax scope. Joomla User groups ordinarily govern permissions and access, although a particular integration may consume those groups for commercial rules. A source group must therefore be translated with the Product, rule and buyer relationship it controls, rather than copied as a label or assumed to grant the same privileges.
| 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 buyer context, billing and shipping snapshots, purchased Product lines and chosen options, quantities, recorded prices and totals, and associated methods, states or checkout values where available. These records explain what happened; they do not instruct the destination to recalculate the transaction under current prices, group membership or tax rules. Unmatched source fields need an explicit destination owner rather than an assumed native Order field.
| 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.
Historical references also have an authority boundary. A payment method or transaction key does not recreate gateway credentials, reusable payment authorization or a continuing subscription. A purchased download and its recorded access conditions do not by themselves recreate future file entitlement. Those behaviors require a compatible destination owner in addition to the retained transaction evidence.
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.
EShop’s multilingual model can retain one business record with language-specific values. Joomla core content can instead use distinct records linked as language equivalents. If a source exports one Product per language, those rows may describe translations of one sellable item rather than separate stock. Product identity, language values and Joomla route relationships must be translated separately. Interface strings and custom extra-field definitions have their own language treatment; translated text alone does not establish that treatment.
| 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.
For example, French and English titles can describe the same EShop Product and stock position while language-specific Joomla Menu Items expose different paths. Treating those titles as separate Products can duplicate inventory; treating the menus as interchangeable can lose the intended language route. Both relationships are needed even though the buyer sees one localized Product page.
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 selected EShop Product and option model preserves the source relationship. Independent stock, lifecycle, URLs or external identities can require separate Products or another explicit design. An option label or a code composed from selected values does not establish a separately stocked size-and-color combination.
Are Joomla User groups equivalent to EShop Customer groups?
No. EShop Customer groups can govern commercial rules such as pricing, visibility or tax scope, while Joomla groups ordinarily govern permissions and access. A specific integration may connect them, but the consuming rule and its Product/buyer relationships must remain explicit.
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 historical amounts, choices, states and references. Future behavior depends on the destination rules and enabled plugins. Retaining an old transaction key also does not prove continuing payment authority, subscription behavior or file-access entitlement.
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.
Do translated EShop Products need separate Product identities?
Usually the translated values belong to one EShop business record, rather than separate stock-bearing Products. Joomla content and language-specific Menu Items can use different records or associations around that Product. When a source exports separate language rows, preserve their common sellable identity and translate the language and route relationships according to the selected implementation.