How to Integrate Live Chat in your magento store

 

Introduction

If you look at the right-bottom of this page, you will notice a nice looking chat widget. Yes that’s the Zopim Live Chat.

If you want to interact with your visitors, give support to them, know the statistics of the visits, get offline messages etc. then Zopim Live Chat seems to be very promising choice.

Integration of Zopim Live Chat

If you want to add Zopim Live Chat to your Magento Store, you don’t need to use any third party modules as it is so simple & straight forward to use.

Integration Steps:

  1. Sign up with Zopim

    Visit Zopim site to sign up/create a account. Once you complete the sign up form then you will get a confirmation link in your mail for verification. Once confirmed your account is ready to use the Zopim Live Chat widget.
    Related Snaps:

  2. zopim-chat-step1

    zopim-live-chat-demo1

  3. Grap the Widget Code

    Login to the Zopim Dashboard page with the credentials used during sign up. After login, click on the Settings tab on the top right then you can see the following screen:
    system-configuration-design-footer
    When you are in Settings section,then you can see two tabs on the left: ‘Embed widget on my site‘ & ‘Customize widget‘.

    Embed widget on my site‘ -> When you click on this tab you will see the script ready for copy-paste in Magento.
    Customize widget‘ -> Click on this tab if you want to customize the look and feel, default text, position etc of your chat widget.

  4. Insert the Widget Code in Magento

    After getting the Widget code(Zopim Dashboard > Settings > Embed widget on my site) from Zopim Site, login to the Magento and go to:
    System > Configuration > General > Design > Footer > Miscellaneous HTML > Paste the widget code here..

  5. dashboard-settings

   4. You’re done 🙂

Refresh the cache and load the frontend page, you will see the sexy chat widget ready for interaction

step2-create-a-account

Magento Design Patterns : Magento Uses 12 Design patterns

 

1. Model View Controller Pattern

Model View Controller, MVC for short, is a design pattern where business, presentation and coupling logic are separated. Magento heavily utilizes XML as templating-logic and HTML mixed with PHP files for its views. Models are backed by Varien’s ORM. Most business logic happens in the models whereas the controllers map the model-data to the views.

Because Magento its views are “fat” – they often contain a lot of logic – its not rare that views have an additional PHP class (the Block system) which will help with rendering.

2. Front Controller Pattern

The front controller pattern makes sure that there is one and only one point of entry. All requests are investigated, routed to the designated controller and then processed accordingly to the specification. The front controller is responsible of initializing the environment and routing requests to designated controllers.

Magento has only one point of entry ( index.php) which will initialize the application environment ( Mage::app()) and route the request to the correct controller.

3. Factory Pattern

As implied by the name, the factory pattern is responsible of factorizing (instantiating) classes. It’s widely used through the Magento code base and leverages the autoloading system in Magento. By defining an alias in a module its config.xml you are letting the factory know where it can find classes.

There are various factory-helper methods in the Mage core class and one of them is getModel(). It accepts an alias for a class and will then return an instance of it. Instead of having include calls scattered through the code base, the factory pattern will instantiate classes in an uniform way.

4. Singleton Pattern

Another way to retrieve an instance of a class, is to call Mage::getSingleton(). It accepts a class alias and before returning an instance, it checks the internal registry whether this class has already been instantiated before – this results in a shared instance. An example of where this is mandatory, is the session storage which should be shared through the code base instead of creating it anew every time.

5. Registry Pattern

All the singletons are stored in the internal registry: a global scoped container for storing data. It is not only for internal use. The Mage::register($key, $value), ::registry($key) and ::unregister($key) methods can be respectively used for storing, retrieving and removing data from the registry. The registry is often used for transferring data between scopes when they cannot be passed on, otherwise.

6. Prototype Pattern

