Moments in the development and sale of Bitrix modules

Here we’ll talk not so much about the technical aspects of Bitrix expansion (one of the reasons why they don’t like it), but rather about the moments related to the Bitrix ecosystem (another reason why they don’t like it), although technical things will also be, but to a much lesser extent, so that do not repeat the documentation.


In this article there will be no subjective assessment of cms or company, only dry facts and thoughts that will help to earn on modules. We will list the points that our own experience in selling modules through Marketplace taught us . Some of them seem very obvious and general, while others, on the contrary, are very specific to the platform, but they all relate to work on Bitrix modules, and therefore are included in the list.


This article will be useful to those who want to start selling their modules on Marketplace or promote their company with his help.

Earn on support, not on purchase


Purchase, of course, may be paid, in an ideal world, it would have to be 100? the amount of earnings from ready-made solutions (for which they are ready-made), but buyers will almost always not be programmers and will not have a programmer on staff. This is the ecosystem that cms creates, and especially Bitrix.

Therefore, the tasks of integrating functionality or edits in the design often fall on the creators themselves. And since the time of programmers is expensive, you have to take money from the client on top of the purchase, and pay the client twice.


A good solution may be to reduce the price of the module, even to zero, despite the fact that you want to earn from sales, but clearly declare the price of the hour of work. With increasing autonomy of the installation, you can increase the purchase price. But autonomy will never be 100%, because sites are not always made according to Bitrix guides.


Advice, of course, is relevant only if you are going to make money on modules.


Let's be able to reinstall the module


Sometimes you just need to remove the module and reinstall it. There may be a million situations when something went wrong: the module did not download completely, somehow the updates got crooked, someone changed the source code of your solution on the buyer's website, ...


The problem is that the module needs to store data in a database or files.


When the module is completely removed, of course, it’s worthwhile to replace all traces of its presence, otherwise, by the way, you can’t pass moderation either. But when rearranging, on the contrary, you need to somehow save everything so that the user does not need to re-fill and configure everything.


To give a choice when deleting a module whether to erase data or not is the best way out in this situation, despite the fact that Bitrix usually says about the complete erasure of module traces during uninstallation.


A lot of functionality inside one module or many small modules?


I will explain the problem using the example of a comment module.


So you made such a product (comment module) and released it in Marketplace. With it, you can write comments on products. And it is even possible to delete, edit and respond to others.


But one buyer wanted all the same that you have, and even in the same design, but that they were full reviews: with ratings, photos, fields of advantages and disadvantages.


Do the second module or expand the functionality of the first? It may seem that the question is purely individual, but if you look at the entire Bitrix ecosystem: expensive cms with a lot of functionality out of the box, typical sites and even design sites are very popular in the store, development prices are quite high, you can identify the trend that redundancy and prices not so important to buyers.


It is also worth considering that buyers are often a business, therefore, sales take quite a while, and prices do not matter as much as when working with physical. persons.


Plus, we talked directly with customers and many of them replied that they bought some kind of expensive product because of which one specific chip. For example, the purchase of a website designer for several tens of thousands of rubles (with terrible reviews) happened because they liked the banners. Yes, and you probably heard stories from your customers why they want Bitrix as such, and you heard about the same answers.


Customer Support


So you have released a good module with clean and easy-to-read code, written documentation and instructions for all occasions, the module performs only its specific and explicitly stated functions, it is installed - download and use. But in real life, if there is any problem on the site in which at least somehow your module is involved, they will first write to you.


By the way, any problem that occurred on the buyer's website after installing your module and before installing another module or major design changes will be considered a problem with your module. Even if you had a callback module and it was set 4 months ago, and unloading in 1C fell off yesterday, they can still write to you.


This is partly due to the Bitrix tech support policy. They answer everyone, but if they see someone else's code, they immediately wash their hands. For example, if your module uses some kind of kernel event (and it most likely uses it), then those. Support will quickly transfer the client’s problem to you if this event is called somewhere in the error scenario. For example, an error occurs when creating an order, and the module has an event handler for receiving the price of the goods. And they can be understood. Who would like to understand someone else’s code for free?


And then, almost no one will read your instructions or go to your intuitive settings page, in 80% of cases they will immediately write to you for technical support. Probably, in any field of activity. But it seems to us that the huge Bitrix admin panel and the need to read several courses to be able to use it are adding fuel to the fire.


Take this into account when pricing and labor planning.


The ability to customize component templates through copying against customization through component connection settings


All sites are different and, accordingly, they need different things from your components, for example, other texts for labels, design, a set of elements.


In Bitrix, you can copy component templates and change them in your own way. This is normal practice. But experience has shown that it is better to protect users from such actions.


After all, if an error occurs in the template or you simply improve it, add new chips, it will not be possible to update the template from the client, as it is customized. So you can’t even help the client with his mistake in displaying your own functionality.


Therefore, it will be a good solution to provide as many settings for connecting a component as possible so that all necessary customizations can be carried out without editing its code, but simply “twisting” the settings.


An additional plus of this approach is the absence of the need for a client in the programmer.


Storing javascript code


Technical point, also related to customization. Here is the structure of the component in general form.

  • my.component /
    • class.php
    • component.php
    • .parameters.php
    • .description.php
    • templates /
      • .default /
        • .parameters.php
        • result_modifier.php
        • template.php
        • style.css
        • script.js
        • component_epilog.php
        • lang /
          • com /
            • .parameters.php
            • result_modifier.php
            • template.php
            • component_epilog.php



    • lang /
      • com /
        • class.php
        • component.php
        • .parameters.php
        • .description.php


