Tag Archives: PHP

Magento directory structure

Magento aims to decrease the amount of time that developer uses for manually including of files into the different modules and on the other hand to decrease the amount of files, which has been load on a single request. In order to do that it uses specific directory structure, xml configuration and some additional configuration under the app/code/Mage/Core.
The most important directories under the Magento root folder one are presented with orange in the figure on the right. At this level in the hierarchy the directory naming is based on keywords.
The files under the directory ‘app’ are, as it can be suggest from the name, build the entire functionality of the web shop application, they are never addressed directly by the browser.

The ‘js’ folder contains all JavaScript libraries used in Magento. The mainly used library in the Magento 1.xx versions is Prototype, therefore the usage of the other popular JavaScript libraries e.g. JQuery should be taken careful, because it can cost conflicts. The expected JavaScript framework for Magento 2 is JQuery.

The ‘lib’ directory contains different libraries – Zend, Varien are the libraries implemented by Magento and other third party libraries. In the Varien library for example contains the autoloader, which loads the PHP files called from the factory methods.

The ‘media’ folder contains the uploaded files for given module. For example the products and categories images are placed under the ‘catalog’ directory.

The ‘skin’ directory contains three design areas/folders ‘adminhtml’, ‘frontend’, ‘install’ and each of them contains images and css files specific for the current area. They are always accessed from the browser.

The ‘var’ directory contains the dynamically-created and temporary files such as cache, logs, session storage. This folder can be completely deletes Magento will recreate it, if it is needed.

The files under the root directory are colored with blue in the figure on the right. The file ‘.htaccess’ contains the host configuration for the apache. It is mainly used for declaring URL rewrites e.g. if you enable the URL rewrites, URL from the type ‘http://xxx/webshop/admin’ will be automatically translated to ‘http://xxx/webshop/index.php/admin’. In the webshop the URL rewrites can be enabled. The index.php is the initialization file – this is the only entry to the web shop application. And cron.php is used for scheduled job functionality.

The most important folder for the proper Magento system functionality is the ‘app’ folder: It is presented in the figure in the right the three folders underneath have different responsibilities to the end system functionality.
The ‘code’ directory consists of the 3 code pools in Magento:

  • core – this is the base, the core Magento functionality. These files should not be changed from the custom modules.
  • local – this is for Magento custom modules in development phase
  • community – this is for Magento custom modules in production phase

The design folder divided the same as the skin into three areas/folders ‘frondend’, ‘adminhtml’ and ‘install’. Each of them consists of its own templates(.phtml) and layouts(.xml) files.

The ‘etc’ folder contains ‘modules’ folder containing the register .xml file for each module e.g. Company_Module.xml. Without file in this directory all files from a certain module are not going to be evaluated from the system.

The ‘locale’ folder contains the different language possibilities and the map file (.csv) is for the different language files.

Kayako PHP API library for Kayako Fusion RESTful API

kayako php api

I personally found the official  Kayako PHP API library 1.1.0 for Kayako Forge quite disappointing. It reminded really on the auto-generated SOAP connectors in Java with the only difference that since it is REST web service there is no way to be sure that the library version that you have will match the one on your Kayako installation.

The official Kayako PHP API quite reminded my on the auto-generated SOAP, with the only difference that the Kayako one isn’t auto-generated.

Some background on auto-generated connectors. They are generated based on the SOAP WSDL descriptors and therefore they are normally slightly large, complicated and messy.  The positive part in them is the reassurance that the connector is going to work with exactly that web service structure that you have installed.

In REST services unfortunately there are no descriptors so it is not possible for you to generated something based on your web service structure.

I find the official Kayako PHP API library poorly designed, because:

  • There are thousands of classes and nestings throughout the library.

That makes the easy web service functionality to look extremely complicated, confusing and uncompromisable.

  • The library constantly throws E_STRICT exceptions due mismatch between the abstract Base class constructors and the classes extended from them.

Normally when one makes library all exceptions should be accepted, because you don’t know what are the error settings of the systems which this library will be integrated in.

  • There are too many specific static variables in the different classes which are hard-coded to the actual web service values.

I found that not only confusing but also a potential for a lot of problems.

The Kayako PHP API solution that I used

 

After spending the better part of the day in different ways to making that delicious treat to work I just decided to make a really light Kayako PHP API library on my own.

Git repository – https://github.com/ki6i/kayako_api

This Kayako PHP API library is built with the same design used in the official Mandrill PHP library. It aims to spare you redeclaring all keys and HTTP related setting.

If you want to read more about the Kayako Fusion RESTful API and the official Kayako PHP API, here is the documentation: http://wiki.kayako.com/display/DEV/REST+-+TicketSearch

Magento Grid View Debug

In order to check if everything is working properly in your grid view you maybe will be willing to check that the SQL statements look as you expected:

Way to do that in Magento is $collection -> load(true); to the _prepareCollection() of the Grid view that you want to debug
Continue reading Magento Grid View Debug

Magento join – EAV and Flat table

Case 1: After the Magento join, we want to have a EAV Collection as a result collection

//the ‘1’ is just a example of a where clause, you can totally miss this part, if you do not need it :)


$collection = Mage::getModel('catalog/product_link')
                    ->useRelatedLinks()
                    ->getProductCollection()
                    ->joinTable('sales/order_item',
                                'product_id=entity_id',
                                array('*'),
                                'entity_id=1',
                                'left');

Continue reading Magento join – EAV and Flat table

Magento Architecture – Blocks, Models, Helpers

Magento is structured from many small modules working and existing as atomicly as possible. The typical Magento architecture for each module is divided on Blocks, Models, Helpers.

Tips: If you want to see more about most Magento interesting configuration one good class for that is core/code/Mage/Core/Model/Config.php

Now the interesting part have you thought why there are Mage::getModel(”) and Mage::getResourceModel(”) but Mage::helper?

Well, I still have not answer to that question. XD

But I have thought a lot of why you are able to get Mage::helper(‘unique_name’) but you able only to that -> Mage::getModel(‘unique_name/filename’) for the models.

Well, the answer is easy and it is in core/code/Mage/Core/Model/Config.php


public function getModelClassName($modelClass) {
    $modelClass = trim($modelClass);
    if (strpos($modelClass, '/') === false) {
        return $modelClass;
    }
    return $this->getGroupedClassName('model', $modelClass);
}

public function getHelperClassName($helperName) {
    if (strpos($helperName, '/') === false) {
        $helperName .= '/data';
    }
    return $this->getGroupedClassName('helper', $helperName);
}

In the helper one Magento configuration adds automatically /data if there is no slash in the $helperName so if you write something from this kind Mage::helper(‘unique_name’) it is presenting Data.php file in your Helper folder that this unique_name is defining it will be loaded automatically.

Magento Admin Redirect

How can you redirect the user request from your custom module to Magento Admin Core module?

If my module is in the local or the community pool and we want to redirect an action from the controller in our module to a controller in the core module the easiest way to make that Magento Admin redirect is:


public function someAction() {
    //general syntax $this->_redirect("adminhtml/module/action", params)
    $this->_redirect("adminhtml/sales_order/view", array('order_id', '11'));
}