Unable to override Fulltext\Collection in module et/di.xml

[joachimVT]

Preconditions

1. Magento 2.1.1
2. Using Ubuntu/trusty64 vagrant-box, php7, apache

Steps to reproduce

1. Add a new custom module
2. Update etc/di.xml in your custom module

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../../../lib/internal/Magento/Framework/ObjectManager/etc/config.xsd">
    <preference for="Magento\CatalogSearch\Model\ResourceModel\Fulltext\Collection" type="Sanimarkt\App\Model\ResourceModel\Fulltext\Collection" />
</config>

3. Add new Collection.php file and override _renderFiltersBefore() method

<?php

namespace Sanimarkt\App\Model\ResourceModel\Fulltext;

/**
 * Fulltext Collection
 * @SuppressWarnings(PHPMD.CouplingBetweenObjects)
 */
class Collection extends \Magento\CatalogSearch\Model\ResourceModel\Fulltext\Collection
{
 protected function _renderFiltersBefore()
 {
  die('stopping here');
 }
}

4. clear cache
5. Make a search request

Expected result

1. The search request should stop and show 'stopping here' on the screen

Actual result

1. Nothing happens the custom class Sanimarkt\App\Model\ResourceModel\Fulltext\Collection.php is not executed.

[igrybkov]

Hi,

Thanks for reporting this issue.

We've created internal ticket MAGETWO-64162 to address this issue.

The reason why it doesn’t work now is because the class \Magento\CatalogSearch\Model\ResourceModel\Fulltext\Collection is used in the CatalogSearch with customization through virtual types and there is no direct usage of this class.
Customization of the source class for a virtual type is not possible because the ObjectManager resolves preference before resolving is a virtual type used and if that, then which class it should instantiate.
However, with the current implementation, you can customize specific virtual types and it should help you.

In Magento 2.1.3. I can find only one virtual type for the class Magento\CatalogSearch\Model\ResourceModel\Fulltext\Collection:

<virtualType name="Magento\CatalogSearch\Model\ResourceModel\Fulltext\SearchCollection" type="Magento\CatalogSearch\Model\ResourceModel\Fulltext\Collection">
    <arguments>
        <argument name="searchRequestName" xsi:type="string">quick_search_container</argument>
    </arguments>
</virtualType>

So to resolve your problem you may define preference for the virtual type:

<preference for="Magento\CatalogSearch\Model\ResourceModel\Fulltext\SearchCollection" type="Sanimarkt\App\Model\ResourceModel\Fulltext\Collection" />

[maghamed]

Hi @joachimVT ,

Could you please provide a bit more details why do you need to extend search Collection?
I am asking because extending of this specific collection is not a good idea (actually Magento discourages inheritance for all classes and entities in general in favor of composition and customization with a help of Dependency Injection/Plugins/Event Observers etc., but especially Search collection is very fragile and overwriting some of the logic inside could lead to broken search functionality).

This happens because of the Search Collection design.
\Magento\CatalogSearch\Model\ResourceModel\Fulltext\Collection plays a role of CatalogSearch API.
It uses another Search API (API of module Search - \Magento\Search\Api\SearchInterface) inside (in the method - _renderFiltersBefore). So, after _renderFiltersBefore executed we already have search results and Layered Navigation built. So, for example, applying additional filters to the Select object after that stage will break Layered navigation values.
Overwritten of its logic also a bad idea, because guaranteeing of consistency that total results count and Layered Navigation count are equal becomes your responsibility.

That's why it's better to leave \Magento\CatalogSearch\Model\ResourceModel\Fulltext\Collection as is, and customize its behavior with other mechanism. We could advise you how to better solve your specific task if you will shed some light and provide more details.

[sergei-sss]

Customization of the source class for a virtual type is not possible because the ObjectManager resolves preference before resolving is a virtual type used and if that, then which class it should instantiate.

I don't understand, It is bug or feature? )
Here KAndy wrote, that is a bug and it worked before developer beta.

[igrybkov]

In the comment you mentioned, @kandy talking about an ability to use plugins with virtual types and that's another issue. I'm not sure is it fixed or not, but that's not the same issue as this one.
In this issue, we're discussing the case when the developer wants to override the class from which virtual types are built.
Actually, I've got an update regarding this case. We've decided that this is not an issue and this restriction to rewrite source class of a virtual type is totally correct, and this behavior should not be changed. That's true because in another way it's too easy to break the code which relied on that behavior through a virtual type.
So, the right way to do such customizations is to set the preference for each specific virtual type.

[korostii]

@igrybkov, great comment, thank you for the clarification!

So, the right way to do such customizations is to set the preference for each specific virtual type.

Now that's something that should be put into the devdocs for good.

[igrybkov]

@korostii, probably it should be documented as an answer to the question "how to override virtual type" or even "what to do when I want to override a class which is used as virtual type", but in general, as @maghamed said, Magento discouraging inheritance, and for each specific case it's better to find the way how to customize behavior using plugins and specific API/SPI or another extension points.
For example, the initial case for this issue is an example when developer chose inheritance instead of existing customization point through the Search API. I'm not sure what actually @joachimVT tried to customize, but there should be used another extension point (something behind Search) - which one depends on the specific customization needs. Anyway, if it's something impossible to customize through existing extension points (Search API in this case), then the issue should be raised regarding this case and inheritance may be used as a workaround until an issue will be fixed. But it's never the preferred way to solve the problem.

[joachimVT]

@igrybkov The reason I want to customize the search engine is to use Logical AND search I know this is possible by using the SEARCH REST API (http://devdocs.magento.com/guides/v2.0/howdoi/webapi/search-criteria.html#logical-and-search)

But I wanted this to be possible by searching in the standard search form.

[m2developer]

@igrybkov Thanks for the explanation.

Right now I have same requirement (I mean to override search collection, with your comment I can able to override the class), But can;t get any search result.

Before overriding I am getting the search result and after overriding I am not getting any search result. Even I tried to search with exact product name but couldn't get any search result. Any comment for this ?

Note : I done the di;compile and cache:flush after changes in di.xml.