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.
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/static directory
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/static directory
provides verbose logging
Enables automatic code compilation
Enables enhance debugging
Slowest performance
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
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.
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 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)
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??
Selama proses development, kadang ditemukan kasus di mana kita ingin mengubah hak akses (file permission) file atau folder pada repo lokal, tapi tidak ingin mengubahnya di remote repo.
Misalnya kita ingin mengubah file permission folder bernama log agar writable, dengan mengeset chmod 777. Ternyata saat kita cek git status, folder tersebut akan ditandai sebagai modified.
Untuk mencegah git mengabaikan perubahan hak akses file atau folder, cukup dengan mengetikkan perintah berikut di git shell :
git config core.fileMode false
Sebagaimana tertera pada manual git :
core.fileMode
If false, the executable bit differences between the index and the working tree are ignored; useful on broken filesystems like FAT. See git-update-index(1).
The default is true, except git-clone(1) or git-init(1) will probe and set core.fileMode false if appropriate when the repository is created.
Dengan mengikuti tutorial dari artikel howtogeek, saya mencoba menginstal Android di VirtualBox. Setelah membuat membuat virtual disk untuk Android, dan mengalokasikan storage 10Gb dan RAM 1Gb, saya mencoba booting untuk menginstall Android yang saya download dari sini.
