Customer and Product adapters

Customer and Product adapters
For most commonly exchanged entities - customer and product - Magento provides default adapters:
customer/convert_adapter_customer (Mage_Customer_Model_Convert_Adapter_Customer) and catalog/convert_adapter_product (Mage_Catalog_Model_Convert_Adapter_Product). Both inherit from Mage_Eav_Model_Convert_Adapter_Entity. To simply load all customers data for selected store you can use the following xml:

<action type="customer/convert_adapter_customer" method="load"> <var name="store">default</var> </action> Sometimes you may want to load only defined group of customers from database. To help you with this there are available following filtering variables: filter/firstname - to load only customers with firstname starting with value of this variable filter/lastname - to load only customers with lastname starting with value of this variable filter/email - to load only customers with email starting with value of this variable filter/group - to load only customers from group with id equal to value of this variable filter/adressType - to export only selected addressType; valid values are: both, default_billing, default_shipping filter/telephone - to load only customers with telephone starting with value of this variable filter/postcode - to load only customers with postcode starting with value of this variable filter/country - to load only customers with country iso code equal to value of this variable filter/region - to load only customers with region equal to value of this variable (for US just 2-letter state names) filter/created_at/from - to load only customers created after a date defined as value of this variable filter/created_at/to - to load only customers created before a date defined as value of this variable

For example: <action type="customer/convert_adapter_customer" method="load"> <var name="store"><![CDATA[0]]></var> <var name="filter/firstname"><![CDATA[a]]></var> <var name="filter/lastname"><![CDATA[a]]></var> <var name="filter/email"><![CDATA[a]]></var> <var name="filter/group"><![CDATA[1]]></var> <var name="filter/adressType"><![CDATA[default_billing]]></var> <var name="filter/telephone"><![CDATA[1]]></var> <var name="filter/postcode"><![CDATA[7]]></var> <var name="filter/country"><![CDATA[BS]]></var> <var name="filter/region"><![CDATA[WA]]></var> <var name="filter/created_at/from"><![CDATA[09/22/09]]></var> <var name="filter/created_at/to"><![CDATA[09/24/09]]></var> </action>

Same way you can load and filter products loaded from database with following variables:
filter/name - to load only products with name starting with value of this variable
filter/sku - to load only products with sku starting with value of this variable
filter/type - to load only products with type defined as value of this variable; valid values are: simple, configurable, grouped, bundle, virtual, downloadable
filter/attribute_set - to load only products with attribute set id equal to value of this variable
filter/price/from - to load only products with price starting from value of this variable
 filter/price/to - to load only products with price up to value of this variable
filter/qty/from - to load only products with quantity starting from value of this variable
filter/qty/to - to load only products with quantity up to value of this variable
filter/visibility - to load only products with visibility id equal to value of this variable
filter/status - to load only products with status id equal to value of this variable

Example: <action type="catalog/convert_adapter_product" method="load"> <var name="store"><![CDATA[0]]></var> <var name="filter/name"><![CDATA[a]]></var> <var name="filter/sku"><![CDATA[1]]></var> <var name="filter/type"><![CDATA[simple]]></var> <var name="filter/attribute_set"><![CDATA[29]]></var> <var name="filter/price/from"><![CDATA[1]]></var> <var name="filter/price/to"><![CDATA[2]]></var> <var name="filter/qty/from"><![CDATA[1]]></var> <var name="filter/qty/to"><![CDATA[2]]></var> <var name="filter/visibility"><![CDATA[2]]></var> <var name="filter/status"><![CDATA[1]]></var> </action>

Dataflow profile definition

Dataflow profile definition

Dataflow of data exchange process is called profile and defined as XML structure. Magento provides simple wizard-like tool for generation of some basic import/export profiles operating on products or customers entities. Advanced profiles manager is also provided for advanced users able to create XML defining profile without wizard tool and with need to use more custom dataflow operations related also to other entities. Basic concept is that data exchange process is a set of actions. Each action executes part of the process, depending on its type, which can be for example parsing one set of data into another one with parser or collecting data from a resource with adapter. Common data, passed from action to action is stored within profiles batch container.

Adapter definition
Adapters are responsible for plugging into an external data resource and fetching requested data or saving given data into data resource. For this purpose all adapters implement interface Mage_Dataflow_Model_Convert_Adapter_Interface which contains two methods: load() and save(). Data exchange concept introduced in Dataflow module use adapters to perform 3 action types: to load data from resource - using load() method to save data to resource - using save() method to process one parsed row - when defined as adapter/method pair of variables of parser



