All about Magento E-commerce Store.......MagentoForum

Magento: How to get top rated products?

2012-01-08T11:03:00.000+05:30

Here, I will be showing you how to get the top/highest rated product.

The basic idea for getting the top rated products is fetching all products, looping through them, getting ratings of each product and populating a ratings array. After that sort the array and then slice the array for limiting the number of product to display.

Here is the function to get the top rated products:-

/**
 * Get Top Rated Products
 *
 * @return array
 */
public function getTopRatedProduct() { 

 $limit = 5; 

 // get all visible products
 $_products = Mage::getModel('catalog/product')->getCollection();
 $_products->setVisibility(Mage::getSingleton('catalog/product_visibility')->getVisibleInCatalogIds());
 $_products->addAttributeToSelect('*')->addStoreFilter();            

 $_rating = array(); 

 foreach($_products as $_product) {  

  $storeId = Mage::app()->getStore()->getId(); 

  // get ratings for individual product
  $_productRating = Mage::getModel('review/review_summary')
       ->setStoreId($storeId)
       ->load($_product->getId()); 

  $_rating[] = array(
      'rating' => $_productRating['rating_summary'],
      'product' => $_product
     );
 } 

 // sort in descending order of rating
 arsort($_rating); 

 // returning limited number of products and ratings
 return array_slice($_rating, 0, $limit);
}

Now, you can display the products in any template file. Here is the sample code to display the top rated products:-

<!-- I suppose that you have put the getTopRatedProduct() function in helper class of your module -->
<?php $topRatedProducts = $this->helper('yourModule')->getTopRatedProduct();?>

<ul>
<?php foreach($topRatedProducts as $_rating): ?>
 <?php $_product = $_rating['product']; ?>
<li>
 <img src="<?php echo $this->helper('catalog/image')->init($_product, 'small_image')->resize(150); ?>"  alt="<?php echo $this->htmlEscape($this->getImageLabel($_product, 'small_image')) ?>" title="<?php echo $this->htmlEscape($this->getImageLabel($_product, 'small_image')) ?>" />
 <a href="<?php echo $_product->getProductUrl() ?>" title="<?php echo $this->htmlEscape($this->getImageLabel($_product, 'small_image')) ?>">
  <span>View Details</span>
 </a>
</li>
</ul>
<?php endforeach; ?>

Hope this helps.
Thanks.

Magento: How to setup Ogone Payment Method?

2012-01-08T11:02:00.000+05:30

Ogone is one of the leading European Payment Service Providers with more than 28.000 clients across 40 countries.

Ogone is connected through certified links to more than 200 European banks/acquirers that enable handling of international payment methods like Visa, MasterCard, American Express, Diners Club and JCB as well as local ones like iDEAL and Machtigingen in The Netherlands, Solo and Maestro UK in United Kingdom and ELV and giropay in Germany.

For Magento, there is a Ogone Module (community edition extension) released officially by the Magento Core Team.

At present this only supports to Magento CE (Community Edition) version 1.3. It might not support the latest versions of Magento CE. However, Ogone payment method is present by default in Magento EE (Enterprise Edition).

Creating account in Ogone

- Go to Ogone website

- Select your desired country. The country selection list is present in the top header of ogone.com

- Then under ‘Merchant login’, you will find link to login to ‘Production Account’ and ‘Test Account’. You will also find link to ‘Create a Production Account’. In the website, you will also find a button to ‘Create FREE test account’.

Link to Register for Production Account: https://secure.ogone.com/ncol/prod/new_account.asp?BRANDING=ogone&ISP=OBE&SubID=1&SOLPRO=&MODE=STD&ACountry=BE&Lang=1
Note: ACountry=BE (this indicates the country is chosen as ‘Belgium’)

Link to Login to Production Account: https://secure.ogone.com/ncol/prod/frame_ogone.asp?BRANDING=ogone&ISP=OBE&SubID=1&SOLPRO=&MODE=STD&ACountry=BE&Lang=1
Note: ACountry=BE (this indicates the country is chosen as ‘Belgium’)

Link to Register for Test Account: https://secure.ogone.com/ncol/test/new_account.asp?BRANDING=ogone&ISP=OBE&SubID=1&SOLPRO=&MODE=STD&ACountry=BE&Lang=1
Note: ACountry=BE (this indicates the country is chosen as ‘Belgium’)

Link to Login to Test Account: https://secure.ogone.com/ncol/test/frame_ogone.asp?BRANDING=ogone&ISP=OBE&SubID=1&SOLPRO=&MODE=STD&ACountry=BE&Lang=1
Note: ACountry=BE (this indicates the country is chosen as ‘Belgium’)

When you register for Test or Production account, you need to consider the following things:-
- Provide PSPID (this will be required for login)
- Provide valid company email address. Gmail, hotmail, yahoo, etc. email addresses are not valid for Ogone account.

After you submit the registration form, Ogone team will review your data and if everything is okay and valid, then they will email you the login password. They will also email you, if the registration data is invalid.

Making necessary settings in Ogone

Adding Payment Methods

To add payment methods to Ogone, you can click on the ‘Payment methods‘ menu present in left sidebar.

Then, you will see the following page. From here, you can add and edit payment methods present in Ogone.

Adjusting Technical Settings

The other and the most important settings for Ogone payment method is the Technical Setting. You can access the technical settings page by clicking the ‘Technical information‘ menu present in left sidebar.

After that, you go to the technical settings page. The first tab is ‘Global transaction parameters‘ tab. Check if the settings in that page is like the below image.

Click on the image to view full size.

Click the ‘Confirm’ button present in the bottom of this page. Then you will proceed to ‘Global security parameters‘ tab. Check if the settings in your page is similar to the image below.

Click on the image to view full size.

Click the ‘Confirm’ button present in the bottom of this page. Then you will proceed to ‘Payment Page Layout‘ tab. Check if the settings in your page is similar to the image below. You must put your website URL instead of example.com.

Note that your URL might also contain ‘www’ in the beginning like http://www.your-site.com

Click on the image to view full size.

Click the ‘Confirm’ button present in the bottom of this page. Then you will proceed to ‘Data and origin verification‘ tab. Check if the settings in your page is similar to the image below.

Put your website URL instead of example.com.

SHA-IN Pass phrase should be 16 character long consisting alpha-numeric characters. For example: 123456789@abcdef

Click on the image to view full size.

Click the ‘Confirm’ button present in the bottom of this page. Then you will proceed to ‘Transaction Feedback‘ tab. Check if the settings in your page is similar to the image below.

SHA-OUT Pass phrase should be 16 character long consisting alpha-numeric characters. It should be different from SHI-IN Pass phrase. For example: 123456789#abcdef

Click on the image to view full size.

Click the ‘Confirm’ button present in the bottom of this page. Then you will proceed to ‘Transaction e-mails‘ tab. Check if the settings in your page is similar to the image below.

Click on the image to view full size.

