What are code pools?
Magento, in the never ending fight to be as organized and as modular as possible, decided that all code should belong in a different area depending on it’s origin. This means a true separation of all code that belongs to different parties.
This is, of course, nothing new. Many applications separate core code from 3rd party code. In many aspects, Magento is like many other applications. They follow a lot of the practices that many other companies follow. But in case you are wondering what the method to their madness is, (and you will the moment you develop your own Modules), it pays to know where everything lies.
The Three Code Pools
app/code/ folder, you will find three additional folders. They are:
Basically, these three folders all contain Modules that define Magento’s application. But they also separate where those modules came from.
core – This is where the Magento Core Code resides. All native Magento functionality is in this folder.
community – All third party modules reside in this location. Anything you’ve downloaded from Magento Connect or third party sites (should) reside in here.
local – This is all code that is custom to your particular store. This is where all modules that are developed specifically for you reside.
So, how does Magento know where to look? Guess what? It doesn’t.
Magento actually semi-aimlessly searches around until it finds what it’s looking for. Sure it’s got a good starting point set by the module, but it still will search until it absolutely cannot find it.
How does it know the starting point? The module lets it know.
if you look inside of
app/etc/modules/, you will find a whole bunch of xml files. It is in these files that hold the secret of where Magento should start to look.
Do you see it? There is a
node that tells Magento where to look.
But it doesn’t just look there. It will look in all the code pools and then look inside the
lib/ folder just to be safe. You get a hint of this when you look inside how Magento does it.
If you look inside of
app/Mage.php, you will see not only the folders it looks in, but the order it looks in those files. Here is a snippet:
$paths = BP . DS . 'app' . DS . 'code' . DS . 'local';
$paths = BP . DS . 'app' . DS . 'code' . DS . 'community';
$paths = BP . DS . 'app' . DS . 'code' . DS . 'core';
$paths = BP . DS . 'lib';
This order is important. This means that for every single class it’s trying to find, it will first look in local, then community, then core, and at last lib. In that specific order.
This also creates an easy cheat for anyone who catches on and is smart. This means that if you copy the directory structure EXACTLY of what another code pool has, you can override a core or community file in your local file without having to edit the core file directly. This is NOT what you are supposed to do, but alas, people do it anyway.
So why the lib folder? Magento didn’t write everything from scratch. It utilizes a number of libraries to help it do what it needs to do to get things done. It has it’s own library, the Varien library. It also utilizes the Zend Framework. In an effort to stay modular, it decided to keep these files separate instead of integrating them into the core.
Now that you’ve gotten a grasp on how Magento loads it’s files, you now no longer have to wander aimlessly around until you find what your looking for. I hope this “compass” helps you shave a little development time off of your next project.
Until next time!