Difference between revisions of "Modules - Packaging rules and Dolistore validation rules"

From Dolibarr ERP CRM Wiki
Jump to navigation Jump to search
Tag: 2017 source edit
Line 2: Line 2:
<!-- You can edit this section but do NOT remove these comments
<!-- You can edit this section but do NOT remove these comments
     Links below will be automatically replicated on translated pages by PolyglotBot -->
     Links below will be automatically replicated on translated pages by PolyglotBot -->
[[fr:Modules - Règles de packaging et validation DoliStore]]
<!-- END interlang links -->
<!-- END interlang links -->

Revision as of 18:02, 12 December 2019

Art.png Enabling/activation condition of external module on DoliStore

Here are the rules that will be apply by Dolibarr team on validation/activation of external module on https://www.dolistore.com


All modules that are dolibarr modules must be called module_mymodulename-VERSION.zip (where VERSION is version can be x or x.y or x.y.z) If the module is for another software, the name of zip must be moduleothersoftware_mymodulename-VERSION.zip (for example moduleprestashop_mymodulename-1.0.zip)

The packages that are Android application, PDF or ODx documents are free to use the name of their choice. The extension however must follow the type of file (.app, .txt, .pdf, .odt, ...)

The rest of the document applies for Dolibarr modules only.


All modules must follow a structure similar to the one provided into htdocs/modulebuilder/template

  • mymodule/build/ can contains any file you develop for compiling or building package
  • mymodule/core/modules/ contains module descriptor file modMyModule.class.php
  • mymodule/core/triggers contains triggers provided by module
  • mymodule/admin/ contains pages to setup module
  • mymodule/class/ contains PHP class files provided by module
  • mymodule/css contains CSS files provided by module
  • mymodule/docs to provide doc and licence files
  • mymodule/img contains images files provided by module
  • mymodule/langs/xx_XX contains language files for language xx_XX (try to put at least en_US)
  • mymodule/lib contains libraries provided and used by module
  • mymodule/scripts to provide command line tools or scripts. Note: Command lines script must start with line #!/usr/bin/env php
  • mymodule/sql contains SQL file provided by module to add new tables or indexes
  • mymodule/theme/mytheme if module provide its own theme/skin
  • mymodule/* contains php pages (note that you can also add any other subdir of your choice). Note: If your module is a metapackage (a module that will embed other modules in same zip, you must put here a file metapackage.conf)


  • To include a core file, use
include_once/require_once/include/require DOL_DOCUMENT_ROOT.'/pathtofile';
  • To include a file of module into a file of same module, use
include_once/require_once/include/require './mymoduledir/...';
  • To include a file of another external module into a module file, use

Link to Dolibarr core object

All link to a page of a standard dolibarr object (an invoice, an order, a bank account, ...) should be included into the code using the getNomUrl method of the class of the object.

Custom directory management

An external module called mymodule can be installed into htdocs/custom/mymodule (the default) as well as in htdocs/mymodule. It must works in both cases.

No writing in standard tree

The module must not write in Dolibarr's "programs" but only into files located into the directory "documents". Including for temporary files. It should be remembered that on a proper secured installation of Dolibarr, the entire program tree (with the exception of the custom directory) is set to read-only.

Core file modifications

Your module MUST NOT change or overwrite any files provided by standard Dolibarr distribution. If some Dolibarr core files need to me modified to have your module working, you must submit this change to core team. They will be accepted :

  • If they are pushed to dolibarr develop branch on GitHub
  • If what you push is adding hooks or triggers, or optionnal parameter to existing functions, it should be accepted with no condition. For other change, it may depends if change keeps old code compatible and is interesting for everybody.

Mandatory data on record


Product description is mandatory in English


If your module is not free you have to give a email adress for support (or a website that allow customers to contact you)