Click the ‘Confirm’ button present in the bottom of this page. Then you will proceed to ‘Test Info‘ tab. Check if the settings in your page is similar to the image below.

Click on the image to view full size.

Making necessary settings in Magento Admin

After completing the settings task in Ogone, we need to make changes in the Ogone payment module settings in Magento admin.

Go to: System -> Configuration -> Payment Methods -> Ogone

myPSPID should be your PSPID that you entered while registering in Ogone.

SHA1-IN and SHA1-OUT Signature should be the one which you entered in SHA-IN and SHA-OUT Pass phrase in Ogone settings.

You can adjust the Gateway URL for test account and production account.

Test account Gateway URL: https://secure.ogone.com/ncol/test/orderstandard.asp
Production account Gateway URL: https://secure.ogone.com/ncol/prod/orderstandard.asp

Click on the image to view full size.

Finally, Ogone configuration is completed and now you can use fully functional Ogone Payment method in your Magento shop.

Hope it helps. Thanks.

Magento: Get sub categories and product count

2012-01-08T10:58:00.000+05:30

Here, I will be showing you the code to get sub categories of a particular category and the number of products (product count) present in the sub categories.

Like, I have a category named Furniture. The sub categories under Furniture are Living Room and Bedroom. Now, I want to show the sub categories under Funiture and the products associated with the sub categories (Living Room and Bedroom).

Furniture
- Living Room (4)
- Bedroom (2)

/**
 * get current category
 */
$currCat = Mage::registry('current_category');

/**
 * get sub categories of current category
 */
$collection = Mage::getModel('catalog/category')->getCategories($currCat->getEntityId());

/**
 * looping through sub categories
 * only showing active sub categories ($cat->getIsActive())
 */
foreach($collection as $cat) {
 if($cat->getIsActive()) {
  $category = Mage::getModel('catalog/category')->load($cat->getEntityId());

  /**
   * getting product collection for a particular category
   * applying status and visibility filter to the product collection
     * i.e. only fetching visible and enabled products
     */
  $prodCollection = Mage::getResourceModel('catalog/product_collection')->addCategoryFilter($category);
  Mage::getSingleton('catalog/product_status')->addVisibleFilterToCollection($prodCollection);
  Mage::getSingleton('catalog/product_visibility')->addVisibleInCatalogFilterToCollection($prodCollection);

  ?>

  <a href="<?php echo $category->getUrl() ?>"><?php echo $category->getName() ?></a> (<?php echo $prodCollection->count() ?>)<br/>

  <?php
 }
}

From Mukesh Chapagain's Blog, post Magento: Get sub categories and product count

Magento: How to get all associated children product of a configurable product?

2012-01-08T10:56:00.003+05:30

A configurable product can have multiple other products associated to it.

Here is the code to fetch all the children products that are associated with a configurable product.

Here goes the code :)

/**
 * Load product by product id
 */
$product = Mage::getModel('catalog/product')
     ->load(YOUR_PRODUCT_ID);

/**
 * Get child products id (only ids)
$childIds = Mage::getModel('catalog/product_type_configurable')
     ->getChildrenIds($product->getId());

/**
 * Get children products (all associated children products data)
 */
$childProducts = Mage::getModel('catalog/product_type_configurable')
      ->getUsedProducts(null,$product);

Hope this helps. Thanks.From Mukesh Chapagain's Blog, post Magento: How to get all associated children product of a configurable product?

Magento: Product Edit Warning: Invalid argument supplied for foreach()

2012-01-08T10:55:00.001+05:30

Scenario:

While editing product programatically from frontend. I was trying to change the status of the product with the following code:

Mage::getModel(‘catalog/product’)->load($product->getId())->setStatus(2)->save();

Problem:

Product could not be edited programatically from frontend. The following error message is shown:

Warning: Invalid argument supplied for foreach() in /var/www/magento/app/code/core/Mage/Eav/Model/Entity/Abstract.php on line 937

Solution:

It seems that product updates are only made on the admin side and you have to change the store view while editing product from frontend.

Write the following before you edit product:

Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);

Hence, my new code will be :

Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);
Mage::getModel('catalog/product')->load($item->getProductId())->setStatus(2)->save();

From Mukesh Chapagain's Blog, post Magento: Product Edit Warning: Invalid argument supplied for foreach()

Magento: Reindex Data Programmatically

2012-01-08T10:52:00.002+05:30

This article shows how to reindex Magento Data Programmatically (through code).
You can manually reindex data from System -> Index Management. However, this article is concerned how this can be done through code/programming.

Currently, there are 9 indexes. They are as under (with their respective key number):-

1. Product Attributes
2. Product Prices
3. Catalog URL Rewrites
4. Product Flat Data
5. Category Flat Data
6. Category Products
7. Catalog Search index
8. Tag Aggregation Data
9. Stock Status
So, if you want to reindex “Category Products” only then you can do as follows:-

$process = Mage::getModel('index/process')->load(6);
$process->reindexAll();

If you want to reindex all data then you can loop through these indices and then reindex them:-

for ($i = 1; $i <= 9; $i++) {
    $process = Mage::getModel('index/process')->load($i);
    $process->reindexAll();
}

Hope this helps. Thanks.

Magento: How to get product rating and review?

2012-01-08T10:49:00.002+05:30

Here is the code to get ratings and reviews for any particular product.

/**
 * Getting reviews collection object
 */
$productId = $product->getId();
$reviews = Mage::getModel('review/review')
    ->getResourceCollection()
    ->addStoreFilter(Mage::app()->getStore()->getId())
    ->addEntityFilter('product', $productId)
    ->addStatusFilter(Mage_Review_Model_Review::STATUS_APPROVED)
    ->setDateOrder()
    ->addRateVotes();
/**
 * Getting average of ratings/reviews
 */
$avg = 0;
$ratings = array();
if (count($reviews) > 0) {
 foreach ($reviews->getItems() as $review) {
  foreach( $review->getRatingVotes() as $vote ) {
   $ratings[] = $vote->getPercent();
  }
 }
 $avg = array_sum($ratings)/count($ratings);
}

Displaying the ratings

<!-- REMOVE 'IF CONDITION', TO SHOW RATING IN ALL RATED/UNRATED PRODUCTS -->
<?php if($avg): ?>
 <div class="rating-box" style="float:left;">
  <div class="rating" style="width: <?php echo ceil($avg) ; ?>%;"></div>
 </div>
<?php endif; ?>

Hope this helps. Thanks.

Magento: Show/Hide website to search engines by adjusting robots meta tag

2012-01-08T10:47:00.002+05:30

The Robots META Tag is meant to provide users who cannot upload or control the/robots.txt file at their websites, with a last chance to keep their content out of search engine indexes and services.

<meta name="robots" content="robots-terms">

The content=”robots-terms” is a comma separated list used in the Robots META Tag that may contain one or more of the following keywords without regard to case: noindex, nofollow, all, index and follow.

noindex = Page may not be indexed by a search service.
nofollow = Robots are not to follow links from this page.

