The basic structure of Magento 2.x is much like that of 1.x. Customers interact with a cached and served Website/Store frontend, administrators and store owners interact with a cached and served Admin front-end, and developers/hosts interact with back-end code files, database, and server. In addition to core Magento modules, there may also be paid/free license extensions installed, connections made to external APIs, and sync relationships set up with external business software.
In this article, we will talk about each of these areas to give you a broad overview of how Magento 2 works. Before beginning here, be sure to install Magento using our Environment Setup tutorial.
To have a team of experienced developers guide you through the process, contact us at Ameronix Corporation. Or if you are in the Richmond, Virginia area, stop by our office for a demo.
Storefont Hierarchy
- Websites
By default, Magento will create a single website and store upon installation. However, a single Magento installation can serve as the back-end code and administrative interface for multiple websites, each with a different domain. Each website will contain its own currency, tax classes, shipping methods, payment methods, and checkout cart. If multiple stores are created, the sharing (or exclusivity) of customer bases is a configurable option. Customers can be required to maintain separate logins for each website, or you can choose to let them use one login for all websites. Prices are also configurable in this way. Each website can have unique pricing schemes, or one pricing scheme can be shared between all websites.
- Stores
A Magento website is the parent for one or more stores, so every store within the same website will share the same Admin interface, customer accounts, currency, and prices. Products and Product Categories, however, are managed at the store level, and can be configured per-store. Common uses for multi-store setups include separating Men’s and Women’s products or creating stores for seasonal products.
- Store Views
Each store can contain one or more store views. This level exists primarily for configuring in what language your store’s text will be written. Create a store view, install a language pack from Magento Marketplace, and set your storeview’s Locale to handle the bulk of language translation. Then, if necessary, some inline translation may be required for product names, descriptions, and static blocks.
Store views can also be used to configure anything related to design and theme.
- Themes
An instance of freshly installed Magento 2 comes with two theme options. The most basic option is the “Blank” theme, which will serve very basic storefront pages with white background, Magento logo, and simple grey icons.
The second option is a more modern, developed theme called “Luma”. “Luma” is a bit of an upgrade from Magento 1.x’s “Madison Island” theme. Carousels have changed to tiled image layouts, thumbnail images are larger, and styling is very clean. While “Luma” is a great starting point for a new store, it will still require some work to become functional (e.g. adding your own product data, uploading images, creating Discount Codes to apply at checkout), and it only scratches the surface of what is possible with a custom Magento theme.
Additional themes may be purchased from the Magento Marketplace and installed to your store via Admin Panel > System > Tools > Web Setup Wizard. Or, you can develop your own by extending “Blank” or “Luma”.
Admin Panel
During installation of Magento 2, you will be given a randomly generated admin URL such as “/admin_1d2589”. This URL may be difficult to remember, but is much more secure than Magento 1.x’s generic default “/admin” URL. Type this at the end of your website’s base URL then log in with administrator credentials to reach the Admin Panel. Normal customer credentials will not be successful in logging in here.
The Admin Panel is a Graphical User Interface for configuring the back-end of a Magento 2 installation. This is where you will set up your websites, stores, select themes, add/remove users, add/remove products and categories, configure caching and indexing, add extensions, and view store performance information. Each Magento installation will have only one Admin Panel. When configurations are store- or website-specific, a drop down menu will display for selecting which store or website you would like to configure.
Generally, no knowledge of coding languages or command line are required to use the Admin Panel, but some configuration tasks may require more in-depth knowledge about how Magento works. If you are a developer, however, the Admin Panel can be re-designed, themed, and extended with modules just like the Storefront by changing back-end code.
Back-end Files
When running Magento 2 locally for development, your web root will be the Magento installation root directory. This directory contains all the files and folders related to the website. Many settings that can be changed using either the Admin Panel or CLI commands can alternatively be changed by changing values in back-end files. This file structure can also be manipulated to customize existing modules or develop new modules. It is recommended that back-end files be version controlled during development and backed up frequently while running on a production server.
Note that the file structure changed significantly since Magento 1.x. Core and community code have moved from app/code/ and app/etc/modules to vendor/, skin/ styles are now placed directly in module directories under view/, and a new pub/ directory serves as the webroot for production to protect back-end files from being accessed via the web.
The Magento 2.x root directory contains the following main folders:
- app/etc/
This directory includes configuration files that you may refer to often. Your database connection credentials and Admin Panel URL can be viewed or changed in “env.php”. This file also contains values to turn caching on/off for different cache types, and to toggle the MAGE_MODE between default, production, and developer. To see a list of modules installed in your Magento instance and whether they are enabled or disabled, refer to “config.php”.
- app/code/
This directory is used to house any custom modules developed for your store. The name of each sub-directory is commonly referred to as a “namespace”, and usually reflects the name of the organization that developed the code. This directory can also be used to override core or community modules from vendor/ by placing a matching folder/file structure in app/code.
- app/design/
Similar to app/code for modules, this directory is used to house any custom themes developed for your store, and files used to override core and community themes from /vendor. The name of each sub-directory here is also a “namespace”.
- vendor/
Any packages installed using composer will be located in vendor/. This includes most of the module and theme code installed with Magento, plus the code for any extensions installed using composer.
It is strongly recommended that you never alter code in these directories. One reason for this is that the code could be overwritten when a module updates to a new version. More importantly, vendor/ core code may be needed for certain extensions or modules to function properly, so altering core files can cause unexpected issues. If you need to change a module’s behavior, it is best practice to override the code with your own files in app/code and app/design.
- var/
This folder stores non-essential files like caches, logs, and reports. Its contents can generally be deleted without crashing your store, but keeping caches and preprocessed code will help your pages load more quickly.
- pub/
To improve security, pub/ should be set as the web root once the site is ready for production deployment. It contains publicly accessible files including index.php, cron.php, images, CSS, and javascript, but does not allow access to any other root sub-directories.
- bin/
This directory contains an executable for magento CLI. If you navigate to this directory in command line (or include it in your system PATH), you can execute any of the commands included with Magento, plus any custom CLI commands that you have developed by entering ‘php magento
Database
Connection
In order to use Magento, your installation must connect to a MySQL database. This database can be housed on your local machine or on a server. You should have entered database connection information during the installation of Magento, but if you need to change the connected database or credentials later, they are stored in app/etc/env.php.
Table Prefix
During installation, you were given the option to add a table prefix to your Magento database tables. This setting will add trailing characters to every table name created during the installation process. For example, with a table prefix of “magento_” set, the “admin_user” table would be created as “magento_admin_user”. Adding a table prefix is a security measure that makes it more difficult for malicious users to alter your database, since they would not know what prefix you have used on your tables.
Commonly Used Tables
A fresh Magento database contains over three hundred tables, and one should be wary of manipulating those tables directly. Some tables are linked with foreign keys, and updating single tables or entries on their own can cause those links to break (e.g. store, store_group, and store_website tables). You can view a diagram of all tables and their links for Magento CE 2.1.3 here. A few tables that you may refer to often are as follows:
- core_config_data
Contains the secure/base_url and unsecure/base_url for your stores and websites. You may need to edit these URLs when moving to a new domain, copying a store to your local machine for development, or after changing the security of your domain.
- admin_user
Contains a list of users who may access the Admin Panel. If you are developing on an existing store and the admin user’s password is unknown, you can query this table to change the password as instructed here. You may also want to check this table for unauthorized users if your website has been hacked.
- setup_module (formerly core_resource in Magento 1.x)
Contains a list of all installed modules and their current version. To re-install a module completely, remove its line item from this table, clear your cache, and run “php bin/magento setup:upgrade” from the root directory. Similarly, if you need to re-run an upgrade from one version to another, you can alter the “schema_version” column of this table to reflect the version you would like to upgrade from, clear your cache, then run setup:upgrade. (Note: If the installation or upgrade script that you would like to re-run contains code to create additional database tables, you will also need to delete those tables before re-running the script, otherwise you may get “SQL Error: <table_name> already exists”.)
- cron_schedule
Contains a list of all scheduled and completed cron jobs that have not expired and been cleared from the database. You may need to check the schedule, status, or messages in this table when debugging issues with sync schedules, newsletter distribution, outgoing transactional emails, or other timed processes. It is recommended that your host server be set to run cron.php every 5 minutes, but the cron schedule can be updated manually at any time by navigating to <base_url>/cron.php in your browser.
- customer_entity
Contains a list of all registered customers along with their email addresses, hashed passwords, and birth dates.
- sales_order (formerly sales_flat_order in Magento 1.x)
Contains a list of all sales orders placed in your store along with their status and transaction details.
Next Steps
Now you have been introduced to the major areas of Magento 2 that you will need to become familiar with to get started with a new store. In our next tutorial, Custom Themes, we will show you how to put your best front forward with a customized theme.
