We did not reinvent the most basic standards for Website Baker and arbitrarily define some rules, but we use basically the same set of rules as many other notable projects and large frameworks (see PHP-FIG Referenzliste).
The basic standards for Website Baker are the standards PSR-0 / PSR-1 / PSR-2 and PSR-4 of the PHP Framework Interop Group.
Some might feel uncomfortable with the quite strict wording using the expressions MUST! or MUST NOT! etc. However, these terms are taken exactly as they are from the original PSRs which in turn striclty stick to RFC 2119 and should therefore be understood exactly in this sense.
The most important keywords defined in RFC2119 are:
|MUST / REQUIRED / SHALL||This means that the definition is an absolute requirement of the specification.|
|MUST NOT / SHALL NOT||These phrases mean that the definition is an absolute prohibition of the specification.|
|SHOULD / RECOMMENDED||This is also a very strong requirement/prohibition. However, there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.|
|SHOULD NOT / NOT RECOMMENDED|
|MAY / OPTIONAL||This states an item which is truly optional.|
With every subsequent release of WebsiteBaker, the programming style evolves continually away from the previous 'anarchic' style, widely used for almost 10 years, towards to a more modular, but also forcibly bound to strict programming interfaces manner. This requires a consistent rethinking especially for addon programmers.
At present, i.e. before 2.10.0, compliance with many regulations is still voluntary, in the 2.12.0 much is already deprecated, and later on many of the specifications of 2.12.0 will be mandatory. All this sounds very restrictive to many, but this is gladly accepted, since precisely these limitations will eventually ensure a stable modularity, flexibility and interchangeability for stable, reusability and mainly maintainability of code.
.. which should should, regardless of WB, apply as well to any at least semi-professional project and be a basis of every serious programmer training.
for later versions (2.12), further restrictions will come. See the respective sections of this documentation.