{label}Menu
{contenu}
Configure instance
{contenu}
After installation of the instance, the instance should operate immediately.
If this is not the case, or if you wish to correct or add configuration variables,
The following information can help you :
If this is not the case, or if you wish to correct or add configuration variables,
The following information can help you :
¤ First thing to set up: Language!
If you are starting a multilingual project, or if you want to change the default language, it is essential to configure this aspect first.
The instance is provided by default in English, but is also fully translated into French (The original language of the team... Sorry if there are any errors in English, and thank you in advance to report them to us).
From the administration interface, in the settings/languages menu, you can access a simple interface to add languages but also upload an image to create a flag icon that can be used by the language module.
It is best to go through this module to set languages, as it will change both the database (table "languages_allowed") and the configuration file "main.php" which is in the "config" folder of your instance.
In the config file, it will change the constant "AVAILABLE_LANGUAGES" (array).
In this file there are other language variables, but they are controlled by the maintenance module.
¤ Other main variables
From the admin interface, in the menu "settings"/"maintenance", tab "configuration" you can manipulate the variables of the configuration files of your instance.
Each field displayed corresponds to a value in the files of the "config" folder of your instance.
All these values being available in the global $CONFIG in all the PHP components of helPHP, and some in H_constants on the javascript side.
With the exception of the db.php file which contains the variables related to MySQL servers (their modifications involving heavy actions that need to be prepared).
For the sake of readability, the constants are presented with more explicit labels, here is the correspondence of these labels with the configuration constants, and what they serve:
For the sake of readability, the constants are presented with more explicit labels, here is the correspondence of these labels with the configuration constants, and what they serve:
{contenu}
| Label: | Constant: | Use: |
| Developpement mode | DEVMODE | Allows to pass the instance of the development mode to production, the Javascripts and CSS data are no longer loaded individually but replaced by a single compressed file, the helPHP debugger becomes silent, the document module displays the cached versions of documents. |
| Demo | DEMO | Allows you to define another mode of operation without saving data (not used by the basic instance) |
| First launch | FIRST_USE | If true, then when attempting to connect to the instance administration, a form allows to create the first user. |
| Video download lock | SECUVID | Enables the function to lock downloading videos possibility that are streamed by the media class. |
| Mono session | MONOPOSTE | Restricts connection to one machine once |
| Site name | SITE_NAME | Internal name, used to name session cookie |
| Public theme | THEME_ID | ID of the theme in database for "public" / front display (ID is displayed in the CSS editing module) |
| Admin theme | THEME_ID_ADMIN | ID of the theme in database for "admin" / backoffice display (ID is displayed in the CSS editing module) |
| SVG Sprite icons file | SVG_SPRITE_ICONS_FILE | File name in the image/icons folder used as a sprite board for the "icons" module and H:icon |
| Storage quota | STORAGE_COTA | Storage limit (controlled by php Ajax class during uploads) |
| (not displayed in maintenance) | GLUSTER_STORAGE | Whether storage is "Gluster" type (change the method of calculating storage size) |
| Base domain name | DOMAIN | Site domain name |
| Protocol | (changes BASE_URL) | Pass the start of the BASE_URL constant from http to https |
| (not displayed in maintenance) | SITE_FOLDER | File or path following the domain name (useful if using more instances on the same domain name) |
| (not displayed in maintenance) | HOME_FOLDER | Local path of the folder containing the instance |
| (not displayed in maintenance) | BASE_URL | Full access address (default: 'https://www.'.Config::DOMAIN.'/'.Config::SITE_FOLDER ) |
| Admin folder name | ADMIN_FOLDER | Folder name to access administration (default: 'admin') after BASE_URL. It is recommended to change the folder name to limit backoffice attacks. |
| (not displayed in maintenance) | HELPHP_FOLDER | Local path to access the "main" of helPHP (libraries/modules etc.). |
| (not displayed in maintenance) | LOG_FILE | Path to save the dev log file of the helPHP debugger (disabled in production) |
| (not displayed in maintenance) | ROOT_FS | Local path in which the PHP Filesystem class will limit access according to the status of the skip_check_path variable. It will check that the operation is done only in this path if $FS->skip_check_path is false. |
| Apache user | APACHE_USER | User name apache applied to the file after manipulation. |
| (not displayed in maintenance) | LIBTRANSLATE_URL | Libre Translate API Address for translation requests |
| (not displayed in maintenance) | LIBTRANSLATE_APIKEY | Api key for calls to Libre Translate |
| (not displayed in maintenance) | API_MODE | Enables the helPHP API |
| (not displayed in maintenance) | TINYMCE_UPLOAD | Allow media upload in a TinyMCE editor |
| (not displayed in maintenance) | CLUSTER_MODE | Whether the instance works in a cluster (cloud/multiple VM or server) to change session type. |
| Duration of a session, in hour | SESSION_HOURS | Session time in hours |
| Redis enabled | REDIS | Enables or not record of sessions and process tracking in a Redis server (otherwise it is database, therefore slower). |
| Host | REDIS_HOST | Network or IP name of Redis server |
| Port | REDIS_PORT | Redis server port |
| (not displayed in maintenance) | REDIS_ADDRESS | Address of the Redis server composed using the REDIS_HOST and REDIS_PORT constants |
| Duration of an API connection token, in minutes | TOKEN_MINUTE | Number of minutes for the lifetime of a connection token used to replace sessions during communication via the helPHP API. |
| (not displayed in maintenance) | CRYPT_KEY | Crypt class default encryption and decryption key |
| Allowed for login | USERNAME_VALID_STRING | all characters allowed for a login |
| Minimum size of a password | USEXIMUM_LENGTH | minimum number of characters for a password |
| Default language | DEFAULT_LANGUAGE | Language that will be used by default if no language is detected. This language must have been added with the admin language module in advance. |
| (not displayed in maintenance) | MODULES_BASIC | List of modules essential for the functioning of the proceeding, and therefore publicly accessible. They must also have their CSS edited in the basic theme, not in the theme limited to a module (as preloaded by default) |
| (not displayed in maintenance) | AVAILABLE_LANGUAGE | List of available languages, managed with the admin language module. |
| Number of attempts to connect before banishment | MAX_USER_CONNECTION_ATTEMPS | |
| Duration of banishment, in hours | CONNECTION_TRY_BAN_HOURS | |
| (not displayed in maintenance) | INCLUDE_JS_ANIMATE | Enables and loads the helPHP JavaScript animation engine, and activates animation detection (needs to generate the constant file again.js from the general maintenance tab to be applied) |
| (not displayed in maintenance) | MINIFICATION_TIME | Timestamp updated during last use of utils/minification to force refreshment of compressed Javascripts and CSS after going to production |
| (not displayed in maintenance) | MODULE_LIST | Table of available modules and their options (explained below). |
¤ The constant MODULES_LIST:
In the config/main.php file this constant contains the various parameters for each module.
In each sub-array on behalf of the modules, we find various parameters:
In each sub-array on behalf of the modules, we find various parameters:
- options : an object containing additional options for the module that will then be available in $this->options (to adjust your module at your convenience).
- indexable : indicates whether the module creates indexable content (and therefore can be displayed directly by the public core in the main div "the main", but also needs to be browsed to create sitemaps and update the "social" module if it is present.
- admin_param : the default parameter sent to the module, in the case of "core" in a request of type admin/#core=x (x being a digit of an ID) it will be automatically translated into admin/#core?id=x which allows to hide the names of the parameters or variable name that one wishes to transmit (useful in the case of a get)
- public_param : identical to admin_param but for the public version of the module , in the case of the core public/#core=x module becomes public/#core?disposition=x
- hierarchy : is a boolean that allows to indicate whether you can propose the contents of the module in the hierarchy module for menu creation, as is the case for the document module. In this case, when adding a menu item, you will be offered the contents of the "document" module classified by the "name" field.
Note that these settings appear in this array automatically when installing the instance or a module, and you usually rarely need to touch it unless you are currently developing a new module.
This constant is between two special comment lines allowing it to be re-edited during module installation/uninstallation:
Thank you for not deleting them.
This constant is between two special comment lines allowing it to be re-edited during module installation/uninstallation:
//>>>modules>>>>
const MODULES_LIST = array (
.....
);
//<<<
¤ Database configuration in config/db.php:
These configuration variables are created during the installation of the instance, but if you need to change the configuration of your database servers, you will need to intervene in this file.
The constant DB_TABLE_PREFIX, indicates the prefix added in front of all table names, which allows to have several instances that coexist on the same database.
DB_HOST, DB_USER, DB_BASE, DB_PASS are the default MySQL server constants: host server, user, database name, and password.
DB_HOST, DB_USER, DB_BASE, DB_PASS are the default MySQL server constants: host server, user, database name, and password.
If you use two MySQL servers as master slave, pass the constant MASTER_SLAVE_MODE to true and fill the constants DB_SLAVE... The DB class of helPHP will write in the master and read the data from the master (DB_HOST) and the slave alternately (DB_SLAVE_HOST). And he will address the surviving server if one of them fails.
Example: In case the master dies, helPHP will work with the slave, if you wish to pass the slave into master and create another slave :
- Replace the master's 4 constants with the slave's
- Pass the MASTER_SLAVE_MODE constant to false
- Install your slave server and synchronize it with the new master (beware of mysql configuration variables for replication!)
- Enter the new slave constants in db.php and return the MASTER_SLAVE_MODE constant to true!
If you want to use a central database to share user accounts between several helPHP applications, then pass the constant DB_CENTRAL to true and fill in the corresponding constants.
the constant DB_CENTRAL_TABLES contains the list of tables that are deported in this database, and therefore the query on these tables are done via another object from the DB class.
When DB_CENTRAL is false, the default server contains these tables, and therefore the $DB and $DB_central object are identical.
the constant DB_CENTRAL_TABLES contains the list of tables that are deported in this database, and therefore the query on these tables are done via another object from the DB class.
When DB_CENTRAL is false, the default server contains these tables, and therefore the $DB and $DB_central object are identical.
Similarly if you want to create "jobs", either long tasks like video encoding or compression of large folders, and their tracking is shared (necessary if you use multiple server/VM/container running the same instance) you can use the constant DB_JOBS To true and fill the dedicated constants .
The DB_JOBS database may be the same as the first server if you want to run with a single database server, but it is recommended to create a separate database from the first one to facilitate the evolution of your project if you need to extend it (cloud or several server/VM/container)
The DB_JOBS database may be the same as the first server if you want to run with a single database server, but it is recommended to create a separate database from the first one to facilitate the evolution of your project if you need to extend it (cloud or several server/VM/container)
{contenu}
¤ The configuration of emails:
HelPHP uses the excellent PHP_Mail (thank you for supporting them) to send emails.
It is in the hand in the libs/externals folder, and is called by libs/Mail.php.
Mail.php also contains simple sending methods that do not use PHP_Mailer, but offer fewer features.
It is in the hand in the libs/externals folder, and is called by libs/Mail.php.
Mail.php also contains simple sending methods that do not use PHP_Mailer, but offer fewer features.
In the instance, in config/email.php we have the settings dedicated to emails.
The first constants are easy, but let's look in detail EMAIL_SIGNATURE_BODY and EMBEDED :
These two constants contain enough to create an HTML signature and incorporate images, the images indicated in the EMBEDED array have a src (from home) and a name.
This name is found in the src attribute of the "img" tags![]()
in the form of "cid:name".
When sending an email, these two constants will be used (if EMAIL_SIGNATURE_BODY is not empty) to create the signature, but nothing prevents you from changing the content of the email and adding images to create a bit more complicated mail body.
Here is an example of a code used to send emails with helPHP:
The first constants are easy, but let's look in detail EMAIL_SIGNATURE_BODY and EMBEDED :
These two constants contain enough to create an HTML signature and incorporate images, the images indicated in the EMBEDED array have a src (from home) and a name.
This name is found in the src attribute of the "img" tags
When sending an email, these two constants will be used (if EMAIL_SIGNATURE_BODY is not empty) to create the signature, but nothing prevents you from changing the content of the email and adding images to create a bit more complicated mail body.
Here is an example of a code used to send emails with helPHP:
Overall $CONFIG_EMAIL;
$mail = new Mail();
if ($CONFIG_EMAIL::EMAIL_SIGNATURE_BODY!= ''){
$mail_content.= $CONFIG_EMAIL::EMAIL_SIGNATURE_BODY;
foreach($CONFIG_EMAIL::EMBED as $to_embed){
$mail->mail->AddEmbedgedImage($CONFIG::HOME_FOLDER.$to_embed['src'], $to_embed['name']);
}
}
TitleExecutive summary
Set it up via the maintenance module interface or via configuration files.
Date of establishment2026-02-17 00:00:00Date of publication2026-02-17 00:00:00
