Phoca Cart is a Joomla-native commerce component with its own Product, Category, Customer, Order, pricing, tax, stock, and benefit structures. Joomla still supplies users, access levels, menus, modules, templates, language context, routing, and the wider extension environment. Migration must therefore translate both the commerce records and the Joomla relationships that make those records discoverable and usable.
Phoca Cart also separates several concepts that source platforms often combine: Product options, attributes, specifications, customer-group prices, discounts, coupons, reward points, tax rates, currencies, stock statuses, and downloadable access. A field name is not enough to choose the destination. The destination should follow how the value affects buying, administration, and historical interpretation.
Product Identity and Catalog Relationships
A Phoca Cart Product can connect to Categories, manufacturers, images, attributes, options, specifications, related Products, downloads, stock, prices, discounts, taxes, reviews, language content, and customer-group rules. The Product row is therefore only the center of a relationship network.
| Source meaning | Possible Phoca Cart owner | Relationship to preserve |
|---|---|---|
| Core Product identity | Product record | Name, alias, code/SKU, descriptions, publication state, and language |
| Catalog placement | Phoca Cart Categories | Product-to-Category assignments and intended hierarchy |
| Brand identity | Manufacturer record, Category, or external key | Product-to-manufacturer and any browsing or integration use |
| Product media | Product images, downloadable files, or content assets | Role, ordering, visibility, and access |
| Shopper choice | Option or attribute relationship | Selected value to price, stock, image, or Order-line meaning |
| Descriptive data | Attribute, specification, parameter, or content field | Display, comparison, filtering, or administration purpose |
| Buyer-specific benefit | Customer group, price, discount, coupon, or reward record | Customer eligibility to the commercial result |
A source Product that has separate child SKUs may remain separate Products or may be represented through options, depending on whether Phoca Cart needs independent stock, price, image, code, or fulfillment identity for each choice. The target model should not collapse distinct sellable items merely to produce a simpler page.
Options, Attributes, Specifications, and Parameters
The most important Phoca Cart catalog distinction is the function of Product detail values.
- Options represent shopper selections that participate in purchasing.
- Attributes can describe Products or participate in option structures depending on the implementation.
- Specifications organize comparable technical or descriptive information.
- Parameters and custom values may support display, filtering, import/export, modules, or custom code.
A source field such as “size” illustrates the problem. It can be a selectable clothing size, a package dimension, a filter value, or internal warehouse data. Those meanings need different target owners.
| Source behavior | Target interpretation | Meaning to retain |
|---|---|---|
| Choice changes stock or Product code | Structured option/attribute or separate Product relationship | Inventory and Order-line identity |
| Choice changes price only | Option value with price relationship | Selected value and price adjustment |
| Shopper enters text | Input-oriented field or extension record | Entered value attached to the correct Order item |
| Technical specification | Specification or descriptive attribute | Label, value, group, ordering, and comparison use |
| Search/filter facet | Structured attribute or parameter used by filters | Normalized value and filter membership |
| Internal operational value | Custom field or external-system record | Administrative ownership without accidental storefront display |
Definitions and Product assignments should remain separate. A specification group, attribute definition, or option definition can be reused across many Products, while the Product-specific value or allowed selection belongs to the individual Product relationship.
Prices, Stock, Discounts, Coupons, and Rewards
Phoca Cart can express more than one kind of commercial value. Base price, customer-group price, Product discount, cart discount, coupon, reward points, tax, currency, and stock status are separate concepts. Combining them into one “price” field removes the rule that explains when and for whom the value applies.
| Source commercial rule | Phoca Cart relationship | Translation question |
|---|---|---|
| Wholesale or member price | Customer group plus Product price | Which Customers belong to the group and which Products use the price? |
| Product-specific sale | Product discount and effective conditions | Is the discount a stored amount, percentage, or timed rule? |
| Cart promotion | Cart discount or coupon | Which cart conditions and usage limits define eligibility? |
| Loyalty balance | Customer reward-point record | Is the balance authoritative in Phoca Cart or another system? |
| Stock availability | Product stock, option stock, and stock status | Does inventory belong to the Product or one selection? |
| Multicurrency value | Currency and price/display relationship | Which amount is stored and which is converted for display? |
Historical Order totals should retain the price, discount, coupon, reward, tax, shipping, payment, and currency evidence recorded at purchase time. Those snapshots are not substitutes for active target rules. New carts use the current Phoca Cart configuration and plugin logic.
Reward points need explicit ownership. A Customer balance, points earned by an Order, points spent, and the rule that converts points into value are related but different records. Migrating only the balance can leave the history and eligibility logic unexplained.
Categories, Manufacturers, Search, and Joomla Navigation
Phoca Cart Categories and manufacturers belong to the commerce catalog. Joomla menus and modules expose selected Product, Category, manufacturer, search, filter, comparison, or other views to shoppers. A source navigation structure may therefore translate into several target relationships rather than one Category tree.
| Source structure | Possible destination | Meaning to preserve |
|---|---|---|
| Product Category | Phoca Cart Category and Product assignments | Catalog hierarchy and buyer grouping |
| Brand page | Manufacturer record plus menu or module destination | Brand identity, browsing, and filtering |
| Dynamic collection | Filter, search rule, module query, Category, or custom logic | Membership rule rather than only current Product IDs |
| Featured or latest block | Joomla module configuration | Query, ordering, audience, and placement |
| Comparison or wish list | Phoca Cart Customer/session records and modules | Product relationships and account ownership where persistent |
| Restricted catalog | Joomla access level, Customer group, or extension | Who can see or buy the Products |
Joomla Categories and Phoca Cart Categories are not automatically the same taxonomy. Joomla Categories organize records inside Joomla components; Phoca Cart maintains its commerce Category model. A migration should not merge them merely because the labels match.
Search and filtering depend on normalized Product values. If source attributes contain inconsistent spelling, units, or value formats, the target can retain every string while still losing useful filter behavior. The relationship between Product, attribute/specification definition, and normalized value is the relevant data model.
Customers, Joomla Users, Groups, and Addresses
A registered Phoca Cart Customer may link to a Joomla user. Customer groups can influence prices and benefits, while Joomla access levels can control site visibility. Addresses, tax details, company data, reward points, wish lists, and Orders may belong to different parts of the Customer relationship.
| Customer value | Appropriate owner | Reason |
|---|---|---|
| Login identity and enabled state | Joomla user | Controls authentication |
| Site access role | Joomla user group/access level | Controls content and component visibility |
| Commercial segment | Phoca Cart Customer group | Can affect prices, discounts, or benefits |
| Reusable billing/shipping address | Phoca Cart Customer/address record | Belongs to the Customer lifecycle |
| Guest address | Historical Order | Belongs to one transaction |
| Reward balance | Phoca Cart reward records or external loyalty system | Requires an authoritative ledger |
| Tax or company identifier | Customer, address, Order, or external system | Ownership depends on reuse and legal purpose |
Joomla user groups and Phoca Cart Customer groups should not be assumed to be interchangeable. One can control CMS access while the other controls commerce treatment. Some stores connect them through custom logic, but that connection is itself a relationship that must be identified.
Guest Customers should remain distinguishable from registered accounts. An Order email does not prove that a persistent Joomla user existed, and generating accounts from all guest history can create duplicate identities.
Orders, Invoices, Payments, and Shipping Evidence
Phoca Cart Orders can include Product and option details, addresses, Customer context, prices, discounts, coupons, reward points, taxes, shipping, payment, currency, status, notes, and invoice references. The Order should preserve a snapshot of the transaction rather than relying only on the current Product or Customer record.
| Order relationship | Meaning to preserve |
|---|---|
| Order to Customer or guest | Identity used at purchase time |
| Order line to Product and option values | Exact purchased configuration |
| Order line to price and discount | Historical amount formation |
| Order to coupon or reward use | Benefit applied to the transaction |
| Order to tax, shipping, and payment | Historical financial and fulfillment context |
| Order to status and timestamps | Operational progression |
| Order to invoice or receipt reference | Document continuity where required |
| Order to external ID | ERP, POS, accounting, carrier, or marketplace continuity |
Phoca Cart can support invoicing and point-of-sale workflows. Those capabilities should not be inferred from one Order table alone. Online and offline transactions may share Products, Customers, stock, and document numbers while using additional POS or invoice records. The target model needs to identify the authoritative source for each sequence and external reference.
Payment and shipping plugins also create a distinction between historical evidence and active behavior. An old Order needs readable method names, amounts, tracking, and provider references where retained. The current target needs its own plugin configuration.
Content, Language, URLs, and Storefront Presentation
Phoca Cart operates inside Joomla, so Product and Category records are only part of the customer-facing result. Joomla menus, modules, templates, language assignments, access levels, routing, and content pages shape discovery and presentation.
A source store may combine Product data with buying guides, comparison pages, manufacturer pages, Blog Posts, landing pages, and downloadable resources. These should be assigned to the target record that owns their lifecycle:
- Product-specific selling content can belong to Product fields;
- Category introductions can belong to Category content;
- broader editorial material can become Joomla CMS Pages or Blog Posts;
- module-driven Product blocks remain Joomla presentation configuration;
- downloadable assets can belong to Product access or CMS content depending on purpose.
Multilingual relationships can include translated Products, Categories, manufacturers, attributes, specifications, menus, modules, metadata, and URLs. Copying translated text without the language and route relationships produces disconnected content.
URL ownership is shared. Product and Category aliases provide commerce identity, while Joomla menu context and routing can determine the visible path. The target should identify canonical destinations and relate redirects to them rather than treating the full source URL as one Product field.
Plugins, Modules, Imports, POS, and External Systems
Phoca Cart is modular. Payment and shipping plugins, search and filter modules, PDF generation, newsletters, Open Graph integration, import/export workflows, POS functions, template overrides, and custom Joomla extensions can create or consume data outside the standard Product-Customer-Order structures.
| Dependency | Additional data or assumptions | Destination question |
|---|---|---|
| Import/export workflow | Column mappings, external IDs, schedules, transformed values | Will Phoca Cart or an external process remain authoritative? |
| POS workflow | Offline Orders, stock updates, document numbering, cashier or location context | Which records are shared with online commerce? |
| Search/filter module | Indexed values, parameter definitions, query configuration | Which Product relationships drive discovery? |
| Payment/shipping plugin | Provider references, tracking, method metadata, custom statuses | What is historical evidence and what is active configuration? |
| PDF or invoice extension | Document templates, numbering, generated files | Which identifiers and files require continuity? |
| ERP, accounting, marketplace, or feed integration | Stable Product, Customer, Order, tax, and stock keys | Which system owns each identifier? |
| Template override | Expected fields, module positions, route assumptions | Which translated records must remain addressable? |
The presence of an extension should lead to a data-ownership question, not an assumption that all its records belong in a generic custom field. Some values belong to Phoca Cart, some to Joomla, and some to the external system that created them.
How Phoca Cart Differences Change Migration Scope
Phoca Cart scope should distinguish these treatments:
| Treatment | Typical examples | Scope consequence |
|---|---|---|
| Direct record translation | Products, Categories, manufacturers, Customers, Orders, media | Map supported fields and identifiers |
| Relationship reconstruction | Options, attributes, specifications, Customer groups, reward records, Order benefits | Rebuild definitions, assignments, and ownership links |
| Joomla presentation structure | Menus, modules, templates, routes, access, language context | Assign to target site implementation |
| Plugin or workflow data | POS, invoices, imports, payment/shipping metadata, search indexes | Define a current destination or historical archive |
| External-system continuity | ERP, accounting, marketplace, loyalty, carrier, feed IDs | Preserve durable keys and named ownership |
| Intentional retirement | Obsolete modules, unused parameters, duplicate routes, abandoned integrations | Exclude with a recorded reason |
A coherent target model lets staff trace a Product through its Category, option, specification, price, stock, Customer-group rule, Order line, Joomla route, and external identifier without guessing which system owns the value.
Conclusion
Phoca Cart data model differences come from the combination of a rich commerce component and the Joomla site around it. Products can depend on Categories, manufacturers, options, attributes, specifications, prices, stock, benefits, taxes, plugins, and multilingual content. Customers can span Joomla users, access levels, Phoca Cart groups, addresses, rewards, and Orders. Storefront routes and presentation remain Joomla relationships.
A reliable migration translates each value by function. Shopper choices stay connected to the correct Product and Order line; descriptive values remain useful for display and filtering; historical totals remain separate from active rules; and plugin or external-system data receives a clear owner. That approach preserves how the store works rather than only how its tables were named.
Common Questions
What is the practical difference between a Phoca Cart option and a specification?
An option participates in the shopper’s purchase choice. A specification describes or compares the Product. The same label, such as size or material, can belong to either structure depending on whether it changes the purchased result.
Should Joomla Categories and Phoca Cart Categories be merged?
Not automatically. They belong to different Joomla components and can serve different purposes. Phoca Cart Categories organize commerce records, while Joomla Categories organize records inside the CMS component that owns them.
How should Customer groups and Joomla user groups be translated?
Preserve them as separate relationships unless the store has explicit logic connecting them. Joomla groups can control site access; Phoca Cart groups can control prices, discounts, or other commerce treatment.
Do reward points belong only to the Customer balance?
No. The balance, points earned, points spent, the related Orders, and the conversion rules can be separate records. The target needs an authoritative owner for the complete loyalty relationship.
Can historical tax, payment, and shipping data use the same records as active checkout rules?
Historical Orders should preserve the amounts, labels, and references recorded at purchase time. Active target rules and plugins govern new transactions and remain a separate configuration layer.
How should POS or import/export data be handled?
Identify which Products, stock records, Orders, document numbers, and external identifiers are shared with Phoca Cart. Preserve durable business keys and assign operational state to the system that will remain authoritative.