A tutorial to enable Firebug console.log in Magento

Firebug is probably one of the most used extensions for developpers.

One of the common firebug extension usage is to log and debug elements in console; this is done through the syntax:


console.log(somethingtolog);

Problem is this syntax does not render anything with Magento. This tutorial will help you to reactivate this functionnality:

Why cannot we use console.log syntax within Magento?

For security reasons, Varien has rendered silently all the methods availables on console object. This is made in the js/varien/js.js javascript file:

js.js file is loaded on frontend and adminhtml default layout; so in every page, we won’t be able to use console

Well, and how are we gonna be able to use it?

How will we be able to reuse the console methods?

I hope that you’ve not thought of edit js.js and comment the varien code…. 🙂

We will keep the native functions but want to be able to use it for developments purpose.

Because this is a javascript framework file, we cannot use the skin overload mechanism. So, we’ll load a copy of the native script but only for development purposes

Make a copy of the original js.js file

cd js/varien
cp js.js jswithconsole.js

Commnent the original code source that disables the console methods

In the copy, we’ll comment the console function overload. You should have something like this:

Load firebug console native methods only for Magento developments purposes

In vhost configuration file, or .htaccess file, we’ll replace our file with the new one containing the following rewrite rule:

<IfModule mod_rewrite.c>

############################################
## enable rewrites

    Options +FollowSymLinks
    RewriteEngine on
## begin update to load a specific file 
## which enable firebug console when developper mode is set
## http://blog.kyp.fr
    RewriteCond %{REQUEST_URI} js/varien/js.js
    RewriteCond %{ENV:MAGE_IS_DEVELOPER_MODE} =1
    RewriteRule ^js/varien/js.js$ /js/varien/jswithconsole\.js [R=302,L]
## end update
...
</ifModule>

Make sure that MAGE_IS_DEVELOPER_MODE value can be tested

The only problem with this rewrite rule is that we test a value for an environnement variable. It will never work if you used to declare MAGE_IS_DEVELOPER_MODE with the following syntax:

	<Directory /your/magento/root/folder>
		Options Indexes FollowSymLinks MultiViews
		AllowOverride All
		Order allow,deny
		allow from all
		DirectoryIndex index.php
		setEnv MAGE_IS_DEVELOPER_MODE "1"
	</Directory>

One way to ensure that testing environnement value will work could be the following MAGE_IS_DEVELOPER_MODE definition:

	<Directory /your/magento/root/folder>
		Options Indexes FollowSymLinks MultiViews
		AllowOverride All
		Order allow,deny
		allow from all
		DirectoryIndex index.php
		#setEnv MAGE_IS_DEVELOPER_MODE "1"
		SetEnvIf _ .* MAGE_IS_DEVELOPER_MODE=1
	</Directory>

Magento multistore model: in which default language do I have to describe best my sales catalog?

One of the Magento amazing feature is the ability to manage different stores in different languages: You can administrate many websites to share a common sales catalog in a same Magento host

Magento configuration hierarchy is based upon a cluster of website, stores and store views. The following schema is an exemple of a possible Magento multi store usage: We have two websites; the first one is available in French and English, the second one in Japanese and Chinese

Magento products are initially in a code pool not linked to a website. Linking a product to a website renders it available for sale. But if you share this sales catalog within different languages, it’s interesting to take time to define in which default language you’ll define your catalog, the language for the product code pool / default scope

Take a look at the following example:

  • If you store your catalog in French, you only have to overload description for English store view.
  • If you store your catalog in English, you must make two times the same work for the French stores views

Take care also of your deploying plan: if you plan to open many website for south america, perhaps it could be interesting to set up your catalog in spanish instead of you using your native language: describe a catalog is a long task, and time is money

So you should always use the most used language

Zend_Cache component usage in Magento

Magento performances is a hot topic subject. One element of the Magento performance is the cache block policy which allows to store in cache part of the page content: You probably have all read the tutorial available through the Magento wiki, written by my old colleague Laurent BOURREL, about the cache block policy available in Magento.

All concepts of this policy are based upon Zend_Cache component. Let’s see how Magento use it

Reminder about Zend_Cache component

Zend cache module structure

Zend_Cache component is divided into two parts, frontends and backends models:

  • Frontend components define what is covered by cache policy:
    • Files
    • Output rendering
    • Method call
    • Class
  • Backend components define where will be stored cached data:
    • In file
    • In memcached
    • In apc
    • ….

This model allows to easily dissociate which data will be cached, and where they will be cached

Zend_Cache usage in Magento

Embedded Zend_Cache backend in Magento

If we check Zend framework version from CE 1.3.2.4 to CE 1.7.0.0 (and related Entreprise versions), we should be able to use the following backend within Magento:

CoreApcBlackholeFileLibmemcachedMemcachedSqliteStaticTestTwolevelsXcacheZend_PlateformZend_Server diskZend_Server shared memory
CE 1.3.2.41.7.2
CE 1.3.3.01.7.2
CE 1.4.0.11.9.6
CE 1.4.1.01.9.6
CE 1.4.1.11.9.6
CE 1.4.2.01.10.8
CE 1.5.0.11.11.1
CE 1.5.1.01.11.1
CE 1.6.0.11.11.1
CE 1.6.1.01.11.1
CE 1.6.2.01.11.1
CE 1.7.0.01.11.1
EE 1.6.0.01.9.3PL1
EE 1.7.0.01.9.6
EE 1.8.0.01.9.6
EE 1.9.0.01.10.5
EE 1.9.1.11.10.8
EE 1.10.0.11.11.1
EE 1.10.0.21.11.1
EE 1.11.1.11.11.1
Loaded from Zend FrameworkAdded or updated by Magento sources, but available

