Since WebsiteBaker existed before the appearance of the PHP FIG standards a few adjustments to the standards are required, which are described below. Further adjustments to adhere are included in the chapters on the individual WB versions / WB version groups!
Caution: For all new Code the principle of electronic data processing, valid since the invention of the computer and which has often been disregarded in WB in the past, from now on has to be followed in WB as well:
- Input » Processing » Output
These 3 areas must be strictly separated and always occur in the exact order. New modules that do not adhere to this basic rule are no longer included in future in the repository, or they are marked as 'not compatible'.
For files with the extension *.php which include only PHP code or end with PHP code, the closing tag ?> is not allowed. It is not required by the web server nor by PHP and omitting it prevents from accidentally including blank lines which would may prematurely trigger that headers are sent.
If a file starts with PHP code, the opening <?php-tag must be placed on the first column of the first line of the file. Text files (not binary files such as images, etc.) must be saved in UTF-8 format without BOM (ByteOrderMark).
Particularly users of Windows environments have to be cautious about this, because usually for Unix / Linux UTF-8 is the system-wide standard anyway.
The standard pitch of the tab should be set to 4 spaces. An indentation generally consists of 4 spaces. Tabs themselves are not allowed at any point and for convenience should be automatically converted by the editor each in 4 spaces.
The target line length is 80 characters. Developers should keep each line of their code below 80 characters, as far as is possible and practicable. Nevertheless, longer lines are allowed in exceptional cases. However, the maximum length of a PHP code line should not exceed 130 characters.
Line termination follows the Unix text file convention. Lines must end with a single linefeed (LF). Newline characters are represented by an ordinal 10, or 0x0A (hexadecimal).
Note: Do not use the carriage return (CR / 0x0D) as in the conventions of Apple or the combination of carriage return and line feed (CR/LF / 0x0D, 0x0A) as specified in the standard for Windows.
Website Baker largely adopts the PSR here as well, in a version slightly adapted to the specific requirements WB. The main difference is found in the structure of the search paths for the files. In later versions also here a further approximation to PSR will take place.
Note: Strict compliance with these conventions is imperative so that there can be no homonyms of classes and functions / methods in different modules. The core is thus able to clearly determine the location of the class file based on the class name to reload them using the autoloader optimized on WB. An explicit inclusion of the class files via include () or require () is superfluous.
Website Baker from v2.8.4 on requires PHP 5.4.x as a minimum requirement. For a transitional period 2 different naming conventions for classes are permitted. However, the stated objective is to convert entirely to namespaces to utilize their advantages and also to reduce the cost significantly when naming classes.
Class names must be declared in StudlyCaps (also called UpperCamelCase) and correspond to the following RegEx rule: '/[A-Z][a-zA-Z0-9]+/'. Numbers are permitted in class names, but should be limited to what is necessary and do not pose any risk of confusion with letters. If the class name consists of more than one word, the respective first letter of a word has to be in uppercase. Several consecutive uppercase letters are not allowed. Example based on a name:
In general, abstract classes and interfaces follow the same conventions as classes, with an additional rule: The names of abstract classes and interfaces should end with the term “Abstract” or “Interface”, and the term must not be preceded by an underscore. As an example Plugin_Abstract is considered invalid, but PluginAbstract or m_MyModul_PluginAbstract would be valid names.
In this mode in class names the underscore '_' is permitted additionally as special/functional character. However, it is intended solely as path separator. Class names in this context do not only consist of the name defined so far, but they must also contain a well-defined prefix. Only then it is possible to find the correct file out of the class name, so that the appropriate file can be loaded automatically (included) when accessing a class.
The class libraries of WebsiteBaker are divided into several groups:
The core classes: reside in the directory
wb/framework/ or one of its subdirectories. For these no prefix is needed at all.
Classes of modules: classes of modules in the appropriate module directory
wb/modules/%module_name%/ or one of its subdirectories. The identifier must necessarily get the prefix 'm_'. Example: m_MyModule_PluginInterface
Classes of ACP: (AdminControlPanel ⇒ Former backend) are located in the directory
wb/admin/ or one of its subdirectories. The ClassIdentifier must necessarily get the prefix 'a_'. Example: a_Pages_PageTree
Classes of third-party libraries: lying in the directory
wb/include/ and its subdirectories are not automatically covered by the autoloader. However, each library has the ability to carry out its own registration in the SPL autoloader stack. More on this can be found in the description of the autoloader the respective WB version.
As far as the above-mentioned rules for class names have been complied with, the filename would clearly result from the class name. The class m_MyModul_PluginAbstract accordingly can be found in the file
For all other files, only alphanumeric characters and the dash (-) are allowed. Spaces are strictly prohibited.
Each file which contains executable PHP code should end with the extension .php and be carried out in UpperCamelCase.
For naming directories the same basis as for files apply. Only alphanumeric characters and a few special characters of standard 7-bit ASCII range <128 ( ! # - . @ ~ ) are allowed. As with file names, spaces, and the underscore are prohibited.
Function and method names may only contain alphanumeric characters. Underscores are not permitted. Numbers are however permitted in function names in most cases however not recommended. Verbosity is generally encouraged. Function names should be as verbose as possible to describe their purpose and behavior as precisely as possible.
Functions or methods have to be written whenever possible in lowerCamelCase (or simply camelCase). This means they should begin with a lowercase verb like get, set, add, delete, load, save, execute etc. followed by a noun in StudlyCaps that describes the object to be processed. Example:
Warning: doulble underscores may never be used as a prefix for method, function, or variable names. There is the danger that it overlaps with current or future, PHP's intrinsic Magic Functions etc..