Magento image quality on resize – GD library white color loss

When magento resizes images, resized images always loss their original colors. whether you set quality to 100 or not. Maybe it’s okay to live with to some of us.

But what if it’s true color such as white(#FFF) or black(#000)? As far as I tested, GD2(magento default image lib) doesn’t really handle well with these. So if you really want to keep white color as white then you will need some update on magento’s GD2 file.

So here is the sample code for fixing white color issues.

Magento Backend Tutorial – Application Directory Structure / Coding Standards

Application Directory Structure

  • app – core & extended application code, templates, layout, translation, configuration.
    • app/code – application code (see more: code pools).
    • app/design – frontend and admin templates & layout XML files.
    • app/etc – system configuration files (ex. database connection), and module declaration (pools, namespaces, and dependencies).
    • app/locale – localization.
  • js – JavaScript libraries (ex. Prototype). Do not put skin specific JavaScript files into this directory.
  • lib – PHP libraries which Magento, or its modules, depend upon (ex. Zend Framework).
  • media – storage of product images, category images, CMS WYSIWYG, etc.
  • skin – CSS, JS, and images that are unique to a given theme.
  • var – dynamically created system files (ex. cache, FPC, sessions, index locking).

Magento Backend Tutorial – Using Collections

Magento provides a robust ORM for accessing data from various modules, without having to write any SQL. It also provides abstraction for the underlying RDBMS.

An example below illustrates loading of a product collection, if our task required getting names and SKUs of all simple products in the system, which are enabled, sorted by SKU:

$products = Mage::getModel('catalog/product')
  ->addFieldToFilter('status', Mage_Catalog_Model_Product_Status::STATUS_ENABLED)
  ->addFieldToFilter('type_id', Mage_Catalog_Model_Product_Type::TYPE_SIMPLE)
  ->setOrder('sku', 'asc')

Magento Backend Tutorial – Rewriting Modules

Module rewriting should be the second choice, after it is determined to be the absolute necessity, and impossible to achieve with the use of observers.

Do not use local/Mage

It may be tempting to simply copy the desired files, in their entirety, from core/Mage to local/Mage, but this method violates Magento coding standards. This method technically functions due to Magento’s autoloader searching for the given classes inside the local pool, before proceeding to the core, effectively forcing the copied classes to be loaded first. This is considered to be bad practice, as it makes upgradability significantly more difficult. Even a minor version bump is meant to replace all files inside core/Mage. If any of these files are rewritten in local/Mage, then the updated files will never be executed, and outdated versions from local scope will continue to be used. Furthermore, copying of entire files, rather than rewriting specific methods, include redundant code, that is not necessarily being changed. Edits and customizations become difficult to track and maintain.

Magento Backend Tutorial – Observers

Observers are the preferred way of extending Magento’s core functionality. Observers simplify upgradability of code, as they do not overwrite any core classes. Furthermore, they reduce the possibility of conflict between modules and extensions. Multiple modules can observe the same event. To accomplish a similar task using rewrites, class chaining would be required.

The example below will illustrate observing an event which fires after a product is added to a cart.

config.xml (app/code/local/YourTheme/Example/etc/config.xml)

<?xml version="1.0"?>

Magento Backend Tutorial – Module Structure

Code pools

  • community – reserved for extensions available through public marketplaces (ex. Magento Connect).
  • core – contains the base Magento application, separated into two namespaces: Mage & Enterprise. Files in this pool should never be edited directly.
  • local – customizations, overrides, etc. should all be placed into this namespace.

Namespaces & modules