You can find more about the robots meta tag over here: http://www.seoconsultants.com/meta-tags/robots/
There is an easy way in Magento to adjust robots meta tags. You can simply choose from admin settings.
Go to System -> Configuration -> Design -> HTML Head -> Default Robots
You have the following options to choose:

- index, follow
- noindex, follow
- index, nofollow
- noindex, nofollow

If you have a live site (production site) then choose ‘index, follow‘. If you have a test site (development site) then choose ‘noindex, nofollow‘.
Hope it helps. Thanks.

Magento: Show/Hide Demo Store Notice

2012-01-08T09:59:00.000+05:30

A demo store is where there are products but the order done by customer is not processed. If your website is in development mode then it is better to enable demo store notice.
Enabling demo store notice in Magento is very simple. You just need to select an option in configuration settings in admin panel.

Go to System -> Configuration -> Design -> HTML Head -> Display Demo Store Notice
By default, it is set as ‘No’. To enable demo store notice, select ‘Yes’.
Now, you will see a notice bar at top of your page saying ‘This is a demo store. Any orders placed through this store will not be honored or fulfilled.‘
Hope it helps. Thanks.

Magento: Redirect Customer to Login page if not logged in

2011-10-11T09:06:00.002+05:30

If you are developing a module which needs to give access
to its content only to logged in user then the preDispatch function will be very useful.
This dispatches event before action.
Just write the following function in your module's controller and customer
log in is checked before each of your controller action.

/**  * Checking if user is logged in or not

* If not logged in then redirect to customer login

*/ public function preDispatch() {

parent::preDispatch();

if (!Mage::getSingleton('customer/session')->authenticate($this)) {

$this->setFlag('', 'no-dispatch', true);  } }

Hope this helps. Thanks.

Magento Development Environment

2011-09-16T22:44:00.005+05:30

Learning Magento can range from frustrating to infuriating for the first time user. Here's a few tips to ease the burden of assimilating an entirely new system.

Turn on Logging

While the Magento Community Edition doesn't have much default logging, it does have a solid logging system in place. Anywhere you can execute PHP in Magento you can do something like

Mage::Log($variable);

Magento will output the contents $variable to a log. Arrays and Objects are auto-expanded and pretty printed, allowing you quickly zoom in on the portion of the data structure you're interested in. I've found using this in combination with Mac OS X's Console.app to be a much smoother experience than dumping objects to the browser, particularly given how often Magento objects store references to a good portion of the system (resulting is large object data dumps).

Logging is turned off by default, to change that

In the Magento Admin, go to System->Configuration

In the left column, click on Developer (under Advanced)

If it's not expanded, Click on Log Settings

Select Yes from the "Enabled" drop down

Click on Save Config

Unfortunately, Magento won't create your log files for you. If they don't exist you'll need to create them yourself. By default, log files are stored at

var/log/system.log var/log/exception.log

If the log folder doesn't exist, create it along with system.log andexception.log. Make sure Apache has write access to both the directory and the files. Check with your system administrator on the best way to do this.

Calls made using Mage::Log will be dropped in system.log. Exceptions will be logged to exception.log

Turn on Developer Mode

If you look in the Magento bootstrap file (index.php) you'll see lines similar to the following

#Mage::setIsDeveloperMode(true); #ini_set('display_errors', 1);

Uncomment these. In a production system, you'd never want to have your errors display to the browser, but while developing having an errors and warnings thrown immediately in your face is invaluable.

Setting the IsDeveloperMode flag is a big time saver. By default, when Magento discovers an exception, it will log the exception to a report and then forward the user to a page that will display that report. This can be infuriating when you're developing, particularly because Magento redirects in such a way that you can't backup to the page you were just on. Setting the developer mode flag results in the Exception output being sent directly to the browser with <pre> formatting.

Logging Magento’s Controller Dispatch

2011-09-16T22:44:00.004+05:30

I'm taking a quick break from the Magento series as I plumb the depth of EAV and get through a crunch phase at The Day Job™. In the selfless interest of helping out the internet and the selfish interest of keeping my front page free of moldy content, I thought I'd pass on a simple Controller dispatch logging patch for Magento. This is mainly useful when you're setting up a new Module and can't figure out why Magento won't see it, or if Magento keeps throwing the CMS 404 page in your face

A Few Caveats

These files are not a true Magento Module. While powerful, creating something like this with Magento's override system would be an order of magnitude harder

Because of the above, I can't make any promises about using this with a anything but Magento version 1.3.2.3

Standard caveats about production servers apply. Use at your own risk, no warranties, etc.

Installing

Take the "Mage" folder (1.3.2.3/Mage) and place it in

app/code/local

so that your directory tree looks like

local/Mage/Core/Controller/Varien/Action.php local/Mage/Core/Controller/Varien/Front.php local/Mage/Core/Controller/Varien/Router/Standard.php local/Mage/Core/Model/App.php

Then, enable logging and you should start seeing messages in your system.log that look something like

2009-09-20T16:55:48+00:00 DEBUG (7): Matching router [standard] = Mage_Core_Controller_Varien_Router_Standard  vs. request 2009-09-20T16:55:48+00:00 DEBUG (7): Module: helloworld 2009-09-20T16:55:48+00:00 DEBUG (7): Found Modules: Array (     [0] => Alanstormdotcom_Helloworld )  2009-09-20T16:55:48+00:00 DEBUG (7): Setting Route Name [helloworld] on request 2009-09-20T16:55:48+00:00 DEBUG (7): Passing request into controller Alanstormdotcom_Helloworld_IndexController 2009-09-20T16:55:48+00:00 DEBUG (7): Setting Module Name to: helloworld at Mage_Core_Controller_Varien_Router_Standard::match(248) 2009-09-20T16:55:48+00:00 DEBUG (7): Setting Controller Name to: index at Mage_Core_Controller_Varien_Router_Standard::match(250) 2009-09-20T16:55:48+00:00 DEBUG (7): Setting Action Name to: index at Mage_Core_Controller_Varien_Router_Standard::match(252) 2009-09-20T16:55:48+00:00 DEBUG (7): Calling dispatch method on Alanstormdotcom_Helloworld_IndexController 2009-09-20T16:55:48+00:00 DEBUG (7): Action Controller: Alanstormdotcom_Helloworld_IndexController dispatching with action [index]

You'll also see a message whenever Magento can't make a Module, Controller, or Action Method match, which is useful when debugging 404 problems.

Magento’s Class Instantiation Abstraction and Autoload

2011-09-16T22:43:00.002+05:30

If you're at all conversant with object oriented programming, the following line should look familiar to you.

$customer_group = new Mage_Customer_Model_Group();

We're instantiating an instance of the Mage_Customer_Model_Group class. However, if you were to search the Magento codebase forMage_Customer_Model_Group, you'd never find a single expression that looks anything like the one above. You would, however, see a lot code that looks something like this

$customer_group = Mage::getModel('customer/address');

By the end of this article, you'll understand the how and why of instantiating classes in Magento, as well as how to include custom Models, Helpers, and Blocks in your own modules.

