15 min read

In this article by Jérémie Bouchet author of the book Magento Extensions Development. We will see how to handle this aspect of our extension and how it is handled in a complex extension using an EAV table structure.

In this article, we will cover the following topics:

  • The EAV approach
  • Store relation table
  • Translation of template interface texts

(For more resources related to this topic, see here.)

The EAV approach

The EAV structure in Magento is used for complex models, such as customer and product entities. In our extension, if we want to add a new field for our events, we would have to add a new column in the main table. With the EAV structure, each attribute is stored in a separate table depending on its type. For example, catalog_product_entity, catalog_product_entity_varchar and catalog_product_entity_int.

Each row in the subtables has a foreign key reference to the main table. In order to handle multiple store views in this structure, we will add a column for the store ID in the subtables.

Let’s see an example for a product entity, where our main table contains only the main attribute:

The varchar table structure is as follows:

The 70 attribute corresponds to the product name and is linked to our 1 entity.

There is a different product name for the store view, 0 (default) and 2 (in French in this example).

In order to create an EAV model, you will have to extend the right class in your code. You can inspire your development on the existing modules, such as customers or products.

Store relation table

In our extension, we will handle the store views scope by using a relation table. This behavior is also used for the CMS pages or blocks, reviews, ratings, and all the models that are not EAV-based and need to be store views-related.

Creating the new table