Where the factory pattern (#3 on our list) stops, is where the prototype pattern continues. It defines that instances of classes can retrieve a specific other class instance depending on its parent class (the prototype). A notable example is the Mage_Catalog_Model_Product class which has a getTypeInstance method to retrieve the specific Mage_Catalog_Model_Product_Type with a specific subset of methods and properties not applicable to all products.

For example, the Mage_Downloadable_Model_Product_Type ultimately extends the Mage_Catalog_Model_Product_Type. If you are iterating over an order and want to call a specific method of a downloadable product, you will need to factorize it first with the getTypeInstance method of the original product.

7. Object Pool Pattern

The object pool pattern is simply a box with objects so that they do not have to be allocated and destroyed over and over again. It’s not used a lot in Magento other than for heavy tasks where resources can get limited soon, like importing products. The object pool (managed by Varien_Object_Cache) can be accessed with Mage::objects().

8. Iterator Pattern

The iterator pattern defines that there is a shared way to iterate over a container with objects. In Magento, this is handled by the Varien_Data_Collection which on its turn uses various baked-in PHP classes (like ArrayIterator) for having a more OO-interface to arrays. This ensures that model-collections will always have a common API to iterate over without being dependent of the actual models.

9. Lazy Loading Pattern

Lazy loading ensures that loading data is delayed until the point when it is actually needed. This results in less resources being used. One of the lazy loading behaviors of Magento is that of collections. If you were to retrieve a collection of products with Mage::getModel(‘catalog/product’)->getCollection(), the database will only be touched when you actually access the collection by, for example, iterating over it or retrieving the count of models found.

10. Service Locator Pattern

The service locator pattern abstracts away the retrieval of a certain service. This allows for changing the service without breaking anything (as it adheres to its abstract foundation) but also fetching the service as seen fit for its purpose.

Ryan exemplifies this with database connections. Another example is that of Magento its caching mechanism where Mage::getCache() is a service locator by-proxy for the cache storage supplied by Zend or other vendors.

11. Module Pattern

Anyone familiar with Magento development has stumbled upon the module pattern. It basically defines that different domains are grouped into separate modules which function independent of each other and can be plugged-in to the main system as deemed appropriate. In an ideal situation, an implementation of the module pattern would make sure that each element can be removed or swapped. One of the protagonists of the module pattern in PHP is the Composer package manager.

Though Magento heavily relies on a modular architecture, its not modular to the bone. Certain functionality is heavily tied to the core and can not be easily changed. There is also the heavy usage of the super-global Mage core-class which introduces all sorts of system-wide dependencies not easily overseen.

12. Observer Pattern

Magento its event-driven architecture is a result of an implementation of the observer pattern. By defining observers (or listeners), extra code can be hooked which will be called upon as the observed event fires. Magento uses its XML-data storage to define observers. If an event is fired with Mage::dispatchEvent($eventName, $data), the data storage will be consulted and the appropriate observers for $event will be fired.

 

Difference between Mage::getModel() and Mage::getSingleton() in Magento

Mage::getModel()

Mage::getModel() will create a new instance of an object each time even such object exists in configuration.

Example

1
2
$prod1 = Mage::getModel('catalog/product');
$prod2 = Mage::getModel('catalog/product');

$prod1 and $prod2 both have different instant of same object and also occupy different memory .

Mage::getSingleton()

Mage::getSingleton() will first check the same class instance is exits or not in memory. If the instance is created then it will return the same object from memory. So Mage::getSingleton() faster then Mage::getModel().

1
2
$prod1 = Mage::getSingleton('catalog/product');
$prod2 = Mage::getSingleton('catalog/product');

$prod1 and $prod2 both will share same memory of OS and return only one instance each time.

Run below file in your root directory it will fix your issue.

<?php
require_once ‘app/Mage.php’;
umask( 0 );
Mage :: app( “default” );
Mage::log(“Started Rebuilding Search Index At: ” . date(“d/m/y h:i:s”));
$sql = “truncate catalogsearch_fulltext;”;
$mysqli = Mage::getSingleton(‘core/resource’)->getConnection(‘core_write’);
$mysqli->query($sql);
$process = Mage::getModel(‘index/process’)->load(7);
$process->reindexAll();
Mage::log(“Finished Rebuilding Search Index At: ” . date(“d/m/y h:i:s”));

?>

 

sending Magento order confirmation emails for orders placed  using order id.

<?php
require ‘app/Mage.php’;
Mage::app(‘admin’)->setUseSessionInUrl(false);
//replace your own orders numbers here:
$test_order_id = ‘100000014’;

$order = Mage::getModel(‘sales/order’)->loadByIncrementId($test_order_id);

if ($order->getId()) {
try {
$order->sendNewOrderEmail();
echo “Order $orderIncrement successfully sent\n”;
} catch (Exception $e) {
echo $e->getMessage();
}
} else {
echo “Order $orderIncrement not found\n”;
}

 

?>

1. Explain Magento’s MVC architecture

First of all, what is MVC?
MVC stands for Model-View-Controller. Any application that separates it’s data access, business logicand user interface is called MVC. There can be two types of MVC: convention-based and configuration-based. Example, cakePHP is convention-based, i.e. you just need to follow the instructions of the core system to get your module ready in just few lines. Magento is configuration-based, i.e. you need to specify each and every thing to your module’s config file in order to get it work. Magento has Controller (for Routing), Block (for Business Logic), Model (for DB access, sql) and Template file (for Presentation i.e. View).

How Magento’s MVC works:
1. When you enter the URL (something like http://mysite.com/frontname/controller/method/param1/value1/param2/value2), this URL is intercepted by one PHP file called index.php which instantiates Magento application
2. Magento application instantiates Front Controller object
3. Further, front controller instantiates Router objects (specified in module’s config.xml, global tag)
4. Now, Router is responsible to “match” the frontname which is in our URL
5. If “match” is found, it sees controller name and method name in the URL, which is finally called.
6. Now depending on what is written in action name (method name), it is executed. If any models are called in it, the controller method will instantiate that model and call the method in it which is requested.
7. Then the controller action (method) instantiate the Layout object, which calls Block specified for this action (method) name (Each controller action name have block and template file associated with it, which can be found at app/design/frontend or adminhtml/namespace/module/layout/module.xml file, name of layout file (module.xml) can be found in config.xml of that module, in layout updates tag).
8. Template file (.phtml) now calls the corresponding block for any method request. So, if you write $this->methodName in .phtml file, it will check “methodName” in the block file which is associated in module.xml file.
9. Block contains PHP logic. It references Models for any data from DB.
10. If either Block, Template file or Controller need to get/set some data from/to database, they can call Model directly like Mage::getModel(‘modulename/modelname’).

More Magento Questions with answers

Q 1. What is Magento?
Ans. Magento is a feature-rich eCommerce platform built on open-source technology that provides online merchants with unprecedented flexibility and control over the look, content and functionality of their eCommerce store. Magentos intuitive administration interface features powerful marketing, search engine optimization and catalog-management tools to give merchants the power to create sites that are tailored to their unique business needs. Designed to be completely scalable and backed by Variens support network, Magento offers companies the ultimate eCommerce solution.

Q 2. What is the difference between Mage::getSingletone() andMage::getModel() in Magento
Ans. Mage::getSingletone() always finds for an existing object if not then create that a newobject but Mage::getModel() always creates a new object.

Q 3. Why Magento use EAV database model ?
Ans. In EAV database model, data are stored in different smaller tables rather than storing in asingle table.product name is stored in catalog_product_entity_varchar tableproduct id is stored in catalog_product_entity_int tableproduct price is stored in catalog_product_entity_decimal tableMagento Use EAV database model for easy upgrade and development as this model givesmore flexibility to play with data and attributes.

Q 4. How to upgrade to the latest version using Magento Connect?
Ans. Upgrading Magento to the latest version is a fairly simple task. Copy and Paste this key magento-core/Mage_All_Latest VIA Magento Connect where it states Paste extension key to install:. This will upgrade Magento to the newest version.

Q 5. Explain about the Modules of Magento?
Ans. Magento supports installation of modules through a web-based interface accessible through the administration area of a Magento installation. Modules are hosted on the Magento eCommerce website as a PEAR server. Any community member can upload a module through the website and is made available once confirmed by a member of the Magento team. Modules are installed by entering a module key, available on the module page, into the web based interface.

There are three categories of modules hosted on Magento Connect:

Core Modules
Community Modules
Commercial Modules
Core and Community modules can be installed via the administration area. Commercial module pages provide price information and a link to an external website.

Q 6. What technology used by Magento?
Ans. Magento uses PHP as a web server scripting language and the MySQL Database. The data model is based on the Entity-attribute-value model that stores data objects in tree structures, thus allowing a change to a data structure without changing the database definition.

Q 7. What is MVC structure in Magento?
Ans. The Model-View-Controller (MVC) architecture traces its
origins back to the Smalltalk Programming language and Xerox
Parc. Since then, there have been many systems that describe
their architecture as MVC. Each system is slightly
different, but all have the goal of separating data access,
business logic, and user-interface code from one another.

Q 8. What is benefit of namespace (package) in magento?
Ans. We can have more than one module with same name but they should be placed in different namespaces. All magento core modules are contained in mage namespace.
core/Mage/Catalog

and all custom modules are placed in

local/CustomModule

Q 9. How to include CMS block in template file(.phtml)?
Ans. Access block’s content from .phtml template file by :

echo $this->getLayout()->createBlock(‘cms/block’)->setBlockId(‘static_block_id’)->toHTML();

Q 10. How to add an external javascript/css file to Magento?
Ans.
css/yourstyle.css
or
skin_jsjs/ yourfile.js
skin_csscss/yourstyle. css

Q 11. What are handles in magento (layout)?
Ans. Handles are basically used for controlling the structure of the page like which block will be displayed and where. First level child elements of the node are called layout handles. Every page request can have several unique Handles. The handle is called for every page. handle for products belongs to virtual product type, PRODUCT_TYPE_simple is called for product details page of simple product type and PRODUCT_TYPE_virtual is called for the virtual product detail page and customer_logged_in handle is called only if customer is logged in. The muster_index_index handle is created by combining the frontName (muster), Action Controller (index), and Action Controller Action Method (index) into a single string and this handle will be called only when /zag/index/index url is accessed.

Q 12. What is in magento?
Ans. The routers tag allow us to decide frontname for each module. The tag is defined in config.xml file of module. For Namespace_MyModule frontname is moduleurl so the url will be like :
websiteurl.com/moduleurl/controllername/actionname

standard
Namespace_MyModule
moduleurl

Q 13. Which factors affect performance of magento?

Ans.
1. EAV structure of magento database, even for retrieving single entity the query becomes very complex .
2. Magento’s template system involves a lot of recursive rendering
3. Huge XML trees built up for layout configuration, application configuration settings

Q 14. How to improve magento performance?
Ans.

Enabled magento caching
MySQL Query caching
Enable Gzip Compression
Disable any unused modules
Disable the Magento log
Optimise your images
Combine external CSS/JS into one file
Enable Apache KeepAlives: Make sure your Apache configuration has KeepAlives enabled.

Q 15. How to get the Total Price of items currently in the Cart?
helper(‘checkout’)->formatPrice(Mage::getSingleton(‘checkout/cart’)->getQuote()->getGrandTotal()); ?>

Q 16. How to set different themes for logged in users?
if(Mage::getSingleton(‘customer/session’)->isLoggedIn()):
Mage::getDesign()->setPackageName(‘package_name’)->setTheme(‘themename’);
endif;

Q 17. How to create magento custom module?
Ans. Steps to create custom magento module:
Namespace : Zag
Module Name : Mymodule
1. Create directory Mymodule in app/code/local/Zag
2. Create Block, controllers, etc, Module directories. Create controller, block and module file as required.
3. Create module configuration file (app/code/local/Zag/Mymodule/etc/config.xml).
4. Create xml file (app/etc/modules/Zag_ Mymodule.xml)to enable/disable module and tell magento system from which code pool that module will be taken.

Q 18. How to set different themes for each store?
Ans. Go to : System>Designs
Then, add new design change or edit existing. You can select Store and Custom Design.

Q 19. How to make product’s custom attribute searchable in adavance search?
Ans. Go to : Catalog > Attribues > Manage Attribues
Edit the attribute and select “Yes” for Use in Advanced Search.

Q 20. How to fetch 5 bestsellers products programmatically?
Ans.
Mage::getResourceModel(‘reports/product_collection’)
->addOrderedQty()
->addAttributeToSelect(‘*’)
->setPage(1, 5)
->load();

Both junior and senior developers, who work with Magento on a constant basis or just start learning this platform, think over the perspective to obtain Magento Developer Certificate some day. Benefits are innumerable, ranging from a catchy point in CV, worldwide job skills recognition to exciting career prospects on on a global scale.

Magento Certified Developer Exam, which contains of multiple-choice questions based on Magento Community Edition 1.5. Magento exam does not imply prerequisites. Find more information about Magento Developer Certification on Magento Commerce official website. Preparing themselves to exam, developers are offered to examine the Magento Certified Developer Study Guide.

We start a new section in our blog, dedicated to Magento Certified Developer Exam preparation, answering questions from above-mentioned Study Guide in series. Today we look through the first question Describe Magento codepools from the Basicschapter, High-level Magento architecture.

Describe Magento Codepools

Magento has three different codepools:

  • Community
  • Core
  • Local

Core pool

First of all, this folder stores all the code that makes Magento so powerful, flexible and lovely. The chief rule of Magento development is that you should never make any changes in it. In other words, this folder belongs to Magento core developers only and if you are going to edit anything in this pool, their evil spirit could punish you even through the display.

Community pool

This folder belongs entirely to community developers. This is the right place for hundreds of 3rd party extensions, both free and paid, that can be found at MagentoConnect or available on extensions development store. So basically, if you have installed any extension, it must be in app/code/community/ only.

Local pool

If you have your own Magento-based store and want to make everything by yourself or you are a Magento developer and have a purpose to change the logic somehow, local pool is the place where everything should be done. If you want to override Magento extensions, blocks or methods, copy the necessary folders from the Core pool and do whatever you are inclined to do. Apply the same rule for custom extensions that are created specifically for the website – all code should be in local pool.

How does the framework interact with the various codepools?

To identify the proccess let’s take a look at app/Mage.php

1

2

3

4

5

6

7

8

9

10

11

12

/**

* Set include path

*/

$paths[] = BP . DS . ‘app’ . DS . ‘code’ . DS . ‘local’;

$paths[] = BP . DS . ‘app’ . DS . ‘code’ . DS . ‘community’;

$paths[] = BP . DS . ‘app’ . DS . ‘code’ . DS . ‘core’;

$paths[] = BP . DS . ‘lib’;

 

$appPath = implode(PS, $paths);

set_include_path($appPath . PS . Mage::registry(‘original_include_path’));

include_once “Mage/Core/functions.php”;

include_once “Varien/Autoload.php”;

This code snippet illustrates the order Magento is using to include paths – firstly it includes Local code pool, than community and after that – core, which allow developers to override classes without changing core files.

 

Magento is by far the most robust and flexible open-source shopping cart available. Magento Enterprise Edition has been deployed by companies like 3M, The North Face, Lenovo, Homedics, and more. Magento Community Edition offers almost all of the flexibility with a much lighter price tag (it’s free).

Because Magento is so powerful and flexible, it has a relatively steep learning curve. Don’t let that worry you though. If you’re comfortable with HTML and CSS and know a little bit of PHP and MySQL you can have an enterprise-class shopping cart up and running in no time.

 

Magento is the robust and flexible open-source shopping cart. It is ecommerce web application launched on 31st March, 2008 and created by Varien. It is built on components of Zend Framework. As Magento is powerful and flexible, it has steep learning curve. If you have knowledge of HTML and CSS and know somewhat of PHP and MySQL then you can have enterprise class shopping cart running in no time. Magento is available under the Open Software License version 3.0. Varien is now Magento Inc. Varien, the company that owns Magento, formerly worked with osCommerce. They originally planned to split osCommerce but later decided to rewrite it as Magento. Magento officially started development in early 2007. Seven months later the first public beta version was released. On May 30, 2010 Magento mobile was released, it allows store owners to create native mobile storefront apps. Magento supports installation of modules through a web-based interface accessible through the administration area of a Magento installation. Modules are hosted on the Magento e-Commerce website as a PEAR server. Any community member can upload a module through the website and is made available once confirmed by a member of the Magento team. Modules are installed by entering a module key, available on the module page, into the web based interface.

Magento developers are familiar with the MVC (Model View Controller) design pattern that is everywhere throughout web frameworks. In the code of Magento, there are many other components besides the M’s the V’s and the C’s. Each module contains the Controller and Model. Within each module, there are no Views. You will find extra tidbits, such as “helper”, “etc” and “sql”. In these modules there is also the sort of files which we very often work with. This article will try to describe just what a Block is and how it is used. A top priority of Object Oriented Programming is the decoupling of code which means that code should have the least amount of dependency on other code as possible. Blocks are part of Magento solution to keep the application loosely coupled.

 

The Basics of Magento Development

 

Over the past summer, I’ve spent a lot of time working with e-commerce software Magento for several clients. Its biggest appeal is also its worst downside for developers: Every part of it is completely extensible without ever needing to touch the core code. That’s great, as long as you don’t look too closely at how that’s actually achieved. I’m not here to rant, though–with a little luck, I’ll save you some of the headaches I ran into when I was starting off.

Fact is, Magento can and probably will be overwhelming on your first time digging through the code, especially if you’re not familiar with the Zend Framework. But then, it does have more than 9,300 files before it’s even installed…

Almost everything you will need to deal with, whether you’re a designer or a developer, is in the /app folder.

/app/etc contains Magento’s basic configuration.

/app/code contains all of Magento’s code, split up by source [community, core or local], publisher, and module. All of the core Magento code is in /app/code/core/Mage. If you ever plan on upgrading, you probably shouldn’t change anything in that folder. If you install a Magento Connect extension, you’ll find the code for it in /app/code/community.

Within each module there are a bunch more subfolders: Block, controllers, etc, Helper, Model, and sql. If you plan on creating your own module you’ll need to understand this better, and there are guides for that; for now, it’s probably enough to know that most of the actual code can be found in the Block folder.

All these underscores… what do they mean? If you’ve glanced at any of the actual code, you might’ve noticed that class names seem like long, repetitive nonsense. In fact, the class name tells you exactly where you can find it. “Mage_Catalog_Block_Navigation” is in the Mage folder, in the Catalog module, it’s a block, and it’s called Navigation. So, you’ll find it at /app/code/core/Mage/Catalog/Block/navigation.php. It works the same way for any other publisher, module, type and class. If the class name has more than four parts, such as “Mage_Catalog_Model_Category_Api_V2″, look for subfolders with those names. That class is at /app/code/core/Mage/Catalog/Model/Category/Api/V2.php.

/app/design contains all of Magento’s templates, split up by frontend/backend, then by base/default, then by theme name and finally by module [mostly corresponding to each of the modules within the code section, above]. If you are working on a new site, one of the first things you’ll want to do is copy the modules you’re working on from /app/design/frontend/base/default into /app/design/frontend/default/default so that you can change the templates without worrying about upgrades.

Within each theme folder there are as many as four subfolders: etclayoutlocale, and template.

  • etc contains basic config files for the theme.
  • layout contains configuration files for each module, which you can use to include blocks and other templates, and in some cases do a whole lot more.
  • locale contains language files, allowing you to translate pages [or change words] without touching the actual templates.
  • template contains the actual HTML for each module, split up into a number of .phtml files.

Looking for the page wrapper? That’s in /app/design/frontend/*/*/template/page. Inner-page templates are there; the header, footer and other includes are in the html subfolder.

If you’re going to change any styles, there’s one more place that will interest you…

/skin contains all CSS, Javascript and image files. The folder structure is exactly like /app/design–follow the folder tree until you get to the files for your skin.

 

There are three more things you should know before you dig in.

First, Magento’s caches are all enabled by default. I don’t know how many hours I’ve burnt trying to figure out why the heck changes I made weren’t doing what they should… just to realize that it was being cached. You can [and should] disable these while you’re working on the site in Admin > System > Cache Management. Select all, actions -> disable, submit.

Second, there’s an invaluable free extension called the Developer Toolbar. It adds a toolbar to the bottom of the site with a number of handy links that control various settings in Magento. One in particular is incredibly useful: enabling “Frontend Hints” shows you exactly where in the code and in the templates that every single part of the page is coming from. Don’t try to search for where something on the page is coming from–enable the frontend hints and you should be able to figure it out within ten seconds.

Third, everything in Magento will inherit. For templates, Magento will look for a template file within your specific theme. If that doesn’t exist, it’ll try to load it from the default theme; if that doesn’t exist, it’ll fall back to the base skin. The same thing applies to config, layout and locale files. Similarly with classes: You can overload any core class through the community or local folders.

 

Magento is an open source eCommerce solution. It comes with a variety of tools, necessarily for building a successful online shop. Magento offers a lot of built-in capabilities, such as promo pricing and coupon codes, detailed statistics, and SEO options.

This Magento tutorial will provide you with comprehensive installation instructions for Magento shopping cart and will also show you how to create and manage a web site using Magento.

Magento tutorial covers the following topics:

  • Magento installationHow to install Magento shopping cart on your hosting account and how to use Magento encryption key to secure data
  • Magento featuresWhich are the main Magento features
  • Create a web store with MagentoLearn how to start creating your Magento web store – how to manage Magento categories, how to set special prices and promotions in Magento and how to process Magento orders
  • Magento productsHow to add new products in Magento – how to add images, how to manage product promotions and how toimport products in Magento, how to add quantity to Magento products
  • Magento themesHow to change Magento themes – where to find Magento themes and how to upload the new theme to your store
  • Magento CMSHow to use Magento CMS options to manage your shop pages
  • Magento SSLHow to set SSL certificate in Magento
  • Magento customer managerHow to use Magento customer manager
  • Magento modulesHow to add Magento modules with Magento Connect. How to configure Magento shipping modules andMagento payment modules
  • Magento issues and problems10 most common issues and problems with Magento
  • Magento newsletterHow to send newsletters with Magent
  • Magento widgetsHow to use Magento widgets
  • Magento SEOHow to optimize your shop for the Search engines (SEO)
  • Google Analytics for MagentoHow to configure Google Analytics for Magento
  • Move MagentoHow to transfer Magento to another location

magento-mvc-flowchart

 

Magento mvc flow chart image