PHP Autoload

Before we get into the nitty gritty of Magento's class instantiation abstraction, we need to spend a minute or two talking about PHP include files.

Prior to version 5, PHP didn't offer much guidance on how project files should be structured. PHP has a simple concept of including or requiring a file. You pass the include or require statement a string that contains a path to another PHP file

include('/path/to/file.php');

and PHP acts as though the code in file.php was part of your main program. There's no automatic namespacing, linking, packaging or any attempt to reconcile the context of the included files.

Over the years this has led every PHP shop and project to develop their own conventions as to how their base system/library code should be included. If two headstrong developers have a difference of opinion on how this should be accomplished, the resulting codebase quickly becomes a rat's nest of redundant includes and requires.

While PHP still doesn't enforce any particular strategy, PHP 5 introduced the concept of autoloading your class files. Developers can create an autoload function that will be called whenever an undefined classes is referenced anywhere in the codebase, with a single argument of the referenced class name.

For example, consider the following simple autoload function

function __autoload($class_name){     require('lib/'.strToLower($class_name).'.class.php'); }

The team that uses this function stores all its classes in a directory structure that looks something like this

lib/customer.class.php lib/email.class.php

While not suitable for every project, if used judiciously the autoload concept frees developers from having to care about when and where they include their class files, as well as enforcing/encouraging a consistent naming convention.

Magento Autoload

As you'd imagine, Magento's module system leverages the autoload feature heavily. While tricky to master, once you understand the naming convention, you'll know exactly where to find any Magento class is, as well as know where to place your own classes.

You can split all Magento classes into four parts that we'll call Namespace, Module Name, Class Type, and Name. Consider the The class mentioned above

Mage_Customer_Model_Group Namespace_ModuleName_ClassType_Name

Namespace: A classes's namespace lets you know who's responsible for creation and maintain of the class, and helps prevent name collisions between modules. All Magento core modules use the Mage namespace, and the recommended convention is to use a version of your company name for your own modules.
ModuleName: All customization of Magento is done through modules, which are a collection of source code and config files that can be loaded into the Magento system. In the example above, the ModuleName is Customer.
Class Type: Without getting into too much detail, there are several broad categories of classes in Magento, including Model, Singleton, Helper, and Block.
Name: Finally, each class should have a unique name that describes its intended use or function. In the above example, this is Group.

Directory Structure

PHP source files for modules are stored in the app folder. Magento core files are stored separately from local files

//base for core files app/code/core  //base for your custom and downloaded modules app/code/local

There's also a legacy folder named community. You can safely ignore this folder. Varian's current recommendation is that all non-core modules be stored in the local folder.

So, Magento's autoload uses the above parts to determine where you'll find the source for a given class. Starting with the appropriate base folder, source code can be found in the file at

Namespace/ModuleName/ClassType/Name.php

So, the class Mage_Customer_Model_Group may be found in the following folder

app/code/core/Mage/Customer/Model/Group.php

A custom class named Companyname_RoiMagic_Helper_Moneymaker would be found in

app/code/local/Companyname/RoiMagic/Helper/Moneymaker.php

So, you may be wondering what to do with a class like this

Mage_Customer_Model_Address_Config

Magento separates the class name into the same sections, so the class's "Name" is considered to be Address_Config. However, you will NOT find this class at the following location

//not here app/code/core/Mage/Customer/Model/Address_Config.php

Instead, underscores in a name tell Magento to go looking for the class in sub-directories, meaning you'd find this source file at

app/code/core/Mage/Customer/Model/Address/Config.php

Abstracting Away Class Instantiation

So, we now know the basic naming convention for a Magento class, but we're still left with this mystery

$customer_group = Mage::getModel('customer/address');

It's always important to remember that Magento is more than an application, it's a programatic system. Whenever they're creating a new system, engineers are always looking for things to abstract away. With Magento, the Varian engineers have abstracted away the declaration of classes into a series of static "get" method on the global Mage object.

The line of code above is saying, in effect

Give me an instance of the Address Model for the conceptof a customer address

Let the word concept percolate in the back of your brain for a bit because we need to take another side trip, this time into the world of config files

Magento Config Files

Every Magento module has a file named config.xml, located in the module's etc folder. When the Magento system loads a request, all of these config files are merged into one large XML tree.

When you call the various Mage::getModel, Mage::getSingleton, Mage::getBlockSingleton or Mage::getHelper, you're telling Magento

"Hey, go look in your config tree and tell me what class I should be instantiating for this URI"

The URI is the path-like string you're passing into these methods. Consider the following method call and config fragment.

$customer_group = Mage::getModel('customer/address' ) <config>     <!-- ... -->     <global>         <models>             <customer>                 <class>Mage_Customer_Model</class>                 <resourceModel>customer_entity</resourceModel>             </customer>             <!-- ... -->         </models>     </global>     <!-- ... --> </config>

When you call getModel, you're telling Magento to look in the globals/models section of the config file. Then, the first section of the URI tells Magento which child of <models> it should be looking at. In this case that's customer (customer/address). The <class> node will then give us the base name for our class.

The second section of the URI is used to complete the class name. In this example it is not used to look up anything in the XML config (see rewrite below for an example of where the opposite is true). So in our example, that's address (customer/address), giving us a final class name of

Mage_Customer_Model_Address

Here's another example. Consider the following getModel call

Mage::getModel('dataflow/batch_export')

We look in the <models> block of our merged config for a node called dataflow, and we find

<dataflow>     <class>Mage_Dataflow_Model</class>     <resourceModel>dataflow_mysql4</resourceModel> </dataflow>

That gives us a base class name of Mage_Dataflow_Model, which we combine with the second portion of the URI to get a final class name of

Mage_Dataflow_Model_Batch_Export

With your Own Modules

So far we've only used getModel with the core Mage modules. However, the same concept applies to your own modules, which is why most Magento tutorials recommend you setup a default <models>, <blocks>, and <helpers> section

The following module config

<global>      <models>          <roimagic>              <class>Companyname_RoiMagic_Model</class>          </roimagic>      </models>  </global>

would allow you instantiate an instance of Company_Roimagic_Model_Spamusing

Mage::getModel('roimagic/spam');

High Concept

So, that's a lot of take in. This last bit is the most mind bending of the lot, and the part that makes all this effort worth it. Earlier we talked about the concept of a customer address. With regular class instantiation abstracted away, we're now free to override (if you went to college before 1999) or monkey-patch (if you went to college after 1999) your Magento system.

Overriding base Magento classes is one of the primary ways you extend Magento. While Magento has an event system for you to hook into, there's no way the Varian engineers can know what events you might need.

By building an override mechanism into their system, there's no part of Magento's Models, Helpers or Blocks you can't modify if you need to.

Consider the Magento shopping cart class

//getSingleton is identical to getModel, except it ensures only //one instance of the class is ever created.  i.e. any Magento model //may be treated as a singleton     class Mage_Checkout_Model_Cart $cart = Mage::getSingleton('checkout/cart');

