Native module for admin panel on Webasyst

Quite often, customers ask for the unknown, so you have to lag the engine in the tail and in the mane. Webasyst is inconceivable and mysterious in terms of code logic, and there are very few adequate manuals on the Internet. Therefore, I will write here what I learned through my own bitter experience of trial and error. There are several types of modules in the webasyst, I plan to write about each of them, but I will only talk about methods for embedding my modules in the engine, and not about programming directly.
It is assumed that php is owned by everyone who reads this article.


To begin with, each element in the admin panel has its own did.
For example, the product bookmarks did equal 9.

image

This number corresponds to xID in the SC_divisions table .

The creation of the admin module begins with the fact that we embed a new record in the SC_divisions table.

INSERT INTO `SC_divisions` SET xName='pgn_mymodule', xParentID=9, xEnabled=1, xPriority=100;

Note that xParentID = 9 . This means that the parent of this module will be products. Those. this module will be a tab in the Products tab. The xPriority parameter is responsible for the position between the tabs .
We look at what xID assigned us an auto-increment, we remember it. Suppose in our case it is 209 .

Next we go to the SC_division_interface table . Here, on the one hand, everything is clear, but on the other, it’s not very. And this is what is "not very" lies the most important.

Important fields for us:
xDivisionID- Obviously, this is the identifier of our module. We agreed that it is 209 .
xInterface - The name of the module is stored in this field, and, strangely enough, the path to the module.

To understand what the digit means in front of the module name, let's look at the SC_module_configs table .
If you look at the ConfigKey fields , you can see that they follow the folder structure inside / published / SC / html / scripts / modules .
Yeah. And we would like to enter our module in adminscreens . We look at what ModuleConfigID is for adminscreens . This is 48 .
Now for us there are no riddles, and we can safely write:

INSERT INTO SC_division_interface SET xDivisionID=209, xInterface=48_mymodule;

Great. Half the job done.
Now go to / published / SC / html / scripts / modules / adminscreens / _methods , and create the files there:

mymodule.xml
My Modulemymodule


mymodule.php
get(VAR_SMARTY);
        /*@var $smarty Smarty*/
           // здесь пишите все, что вашей душеньке угодно
           // можно подсмотреть как это делается в других модулях этой папки
    }
}
ActionsController::exec('MymoduleController');
?>


You should pay attention to those places in mymodule.php where the text mymodule is . It should match the name of your module. Otherwise, nothing will work.

There is very little left. Namely, give the administrator the opportunity to see this module. For some reason, this moment is omitted in all similar articles, but it is not easy to guess before. It usually happens that a module works, but we don’t see it. To find this out, I had to thoroughly shovel the webasyst code. The solution is:

We look at the plate U_ACCESSRIGHTS . Add a line:

INSERT INTO U_ACCESSRIGHTS SET AR_ID='ADMIN', AR_PATH='/ROOT/SC/FUNCTIONS', AR_OBJECT_ID=SC__209, AR_VALUE=1;

The main thing in this line is what? Right - SC__209 . And 209 is the number of our module.

It remains to add the translation pgn_mymodule

INSERT INTO `SC_local` (`id`, `lang_id`, `value`, `group`, `subgroup`) VALUES
('pgn_mymodule', 1, 'Мой модуль', 'general', 'prd'),
('pgn_mymodule', 2, 'My module', 'general', 'prd');


And that’s all. Now, if we go to the “Products” tab , we will see the “My module” tab inside , where the code from mymodule.php will be executed .

Also popular now: