How the `media_image` Frontend Input Drives Product Image Detection in OpenMage Image Cleaner

The OpenMage Image Cleaner identifies product images by querying EAV attributes where frontend_input equals media_image, automatically detecting both default and custom image attributes without hard-coding specific attribute codes.

The media_image frontend input type is the standard Magento convention for attributes storing product image file names. In the fballiano/openmage-image-cleaner repository, this metadata field serves as the primary filter for discovering which database columns contain valid image references. By leveraging this architectural convention, the cleaner dynamically adapts to custom attributes while maintaining compatibility with native fields like image, small_image, and thumbnail.

How Product Image Detection Works in the Cleaner

The detection process relies on the Entity-Attribute-Value (EAV) architecture of Magento. Instead of hard-coding attribute codes such as base_image or thumbnail, the cleaner queries attribute metadata to find all fields designed to store images.

Querying the EAV Attribute Table

In app/code/community/Fballiano/ImageCleaner/controllers/Adminhtml/FbimagecleanerController.php, the syncproductAction() method first retrieves every attribute ID marked with the media_image input type:

$attributes = $db->fetchCol(
    "SELECT attribute_id FROM {$resource->getTableName('eav_attribute')}
     WHERE entity_type_id={$entity_type_id}
       AND frontend_input='media_image'"
);
$attributes = implode(",", $attributes);

This query returns identifiers for all image-holding attributes, including custom fields added by extensions or merchant configurations.

Retrieving Image Values from Product Entities

With the attribute IDs collected, the cleaner pulls the actual file names from the catalog_product_entity_varchar table:

$db_images = $db->fetchCol(
    "SELECT value FROM {$resource->getTableName('catalog_product_entity_varchar')}
     WHERE value IS NOT NULL AND LENGTH(value)>0
       AND entity_type_id={$entity_type_id}
       AND attribute_id IN ($attributes)
       AND value <> 'no_selection'"
);
if ($db_images) $db_images = array_map([$this, 'removeLeadingSlash'], $db_images);

This captures all stored image paths while filtering out null entries and the placeholder string no_selection.

Normalizing and Merging Gallery Data

The raw values undergo normalization via removeLeadingSlash() to ensure consistent path formatting. The cleaner then merges these EAV attribute values with entries from the catalog_product_entity_media_gallery table and placeholder configurations. The consolidated list represents all legitimate product images currently referenced by the database.

Implementation Details in syncproductAction()

The synchronization logic resides entirely within the syncproductAction() method of the admin controller. This function orchestrates the database queries, path normalization, and file-system comparison that ultimately populates the fb_imagecleaner_image table with unused file records.

The method executes a three-phase detection strategy:

1. Attribute Discovery: Query eav_attribute for frontend_input='media_image'
2. Value Extraction: Select from catalog_product_entity_varchar using the discovered attribute IDs
3. Path Sanitization: Apply array_map([$this, 'removeLeadingSlash'], $db_images) to standardize paths before comparing them against files in media/catalog/product

Product vs. Category Image Detection

The cleaner distinguishes between product and category image storage conventions through specific frontend input filters. While products utilize media_image, category images employ a different metadata marker.

Category Images Use frontend_input='image'

In the same controller file, the synccategoryAction() method queries for frontend_input='image' instead of media_image:

$attribute = $db->fetchRow(
    "SELECT attribute_id FROM {$resource->getTableName('eav_attribute')}
     WHERE entity_type_id={$entity_type_id}
       AND frontend_input='image'"
);

This distinction ensures the cleaner correctly interprets the EAV structure for each entity type without conflating product media attributes with category image fields. Supporting utility methods in app/code/community/Fballiano/ImageCleaner/Helper/Data.php—including scandirRecursive() and getMediaDirByEntityTypeId()—handle the subsequent file-system scanning after these database queries establish the baseline of used images.

Summary

• The cleaner detects product images by filtering EAV attributes where frontend_input='media_image', covering both native and custom image attributes.
• Attribute IDs retrieved from eav_attribute drive queries against catalog_product_entity_varchar to extract actual file names.
• Path normalization via removeLeadingSlash() ensures accurate comparison with files stored in media/catalog/product.
• Category images use a different filter (frontend_input='image'), demonstrating the input type's role in entity-specific detection logic.
• Unreferenced files discovered through this process are logged in fb_imagecleaner_image for subsequent cleanup operations.

Frequently Asked Questions

How does the cleaner handle custom product image attributes?

When merchants or extensions create custom image attributes using the media_image frontend input type, the cleaner automatically includes them in its detection queries without requiring code modifications. The EAV metadata query discovers these attributes dynamically, ensuring comprehensive coverage of all image fields.

What database tables does the cleaner query to find product images?

The process involves two primary tables: eav_attribute (to identify which attributes store images) and catalog_product_entity_varchar (to retrieve the actual file path values). The results are then cross-referenced with catalog_product_entity_media_gallery to ensure comprehensive coverage of all referenced images.

Why does the cleaner use different frontend_input values for products and categories?

Magento's EAV architecture assigns media_image to product entities and image to category entities. The cleaner respects this architectural distinction by querying syncproductAction() for media_image and synccategoryAction() for image, ensuring accurate entity-type detection and preventing false positives in image identification.

What happens to image files that are not detected in the database?

Files existing under media/catalog/product that do not appear in the consolidated list of database-referenced images are flagged as unused. These paths are inserted into the fb_imagecleaner_image table, where they remain available for review and deletion through the admin interface.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}