Installing the server part General information Preparing the server Launching a container Connection and installation Setting up an SSL certificate Security settings Server update
Development Environment Scripts Root scripts Modular scripts Calling a module script Module script parameters Modular script operation Web modules
Handbook Accepted designations Module data types System keys Global keys Configuration Debugging tools Service Caching Performance API Parser MySql Session Emailer IpUtil Xml
Version update

Module script parameters

Let's start with the first two fields located above the script editor. These are service fields, and you will need to specify the following information in them:

  • The first field is the module description for auto-suggestion. The thing is that the Melbis Shop 6 development environment has an auto-suggestion function when editing HTML templates. For example, if you type the symbol " { ", then after a second a pop-up window will appear that will prompt you about the commands that can follow. When you select the command " MELBIS: ", then the auto-suggestion will offer you a list of available module scripts. This is quite convenient, because there can be many modules, and not only the PHP programmer who developed them can operate them, but also the webmaster who sees them for the first time.

  • The second field is a list of expected parameters when calling the module. After the name of each parameter, you must specify its data type. The following types are available: int , bool , float , str , fix , serail   (for more details, see the section " Module data types ").

On the right is a list of libraries that you can choose to use in this module, and at the very bottom are the module's caching settings:

  • Lazy loading - enables/disables loading of this module using Lazy Loading technology. When this option is selected, during parsing, a special HTML code is substituted in place of the module, and the module itself is not called. After the user has received the page with this code, a request for personal execution of this module and substitution of its result on the page is activated. Thus, given that there may be several modules, the user receives the effect of accelerated page loading.

  • External launch available - allows/prohibits launching the module by calling it in the first way via $gParser->Parse. When designing a store, it is important that it is not hacked and that an intruder cannot call any module he wants. Therefore, it is possible and necessary to limit the call of modules that are internal, that is, are called only in the second way - via the key in the template.

  • Cache - enables/disables the caching mode of the current module's results.

  • Timeout - the delay time for updating the cache, specified in minutes. Some modules do not make sense to update too often (even if the data on the basis of which they are formed has changed). For example, the sales rating of goods: it is enough to recalculate it, say, once every three hours. In addition, using long delays, you can implement so-called cron modules that will perform certain actions with a specified frequency. For example, sending notifications about received goods (once a day).

  • The left list of tables are the tables that the module accesses and, when changed, determines whether the cache needs to be rebuilt. Note that you can disable certain tables and avoid rebuilding the module's cache too often.

  • Right list of tables - tables accessed by libraries attached to this module. This list cannot be changed, however, you will be aware of which tables the result of your module's work and, accordingly, the module cache will depend on.