xml . Magento saves the current module's version in a database, and if the database value and the one in the module. xml do not match, it will execute the upgrade code. Dependencies. If one module depends on another, the module.
Overview. The di. xml file configures which dependencies are injected by the object manager. You can also specify sensitive configuration settings using di.
First and foremost, I highly recommend you buy the PDF/E-Book from PHP Architect. It's US$20, but is the only straightforward "Here's how Magento works" resource I've been able to find. I've also started writing Magento tutorials at my own website.
Second, if you have a choice, and aren't an experienced programmer or don't have access to an experienced programmer (ideally in PHP and Java), pick another cart. Magento is well engineered, but it was engineered to be a shopping cart solution that other programmers can build modules on top of. It was not engineered to be easily understood by people who are smart, but aren't programmers.
Third, Magento MVC is very different from the Ruby on Rails, Django, CodeIgniter, CakePHP, etc. MVC model that's popular with PHP developers these days. I think it's based on the Zend model, and the whole thing is very Java OOP-like. There's two controllers you need to be concerned about. The module/frontName controller, and then the MVC controller.
Fourth, the Magento application itself is built using the same module system you'll be using, so poking around the core code is a useful learning tactic. Also, a lot of what you'll be doing with Magento is overriding existing classes. What I'm covering here is creating new functionality, not overriding. Keep this in mind when you're looking at the code samples out there.
I'm going to start with your first question, showing you how to setup a controller/router to respond to a specific URL. This will be a small novel. I might have time later for the model/template related topics, but for now, I don't. I will, however, briefly speak to your SQL question.
Magento uses an EAV database architecture. Whenever possible, try to use the model objects the system provides to get the information you need. I know it's all there in the SQL tables, but it's best not to think of grabbing data using raw SQL queries, or you'll go mad.
Final disclaimer. I've been using Magento for about two or three weeks, so caveat emptor. This is an exercise to get this straight in my head as much as it is to help Stack Overflow.
All additions and customizations to Magento are done through modules. So, the first thing you'll need to do is create a new module. Create an XML file in app/modules
named as follows
cd /path/to/store/app
touch etc/modules/MyCompanyName_HelloWorld.xml
<?xml version="1.0"?>
<config>
<modules>
<MyCompanyName_HelloWorld>
<active>true</active>
<codePool>local</codePool>
</MyCompanyName_HelloWorld>
</modules>
</config>
MyCompanyName is a unique namespace for your modifications, it doesn't have to be your company's name, but that the recommended convention my magento. HelloWorld
is the name of your module.
Now that the module file is in place, we'll need to let Magento know about it (and check our work). In the admin application
Now, we make sure that Magento knows about the module
If you can live with the performance slow down, you might want to turn off the application cache while developing/learning. Nothing is more frustrating then forgetting the clear out the cache and wondering why your changes aren't showing up.
Next, we'll need to setup a directory structure for the module. You won't need all these directories, but there's no harm in setting them all up now.
mkdir -p app/code/local/MyCompanyName/HelloWorld/Block
mkdir -p app/code/local/MyCompanyName/HelloWorld/controllers
mkdir -p app/code/local/MyCompanyName/HelloWorld/Model
mkdir -p app/code/local/MyCompanyName/HelloWorld/Helper
mkdir -p app/code/local/MyCompanyName/HelloWorld/etc
mkdir -p app/code/local/MyCompanyName/HelloWorld/sql
And add a configuration file
touch app/code/local/MyCompanyName/HelloWorld/etc/config.xml
and inside the configuration file, add the following, which is essentially a "blank" configuration.
<?xml version="1.0"?>
<config>
<modules>
<MyCompanyName_HelloWorld>
<version>0.1.0</version>
</MyCompanyName_HelloWorld>
</modules>
</config>
Oversimplifying things, this configuration file will let you tell Magento what code you want to run.
Next, we need to setup the module's routers. This will let the system know that we're handling any URLs in the form of
http://example.com/magento/index.php/helloworld
So, in your configuration file, add the following section.
<config>
<!-- ... -->
<frontend>
<routers>
<!-- the <helloworld> tagname appears to be arbitrary, but by
convention is should match the frontName tag below-->
<helloworld>
<use>standard</use>
<args>
<module>MyCompanyName_HelloWorld</module>
<frontName>helloworld</frontName>
</args>
</helloworld>
</routers>
</frontend>
<!-- ... -->
</config>
What you're saying here is "any URL with the frontName of helloworld ...
http://example.com/magento/index.php/helloworld
should use the frontName controller MyCompanyName_HelloWorld".
So, with the above configuration in place, when you load the helloworld page above, you'll get a 404 page. That's because we haven't created a file for our controller. Let's do that now.
touch app/code/local/MyCompanyName/HelloWorld/controllers/IndexController.php
Now try loading the page. Progress! Instead of a 404, you'll get a PHP/Magento exception
Controller file was loaded but class does not exist
So, open the file we just created, and paste in the following code. The name of the class needs to be based on the name you provided in your router.
<?php
class MyCompanyName_HelloWorld_IndexController extends Mage_Core_Controller_Front_Action{
public function indexAction(){
echo "We're echoing just to show that this is what's called, normally you'd have some kind of redirect going on here";
}
}
What we've just setup is the module/frontName controller.
This is the default controller and the default action of the module.
If you want to add controllers or actions, you have to remember that the tree first part of a Magento URL are immutable they will always go this way http://example.com/magento/index.php/frontName/controllerName/actionName
So if you want to match this url
http://example.com/magento/index.php/helloworld/foo
You will have to have a FooController, which you can do this way :
touch app/code/local/MyCompanyName/HelloWorld/controllers/FooController.php
<?php
class MyCompanyName_HelloWorld_FooController extends Mage_Core_Controller_Front_Action{
public function indexAction(){
echo 'Foo Index Action';
}
public function addAction(){
echo 'Foo add Action';
}
public function deleteAction(){
echo 'Foo delete Action';
}
}
Please note that the default controller IndexController and the default action indexAction can by implicit but have to be explicit if something come after it.
So http://example.com/magento/index.php/helloworld/foo
will match the controller FooController and the action indexAction and NOT the action fooAction of the IndexController. If you want to have a fooAction, in the controller IndexController you then have to call this controller explicitly like this way :
http://example.com/magento/index.php/helloworld/index/foo
because the second part of the url is and will always be the controllerName.
This behaviour is an inheritance of the Zend Framework bundled in Magento.
You should now be able to hit the following URLs and see the results of your echo statements
http://example.com/magento/index.php/helloworld/foo
http://example.com/magento/index.php/helloworld/foo/add
http://example.com/magento/index.php/helloworld/foo/delete
So, that should give you a basic idea on how Magento dispatches to a controller. From here I'd recommended poking at the existing Magento controller classes to see how models and the template/layout system should be used.
I've been wrestling with Magento for the last month or so and I'm still trying to figure it out. So this is a case of the blind leading the blind. There's little in the way of documentation and the forum/wiki is chaotic at best. Not only that, but there are several solutions that are either outdated or far from optimal. I'm not sure if you have a project or just trying to figure it out, but it's probably easier if you started with modifying existing functionality as opposed to creating something completely new. For that I'd definately go with the "Recommended articles for developers" in the wiki. The new payment method one was a real eye-opener.
For debugging I'd definitely recommend using FirePHP and looking at your HTML source when something goes wrong. The ole echo debug method doesn't really work all that well.
The general architecture is so mind-numbingly complex, that even if I completely understood it, I'd need to write a book to cover it. The best I can do is give you advice I wish someone had given me when I first started...
Stay away from core files. Don't modify them, instead write your own module and override what you need.
Magento uses config files consisting of XML to decide what it needs to do. In order to get it to run your own stuff as opposed to core functionality you need the correct xml. Unfortunately there is no guide on how to build you XML; you need to look at examples and do some serious testing. To complicate things the content of these files is largely case-sensitive. However if you master these you can override any part of the basic functionality which makes for a very powerful system.
Magento uses methods like Mage::getModel('mymodel')
, Mage::getSingleton('mysingleton')
, Mage::helper('myhelper')
to return objects of certain classes. It finds these by default in its core namespace. If you want it to use your own, you need to override these in your config.xml
file.
The name of your classes must correspond to the folder they're in.
A lot of the objects in Magento ultimately extend something called a Varien_Object
. This is a general purpose class (kind of like a swiss army knife) and its purpose in life is to allow you to define your own methods/variables on the fly. For example you'll see it used as a glorified array to pass data from one method to another.
During development make sure you caching is disabled. It'll make magento excruciatingly slow, but it'll save you a lot of head trauma (from banging it on your desk).
You'll see $this
being used a lot. It means a different class depending on what file you see it. get_class($this)
is your friend, especially in conjunction with FirePHP.
Jot things down on paper. A lot. There are countless little factoids that you're gonna need 1-2 days after you encounter them.
Magento loves OO. Don't be surprised if tracing a method takes you through 5-10 different classes.
Read the designer's guide here. It's meant mostly for graphics designers, but you need it to understand where and why the output from your module will end up. For that don't forget to turn on "Template path hints" in the developer section of the admin panel.
There's more, but I'll stop here before this turns into a dissertation.
I will rather recommend Mage2Gen, this will help you generate the boilerplate and you can just focus on the core business logic. it just helps speed up the things.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With