The first step is to create the new table to store the new data:

  1. Create the [extension_path]/Setup/UpgradeSchema. php file and add the following code:
    eavSetupFactory = $eavSetupFactory;
        public function upgrade(SchemaSetupInterface $setup, ModuleContextInterface $context)
            if (version_compare($context->getVersion(), '1.3.0', 'startSetup();
                 * Create table 'blackbird_ticketblaster_event_store'
                $table = $installer->getConnection()->newTable(
                    ['nullable' => false, 'primary' => true],
                    'Event ID'
                    ['unsigned' => true, 'nullable' => false, 'primary' => true],
                    'Store ID'
                    $installer->getIdxName('blackbird_ticketblaster_event_store', ['store_id']),
                    $installer->getFkName('blackbird_ticketblaster_event_store', 'event_id', 'blackbird_ticketblaster_event', 'event_id'),
                    $installer->getFkName('blackbird_ticketblaster_event_store', 'store_id', 'store', 'store_id'),
                    'TicketBlaster Event To Store Linkage Table'

    The upgrade method will handle all the necessary updates in our database for our extension. In order to differentiate the update for a different version of the extension, we surround the script with a version_compare() condition.

    Once this code is set, we need to tell Magento that our extension has new database upgrades to process.

  2. Open the [extension_path]/etc/module.xml file and change the version number 1.2.0 to 1.3.0:
  3. In your terminal, run the upgrade by typing the following command:

    php bin/magentosetup:upgrade
    The new table structure now contains two columns: event_id and store_id. This table will store which events are available for store views:

    If you have previously created events, we recommend emptying the existing blackbird_ticketblaster_event table, because they won’t have a default store view and this may trigger an error output.

Adding the new input to the edit form

In order to select the store view for the content, we will need to add the new input to the edit form. Before running this code, you should add a new store view:

Here’s how to do that:

Open the [extension_path]/Block/Adminhtml/Event/Edit/Form.php file and add the following code in the _prepareForm() method, below the last addField() call:

/* Check is single store mode */
        if (!$this->_storeManager->isSingleStoreMode()) {
            $field = $fieldset->addField(
                    'name' => 'stores[]',
                    'label' => __('Store View'),
                    'title' => __('Store View'),
                    'required' => true,
                    'values' => $this->_systemStore->getStoreValuesForForm(false, true)
            $renderer = $this->getLayout()->createBlock(
        } else {
                ['name' => 'stores[]', 'value' => $this->_storeManager->getStore(true)->getId()]

This results in a new multiselect field in the form.

Saving the new data in the new table

Now we have the form and the database table, we have to write the code to save the data from the form:

  1. Open the [extension_path]/Model/Event.php file and add the following method at its end:
         * Receive page store ids
         * @return int[]
        public function getStores()
            return $this->hasData('stores') ? $this->getData('stores') : $this->getData('store_id');
  2. Open the [extension_path]/Model/ResourceModel/Event.php file and replace all the code with the following code:
  3. The afterSave() method is handling our insert queries in the new table. The afterload() and getLoadSelect() methods are handling the new load mode to select the right events.
  4. Your new table is now filled when you save your events; they are also properly loaded when you go back to your edit form.

Showing the store views in the admin grid

In order to inform admin users of the selected store views for one event, we will add a new column in the admin grid:

  1. Open the [extension_path]/Model/ResourceModel/Event/Collection.php file and replace all the code with the following code:
  2. Open the [extention_path]/view/adminhtml/ui_component/ticketblaster_event_listing.xml file and add the following XML instructions before the end of the tag:
    MagentoCmsUiComponentListingColumnCmsOptionsstore_idStore View0
  3. Before the actionsColumn tag, add the new column:
    ui/grid/cells/htmlfalseStore View
  4. You can refresh your grid page and see the new column added at the end.

    Magento remembers the previous column’s order. If you add a new column, it will always be added at the end of the table. You will have to manually reorder them by dragging and dropping them.

Modifying the frontend event list

Our frontend list (/events) is still listing all the events. In order to list only the events available for our current store view, we need to change a file:

  1. Edit the [extension_path]/Block/EventList.php file and replace the code with the following code:
    _storeManager = $storeManager;
            $this->_eventCollectionFactory = $eventCollectionFactory;
            $this->_customerSession = $customerSession;
         * @return BlackbirdTicketBlasterModelResourceModelEventCollection
        public function getEvents()
            if (!$this->hasData('events')) {
                $events = $this->_eventCollectionFactory
                $this->setData('events', $events);
            return $this->getData('events');
         * Return identifiers for produced content
         * @return array
        public function getIdentities()
            return [BlackbirdTicketBlasterModelEvent::CACHE_TAG . '_' . 'list'];
         * Is logged in
         * @return bool
        public function isLoggedIn()
            return $this->_customerSession->isLoggedIn();
  2. Note that we have a new property available and instantiated in our constructor: storeManager. Thanks to this class, we can filter our collection with the store view ID by calling the addStoreFilter() method on our events collection.

Restricting the frontend access by store view

The events will not be listed in our list page if they are not available for the current store view, but they can still be accessed with their direct URL, for example http://[magento_url]/events/view/index/event_id/2.

We will change this to restrict the frontend access by store view:

  1. Open the [extention_path]/Helper/Event.php file and replace the code with the following code:
    _event = $event;
            $this->_storeManager = $storeManager;
            $this->resultPageFactory = $resultPageFactory;
            $this->_customerSession = $customerSession;
         * Return an event from given event id.
         * @param Action $action
         * @param null $eventId
         * @return MagentoFrameworkViewResultPage|bool
        public function prepareResultEvent(Action $action, $eventId = null)
            if ($eventId !== null && $eventId !== $this->_event->getId()) {
                $delimiterPosition = strrpos($eventId, '|');
                if ($delimiterPosition) {
                    $eventId = substr($eventId, 0, $delimiterPosition);
                if (!$this->_event->load($eventId)) {
                    return false;
            if (!$this->_event->getId()) {
                return false;
            /** @var MagentoFrameworkViewResultPage $resultPage */
            $resultPage = $this->resultPageFactory->create();
            // We can add our own custom page handles for layout easily.
            // This will generate a layout handle like: ticketblaster_event_view_id_1
            // giving us a unique handle to target specific event if we wish to.
            $resultPage->addPageLayoutHandles(['id' => $this->_event->getId()]);
            // Magento is event driven after all, lets remember to dispatch our own, to help people
            // who might want to add additional functionality, or filter the events somehow!
                ['event' => $this->_event, 'controller_action' => $action]
            return $resultPage;
  2. The setStoreId() method called on our model will load the model only for the given ID. The events are no longer available through their direct URL if we are not on their available store view.

Translation of template interface texts

In order to translate the texts written directly in the template file, for the interface or in your PHP class, you need to use the __(‘Your text here’) method. Magento looks for a corresponding match within all the translation CSV files.

There is nothing to be declared in XML; you simply have to create a new folder at the root of your module and create the required CSV:

  1. Create the [extension_path]/i18n folder.
  2. Create [extension_path]/i18n/en_US.csv and add the following code:
    "Event time:","Event time:"
    "Please sign in to read more details.","Please sign in to read more details."
    "Read more","Read more"
    Create [extension_path]/i18n/en_US.csv and add the following code:
    "Event time:","Date de l'évènement :"
    "Pleasesign in to read more details.","Merci de vous inscrire pour plus de détails."
    "Read more","Lire la suite"

    The CSV file contains the correspondences between the key used in the code and the value in its final language.

Translation of e-mail templates: creating and translating the e-mails

We will add a new form in the Details page to share the event to a friend. The first step is to declare your e-mail template.

  1. To declare your e-mail template, create a new [extension_path]/etc/email_templates.xml file and add the following code:

    This XML line declares a new template ID, label, file path, module, and area (frontend or adminhtml).

  2. Next, create the corresponding template by creating the [extension_path]/view/adminhtml/email/share_form.html file and add the following code:

    {{trans "Your friend %email is sharing an event with you:" email=$post.email}}

    {{trans "Title: %title" title=$event.title}}
    {{trans "Venue: %venue" venue=$event.venue}}

    {{trans "View the detailed page: %url" url=$event.url}}

    Note that in order to translate texts within the HTML file, we use the trans function, which works like the default PHP printf() function. The function will also use our i18n CSV files to find a match for the text.

    Your e-mail template can also be overridden directly from the backoffice: Marketing | Email templates.

The e-mail template is ready; we will also add the ability to change it in the system configuration and allow users to determine the sender’s e-mail and name:

  1. Create the [extension_path]/etc/adminhtml/system.xml file and add the following code:
    generalBlackbird_TicketBlaster::event validate-email MagentoConfigModelConfigSourceEmailIdentity Email template chosen based on theme fallback when "Default" option is selected.MagentoConfigModelConfigSourceEmailTemplate
  2. Create the [extension_path]/etc/config.xml file and add the following code:

    Thanks to these two files, you can change the configuration for the e-mail template in the Admin panel (Stores | Configuration).

Let’s create our HTML form and the controller that will handle our submission:

  1. Open the existing [extension_path]/view/frontend/templates/view.phtml file and add the following code at the end:

  2. Create the [extension_path]/Controller/View/Share.php file and add the following code:

This controller will get the necessary configuration entirely from the admin and generate the e-mail to be sent.

Testing our code by sending the e-mail

Go to the page of an event and fill in the form we prepared. When you submit it, Magento will send the e-mail immediately.


In this article, we addressed all the main processes that are run for internationalization. We can now create and control the availability of our events with regards to Magento’s stores and translate the contents of our pages and e-mails.

Resources for Article:

Further resources on this subject:

Subscribe to the weekly Packt Hub newsletter. We'll send you the results of our AI Now Survey, featuring data and insights from across the tech landscape.


Please enter your comment!
Please enter your name here