EShop puts commerce inside a Joomla website. A merchant can connect Product pages to buying guides, brand content and campaigns through the same menus, modules and language environment.
Running that setup leaves the merchant responsible for hosting, updates, templates and extension compatibility, alongside catalog and Order administration.
Choose the EShop Guide for Your Decision
Use this overview to understand the platform, then follow the question that matters to your project.
| Reader question | Guide | What it covers |
|---|---|---|
| Does EShop suit the intended business? | Fit profiles | Joomla ownership, buying requirements and acceptable adaptations. |
| Which relationships are at risk? | Constraints and risks | Option identity, group treatment, historical evidence and storefront dependencies. |
| What must be ready before execution? | Preparation checklist | Recoverable Source evidence, target decisions and representative samples. |
| Which migration approach fits the required output? | Migration approach | Supported scope, adjustments and execution responsibility. |
| What evidence should reviewers require? | Validation priorities | Usable records, functioning storefront and extension features, reliable integrations and launch decisions. |
| Which execution mistakes need prevention? | Pitfalls and prevention | Recurring failures and practical controls. |
EShop as a Joomla-Native Commerce Platform
EShop follows Joomla's component, module, plugin, menu, template and language environment. The merchant has direct control over hosting, site structure, extension selection and presentation.
EShop stores the commerce records; Joomla supplies the surrounding public pages. A Category can exist in EShop while its route and visibility depend on menu items, aliases, module positions and language associations. Product presentation may use EShop layouts, Joomla template overrides and published modules.
| Platform layer | Primary responsibility | Migration significance |
|---|---|---|
| EShop commerce records | Products, Categories, Manufacturers, Customers, Orders, reviews, coupons, vouchers, and related catalog records | These records form the main data scope and must retain useful relationships. |
| EShop configuration | Tax, currency, checkout fields, shipping, payment, order statuses, emails, layouts, and store settings | These areas determine future behavior and are not equivalent to historical data. |
| Joomla site structure | Menus, modules, aliases, templates, content, language associations, media, and access | These elements determine how the Target Store is reached, displayed, and governed. |
| Extensions and integrations | Payment and shipping plugins, add-ons, external systems, custom fields, and custom code | Their data and behavior require separate ownership and support decisions. |
Use the intended compatible EShop build and enabled plugins when assessing features. Migration coverage still needs qualification for the selected path, fields and relationships.
Catalog and Merchandising Structure
A source field named “color” may drive a purchase choice or simply describe a Product. Establish its use before choosing its destination in EShop.
Catalog meaning and field placement
Options usually hold shopper selections such as size or color. Attributes and custom fields hold specifications or other information according to their definitions. Product tabs can present documentation, attachments or videos. A source custom-field system may contain all of these uses.
Keep the following Product information distinguishable:
- commercial identity, including name, SKU, Manufacturer, status, and category placement;
- sellable choices, including options and option values;
- descriptive information, including attributes, custom fields, tabs, and attachments;
- pricing logic, including regular price, special price, quantity discounts, tax class, or customer-group pricing;
- inventory context, including stock, availability, weight, dimensions, and stock status;
- discovery signals, including images, metadata, reviews, related Products, comparison information, and wish lists.
Map a source variant after identifying its purchase choice, sellable identifier and stock relationship. A specification needs an intentional destination, such as an attribute or suitable custom field, rather than being placed in a general description by default. A brand label may be better represented by a Manufacturer relationship when that supports the required browsing or administration.
Catalog relationships and file access
Nested Categories and Manufacturer records provide browsing structure. Category depth can affect menus, filtering, landing pages and SEO paths; Manufacturer associations can support brand discovery and Product identification.
An option value may carry a price adjustment, SKU component, image or quantity. Those values do not establish an independently stocked combination. The installed model must identify the sellable unit and its inventory owner.
Public Product attachments can serve readers before purchase. Purchased Downloads need the correct file association and buyer-access relationships.
The option and inventory risks cover the consequences of assigning those relationships incorrectly.
Customers, Orders, and Commercial History
Historical records need to remain usable for customer support, reconciliation and reporting. Staff should be able to identify a buyer, review previous purchases, read the selected options and understand how an Order total was formed.
Customer data may include names, email addresses, billing and shipping addresses, groups and custom checkout information. Account authentication and access can also involve a Joomla user; preserve the intended relationship between that identity and the commerce profile.
Order lines identify the Product, chosen options, quantity and price. Totals and related records explain discounts, coupons, vouchers, tax, shipping, payment references, status, comments and address information. Unsupported Source references or extension-owned fields need review against the actual supported Order destination.
Historical continuity and account boundaries
| Historical layer | What continuity means | What it does not configure |
|---|---|---|
| Customers | Recognizable buyer profiles, addresses, groups, and support context | Password behavior, Joomla access rules, or every extension-owned profile field |
| Orders | Readable line items, totals, status, tax, shipping, discounts, and payment context | Future tax calculation, live gateways, shipping plugins, or email workflows |
| Reviews | Product-linked customer feedback where supported | Review moderation policy, display layout, or third-party review services |
| Coupons and vouchers | Relevant promotional records and historical context where supported | Future campaign strategy or every legacy promotion rule |
Where Customer Groups govern native prices, discounts, tax or Product visibility, preserve the membership data and identify the corresponding rules for Target Store configuration. Joomla identity and usable password continuity require their own path-specific account decision.
Checkout, Tax, Shipping, and Payment Operations
EShop offers one-page and guest checkout, configurable and custom checkout fields, tax settings, currencies, shipping methods, payment plugins, notifications, invoices and Order-status handling.
Tax rates may depend on geographic zones. Shipping may use price, item, weight, quantity, postcode, carrier services or custom logic. Regional tax requirements, Customer Groups, several currencies and specialized shipping calculations need to match the intended settings and compatible plugins.
A payment reference on a historical Order can remain readable while the gateway for new Orders still needs its plugin, credentials, regional availability and testing.
Plan checkout fields around current data-collection needs, including custom delivery questions, and agree the required notification, invoice and gateway-specific Order-state behavior.
Storefront, Joomla Content, and Discovery
EShop Products and Categories can appear through component views, menu items, modules, search, filters, Joomla articles or template layouts. EShop layouts and Joomla overrides shape the visual hierarchy and responsive behavior around those records.
Joomla entry points and discovery
Follow a priority Category or Manufacturer page from its menu item and alias to the route, module position and layout that expose it. The resulting page needs the intended metadata, with language setup considered where multilingual content is used.
Discovery also includes comparison, related-Product links and content or SEO paths. Buying guides, brand pages and campaign articles can lead shoppers into the catalog; modules may expose Products, Manufacturers, search or filter tools, checkout entry points and promotional content.
Languages, currencies and search continuity
With the Joomla language environment configured, EShop can hold multilingual commerce content. Product and Category names, metadata and routes need to align with that language setup. Currency switching affects both display and transaction expectations. Source prices identify amounts; current currency records and exchange settings govern how the new store displays and transacts them.
Treat valuable routes as part of SEO and traffic continuity, alongside the catalog relationships they expose.
Extensions, Integrations, and Custom Ownership
Payment and shipping plugins, modules, import tools and integrations extend the store's built-in behavior. Local payment methods, carrier rules and connections to business systems depend on which extensions and custom development are in use.
Extensions that use the data
Check which extensions or integrations still use a custom field before deciding how to retain it. A plugin may write extra Product or Order fields; an import tool may create a structure that differs from manually entered records. An integration can rely on the internal identifier, and a template override may expect a field created by custom code.
Distinguish these ownership domains:
| Dependency type | Typical ownership |
|---|---|
| EShop core data | Supported commerce records and standard relationships |
| EShop configuration | Target-side settings and enabled core behavior |
| Joomla implementation | Menus, modules, templates, access, content, and language setup |
| Third-party extension data | Extension-specific records and relationships |
| External integration data | ERP, accounting, fulfillment, marketing, or reporting identifiers |
| Custom code behavior | Business logic that must be reviewed independently |
A field-retention decision needs a business purpose, a storage destination and an accountable continuing owner. The required workflow must still be able to read or update it after launch.
What Makes Migration Into EShop Distinct
An EShop transfer needs a coordinated plan for the records and the site that uses them. Keep these responsibilities explicit:
-
Commerce records and Joomla pages
Plan the Product and Order data alongside the menus, modules, templates, content and routes required by the customer journey.
-
Historical records and future checkout
Preserve purchased selections and payment references as history, and assign live tax, shipping, gateway and checkout configuration to implementation owners.
-
Extension-owned data and behavior
Identify plugin fields, custom tables and integration identifiers, then agree their transfer destinations and the owners of any behavior that must be implemented separately.
Use the EShop migration landing page to begin checking the actual migration direction and supported scope.
Conclusion
EShop is a candidate for a business that wants commerce inside Joomla and can maintain that combined environment. Confirm that the required catalog choices, buyer treatment, languages and extension dependencies have feasible target representations before agreeing the transfer scope.
Use EShop fit profiles to test that choice against the future store's requirements.
Common Questions
Is EShop a standalone hosted e-commerce platform?
No. EShop is installed as a Joomla extension and operates inside a Joomla website. Hosting, Joomla maintenance, templates, modules, menus, plugins, and related site responsibilities remain part of the merchant's environment.
Are Product options and attributes the same in EShop?
No. Options usually represent shopper selections, while attributes and custom fields can hold descriptive or specification data. Source fields should be classified by business purpose before they are assigned to an EShop structure.
Do migrated Orders configure future checkout behavior?
No. Historical Orders can preserve transaction context, but live tax, payment, shipping, currency, status, and notification behavior depends on Target Store configuration and enabled plugins.
Does Joomla content belong to the EShop catalog?
Not automatically. Joomla articles, menus, modules, and other content can support product discovery and customer education, but they remain separate from core EShop Product and Category records.
Can EShop support multilingual and multicurrency stores?
Yes. EShop supports multilingual content and multiple currencies, but the Target Store still needs coherent Joomla language setup, translated commerce content, currency configuration, routing, and validation.
Are plugin-created fields automatically part of standard migration scope?
No. Third-party or custom extension data must be identified by owner and purpose. Supported fields may be mapped, while nonstandard structures may require separate review and project-specific handling.