How does Magento use Zend_Cache?: the factory Mage_Core_Model_Cache

Before CE 1.4, Cache factory was made by the Mage_Core_Model_App model

Since Magento CE 1.4, all cache management is done through the Mage_Core_Model_Cache class; this class is a factory model that will load the Zend_Cache frontend and backends

Magento Zend_Cache frontend

In Mage_Core_Model_Cache, Frontend class is hard coded and restricted to Varien_Cache_Core. Varien_Cache_Core inherits from the frontend class Zend_Cache_Core.

So we are unable to use natively other frontends than Zend_Cache_Core

Magento Zend_Cache backend

Why is there some Backend available in Magento which does not exist in Zend_Cache component?

But this factory method also provides the ability to use some other backends storage that does not exist in Zend_Cache; see the following examples :

  • Database
  • Eaccelerator

These backends have been written by Varien core team

In conclusion, the Zend_Cache backend defined by Magento are the following ones
CoreApcBlackholeFileLibmemcachedMemcachedSqliteStaticTestTwolevelsXcacheZend_PlateformZend_Server diskZend_Server shared memoryEacceleratorDatabase
CE 1.3.2.41.7.2
CE 1.3.3.01.7.2
CE 1.4.0.11.9.6
CE 1.4.1.01.9.6
CE 1.4.1.11.9.6
CE 1.4.2.01.10.8
CE 1.5.0.11.11.1
CE 1.5.1.01.11.1
CE 1.6.0.11.11.1
CE 1.6.1.01.11.1
CE 1.6.2.01.11.1
CE 1.7.0.01.11.1
EE 1.6.0.01.9.3PL1
EE 1.7.0.01.9.6
EE 1.8.0.01.9.6
EE 1.9.0.01.10.5
EE 1.9.1.11.10.8
EE 1.10.0.11.11.1
EE 1.10.0.21.11.1
EE 1.11.1.11.11.1
Loaded from Zend FrameworkAdded or updated by Magento sources, but available

So we will update the available zend_cache backend list according to Magento versions:

And so, what If I want to use a backend that has not been thought of by Varien?

Perhaps you can want to use blackhole, test, or zend_plateform backend for exemple. Is it really difficult? no

Since Mage_Core_Model_Cache model exists (CE 1.4.0.1 and higher, related EE) the factory method has been also thought so that perhaps you want to use another backend :

The value defined in the local.xml node <config><global><cache><backend> can be a class name that implements the Zend_Cache_Backend_Interface.

So, and for my backend configuration? To specify some parameters to this new backend one, you can define a node <config><global><cache><backend_options> which will be passed as arguments when constructing the backend model

Other possibilities to use a custom backend model are the following ones:

  • Define your own backend class that will set up the expected configurations values
  • Overload Mage_Core_Model_Cache to be able to provide other configurations loading

Here’s an example of specific configuration you can have and which works

Conclusion about Zend_Cache usage in Magento

cache tags, cache lifetime and cache key are concepts brought by the zend_cache component

Even if there is no documentation about how to use some custom backend in Magento, it’s not really difficult: just specify the full backend class name in local.xml backend node, and specify arguments through the backend_options node

The only problem I can see with this method that is able to load any backend class is the method used to check if backend exists: it uses class_exists method, which, In Magento context, throws a fatal error if the class cannot be found. It could be interesting, if we provide a backend class which does not exist, that the default one (file) would be used instead of throwing a fatal exception

Updating zend_cache frontend class is quite difficult because it depends on how PHP code was written. So for now, even in Magento 4, 5, I’m not sure that we can use the buffer frontend

Have Zend Studio and Eclipse PDT faster with Magento projects: the build path configuration

Eclipse PDT editors like Zend Studio analyse the PHP source code to enable autocompletion: they analyze source files and index content found in

Magento embeds more than 10000 files (7000 php files) in Magento 1.7.0.0. Do we need to index all content? no

To ensure that eclipse and Zend studio will offer you all the expected functionalities, you can make it faster, by removing all the non required editor files from editing build path.

What is Zend studio and Eclipse PDT build path?

Build path defines classpath for your project: folders that will be analyzed by editors to index content and where look for methods.

All build path sources defined within will be made available for Content Assist options, including source code completion

Basic configuration of the build path directive in Magento projects

Folders that we can remove from build path could be the following ones:

  • var: contains variables Magento data. Too much volatil, there is no real reason to include it in build path
  • media: all media elements used on your website. It should contain all picture files from your website and so there is no reason to analyse binary sources
  • skin: even if skin folder can contain js files, we can remove it
  • app/locale: for the time being, there is no link between magento translations calls and translations files. so we can also remove it
  • app/etc: like translations files, we can remove it
  • If you do not enable javascript support on your magento project, you can also remove the js folder

    How to configure build path with Zend Studio and eclipse PDT?

    On your Magento project, click right on the project and edit the build path configuration menu through the menu configure build path

    You’ll have a new window which look like this one:

    And then edit the excluded folders in list. When finished, eclipse will rebuild the build path with your new configuration

    By updating the build path, you can reduce by 30 percent number of files analyzed by eclipse. Even if you use some ssd disks, your eclipse should be faster. so if you use some slower disks or use shared networks folders, you should not forget to use this configuration value