Bitrix + Bitcoin. We write a solution for the Marketplace. Part 1

Intro: Development of standard solutions for Bitrix in most cases represents a solution of trivial tasks. With each new project, you have to do the same thing again, and again, and again ... But there is a way to make your life easier - to write a library of your components and even make money on them if they offer the required functionality.

Conditions

Given: Bitrix edition of the “Small Business” - one piece.
Task: Teach him to accept Bitcoin payments and ...
And here I thought - and how? Modules for the integration of payment systems for Bitrix, I wrote and rewrote a lot. But what to do with Bitcoins? Which side to approach? I did not know.

Search for a solution

In the process of quite a long googling, we managed to access a payment system that allows accepting BTC and automatically converting them into the currency chosen by the seller in the store settings. It all turned out to be quite simple - there is an API, Bitcoin is accepted as a currency, what else do you need? Go!

Idea

Since my time for this task was virtually unlimited, I wanted to do everything “Feng Shui”, namely, not just to make the payment system processor, give it to the client and forget, but also burn the universal installation package. As you know, Bitrix has its own Marketplace with modules and solutions in which you can freely place your solution and even take money for it if you consider your work materially valuable. At the moment, most modules in the Marketplace are free. I have long since itched my hands to experiment in this direction and now, finally, this opportunity turned up.
')

Documentation

If the API of the payment system turned out to be fairly well documented and intuitively understandable (and there’s really nothing to understand - a couple of functions and sample code), then with instructions for the production of modules for Bitrix everything is extremely ambiguous.
On the one hand, it is, on the other hand, it did not really help me. Everything is somehow messy, crumpled, constant jumps in the text in search of answers to questions. As someone very accurately noticed on the forum of Bitrix himself: “It’s better not even to open dry manuals for modules — they were written not for those who want to learn, but for those who already know how.” A good video tutorial helped, at least a live person explains there.

Note: I would like to separately emphasize that I am not at all stupid and not stolid. This was the first experience of developing a module for the Marketplace. Now, having passed this way, I see that many things are in fact elementary, but the search for these solutions for the first time was carried out using the “finger to the sky” method.

Where does the module start?

First, the module itself is just a set of files, some of which are executed during its installation.
The module has a certain directory structure, which depends on the tasks that you are going to solve in your module.
So, we recreate the structure:

The image is taken from official documentation.
Here it is necessary to clarify what's what. The folder structure shown in the image is unlikely to be exactly the same. It is redundant and when (if?) You will develop your module, it will only have a couple of folders and a couple of files.
Which of this is mandatory:

1. /install/version.php - file with version number (array declaration with a couple of variables)
2. /install/index.php - file with the description of the module, which contains the installer / uninstaller of the module. In fact, and is an installer. That it starts when the user clicks the "Install" button. Rather, the file itself, and the DoInstall / DoUninstall methods described in it. In addition, it may contain auxiliary methods that copy files to different directories, execute SQL queries, etc.
3. /include.php - include file. It connects when the module is activated during the execution of site scripts. That is, in essence, this is an injection into the engine itself. In it, for example, you can add any background agent handlers, add menu items in the administrative interface, etc.

The remaining elements of the structure are auxiliary:

1. / lang / - directory in which all sensitive encoding files must be localized. Do not be lazy to make localization of the component code in the language files!
2. / classes / - as can be seen from the names of subdirectories, these are the main classes of the module (including those for working with various databases)
3. / install / admin / | / install / components / | / install / themes / - subdirectories from which we will copy service files during the installation process.

In order to better understand the purpose of each element, you can see the source code from the archive with the template module , based on which we will make the final decision.

In the next part of the article we will learn how to apply this knowledge in practice, and in the third part there will be a description of the structure and purpose of the module updates.