Managing Modules in Venddor IO

Curating your online store often requires the use of various modules to enhance its functionality. Venddor IO provides a consolidated interface for this via the Administration panel under Modules → Manage Modules.

Building the Modules List

Every time you open the module management interface in Venddor IO:

• An initial scan is made, treating every sub-folder within app/modules as a potential module.
• Venddor IO will attempt to retrieve app/modules/[module]/module.xml from each folder.
• Modules failing to load or parse their respective module.xml will be ignored. Any issues related to XML parsing are displayed in error notifications.
• Names for the modules are extracted. If module.xml follows the 3.0 scheme, module names are fetched from var/langs/[lang_code]/modules/[module].po.
• Any pre-existing module data from the database is then synchronized with this list. As a result, once a module is installed, its name and description remain static.

Installing a Module

For the smooth installation of a module:

1. Venddor IO checks the ?:modules table to ensure no previous entries exist for the module in question.
2. The module scheme is extracted from module.xml.
3. Unmanaged modules won't show up in the Admin panel's list but can only be installed via the console.
4. Venddor IO ensures module classes auto-load by adding the module folder to Tygh::$app['class_loader'].
5. Compatibility checks are made. If the module doesn't match Venddor IO's environment or version, an error is thrown.
6. Dependencies are checked, but conflicting modules are verified only during module activation.
7. Functions specified in module.xml for the "before_install" condition are executed. If any function leads to a database error, the module installation is terminated.
8. Upon successful checks, the module is recorded in the ?:modules and ?:module_descriptions tables with a Disabled status initially.
9. Language variables from the module's PO file are integrated.
10. Templates are copied from var/themes_repository to the design/themes directory.
11. The module's settings in module.xml are stored in the database.
12. Lastly, if the module.xml specifies an Active status for the module, it is activated.

Uninstalling a Module

For a smooth uninstallation:

1. Venddor IO checks if the module is unmanaged. If so, it can only be removed via console.
2. Dependencies are verified. If any module relies on the module being uninstalled, the process aborts.
3. module.xml functions under the "uninstall" condition are triggered.
4. Entries in ?:modules and ?:module_descriptions tables related to the module are deleted.
5. Module settings and language variables are removed.
6. The module's database queries under the "uninstall" condition are executed.
7. Product tabs related to the module are deleted.
8. Module templates in the design/themes directory are deleted.

The module's layouts are rolled back, and cache is cleared.

Activating a Module

1. Venddor IO loads the module scheme from module.xml.
2. An inbuilt check ensures unmanaged modules are only activated via console.
3. A hook, fn_set_hook('update_module_status_pre',...), is executed.
4. Venddor IO checks for any conflicting active modules.
5. Dependency checks ensure that required modules are active.
6. If everything checks out, the module status is set to Active.

Deactivating a Module

1. The module scheme from module.xml is loaded.
2. For unmanaged modules, they can only be deactivated through console.
3. A hook, fn_set_hook('update_module_status_pre',...), is executed.
4. The module's status is then set to Disabled.