Bitrix. Integration. Implementing a catalog with two item group structures

    Disclaimer


    This article is not a campaign for any CMS, no matter how good or bad it is ...

    Prologue


    One of the very first and most common problems that pops up when starting work on the integration of 1C and the online store is the problem of the directory structure. As a rule, the nomenclature structure available in the customer’s 1C database, to put it mildly, is not ready for export to the site, and the customer is extremely opposed to changing it, because the business process has been worked out, everyone is accustomed to such a structure as there is, and no one has the slightest desire to change their habits.
    What do we usually do in this situation? I think that the same as the others, we create an alternative structure, all products are attached to it and the new structure is uploaded to the site, and the old one remains untouched in the 1C database. In the end, everyone is happy. To implement this in conjunction with Bitrix, it is enough to slightly modernize the unloading that comes with the kit ... *

    * - By writing this article, it was planned before the release of the 12th version of Bitrix and updating the upload, respectively. Now staffing functionality has been announced to create a directory structure different from that used in the 1C database. Yes, of course, the presence of full-time functionality is great, but still, it seems to me that it is not always convenient to do the structure adjustment during the configuration of unloading, and therefore I would prefer, as before, to implement a separate structure in the form of a separate directory. But this is a matter of the situation and the taste of each ...

    So, when the problem of structure is caused only by a reluctance to change the basic structure - we can easily solve the problem of substituting groups. But, what if, after all, such a hierarchy in the database is not just a whim, but a requirement of a business process? ..

    Task


    So once we got such a task. This time everything is more interesting, the need has been added to link discounts to groups of goods, not to new ones, but to those that are in the database. For example:

    There is the following hierarchy in the database (in the example I selected the groups based on the manufacturer, in the real database there was no common logic, for example, some groups could be by manufacturer, part by supplier, and part by type of product in general):

    Philips
    	TV P11 - 100rub
    	Iron P11 - 50rub
    Samsung
    	TV S11 - 110rub
    	Phone S11 - 80rub
    


    The hierarchy in the online store is different:
    Equipment
    	Irons
    		Iron P11
    	TV sets
    		TV P11
    		TV S11
    	Phones
    		Phone S11
    


    Suppose that counterparty A has a 10% discount on all products in the Philips group and 15% on Samsung products. And counterparty B Philips - 20%, and Samsung products - 30%.

    Then, it turns out that counterparty A should see the directory like this:
    Equipment
    	Irons
    		Iron P11 - 45rub
    	TV sets
    		TV P11 - 90rub
    		TV S11 - 93.5rub
    	Phones
    		Phone S11 - 68rub
    


    Counterparty B:
    Equipment
    	Irons
    		Iron P11 - 40rub
    	TV sets
    		TV P11 - 80rub
    		TV S11 - 77rub
    	Phones
    		Phone S11 - 56rub
    


    Bitrix has an excellent mechanism for working with discounts, and I would not really want to touch it, because these changes would draw a ton of other edits. Yes, of course, theoretically, it would be possible to make discounts not on an item group, but on a specific product, but then when unloading you have to pull a set of discounts for each product. And now there are about 10 thousand products and about a thousand counterparties in the database, each of which can have a couple of dozens of unique discounts and, moreover, the database is growing, counterparties are being added ... This approach was immediately discarded.
    Obviously, the site needs to know both group structures in order to rely on the first to calculate the price, and based on the second to build a catalog tree.

    Decision


    To solve this, we will need a very convenient property of the information block element in Bitrix - “Binding to sections”. And it’s convenient in that when using the Bitrix API to get a list of elements, the CIBlockElement :: GetList function will return not only the elements that are in this group, but also elements that have a binding through the “Bind to sections” property. It is also interesting that a section of the same infoblock cannot be selected for the "Binding to Sections" property, although at the same time, the similar "Binding to Elements" property does not impose such restrictions. This immediately suggests that there should be two infoblocks in one, the first structure with the elements themselves, and in the second group alternative groups.
    It would seem that everything, the issue has been resolved, since everything is provided for at the module level, then there should not be any further problems, we take the group of the second information block as the basis, and pull out the elements of the first. But it was not there. The standard component of the catalog is not able. A support request confirmed that this was not possible. But why? After all, there is everything for this, and the necessary property and even the platform itself is sharpened to make such selections, but, alas ...

    Yes, of course, no one bothers to make your component and do anything there, but, firstly, it will significantly increase the time development, and hence cost, and secondly, it was curious what was in the standard component that was interfering. It was decided that we will pick the regular catalog and, if possible customizing it, implement support for the functionality we need.

    First, create 2 info blocks described above, hammer in the test information, set up the binding. It should turn out like this:



    (on the left side we see two information blocks described above, and on the right the elements of the Phlips section of the first information block)



    (and here on the right side we see elements of the Samsung section of the first information block)

    If we open the main page of the catalog, we will see sections of our information block:



    If we go to the section, for example, Televisions, then make sure that it is empty:



    So, here we start. The catalog component we use is multi-page. Inside, it consists of a set of one-page components.
    Section.php of the main catalog component is responsible for displaying the contents of a specific section. We open it and find the place where the one-page component bitrix: catalog.section is called. This is a one-page component that displays a list of elements. Immediately copy it to the custom directory and replace the call with custom: catalog.section.
    Open the component.php file responsible for the logic of the custom: catalog.section component. we find the interesting (yes, actually it is the only one there) call of the CIBlockElement :: GetList API. We are interested in $ arFilter, because it is this parameter that determines which records will be filtered. A little higher we find the place where $ arFilter itself is defined:
    $arFilter = array(
    	"IBLOCK_ID" => $arParams["IBLOCK_ID"],
    	"IBLOCK_LID" => SITE_ID,
    	"IBLOCK_ACTIVE" => "Y",
    	"ACTIVE_DATE" => "Y",
    	"ACTIVE" => "Y",
    	"CHECK_PERMISSIONS" => "Y",
    	"MIN_PERMISSION" => "R",
    	"INCLUDE_SUBSECTIONS" => $arParams["INCLUDE_SUBSECTIO
    NS"],
    );
    

    The reason why the component does not see our elements is visible - "IBLOCK_ID" => $ arParams ["IBLOCK_ID"]. With this line, we filter out all the elements that are outside our infoblock, and we have two infoblocks, in one element and in the other sections we need. In principle, it’s enough to remove this line, refresh the page of the TVs section and we will see that our elements have appeared:



    Everything is fine, but when we removed filtering by the information block, the GetList function now searches for elements of all information blocks, even those that we don’t need at all, which obviously will not add performance. Therefore, it is best to customize the catalog component itself, add an additional parameter ID_IBLOCK2 to it, pass it to the custom: catalog.section component. Accordingly, the definition of $ arFilter will look like this:
    $arFilter = array(
    	"IBLOCK_ID" => $arParams["IBLOCK_ID2"],
    	"IBLOCK_LID" => SITE_ID,
    	"IBLOCK_ACTIVE" => "Y",
    	"ACTIVE_DATE" => "Y",
    	"ACTIVE" => "Y",
    	"CHECK_PERMISSIONS" => "Y",
    	"MIN_PERMISSION" => "R",
    	"INCLUDE_SUBSECTIONS" => $arParams["INCLUDE_SUBSECTIONS"],
    );
    

    That's it, now everything is fine with the list of elements, but if we try to open the product card page, for example, P11 TV, we will see an error:



    Everything is the same here, we cured catalog.section, and catalog.element is still looking for our product in another information block. We customize it too. We find the line at the very top:
    $arParams["IBLOCK_ID"] = intval($arParams["IBLOCK_ID"]);
    

    Accordingly, we change it to:
    $arParams["IBLOCK_ID"] = intval($arParams["IBLOCK_ID2"]);
    

    And success, the product card began to open:



    That's it. You can create discounts for the groups of the first information block and everything will work when building the catalog.
    The solution was tested on a working site with ~ 10 thousand products, with three types of prices, 1000 counterparties and more than 5 thousand discounts.

    Epilogue


    With such simple manipulations, we solved the task and realized an interesting functionality that I think is far from being demanded in our only case ... I don’t see any obstacles to implement this functionality from the box, but, alas, alas ...

    If it’s interesting, I can in the following articles to share other recipes, which are also not immediately obvious to a person who does not have sufficient experience with Bitrix, but are often useful.

    P.S


    Thank you all for your attention! I will be glad to your comments, questions, discussions.
    If you notice a typo or any kind of error, a welcom in drugs;)

    Also popular now: