Magento 2 Custom Product Sorting: Move Products Without Images to the End

How Did We Discover the Need to Demote Un-Imaged Products in Magento 2?

While working on an enterprise retail eCommerce platform, we encountered a situation where product synchronization from a legacy ERP system was causing significant user experience issues. The platform synced thousands of products daily, but digital assets—specifically product images—often arrived in a secondary batch process hours later. Because the default category sorting prioritized the newest items, visitors were greeted with pages full of “placeholder” images.

This delay directly impacted conversion rates. Shoppers landing on category pages assumed the site was broken or lacked inventory, causing bounce rates to spike. We realized we needed to dynamically push any product missing a valid image to the very end of the category listing, effectively hiding them on the last pages until their assets arrived. This challenge inspired this article, as we frequently see teams attempt to solve this using inefficient frontend hacks rather than sound backend architecture.

Why Do Products Without Images Disrupt eCommerce Conversion Rates?

In a high-volume retail environment, the category listing page is the primary engine for product discovery. When products without images appear at the top of a category, it creates friction in the purchasing journey. From a business perspective, allocating premium top-of-page digital real estate to incomplete product profiles wastes marketing spend and lowers the return on ad spend (ROAS).

From an architectural standpoint, Magento 2.4.x utilizes complex search and indexing mechanisms (typically OpenSearch or Elasticsearch) alongside MySQL fallback collections. Manipulating the display order of these products isn’t just a matter of changing a visual layout; it requires altering the core product collection query before it reaches the pagination layer. If you modify this incorrectly, you risk breaking database pagination, slowing down page loads, or causing memory limit exhaustion.

What Happens When You Sort Products Incorrectly in Magento 2?

During our initial audit, we found that the internal team had briefly considered modifying the `list.phtml` template file. Their idea was to loop through the loaded `$block->getLoadedProductCollection()` on the frontend, check for images, and reorder the array before rendering the HTML.

This is a fundamental architectural anti-pattern. If a category contains 10,000 products and the pagination is set to 24 items per page, modifying `list.phtml` only sorts the 24 items *currently* loaded in memory. It does not push the un-imaged products to the last page of the 10,000-item catalog; it merely pushes them to the bottom of page one. Furthermore, attempting to load the entire collection into memory to sort it via PHP would immediately crash the server. This is exactly why companies look to hire software developer teams with deep architectural maturity—to prevent systemic performance failures caused by surface-level fixes.

How Should We Approach Custom Sorting in Magento 2 Collections?

To implement this sorting dynamically and safely, we evaluated several architectural approaches to intercept and modify the collection logic.

Could We Sort Directly in the PHTML Template?

As mentioned, doing this in the view layer is disastrous. Templates should only be responsible for rendering data, not transforming or sorting large datasets. Resorting an already paginated collection breaks the integrity of the total page count and destroys the user’s navigational experience.

What About an Elasticsearch or OpenSearch Custom Parameter?

Since Magento 2.4.x relies heavily on Elasticsearch or OpenSearch for catalog routing, a highly scalable approach is to add a custom boolean attribute (e.g., `has_image`) to the search index. You could then apply a default sort order at the search engine level. While highly performant, this requires custom indexers and complex search adapter modifications. We considered this, but opted for a more localized collection modification to keep the time-to-market short and the codebase maintainable.

Should We Use an Observer or a Plugin on the Catalog Block?

The most elegant and standard Magento 2 best practice is to modify the product collection right before it is loaded and paginated. We can achieve this by either writing an Interceptor (Plugin) around the `Layer` or `ListProduct` block, or by listening to the `catalog_block_product_list_collection` event. The event observer approach allows us to inject a custom `ORDER BY` SQL clause natively, ensuring the database handles the sorting efficiently before pagination is calculated.

How Do We Implement the Custom Sorting Plugin in Magento 2?

We finalized our approach by leveraging Magento’s native event dispatch system. By observing `catalog_block_product_list_collection`, we can append a custom `Zend_Db_Expr` to the collection’s select query. This pushes products where the `small_image` attribute is missing or set to `no_selection` to the back of the queue.

Here is a sanitized version of the architectural implementation.

1. Register the Observer (events.xml)

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Event/etc/events.xsd">
    <event name="catalog_block_product_list_collection">
        <observer name="push_no_image_products_to_bottom" instance="VendorModuleObserverSortNoImageProducts" />
    </event>
</config>

2. Create the Observer Class

namespace VendorModuleObserver;
use MagentoFrameworkEventObserverInterface;
use MagentoFrameworkEventObserver;
class SortNoImageProducts implements ObserverInterface
{
    public function execute(Observer $observer)
    {
        $collection = $observer->getEvent()->getCollection();
        
        // Ensure the small_image attribute is joined to the collection
        $collection->addAttributeToSelect('small_image');
        // Apply custom sorting using a conditional SQL expression
        $collection->getSelect()->order(
            new Zend_Db_Expr("CASE WHEN at_small_image.value = 'no_selection' OR at_small_image.value IS NULL THEN 1 ELSE 0 END ASC")
        );
    }
}

Performance Considerations: Because this modification happens at the MySQL query level (or is passed down to the active indexing mechanism depending on your data provider), pagination remains perfectly intact. The database calculates the total records and applies the offset securely. When you hire magento developers for enterprise customization, ensuring that database queries remain optimized like this is a fundamental requirement.

What Can Engineering Teams Learn From This Architectural Customization?

Building scalable enterprise extensions requires discipline. Here are the core lessons our team extracted from this optimization:

• Never Sort in the View Layer: Modifying collections inside a `.phtml` file breaks the Model-View-Controller (MVC) paradigm and destroys pagination accuracy.
• Leverage the Database Engine: Use native SQL expressions (`Zend_Db_Expr`) or search engine indexing to sort data. The database is built to sort millions of rows; PHP memory is not.
• Respect the Event Lifecycle: Utilizing `catalog_block_product_list_collection` allows you to modify the query exactly when it is fully formed but before it executes.
• Account for Attribute States: In Magento, a missing image isn’t always `NULL`. It is often stored as the string value `no_selection`. Your logic must account for both states.
• Prioritize System Stability: Simple backend changes like this prevent massive frontend JavaScript refactoring. When organizations decide to hire php developers for custom backend extensions, they should prioritize developers who look for root-cause architectural fixes rather than quick frontend patches.

How Does Custom Sorting Improve Enterprise eCommerce Platforms?

By moving the sorting logic to the collection layer via an Observer, we successfully pushed thousands of un-imaged products to the end of the catalog without impacting page load speeds. Conversion rates stabilized immediately because shoppers were only presented with fully configured, retail-ready products on the crucial first pages of discovery.

Solving complex data sorting and synchronization challenges requires engineering maturity and a deep understanding of core platform frameworks. If your organization is looking to modernize its systems, scale its architecture, or hire software developers for scalable architectures, contact us to learn how our dedicated engineering teams can deliver robust, production-ready solutions.

Social Hashtags

#Magento2 #MagentoDevelopment #Magento2Development #AdobeCommerce #eCommerceDevelopment #MagentoDevelopers #PHPDevelopment #eCommerceOptimization #OpenSearch #EnterpriseeCommerce