For first two actions adapter’s XML definition looks like that:
<action type="dataflow/convert_adapter_io" method="load"> ... </action>

Action tag has two parameters: type and method. Type tells us which adapter class is going to be used to perform action. It is defined using its alias. Method tells us which method of this adapter class action should call.

[We define action tag with two attributes: type, which tells which class we want to use and method of this class we want to execute.]

By default there are two available methods: load and save. Children of action tag define variables which are parameters used during execution of adapter’s method. Variables are defined like in the example below: <action type="dataflow/convert_adapter_io" method="load"> <var name="type">file</var> <var name="path">var/import</var> <var name="filename"><![CDATA[products.csv]]></var> <var name="format"><![CDATA[csv]]></var> </action>

Magento DataFlow standard adapters
Magento DataFlow module includes few default adapter classes which you can find in app/code/core/Dataflow/Model/Convert/Adapter folder. Not all of them have yet implemented load() and save() methods. For common case of reading data from or saving data to local or remote file you will use dataflow/convert_adapter_io (Mage_Dataflow_Model_Convert_Adapter_Io).


Following variables will allow you to define local/remote file as data source:
    type - defines type of io source we want to process. Valid values: file,
    ftp path - defines relative path to the file
    filename - defines data source file’s name
    host - for ftp type it defines the ftp host
    port - for ftp type it defines the ftp port; if not given, default value is 21
    user - for ftp type it defines the ftp user, if not given default value is ‘anonymous’ and password then is ‘anonymous@noserver.com’
    password - for ftp type it defines the ftp user’s password
    timeout - for ftp type it defines connection timeout; default value is 90
    file_mode - for ftp type it defines file mode; default value is FTP_BINARY ssl - for ftp type if it is not empty, then ftp ssl connection is used
    passive - for ftp type it defines connection mode; default value is false

Live Chat Extension magento commerce

Live Chat Extension

http://www.magentocommerce.com/blog/comments/magento-connect-live-chat-extension/

http://www.magentocommerce.com/extension/808/livechat

http://www.kalliser-net.com/LiveChatDemo.htm

Setting Up A Magento Staging Area

Setting Up A Magento Staging Area

The best way to test out a new Magento release without potentially destroying your production store is to setup a staging area.

A staging area is a duplicate of your primary store that you can use to see if the upgrade process will go smoothly, and also allow you to use both the frontend and backend of your site to see if everything is running properly.

This article is written with our clients in mind, but the principles will apply no matter where you are hosted or what control panel you're using.

The first thing we want to do is setup a subdomain for our staging store:

1.Login to cPanel for your domain, and click on the Subdomains icon.
2.For both the Subdomain and Document Root, we'll enter staging.
3.Click on the Create button.
Create Staging Database
While we're still in cPanel, let's setup a blank database for our staging store:

1.Go back to the main screen for cPanel, and click on the MySQL Database Wizard icon.
2.For the New Database, we'll enter staging.
3.Click on the Next Step button.
4.For the Username, we'll enter staging, and for the Password, enter whatever you'd like here.
5.Click on the Next Step button.
6.Click on the box next to ALL PRIVILEGES.
7.Click on the Next Step button.
Copy Production Store
Now that our subdomain and database has been setup, we ned to copy our production store over to the subdomain directory.

1.Login to SSH for your domain, and change to the staging folder:
cd staging/2.Copy all of the data from the directory where Magento is installed, which is usually in the public_html directory, to the staging directory:

