Moments in the development and sale of modules Bitrix

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

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

This article will be useful to those who want to start selling their modules on the Marketplace or promote their company with its 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 that they are ready), but buyers will almost always be non-programmers and will not have a programmer on staff. This is the ecosystem that cms creates, and especially Bitrix.

Therefore, the task of integrating functionality or edits in design often falls 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 the client to pay 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 announce the price of an hour of work. With increasing autonomy of the installation, you can increase the purchase price. But autonomy will never be 100%, because sites are far from always being made on the guidelines of Beatrix.

The 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. Maybe there are a million situations when something went wrong: the module didn’t download completely, updates were somehow crooked, someone changed the source code of your solution on the buyer's site, ...

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

With the complete removal of the module, of course, you should cover all traces of its presence, otherwise, by the way, you can not go through moderation. But when reversing, on the contrary, you need to somehow save everything so that the user does not need to re-fill and adjust everything.

Giving a choice when deleting a module whether to erase the data or not is the best way out in this situation, despite what Bitrix usually says about the complete erasure of the module’s traces upon uninstallation.

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

I will explain the problem on the example of the comments module.

Here you have made such a product (comment module) and released it in the Marketplace. With it, you can write comments to the goods. And maybe even delete, edit and respond to others.

But here one buyer wanted all the same that you have, and even in the same design, but so that it would be 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 designer sites are very popular in the store, development prices are quite large, you can identify the trend that redundancy and prices not so important to buyers.

Also it should be taken into account that buyers are often a business, therefore sales take a long time, and prices do not matter as much as when working with physical. by individuals.

Plus, we communicated directly with customers and many of them answered that they had bought some expensive product because of one particular chip. For example, the purchase of a site designer for several tens of thousands of rubles (and with terrible reviews) occurred because they liked the banners. Yes, and you probably heard from their customers the stories, why they want Beatrix as such, and heard about the same answers.

Customer Support

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

By the way, any problem that occurred on the customer’s site after installing your module and before installing another module or major design changes will also be considered a problem with your module. Even if you have a callback module and it was installed 4 months ago, and yesterday unloading into 1C fell off, they can still write to you.

This is partly due to the policy of technical support for Beatrix. They answer all, but if they see someone else's code, they immediately wash their hands. For example, if your module uses any event of the kernel (and it most likely uses it), then those. support will quickly transfer the client problem to you if this event is raised somewhere in the error script. 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 want to understand someone else's code for free?

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

Keep this in mind when pricing and planning work.

Ability to customize component templates by copying against customization through component connection settings

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

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

After all, if there is an error in the template or you just improve it, add new chips, you can not update the template at the client, as it is customized. So you cannot even help the client with his mistake in displaying your own functionality.

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

An additional advantage of this approach is the absence of the client's need for a programmer.

Storing javascript code

Technical moment, also associated with customization. Here is the structure of the component in general

• 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 /
        
        • ru /
          
          • .parameters.php
          • result_modifier.php
          • template.php
          • component_epilog.php
          
          
        
        
    
    
  • lang /
    
    • ru /
      
      • class.php
      • component.php
      • .parameters.php
      • .description.php
    
    

But how best to redo it in the presence of 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 /
        
        • ru /
          
          • .parameters.php
          • result_modifier.php
          • template.php
          • component_epilog.php
          
          
    
    
  • lang /
    
    • ru /
      
      • class.php
      • component.php
      • .parameters.php
      • .description.php
      
      

That is, to make important js in the component, and not to keep it in the template. In the latter, only the API should be twitched and handlers hung on elements should be used.

Well, thank you, KO. Common for the js module can be placed in the folder of the module itself.

The point of this is that everything in the component template folder is related only to the display, and not to logic. Accordingly, when customizing the template, the entire folder, including your script.js, is copied. And there are the same problems with support and updates 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 miss on a random site. Also, some people know about the Bitrix js-library, which also provides some kind of wrappers for convenience.
')

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

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

We advise you to write on vanilla or configure the “Connect to jQuery?” Component so that you can fine-tune this moment and disable it where necessary. The latter, by the way, is quite a popular way among developers of modules.

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

Of course, class names should be unique, this applies to all typical web solutions 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 the BEM.

But the presence (and popularity) of “constructor sites” makes it necessary to prescribe almost every parameter for each selector explicitly, even prescribe “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 panel, so the code can be edited through a browser. But experience has shown that if for repairing or analyzing a problem you need to edit at least some file on the site, it’s better to take ftp right away, since you can hit some code that is invoked in init.php (and this is often) and the site immediately will fall without the ability to roll back changes through the admin area, which also will not work.

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

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

Buyers are almost always business

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

It seems to us that the prevalence of the official business in Bitrix will be practically in any customer cuts, at least because it is not cheap - it will very rarely be just a blog.

For us as sellers, this means a large amount of sales per unit of product, but a longer cycle of purchase and anguish with customer accountants.

Bad environment

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

Whatever you say, you should not worry about the kernel code. It has been tested tens of thousands of times, does not change from site to site, updates always have backward compatibility. Yes, and tech support can help with it for free.

But the code of the site itself is another matter. There may be a terrible code, since many sites have been made for a long time, many have become poor programmers, since the threshold for entering php itself is rather low.

And some sites, on the contrary, were made by “good” programmers, but those who came from frameworks or other systems (sometimes self-written) and did not even try to understand Beatrix. Apparently because of pride. By the way, there is another “end” of the code, when only the name and admin panel remains from Beatrix, and most of the functionality is done to bypass the Beatrix modules, and accordingly, the events and database tables.

Plus, third-party modules can overlap your module with their handlers.

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

Do I need to know D7 perfectly?

For quite a while, Bitrix released a new core of its system, in which almost everything was rewritten, a lot of new chips appeared, classes were unified a bit and everything became OOP. But we decided not to write our solutions on pure d7.

We do so because of the spread of technology. Despite the fact that the release took place for a long time, albeit occasionally, but we meet sites on the old core. There are few such clients and most likely there will be a lot of problems with them (because they will be updated and everything will fly), so they can be neglected in the reflections.

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

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

Instead of conclusion

Of course, some points sound like “to write modules, you have to write them”. But all these moments are better understood and kept in mind to avoid mistakes full of experience and not to recruit it yourself.

We are going to replenish the article as experience is gained in order to use it as a cheat sheet within the company.

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