Magento has a basic concept of what a cart is, but your concept might differ. Let's say the folks we're building our RoiMagic module for are paranoid about people changing their mind, so they want to log each and every item that gets removed from the cart.

The Cart Model has a method named removeItem. What we're setting out to do is

Create a new model that will extend the Mage_Checkout_Model_Cartclass, but redefine the removeItem method to include our customer logic (while still maintaining previous behavior)

Tell Magento we want to override the standard customer model with our own

So, first thing we'll do is create a file and stub for our new class calledCompanyname_RoiMagic_Model_Cart

touch app/code/local/Companyname/RoiMagic/Models/Cart.php  #paste the following code inside Cart.php class Companyname_RoiMagic_Model_Cart extends Mage_Checkout_Model_Cart{}

Next, we'll add the new method to our class. This is standard class inheritance at work.

class Companyname_RoiMagic_Model_Cart extends Mage_Checkout_Model_Cart{     public function removeItem($itemId){         Mage::Log('Item '.$itemId.' was removed from the cart');         return parent::removeItem($itemId);     } }

Notice we're returning the results of a call to our parent. This leaves the previous behavior completely unchanged, but still lets us throw in some extra logging. As a general rule, unless you're intimately familiar with the behavior of the Magento system, you should always attempt to maintain the standard behavior with calls back to the parent method.

So, with our new class in place, the last step is to tell Magento to use our class. When Magento modules want to get an instance of the shopping cart, the call that's used is

Mage::getSingleton('checkout/cart');

As a reminder, the getSingleton method is identical to the getModel method, except that Magento will instantiate the model once, and then cache the results for later retrieval. What we're concerned about here in the URI of checkout/cart. That means Magento will be looking in the merged config for a node at

<global>     <models>         <checkout>             <!-- ... -->

So, as part of our module's config, we'll want to add a checkout section that contains our rewrite rule

<global>     <models>         <!-- standard model section -->         <roimagic>             <class>Companyname_RoiMagic_Model</class>         </roimagic>         <!-- new checkout section -->         <checkout>             <rewrite>                                <cart>Companyname_RoiMagic_Model_Cart</cart>             </rewrite>         </checkout>     </models> </global>

So, the <checkout> node is the name of the core Magento module we're overriding, or the first part of the URI from the call to Mage::getSingleton('checkout/cart').

The <rewrite> node lets Magento know we want to override something in the default customer module. Remember, Magento merges all the config files together, so it's seeing something more like

<checkout>     <class>Mage_Checkout_Model</class>     <resourceModel>checkout_mysql4</resourceModel>               <rewrite>                        <cart>Companyname_RoiMagic_Model_Cart</cart>     </rewrite> </checkout>

The presence of the <rewrite> node lets Magento know it shouldn't assume the class you want is Mage_Checkout_Model_Cart. First it looks at the second part of the URI Mage::getSingleton('checkout/cart') and looks for a node with that name in the <rewrite> section. If it finds one, it will use the value found there to instantiate the class. In this case, that's Companyname_RoiMagic_Model_Cart

Wrap-up

Magento is hard, but not impossible. The majority of its difficulty comes from the lack of core-documentation, and a plethora of "give a man a fish" style tutorials. As arbitrary and counter-intuitive as many of the rules seem, there is a logic and a design to the system. Once you understand that logic, you'll have one of the most customizable, powerful e-commerce systems at your command.

clearing the Magento Cache

2011-09-16T22:42:00.002+05:30

Just another quick Magento tip as I continue my journey back into the swamps of e-commerce.

Magneto's admin console has a section for managing your cache
(System->Cache Management) which works well, unless you happen to get a bad configuration cached that crashes the system or renders the admin inaccessible.

When that's happened to me I've been able to completely delete the cache folder, and Magento is smart enough to recreate it on the fly

rm -rf var/cache/mage-*

This will zap all your cached values and allow you to fix whatever it is you broke.

Magento Configuration Lint

2011-09-16T22:41:00.002+05:30

The biggest challenge for Ruby and PHP web developers coming to Magento is having to deal with individual module configuration. This is an integral part of of Magento that won't ever go away, but I think there's huge steps we can take to make Magento's configuration less painful for newcomers.

The System you Have

Convention over Configuration is an old industry war, with an unsteady ceasefire in place between the combatants. Each side agrees to treat the other with silent contempt. I don't want to go anywhere near a debate that radioactive, but here's the problem I think we can solve.

Magento's system is, for better or worse, configuration based. Before you can start writing interesting code you need to write a bunch of boring code (XML) to create the framework for your code to live in. In addition to bringing a different set of assumptions to the table, Magento's configuration files are also deeply nested and not always intuitive. Some nodes have contextual importance and others do not. There's probably a handful of people on the planet who know which ones are which. To make matters worse, a partially misconfigured system will run code — until it won't. This can lead to the incredibly frustrating situation where a developer who's learning the system isn't sure if the problem is their own code or if they've misconfigured something.

The end result is a cliff of a learning curve that most time-strapped developers don't have time to climb. Worse, with so much negative feedback early in the learning process, they never get into that groove where they really start learning to work with the system instead of against it.

I don't want to pick a side in the Convention vs. Configuration fight. I want to make Magento's configuration process less confusing for newcomers.

What's a Lint?

The generic term lint comes from a program of the same name. What the original lint program did was scan C code for things that weren't technically wrong (they'd compile), but were likely not what the original programmer had in mind. The combination of C's terse semantics and raw power led to countless situations where a simple typo or failure to think through a function could lead to subtle memory errors that took days to track down. The lint program scans your code and looks for common errors that still compile. This is sometimes called static analysis.

To web developers (or at least those web developers paying attention) the most well known lint like program is Douglas Crockford's JSLint. JSLint lint scans Javascript code for things Doug thinks will lead to errors and/or misunderstood programs. Javascript has some quirks (attempts by the interpreter to "guess" where you wanted a semicolon, scoping issues with for, etc.) that can lead to subtle and hard to track down bugs. JSLint calls these out right away. Again, JSLint will call out code that is valid and will run, but it's code that may lead to confusing bugs or behavior.

Magento's configuration system suffers from the same problem. It's very powerful, but confusing to newcomers. Even those familiar with it can make a quick slip of the fingers leading, once again, to hard to track down bugs. This is why we need a Configuration Lint, and this is why I've built a new system for creating Lint Cases.

How Configlint Works

There are two Magento modules in the Github Project. The first, Configviewer, is the system that contains the lint runner as well as a few sample Lint Cases. The second, Linttemplate, is a module with several empty Lint Cases (some passing, some failing) that you can use to start writing new cases right away.

To get started, let's download and install both the Configviewer and Linttemplate module I prepared for this tutorial. If you're new here and are unsure on how to install modules, I'd recommend some remedial reading.

Running The Configlint

If you've loaded up both modules, head over to the following URL

http://example.com/configlint/

This URL is calling the Configviewer's IndexController, which contains all the code you need to run your Lint Cases.

File: app/code/local/Alanstormdotcom/Configlint/controllers/IndexController.php  class Alanstormdotcom_Configlint_IndexController extends Mage_Core_Controller_Front_Action {     public function indexAction()     {         $helper = Mage::helper('configlint/runner')         ->runLints()         ->report();     }        }

Running the above should net you at least three failures. You may see more, depending on the state of your other modules.

* Class [Alanstormdotcom_Linttemplate_model] does not have proper casing. Each_Word_Must_Be_Leading_Cased. FAILED: Alanstormdotcom_Configlint_Helper_Lints_Xmlstructure::lintClassCase at 111 * FAILED: Alanstormdotcom_Linttemplate_Helper_Lints_Example::lintFailure at 6 * I failed at 31 in Alanstormdotcom_Linttemplate_Helper_Lints_Example::lintFailureWithCustomErrors FAILED: Alanstormdotcom_Linttemplate_Helper_Lints_Example::lintFailureWithCustomErrors at 11

Let's take a look at what it takes to write a Lint Case.

Writing Config Lints

Take a look at the following file

app/code/local/Alanstormdotcom/Linttemplate/Helper/Lints/Example.php

Inside you'll find a Lint Case