And here is the best way to redo it if there are ajax calls or logic inside js:


  • my.component /
    • class.php
    • component.php
    • script.js
    • .parameters.php
    • .description.php
    • templates /
      • .default /
        • .parameters.php
        • result_modifier.php
        • template.php
        • style.css
        • script.js
        • component_epilog.php
        • lang /
          • com /
            • .parameters.php
            • result_modifier.php
            • template.php
            • component_epilog.php


    • lang /
      • com /
        • class.php
        • component.php
        • .parameters.php
        • .description.php

That is, putting important js into the component, and not keeping it in the template. In the latter, only the API should twitch and use handlers hung on the elements.


Well, thanks, KO. The common js module can be moved to the module folder itself.


The meaning of this is that everything that is in the component template folder refers only to the display, and not to the logic. Accordingly, when customizing the template, the entire folder is copied, including your script.js. And the same problems with support and updates appear as in the previous paragraph, but with the proposed structure, you can significantly reduce them.


JQuery and Bitrix javascript library


Few people want to write ajax calls or do hover processing on pure js, so many are drawn to jQuery, which is now hard to not find on a random site. Also, some people know about the Bitrix js library, which also provides some kind of wrapper for ease of use.

But the reality is that the js-library of cms itself is really meaningless, and also sometimes harmful, for example, because for some reason it does not work with composite.


And with jQuery, the problem is that it is connected almost everywhere, but still not everywhere. And if connected, it may be too old version.


We recommend writing either in vanilla or setting up the component “Do jQuery connect?” So that you can finely control this moment and disable it where necessary. The latter, by the way, is a rather popular way among module developers.


As unique css classes as possible, as many rules for the selector as possible


Of course, class names must be unique, this applies to all standard solutions on the web that have a visual part, since the site can use the same classes as yours. We generally include the full name of the module in the name of the classes and use the names of BEM.

But the presence (and popularity) of “site-builders” force us to write almost every parameter for each selector explicitly, even write “content: ''” for pseudo-elements if you do not use them. Moreover, be prepared for a large number of uses of “! Important” in your css.


Always take ftp accesses if you need to edit the code


You may know that there is a built-in file editor in the Bitrix admin area, so the code can be edited through a browser. But experience has shown that if you need to edit at least some file on the site to fix or analyze the problem, it is better to take ftp right away, since you can touch some code that is called in init.php (and this is often) and the site right away crashes without the ability to roll back changes through the admin panel, which will also not work.

Plus, some developers manage to make the page so that it crashes, just if you look at its code through Bitrix. The reasons for this behavior to us are still not clear, but such cases do occur.


Therefore, editing files through the browser is a rather risky task if you cannot re-raise the site in a minute.


Buyers are almost always business


For the entire time that the modules were sold, we talked only once with a buyer who did not have a settlement account, since there was no IP or LLC. Of course, we are sure that we had more than one individual among buyers, but it is difficult to find out since not all buyers write to us, some just silently buy through Marketplace.

It seems to us that the predominance of official business in Bitrix will be in almost any sections of customers, at least because it is not cheap - they will rarely make just a blog on it.


For us, as sellers, this means large amounts of sales per unit of goods, but a longer cycle of buying and tormenting with customer accountants.


Bad surroundings


Your module will be affected by the Bitrix kernel code, the code of the site itself, and the code of other modules that the client bought.

Что бы не говорили, за код ядра можно не беспокоиться. Он протестирован десятки тысяч раз, не меняется от сайта к сайту, обновления всегда имеют обратную совместимость. Да и техподдержка может помочь с ним бесплатно.


А вот код самого сайта это уже другое дело. Здесь может быть ужасный код, так как многие сайты делались довольно давно, многие делались плохими программистами, так как порог вхождения в сам php довольно низкий.


А некоторые сайты наоборот делались “хорошими” программистами, но пришедшими с фреймворков или других систем (иногда самописных) и даже не старавшимися понять Битрикс. Видимо из-за гордыни. Кстати, есть и другой “конец” кода, когда от Битрикса остаётся только название и админка, и большая часть функционала делается в обход модулей Битрикса, а соответственно и событий и таблиц БД.


Plus, modules of other developers can overlap your module with their handlers.


All this carries problems, mainly in support. Also, be prepared that your module may simply not be installed on the client’s site, not fully installed or may not work, and you will have to debug the site for a long time and explain to the client that he will have to pay extra. work on the site, because otherwise nothing will work.


Do I need to know D7 well?


Quite a long time ago, Bitrix released a new core of its system, in which almost everything was rewritten, a lot of new chips appeared, the classes were a little unified and everything became OOP. But we decided not to write our solutions on pure d7.

We do this because of the proliferation of technology. Despite the fact that the release took place a long time ago, although occasionally, we find sites on the old core. There are few such clients and there will most likely be many problems with them (because they will be updated and everything will fly), therefore they can be neglected in thought.


The key factor for us was the lack of documentation and the fact that the technology was “run-in” a little, which means that a quick search for a solution on the Internet is unlikely to give a solution to the problem.


But with the support of the old kernel, we have not yet encountered a single problem.


Instead of a conclusion


Of course, some points sound like “to write modules, you have to write them”. But it’s better to be aware of and keep in mind all these points in order to avoid mistakes filled with experience and not to type it yourself.

We are going to replenish the article as we gain experience in order to use it as a cheat sheet inside the company.


And in addition, a link to the official Bitrix documentation on the development of modules.

Also popular now: