Developers
Coding style
A list of coding style rules to be used when developing in vtenext.
File encoding:
UTF-8. All files should be encoded in UTF-8
Newlines:
Unix style, so \n, not \r\n or \r
Indentation size:
With TABS, set to 4 character. Don't mix spaces and tabs:
Indentation style:
C Style, so:
Opening brace (
{ ) on the same line as its control clause (an exception can be made if the line is very long, so in this case the brace can go to a new line, for better readability)
Closing brace (
} ) aligned with the opening statement
Single space before the opening brace
Single space before the parenthesis of a control structure (
if,
for,
foreach, ...)
Examples
Good
if ($var === '234') {
$out = 'ok';
} elseif ($var === '567') {
$out = 'also ok';
} else {
$out = 'maybe ok?';
}
Bad: no space between
foreach and
(
foreach($array as $var) {
// do something
}
Bad: opening brace on new line
if ($var == 8)
{
// do something
}
Please note that these style rules are not strictly observed throughout the existing code, so you may find exceptions. Try to follow them, to improve the code homogeneity, but don't be too rigid in following them when evaluating existing code.
Line length:
We don't have a strict maximum line length. Usually up to 200 characters is ok, more than that can be hard to read on smaller screens, so better to split the line, but this is left to the developer's choice.
Also, splitting too much, for example a 300 chars line divided in 30 lines of 10 chars is no more readable than the original line. Balance readability and conciseness of code.
PHP tags:
Use standard opening tag:
) if there's no output.
Examples
Good: standard opening tag, no closing tag
Good: standard opening tag, closing tag with output
Auto formatting:
Core files: Do not enable any "auto formatting on save" functionality in your IDE/editor, to avoid too many changes in existing files, which will be hard to diff.
Custom files: you can reformat existing files to make them compliant with our standards.
License:
When creating a new file (php, js, tpl, html, scss) to be included in the standard vtenext, use the following license at the top of the file:
F::mod
$module = RH::r('module'); // Uses F::mod filter from config
$customParam = RH::r('custom', F::int); // Not in config: vtlib_purify() + F::int
$anotherParam = RH::r('another'); // Not in config: only vtlib_purify()
This approach ensures:
Unknown parameters are still sanitized to prevent XSS attacks
Explicit filters always provide additional type safety
Explicitly mapping more parameters enhances input security in the application.
✅ DO
// ✅ Always access superglobals through RH
$module = RH::r('module', F::mod);
$id = RH::r('id', F::int);
// ✅ Always specify appropriate filters
$email = RH::r('email', F::email);
$age = RH::r('age', F::int);
$status = RH::r('status', F::enum(['active', 'inactive']));
// ✅ Check for null values when data is required
$userId = RH::r('user_id', F::int);
if ($userId === null) {
throw new InvalidArgumentException('User ID is required');
}
// ✅ Use POST for operations that are sensitive or that modify the CRM state (e.g.: sending an email, saving a record, ...)
RH::ensureMethod('POST');
❌ DON'Ts
Avoid these practices: They bypass security, are redundant and can introduce vulnerabilities.
Never access superglobals directly:
$_REQUEST,
$_GET,
$_POST,
$_COOKIE,
$_FILES,
$_SERVER
Don't use manual sanitization: Avoid
vtlib_purify() calls, RH handles this centrally
Don't skip filters: Calling
RH::r('age') without a filter may return unvalidated strings
Don't use raw methods without reason: Prefer
RH::r(..., F::...) over
RH::r_raw(...)
Don't ignore security: Always validate HTTP methods for sensitive operations or action that modify the CRM state
Don't assume data types: Always use appropriate filters and null checks
// ❌ Direct superglobal access
$userId = $_REQUEST['user_id'];
$email = $_POST['email'];
$page = intval($_GET['page']);
// ❌ Manual sanitization
$name = vtlib_purify($_REQUEST['name']);
$description = vtlib_purify($_POST['description']);
// ❌ No filter applied
$age = RH::r('age'); // Returns string "25" instead of int 25
if ($age > 18) { // String comparison may not work as expected
// ...
}
// ❌ Using raw without justification
$data = RH::r_raw('data'); // Bypasses sanitization
echo $data; // Potential XSS vulnerability
// ❌ No null check for required data
$recordId = RH::r('record', F::int);
$record = getRecord($recordId); // May fail if $recordId is null
// ❌ Accepting any HTTP method for sensitive operation or action that modify the CRM state
// No method check here - vulnerable to GET-based attacks
$settings = RH::r('settings', F::json);
saveSettings($settings);
// ❌ Type assumption without validation
$ids = RH::r('ids'); // Assuming it's an array
foreach ($ids as $id) { // Fatal error if $ids is not an array
// ...
}
Main methods
Method
Description
RH::r($key, $filter)
Access $_REQUEST with filter (optional)
RH::g($key, $filter)
Access $_GET with filter (optional)
RH::p($key, $filter)
Access $_POST with filter (optional)
RH::c($key, $filter)
Access $_COOKIE with filter (optional)
RH::s($key, $filter)
Access $_SERVER with filter (optional)
RH::f($key)
Access uploaded files (PSR-7)
RH::r_mod()
Module name from $_REQUEST
RH::r_action()
Action name from $_REQUEST
RH::r_record()
Record ID from $_REQUEST
RH::r_has($key)
Verify key existence (sanitized)
RH::r_has_raw($key)
Verify key existence (raw)
RH::r_all()
All parameters sanitized
RH::r_all_raw()
All parameters raw (unsanitized)
RH::ensureMethod($method)
Force HTTP method (405 if different)
RH::isFromMobile()
Check if request is from mobile app
RH::isFromPortal()
Check if request is from portal
Basic filters
Null input always returns null - All filters preserve null values
Filters for primitive types (int, float, bool) - Convert invalid input to default values (0, 0.0, false)
Validation filters (email, url, ip, enum, regex, datetime) - Return null for invalid input
Sanitization filters (str, html, alpha, alphanum, mod, action, etc.) - Remove invalid characters and return cleaned string
Always check for null - Use null coalescing operator
?? for required values
Filter
Use case
Valid input → Output
Invalid input → Output
F::int
IDs, numbers
"42" →
42
"abc" →
0
null →
null
F::float
Decimal numbers
"3.14" →
3.14
"abc" →
0.0
null →
null
F::str
General strings (no HTML; default max length: 1000 characters)
"Hello" →
"Hello"
"abc" →
"abc" (tags stripped)
"Very long text..." → Truncated to 1000 chars by default
null →
null
F::str(max: 50)
Limited strings (no HTML)
"Short text" →
"Short text"
"Very long text..." → Truncated to 50 chars
null →
null
F::substr(max: 50)
Substring (keeps HTML, may result in invalid HTML)
"text" →
"text"
Long string → Truncated (HTML preserved)
null →
null
F::html
HTML strings (purified)
"bold" →
"bold"
"" →
"" (XSS removed)
null →
null
F::htmlurl
HTML strings (purified, allow URLs) [only from vtenext >= 26.07]
"
" →
""
F::bool
Boolean flags
"1",
"true",
"yes" →
true
"0",
"false",
"no" →
false
null →
null
F::email
Email addresses
"user@example.com" →
"user@example.com"
"invalid-email" →
null
"user@" →
null
null →
null
F::url
URLs
"https://example.com" →
"https://example.com"
"invalid-url" →
null
"htp://exa" →
null
null →
null
F::ip
IP addresses
"192.168.1.1" →
"192.168.1.1"
"999.999.999.999" →
null
"invalid-ip" →
null
null →
null
F::json
JSON data
'{"key":"value"}' →
["key" => "value"]
'invalid json' →
null
'{broken' →
null
null →
null
Specific filters
Filter
Use case
Valid input → Output
Invalid input → Output
F::mod
Module names
"Accounts" → unchanged
"Acc
Outside of