Coding standards are a result of conventions designed to produce high-quality code. Adopting certain standards yields better code quality, reduces the time taken to develop, and minimizes maintenance cost. Following coding standards requires knowing the standards in question and meticulously applying it to every aspect of the code that we write.
Magento 2 Request Flow
URLs in Magento have the format of <AreaName>/<ModuleFrontName>/<ControllerName>/<ActionName>
Magento process a URL request by first stripping of the base URL. The first path segment of the remaining URL identifies request area. For example, admin for adminhtml area, and none for frontend area.
After the area name, the URI segment specifies the frontname which defined in related module. For example, in catalog/product/view, catalog is the module frontname, product is the controller folder, and view is the controller class (replacing action in Magento 1).
We use the router class to assign a URL to a corresponding controller and its action. The router’s match method finds a matching controller, which is determined by an incoming request.
Magento 2 Areas
When doing development in Magento, we define which resources are visible and accessible in a given area. We use this area to control behavior that we need for specific area.
For example:
- we want to add some logic using event observer, which will happened customer data is saved by customer, but not when updated from admin page. To achieve this, we will need to define the observer configuration only in frontend area, but not in adminhtml.
- we want to optimize our REST queries by providing only necessary data to answer a REST query, not the entire HTML
Magento is organized into following main areas:
adminhtml: Magento Admin.frontend: Magento Storefront.base: use as a fallback for files absent in adminhtml and frontend areascrontab: Cron.webapi_rest: Web API RESTwebapi_soap: Web API SOAPgraphql: Web API GraphQL
Magento 2 Application Modes
There are 3 modes of Magento application, i.e. default (which is the default mode after install), developer, and production.
Here is the difference between them:
default:
- Not optimized for production
- Symlinks to static view files are published to the
pub/staticdirectory - Errors and exceptions are not shown to the user, as they are logged to the filesystem
- This is the default mode after install, use it if you only want to view and explore Magento. You should avoid using it in development or production environment.
developer- Symlinks to static view files are published to the
pub/staticdirectory - provides verbose logging
- Enables automatic code compilation
- Enables enhance debugging
- Slowest performance
- Symlinks to static view files are published to the
production- Errors and exception are not shown to the user, as they are logged to the filesystem
- Static view files are not materialized, as they are served from the cache only
- Automatic code file compilation is disabled, as new or updated files are not written to the filesystem
- Enabling and disabling the cache types is not possible from Magento admin
- Fastest performance
Magento 2 Architecture Layers
The following diagram illustrates the component of Magento 2, and shows the layers or tiers for all components, as well as the Magento framework, 3rd party libraries, the supported database, and other technologies.
From top to bottom, Magento can be divided into four architectural layers, namely presentation, service, domain, and persistence.
The presentation layer is the one that we directly interact with through the browser. It contains layouts, blocks, templates, and even controllers, which process commands to and from the user interface. Client-side technologies such as jQuery, RequireJS, CSS, and LESS are also a part of this layer. Usually, three types of users interact with this layer, namely web users, system administrators, and those making the Web API calls. Since the Web API calls can be made via HTTP in a manner that is the same as how a user uses a browser, there’s a thin line between the two. While web users and Web API calls consume the presentation layer as it is, the system administrators have the power to change it. This change manifests in the form of setting the active theme and changing the content of the CMS (short for content management system) pages, blocks, and the products themselves.
When the components of a presentation layer are being interacted with, they usually make calls to the underlying service layer.
The service layer is the bridge between the presentation and domain layer. It contains the service contracts, which define the implementation behavior. A service contract is basically a fancy name for a PHP interface. This layer is where we can find the REST/SOAP APIs. Most user interaction on the storefront is routed through the service layer. Similarly, the external applications that make the REST/SOAP API calls also interact with this layer.
When the components of a service layer are being interacted with, they usually make calls to the underlying domain layer.
The domain layer is really the business logic of Magento. This layer is all about generic data objects and models that compose the business logic. The domain layer models themselves do not contribute to data persistence, but they do contain a reference to a resource model that is used to retrieve and persist the data to a MySQL database. A domain layer code from one module can interact with a domain module code from another module via the use of event observers, plugins, and the di.xml definitions. We will look into the details of these later on in other chapters. Given the power of plugins and di.xml, its important to note that this interaction is best established using service contracts (the PHP interface).
When the components of the domain layer are being interacted with, they usually make calls to the underlying persistence layer.
The persistence layer is where the data gets persisted. This layer is in charge of all the CRUD (short for create, read, update, and delete) requests. Magento uses an active record pattern strategy for the persistence layer. The model object contains a resource model that maps an object to one or more database rows. Here, it is important to differentiate the cases of simple resource model and the Entity-Attribute-Value (EAV) resource models. A simple resource model maps to a single table, while the EAV resource models have their attributes spread out over a number of MySQL tables. As an example, the Customer and Catalog resource models use EAV resource models, while the newsletter’s Subscriber resource model uses a simple resource model.
How to make all objects in AWS S3 public by default
1. Go to AWS Policy Generator. Fill the form with these values:
Select Type of Policy : S3 Bucket Policy
Effect: Allow
Principal: *
AWS Service: Amazon S3
Actions: Get Object
Amazon Resource Name (ARN): arn:aws:s3:::leo-bucket/* (change leo-bucket to your bucket name)
2. Click Add Statement
3. Click Generate Policy. A popup will appears, containing JSON Document. Copy the JSON strings.
4. Go to your AWS S3 Console. Click your bucket (in my case, leo-bucket). Click tab Permissions -> Bucket Policy. Paste the JSON that you copied before to the editor.
5. Click Save. Then voila… all of your bucket items are now public by default.
Magento 1 Database Diagram
Magento is well known for its flexibility. And the cost of the flexibility.. is complexity. Magento database, as well as its codebase, is quite complex, and sometimes makes us overwhelmed when start using it.
Thanks to Anna Völkl effort, you can view the DB diagram for Magento 1.9.2.2. This diagram will give you a better picture of database flow and its table relationship.
You can still use it for any later version in Magento, since the structure is almost the same.
Here is the database diagram (click the image to view Full Size).
How to read:
- Catalog: upper left (yellow group)
- Sales: right (blue group)
- EAV and Core stuff: middle (brown & orange groups)
- Customer tables: middle/bottom (green group)
- The rest (salesrules, logs, reports, newsletter, tags, poll, etc.) : bottom
Difference of using $this and $block in Magento 2 template
One new thing I found in Magento 2 is the usage of object $block in phtml template to get the block method, instead of using $this as we did in Magento 1.
Let’s say we have this method getFoo() in our block:
then we can call the method from our template with:
and surely will outpout “here is Foo“.
Now, let’s call the method using object $this:
and… it turns out that its output still the same: “here is Foo“. WHY??
Ubi est tu, Koin Kuno Luxembourg-ku? (Part 2)
Koin Luxembourg keberuntunganku tetap setiap di kantongku, bahkan ke sekolah juga tak pernah lupa kubawa. Meskipun ternyata tidak ada keberuntungan yang spesial kualami setelah mengantonginya, selalu terasa tidak klop jika tidak membawanya. Begitu juga imajinasiku tentang si empunya sebelumnya. Tapi selanjutnya, imajinasi berganti menjadi misteri kecil yang kurahasiakan sendiri.
Beberapa hari setelah menemukan si koin…
Seperti biasa sepulang sekolah, aku harus membantu orangtuaku bekerja di satu-satunya ladang yang kami punyai. Dan di tengah-tengah ladang kopi tersebut terletaklah makam dari Oppung (orangtua dari ayahku). Kami menyebutnya simin, yaitu bangunan makam yang menjadi tempat tulang belulang leluhur, setelah digali dari kuburan tanah sebelumnya. Hal yang pasti bakal dinilai aneh jika terlihat orang lain adalah, aku suka bertingkah seolah roh Oppungku hadir di situ. Aku akan mengajak mereka ngobrol. Tidak lupa aku menceritakan penemuan koinku. Sesekali tidur di samping ruang yang menjadi tempat tulang belulang. Sama sekali tidak ada rasa takut karena aku merasa mereka tidak akan marah. Toh, aku adalah cucu mereka. Tetap saja, barangkali akan lain ceritanya kalau tiba-tiba mereka nongol dan membalas pembicaraanku. Hahaha…
Ubi est tu, Koin Kuno Luxembourg-ku?
Sewaktu masih duduk di bangku sekolah dasar, ada satu kebiasaan kecil yang sering kulakukan, utamanya setiap hari Kamis. Hari Kamis, karena di kampungku nun jauh di Sumatera Utara, tepatnya di pelosok Sihemun Baru, biasanya jadi hari “libur dari bekerja di ladang”, karena bertepatan dengan hari pekan (kami menyebutnya tiga, lokasinya di Sibuntuon).
Kebiasaan kecil itu berupa “bertualang” ke bagian perbatasan kampungku Kampung Baru (sekarang bernama Sihemun Baru), dengan kebun teh Sidamanik. Kebun Teh ini adalah peninggalan Belanda yang dinasionalisasi Indonesia setelah merdeka. Barangkali karena memang terlahir penyendiri dan introvert, saat para abang dan itoku ngumpul dengan para temannya, aku akan pergi sendirian ke arah toruan, ke perbatasan kampung kami dengan tolu pulu sia (sebutan lokal untuk perkebunan Sidamanik blok no. 39). Di perbatasan itulah, ke arah utara akan terbentang lombang (jurang) yang cukup curam. Aku akan duduk di tepi lombang, mendengarkan kicauan burung-burung, jangkrik yang bersahut-sahutan, dan sesekali pekikan gerombolan bodat (monyet) dan juga here (orangutan) yang sedang melintas. Pemandangan itu kulihat di ladang. Di ladang kami dulu, hanya ada pohon kopi robusta dari ujung ke ujung. Berhubung ladang itulah satu-satunya yang dimiliki orangtuaku, cukup menjemukan melihat pemandangan pohon kopi yang itu-itu saja. Hewan yang kelihatan pun palingan anduhur (puyuh), layang-layang (walet), tupai, dan sesekali ular.
Tapi tidak di lombang ini. Banyak jenis pohon yang aku bahkan tidak tahu namanya. Tidak jarang aku melihat jenis burung sebesar merak, dengan bulu warna-warni yang tidak pernah aku lihat di buku-buku sekolah, termasuk di buku berisi gamba-gambar Binatang (yang aku curi) dari kantor sekolah. Paling mendebarkan adalah saat gerombolan monyet itu lewat. Mereka akan menjerit bersahut-sahutan sambil bergelantungan di pohon menuju ke arah dolok. Kalau kebetulan mereka melihat aku duduk, mereka akan diam sebentar menatap aku waspada. Barangkali mereka pikir aku adalah salah satu pemburu monyet atau tupai.