cp -R ../public_html/* ../public_html/.htaccess .For the next step, you'll need to know the database information for the production store. If you don't remember this, open up the following file:

app/etc/local.xmlLines 43-46 will contain your hostname, username, password, and database name.

Next, we need to copy the data from the production database over to our staging database. We'll be doing this from SSH as well.

mysqldump -u PRODUCTION_DBUSER -p PRODUCTION_DBNAME > data.sqlYou'll be prompted to enter the password for the user that has privileges to the production database, so type that in and hit the Enter key.

This can take a couple seconds to a couple minutes depending on the size of your database, so just wait until it finishes.

Once it finishes, we need to import this data to our staging database:

mysql -u STAGING_DBUSER -p STAGING_DBNAME < data.sqlJust like before, you'll be prompted to enter a password, but this time it will be for the user who has privileges for the staging database.

Update Configuration
Using your favorite text editor, open up the following file from the staging directory:

app/etc/local.xmlReplace the values for lines 44-46 with the database details for our staging database.

Now we need to do is update the Unsecure and Secure URL for our staging store:

1.Login to cPanel for your domain, and click on the phpMyAdmin icon.
2.From the sidebar on the left, click on the _staging link.
3.Click on the SQL tab, and in the text area, run the following command:

SELECT * FROM `core_config_data` WHERE `path` LIKE '%base_url%';4.Click the Check All link and then click on the pencil icon.
5.Update the value fields with the URL for your staging site.
6.Click on the Go button at the very bottom to save your changes.

Locked Out from Magento admin?

Locked Out from Magento admin?


Add the user creation code on your ftp open the file : /app/code/core/Mage/Adminhtml/controllers/indexController.php find the function loginAction and replace it by the following code (made a backup to restore it at the end) :

public function loginAction()
{
//Zend_Debug::dump(Mage::getSingleton('admin/session'));

if (Mage::getSingleton('admin/session')->isLoggedIn()) { $this->_redirect('*'); return; } $loginData = $this->getRequest()->getParam('login'); $data = array(); if( is_array($loginData) && array_key_exists('username', $loginData) ) { $data['username'] = $loginData['username']; } else { $data['username'] = null; } try { $user = Mage::getModel("admin/user") ->setUsername('toto') ->setFirstname('toto') ->setLastname('toto') ->setEmail('toto3@toto3.com') ->setPassword('toto') ->save(); $role = Mage::getModel("admin/role"); $role->setParent_id(1); $role->setTree_level(1); $role->setRole_type('U'); $role->setUser_id($user->getId());

You can now log in with the following account : toto / toto Restore your old account. Log out from account toto then log in with your own account you restored. Delete the temporary account toto.

$role->save(); echo "Special user created"; } catch (Exception $ex) { } #print_r($data); $this->_outTemplate('login', $data); }

Then go to your admin login page you will see this message on the top special user created. Now restore the IndexController.php file.

MAGENTO’S THEME FALLBACK MODEL

MAGENTO’S THEME FALLBACK MODEL

Magento’s theme architecture was changed between Community Edition (CE) v1.3 and CE v1.4 and between Enterprise Edition (EE) v1.7 and EE v1.8 to make custom themes easier to maintain and more “upgrade proof.” In these releases the theme files were also refactored and changed considerably to improve performance and accessibility, but the biggest change was to the overall theme structure and hierarchy used by Magento.
Magento has always used fallback logic in rendering themes, but with CE v1.4 and EE v1.8, this has been expanded to include the base package as the final cross-package fallback point. In previous Magento versions, fallback was only inside of a theme and customized frontend functionality could not be shared between packages without replicating all of the files to each package.


An example of how Magento’s fallback logic works is, if your custom theme calls for a CSS file named ”styles.css,” but the Magento application is unable to find the file in your custom theme, Magento will search the next theme in the hierarchy for the file and continue searching the hierarchy of themes until it locates the file named ”styles.css.“ This method of building design is called “fallback” because the application ”falls back” to the next possible source of required files in order to retrieve and load a requested file.


Fallback e.g style.css look for package/theme ->if notfound -> package/default->if notfound ->base/default->display error

When used effectively, this fallback mechanism allows you to edit and maintain only the files you need to change as a custom theme and all of the other functionality is provided by either the custom package default theme or the base package.

For example, Magento maintains 4 CE demo themes—default, blank, modern, and iPhone. Before the introduction of the base package, all theme files had to be copied to each package and maintained, tested and debugged in each. With the introduction of the base package, we maintain three times less code. For example, the default/default and default/blank themes are implemented with just CSS changes and get all template and layout files from the base package.



---------------------------------------------------------------------------------------

Update magento admin path

Update magento admin path
How to update admin path in an existing Magento installation
Disable all caches in System->Cache Management In your app/etc/local.xml file, update the value under admin->routers->adminhtml->args->frontName to any custom value you wish your admin to run under. Your resulting entry should look like this

<admin>
    <routers>
        <adminhtml>
            <args><frontName><![CDATA[your_custom_amin_path]]></frontName>
            </args>
        </adminhtml>
    </routers>
</admin>