Penn Elcom Store Structure & Elasticsearch Setup

Store Hierarchy Visualization

The following diagram illustrates the Website, Store Group, and Store View hierarchy provisioned by the Ayko_PennElcom setup patches. Because the UK and EU store groups contain a large number of country-specific store views, the most notable ones are listed to keep the visualization readable.

graph LR Root["Penn Elcom"] --> UK["UK Website"] UK --> UK_Store["Main Website Store"] UK_Store --> UK_D["United Kingdom - Default"] UK_Store --> AD["Andorra"] UK_Store --> AE["United Arab Emirates"] UK_Store --> AL["Albania"] UK_Store --> AR["Argentina"] UK_Store --> OthersUK["60+ other country store views..."] Root --> EU["EU Website"] EU --> EU_Store["EU Store"] EU_Store --> EU_D["Europe - Default"] EU_Store --> DE["Germany - EN/DE"] EU_Store --> NL["Netherlands"] EU_Store --> FR["France - EN/FR"] EU_Store --> ES["Spain - EN/ES"] EU_Store --> OthersEU["25+ other European store views..."] Root --> US["US Website"] US --> US_Store["US Store"] US_Store --> US_EN["US - English - Default"] US_Store --> US_ES["US - Spanish"] US_Store --> MX_EN["Mexico - English"] US_Store --> MX_ES["Mexico - Spanish"] Root --> CA["Canada Website"] CA --> CA_Store["Canada Store"] CA_Store --> CA_EN["Canada - English - Default"] CA_Store --> CA_FR["Canada - French"] Root --> AU["Australia Website"] AU --> AU_Store["Australia Store"] AU_Store --> AU_D["Australia - Default"] AU_Store --> NZ["New Zealand"] Root --> CN["China Website"] CN --> CN_Store["China Store"] CN_Store --> CN_D["China - Default"]

Note: The complete list of over 90 store views can be found in app/code/Ayko/PennElcom/Setup/Patch/Data/CreateWebsitesAndStoresAdditionsDefault.php.

Elasticsearch Index Flattening (Deduplication)

Penn Elcom uses a custom module called Ayko_SmileElasticsuiteIndexDeduplication to handle index flattening across its massive list of store views.

Why is this needed?

Because Penn Elcom operates nearly 100 store views (primarily to handle localized URLs, menus, and country selections), maintaining a separate Elasticsearch index for every single store view would consume an enormous amount of server resources and dramatically slow down the indexing process.

How it works

The Ayko_SmileElasticsuiteIndexDeduplication module allows secondary store views within the same Store Group to share the index of the primary (default) store view.

Configuration: A new configuration option is added at Stores > Configuration > Elasticsuite > Indices Settings > Deduplication.
Plugin Interception: A plugin (IndexSettingsPlugin.php) intercepts the getIndexAliasFromIdentifier() method in Smile\ElasticsuiteCore\Helper\IndexSettings.
Index Flattening Logic:
- The plugin checks if the deduplication setting is enabled for the current store.
- It checks if the current store is the default store for its Store Group (e.g., the UK store view for the Main Website Store).
- If deduplication is enabled and the current store is not the default store, it overrides the Elasticsearch index alias to point to the default store's index.

Example:

If a user runs a search on the Andorra (ad_en) store view (which is an English store), the search request will actually query the United Kingdom (default) store's Elasticsearch index.

This effectively "flattens" the Elasticsearch indices at the Store Group level rather than the Store View level, preventing the need to duplicate identical product catalog data across dozens of indices.

How Translations Work with Deduplication

A crucial part of the deduplication setup is that it only applies to English store views (specifically, stores where the locale is set to en_GB).

A setup patch (ConfigureDeDuplicationConfig.php) automatically disables deduplication for any store view that uses a non-English locale (such as German de_DE, French fr_FR, or Spanish es_ES).

Because deduplication is turned off for translated store views, they each receive their own dedicated Elasticsearch index. This ensures search works correctly in the local language:

English Stores: A user on the "Germany - EN/DE" (English) store view will query the shared default eu_en (English) index.
Translated Stores: A user on the "Germany - German" (de_de) store view will query its own dedicated German Elasticsearch index, which contains fully translated product attributes and search terms, allowing native German search to function perfectly.

Magento Scope Hierarchy Breakdown

To assist with the Algolia onboarding, here is a detailed breakdown of the Magento 2 scope levels and how they are typically used in the Penn Elcom setup.

Level	Description	Usage at Penn Elcom
Global	The highest level in the hierarchy. Contains base settings, core product attributes, and shared configurations that apply universally.	Core catalog definitions (e.g., base SKUs, core attributes), global configuration, and integrations.
Website	Defines the business entity. Contains its own customer base, base currency, and pricing. Customers usually do not share accounts across different websites unless explicitly configured.	Segmented by major global regions (e.g., UK Website, EU Website, US Website, Australia Website). Separate websites allow for different base currencies and dedicated customer bases.
Store (Group)	Sits below the Website level. Primarily used to manage category structures. All Store Views within a Store Group share the same root category.	Used to maintain a single unified catalog structure and category tree for a given website (e.g., "EU Store" holds the root category for all EU nations). This is also the level where Elasticsearch index deduplication is applied.
Store View	The lowest level, used primarily for presentation. Affects the language, visual design, currency display format, and localized content on the frontend.	Highly segmented by specific country and language combinations (e.g., "Germany - EN/DE", "Spain - EN/ES"). Used to control specific URLs, localized translations, and regional selections.