class Alanstormdotcom_Linttemplate_Helper_Lints_Example extends Alanstormdotcom_Configlint_Helper_Lints_Abstract {            public function lintFailure($config)     {         $this->fail();     }      public function lintFailureWithCustomErrors($config)     {         $this->fail('I failed at ' . __LINE__ . ' in ' . __METHOD__);     }      public function lintPass()     {         //the lack of a call to fail indicates we passed     }        }

Lint tests are Magento Helper classes that extend the Abstract class

Alanstormdotcom_Configlint_Helper_Lints_Abstract

As of right now there are no abstract methods you'll need to implement, but that may change in future versions.

Th Lint Runner will scan each Lint Case for a public function that starts with the word lint. These functions will automatically be called, and will also be passed an instance of a Magento Config object. Then, the programmer creating the Lint Case will programatically examine the passed in configuration for anything that looks fishy. If a fishy state is detected, the "fail" method should be called

$this->fail();

This signals to the Lint runner that the config has a suspicious construct. Let's comment that out

public function lintFailure($config) {     //$this->fail(); }

and reload our test runner page

http://example.com/configlint/

you'll see you have one less failure to worry about.

* Class [Alanstormdotcom_Linttemplate_model] does not have proper casing. Each_Word_Must_Be_Leading_Cased. FAILED: Alanstormdotcom_Configlint_Helper_Lints_Xmlstructure::lintClassCase at 111 * I failed at 31 in Alanstormdotcom_Linttemplate_Helper_Lints_Example::lintFailureWithCustomErrors FAILED: Alanstormdotcom_Linttemplate_Helper_Lints_Example::lintFailureWithCustomErrors at 11

Turning Lints On and Off

This is Magento, so we're not going to get by without some configuration. Take a look at the following file

File: app/code/local/Alanstormdotcom/Linttemplate/etc/configlints.xml <config>     <lints>     <unique_identifier>         <helper_class>linttemplate/lints_example</helper_class>     </unique_identifier>              <unique_identifier_2>         <helper_class>linttemplate/lints_codepoolcase</helper_class>     </unique_identifier_2>           </lints> </config>

This config file tells us which classes in our module are Lint Cases and should be scanned. You can specify multiple classes, but each will need it's own <unique_identifier>

    <lints>         <unique_identifier>             <helper_class>linttemplate/lints_example</helper_class>         </unique_identifier>                 <unique_identifier_2>             <helper_class>linttemplate/lints_codepoolcase</helper_class>         </unique_identifier_2>           <foo_bar_bar>             <helper_class>linttemplate/lints_another</helper_class>         </foo_bar_bar>           </lints>

The <unique_identifier> and <foo_bar_bar> are unique, arbitrarily named nodes. This is a byproduct of the way Magento loads it's configuration files. Each node needs to have a unique name, but the node names don't tell the system anything.

The value in <helper_class /> is the URI/Grouped Class Name for a Helper class. Quick review of Grouped Class Names: The following URI

linttemplate/lints_example

translates as

The linttemplate value is used to lookup the Namespace/Module name ofAlanstormdotcom_Linttemplate

Because it's a helper class, the type is added to make Alanstormdotcom_Linttemplate_Helper

Finally, the second portion of the URI is added and we end up withAlanstormdotcom_Linttemplate_Helper_Lints_Example

The __autoload dictates that Alanstormdotcom/Linetemplate/Helpers/Lints/Example.php be included to load the class.

Let's comment this out to turn off the Lint Cases for this module

<!--      <unique_identifier>         <helper_class>linttemplate/lints_example</helper_class>     </unique_identifier>         -->

If we reload our page there should only be one failure left

*  Class [Alanstormdotcom_Linttemplate_model] does not have proper casing. Each_Word_Must_Be_Leading_Cased. FAILED: Alanstormdotcom_Configlint_Helper_Lints_Xmlstructure::lintClassCase at 111

This failure is coming from one of the default Lint Cases that ships with the Configlint module (not theLinttemplate module we've been working with). The configlint/lints_xmlstructure lint looks for classes in the config that have incorrect casing. In this case, it found one

Alanstormdotcom_Linttemplate_model

To save you your acking, this model is in the Linttemplate. Open up

File: app/code/local/Alanstormdotcom/Linttemplate/etc/config.xml

and change

<class>Alanstormdotcom_Linttemplate_model</class>

to use the correct casing (Model, not model)

<class>Alanstormdotcom_Linttemplate_Model</class>

If you clear your Magento cache (for the config change) and reload your test page, the last error should be gone. If the other modules in your system pass the existing lints, you should see a message something like this

All Passed 5 Lint Cases passed

Let's take a look at that default Line Case that caught this error, it's at

File: app/code/local/Alanstormdotcom/Configlint/Helper/Lints/Xmlstructure.php class Alanstormdotcom_Configlint_Helper_Lints_Xmlstructure extends Alanstormdotcom_Configlint_Helper_Lints_Abstract {                protected function setWhichConfig()     {         return 'config.xml';     }         /**     * Tests that all the expected top level xml nodes are in place     *     * Doesn't impose that only nodes xyz be in place, it just makes sure     * the known nodes ARE there     */           public function lintTestTopLevel($config)     {         $expected_top   = array('modules','global','frontend','adminhtml','install','default','stores','admin','websites','crontab');         $xml = simplexml_load_string($config->asXML());         $found_top      = array();         foreach($xml as $item)         {             $found_top[] = $item->getName();         }          //if one of the expected modules is missing, fail         foreach($expected_top as $node)         {             if(!in_array($node, $found_top))             {                 $this->fail('Could not find [&lt;' . $node . '/&gt;] at the top level. (in ' .                  __METHOD__ . ' near line ' .                 __LINE__ .                  ')');             }         }     }         /**     * Classes in configs should be one of four types,     * Models, Controllers, Blocks, Helpers     */     public function lintClassType($config)     {         $allowed = array('controller','model','block','helper');         $nodes = $config->xPath('//class');              $errors = array();         foreach($nodes as $node)         {             $str_node = (string) $node;             if(strpos($str_node, '/') === false && strpos($str_node, '_') !== false)             {                 $parts = preg_split('{_}',$str_node,4);                                  if(array_key_exists(2, $parts) && !in_array(strToLower($parts[2]), $allowed))                 {                                $errors[] = "Invaid Type [$parts[2]] detected in class [$str_node]";                 }             }         }         if(count($errors) >0)         {             $this->fail(implode("\n", $errors));         }      }      /**     * Tests that all classes are cased properly.       *            * This helps avoid __autoload problems when working      * locally on a case insensatie system     */           public function lintClassCase($config)     {         $nodes = $config->xPath('//class');                  $errors = array();         foreach($nodes as $node)         {             $str_node = (string) $node;             if(strpos($str_node, '/') !== false)             {                 if($str_node != strToLower($str_node))                 {                     $errors[] = 'URI ['.$str_node.'] must be all lowercase;';                  }             }             else if(strpos($str_node, '_') !== false)             {                 $parts = preg_split('{_}',$str_node,4);                 foreach($parts as $part)                 {                     if(ucwords($part) != $part)                     {                         $errors[] = "Class [$str_node] does not have proper casing. Each_Word_Must_Be_Leading_Cased.";                     }                 }             }             else             {                 $errors[] = 'Class ['.$str_node.'] doesn\'t loook like a class';              }         }          if(count($errors) > 0)         {             $this->fail(implode("\n", $errors));         }     } }

If you take a look at the methods in this class, you can see how an actual Lint Cast might work. Each method in the class will be automatically passed a Magento Config Object, and tests/checks can be run against it.

Wrapup and Three Ways You can Help

This is where I need your help. Right now I've shipped with a few simple Lint Cases and I'll be writing additional ones, but the more common misconfigurations we capture the more useful this tool is. I need your help, here's what you can do

Download the Module and use it. Keep checking back for updates to the default Lint Cases. Let me know if the cases are catching configurations you feel are valid.

Write new cases and let me know about them. Got a configuration situation that's always biting you? Capture it in a Lint Case and never let it happen again.

Don't feel up to writing a Lint Case? Describe your situation in words so someone else can write the case for you! I've setup a Stackoverflow Community Wiki question for tracking your misconfigurations.

Know git? Get in touch, because I'm running the project off GitHub to force my cranky old man self to learn a DVCS, and I'll probably have questions as this this takes off.

Right now the framework for running Lint Cases is simple and not as abstract/robust as some of you might like. However, a more sophisticated Lint Runner and Reporting Engine can come later and we'll still be able to understand the tests we're writing now.

If you've found my tutorials at all useful I urge you to get involved with this project. Both for the altruistic reasons (helping people is good) and selfish ones (helping yourself is really good).

Generated Magento Model Code

2011-09-16T22:40:00.002+05:30

This is a quick one for advanced users, and was inspired by a recent question I answered over at StackOverflow.

One of the nice things about a well abstracted system like Magento is the opportunities it presents for meta-programming. Drop the following code in a controller action (yes, you can define an inner function in PHP)

function someAction() {         header('Content-Type: text/plain');         $coupon = Mage::getModel('salesrule/rule')->load(1);                  function outputValue($value)         {             switch(gettype($value))             {                 case 'string':                     echo "'".str_replace("'","\\'",$value)."'";                     break;                 case 'array':                     echo "array(";                     foreach($value as $v)                     {                         outputValue($v);                         echo ",";                     }                     echo ")";                     break;                 case 'NULL':                     echo 'NULL';                     break;                 default:                     echo "'can\'t handle ".gettype($value)."'";             }          }                 echo '$model';         foreach($coupon->getData() as $key=>$value)         {               echo '->set';             echo str_replace(' ', '',ucwords(str_replace('_', ' ', $key)));             echo '(';              outputValue($value);                         echo ')';             echo "\n";         }          exit; }

Run this code and you'll get some auto-generated code for the creation/updating of a Magentosalesrule/rule Model (assuming you have a Model with an id of 1)

$model->setRuleId('1') ->setName('test') ->setDescription('') ->setFromDate('2010-05-09') ->setToDate(NULL) ->setCouponCode('') ->setUsesPerCoupon('0') ->setUsesPerCustomer('0') ->setCustomerGroupIds(array('1',)) ->setIsActive('1') ->setConditionsSerialized('a:6:{s:4:"type";s:32:"salesrule/rule_condition_combine";s:9:"attribute";N;s:8:"operator";N;s:5:"value";s:1:"1";s:18:"is_value_processed";N;s:10:"aggregator";s:3:"all";}') ->setActionsSerialized('a:6:{s:4:"type";s:40:"salesrule/rule_condition_product_combine";s:9:"attribute";N;s:8:"operator";N;s:5:"value";s:1:"1";s:18:"is_value_processed";N;s:10:"aggregator";s:3:"all";}') ->setStopRulesProcessing('0') ->setIsAdvanced('1') ->setProductIds('') ->setSortOrder('0') ->setSimpleAction('by_percent') ->setDiscountAmount('10.0000') ->setDiscountQty(NULL) ->setDiscountStep('0') ->setSimpleFreeShipping('0') ->setApplyToShipping('0') ->setTimesUsed('0') ->setIsRss('1') ->setWebsiteIds(array('1',))

Magento Connect Role Directories

2011-09-16T22:39:00.002+05:30

This is less a full fledged article this time, and more "something I always forget and can never find anywhere else, so I'm posting it here to help future me".

When you're packaging up a Magento Extension for distribution through Magento Connect

System -> Magento Connect -> Package Extensions

You need to create a list of Roles and Path pairs

The first time you do this, it's not entirely obvious what a Role or a Path is. If you expand the Role drop-down, you get a list of different file types.

A Role defines (and labels) a certain sub-directory in your Magento install. The following Role/file-path pairs were valid for Magento 1.4.1.

Magento Local module file: ./app/code/local

Magento Community module file: ./app/code/community

Magento Core team module file: ./app/code/core

Magento User Interface (layouts, templates): ./app/design

Magento Global Configuration: ./app/etc

Magento PHP Library file: ./lib

Magento Locale language file: ./app/locale

Magento Media library: ./media

Magento Theme Skin (Images, CSS, JS): ./skin

Magento Other web accessible file: .

Magento PHPUnit test: ./tests

Magento other: .

A Path defines a file path, from the base of the Role, to include in your packaged module.

Whenever I go to create a new Connect package, I always have to glop through the code to figure out which sub-directory a Role corresponds to. The last tie this happened I hacked together the following script to grab and display that information.

File: roles.php (in the root magento directory)  /** * Jumps into PEAR files to figure out what paths the connect roles belong to * worked on the 1.4.1 release, and I almost guarantee it'll break in a future * release.   */   function main() {     $paths  = get_key_path_pairs();     $labels     = get_labels();     render_labels_paths($paths, $labels); }     function render_labels_paths($paths, $labels) {     foreach($labels as $key=>$value)     {         echo $labels[$key] .          "\t:\t" .         $paths[$key] .         "\n";     } }  function load_roles() {     $inner = '';             foreach(glob('downloader/pearlib/php/PEAR/Installer/Role/*.xml') as $file)     {         $inner .= file_get_contents($file);      }     $xml = '<roles>'.$inner.'</roles>';     return simplexml_load_string($xml);  }  function get_key_path_pairs() {     $pairs = array();     foreach(load_roles() as $role)     {         $location_config = (string) $role->locationconfig;                   if($role->config_vars->{$location_config}->type &&          $role->config_vars->{$location_config}->type == 'directory')         {             $path = (string) $role->config_vars->{$location_config}->default;             $pairs[$location_config] = $path;         }     }     return $pairs;   }  function get_pair_roles() {     set_include_path('downloader/pearlib/php');     require('downloader/pearlib/php/PEAR/Command/Mage.php');     $fake       = null;     $command    = new PEAR_Command_Mage($fake,$fake);     return $command->getRoles(); }  function get_labels() {     $labels = array();     foreach(get_pair_roles() as $option=>$info)     {         if(array_key_exists('name', $info))         {             $labels[$info['dir_config']] = $info['name'];         }     }     return $labels; }  main();

Magento Base Directories

2011-09-16T22:36:00.001+05:30

As platform, PHP has a long history of relying on the base computer's underlying file system as a storage mechanism for various application and system functions. This ties in closely with PHP's practical history of closely modeling the nacent web's file serving architecture for it's own.

In an ideal world, as an end-user or application developer using the Magento system, you wouldn't need to worry about the file system at all. When you're handling user sessions, you don't care if they're stored on disk or in a database, or when you declare a Model class you don't need to worry about requireing the source file into the system. That's because there's an abstraction that sits on top these systems and allows you to not worry about how they're implemented.

Unfortunately, we don't live in an ideal world. There are times when, either out of deadline pressure or lack of an interface, we need to programmatically deal directly with the raw file system in Magento. This article will teach you how to programmatically find the paths of important Magento systems files, which will allow you to build less fragile applications that can withstand system configuration and installation changes.

Finding The Path

If you're worked much with PHP, you know that finding the full file path to any particular file can be a bit of a black art. When you include or require a PHP file, or open a raw file with functions like file orfile_get_contents using a relative file path, there's a set of rules that PHP will use to determine which directories need to be searched.

Because this list of directories (called the include_path is malleable at runtime, if two files with the same name exist in the include path, it's often hard to tell which one is loaded. Consider the following

1

2

3

4

5

 include('foo.php');
 #files system has
 #   /lib/foo.php
 #   /use/web/phplib/foo.php
 #which one loads?

Because of this, it's a common pattern in the PHP to use the magic constants __FILE__ or __DIR__ to find the absolute path to the calling file, and then navigate to the file you want relative to that calling file

1 2	`$info` `=` `file_get_contents(dirname(__FILE__) .` `'/../data/info.json');` `$info` `= json_decode($info);`

This is far from ideal.

First, there's the problem of symlinks. Depending on your web server system, it's not always clear if __FILE__is returning the file's real path, or its path in the context of a symlink. Because of this, you'll often see the use of the realpath function

1 2	`$info` `=` `file_get_contents(realpath(dirname(__FILE__)) .` `'../data/info.json');` `$info` `= json_decode($info);`

While this works, it's not without its problems. As you can see, this will often lead to code that's a little hard to read. Additionally, calls to realpath mean that PHP needs to stat the filesystem to retrieve that information. As traffic to your application grows, these kind of file stats can start to create a performance bottleneck.

Finally, although it solves the problem of ambiguity in PHP's include path, this isn't a 100% portable solution. If we move the code from one PHP file (say, a Model in a module) to another PHP file (say, a Magento phtml template), the number of ..'s we'll need is different, since one file is deeper in the hierarchy than the other.

Sometimes __FILE__ is the only way to get where you want to go. Fortunately, Magento offers another option for commonly accessed folders.

Magento Base Directories

Add the following code an empty controller action or other area of Magento where you can run arbitrary code.

1

2

3

4

5

 $base_path = Mage::getBaseDir('base');
 var_dump($base_path);
  
 $etc_path = Mage::getBaseDir('etc');
 var_dump($etc_path);

You should see output something like the following

1 2	`string` `'/Users/username/Sites/magento1point4.1.dev'` `(length=43)` `string` `'/Users/username/Sites/magento1point4.1.dev/app/etc'` `(length=51)`

The first folder is the base directory for the entire Magento installation. The second folder is the base directory for Magento's etc folder, which holds configuration files.

In the latest Community Edition release of Magento there are 14 different directories that are considered important enough to be retrievable by this method. The static calls to Mage::getBaseDir are a wrapper/public-api to the getDir method on a Mage_Core_Model_Config_Options object. If you take a look at the Magento Model pseudo-constructor in

 #File: app/code/core/Mage/Core/Model/Config/Options.php
 class Mage_Core_Model_Config_Options extends Varien_Object
 {
     /* ... */
     protected function _construct()
     {
         $appRoot= Mage::getRoot();
         $root   = dirname($appRoot);
  
         $this->_data['app_dir']     = $appRoot;
         $this->_data['base_dir']    = $root;
         $this->_data['code_dir']    = $appRoot.DS.'code';
         $this->_data['design_dir']  = $appRoot.DS.'design';
         $this->_data['etc_dir']     = $appRoot.DS.'etc';
         $this->_data['lib_dir']     = $root.DS.'lib';
         $this->_data['locale_dir']  = $appRoot.DS.'locale';
         $this->_data['media_dir']   = $root.DS.'media';
         $this->_data['skin_dir']    = $root.DS.'skin';
         $this->_data['var_dir']     = $this->getVarDir();
         $this->_data['tmp_dir']     = $this->_data['var_dir'].DS.'tmp';
         $this->_data['cache_dir']   = $this->_data['var_dir'].DS.'cache';
         $this->_data['log_dir']     = $this->_data['var_dir'].DS.'log';
         $this->_data['session_dir'] = $this->_data['var_dir'].DS.'session';
         $this->_data['upload_dir']  = $this->_data['media_dir'].DS.'upload';
         $this->_data['export_dir']  = $this->_data['var_dir'].DS.'export';
     }

you can see where these directory paths are stored.

Let's quickly review each one

Mage::getBaseDir('base');

This is your main Magento directory. In a default root level application instal, this is the equivalent of the document root.

Mage::getBaseDir('app');

This is your Magento application directory. This is the directory where the final class Mage... application file (Mage.php) is stored.