Die Standards für WebsiteBaker wurden jetzt auch nicht neu erfunden und willkürlich festgelegt, sondern wir verwenden prinzipiell die selben, die auch sehr viele andere namhafte Projekte und große Frameworks (siehe PHP-FIG Referenzliste) benutzen. Die grundlegenden Standards für WebsiteBaker sind die Standards PSR-1 / PSR-12 und PSR-4 der PHP Framework Interop Group.
Auf den nachfolgenden Seiten haben wir die Originale ins Deutsche übersetzt. Vielleicht nicht ganz wörtlich, jedoch absolut sinngemäß. Manche mögen sich an der recht strikten Ausdrucksweise (das MUSS!, das DARF NICHT! etc.) stören. Diese Ausdrücke sind aber exakt so aus den originalen PSRs, die sich wiederum strikt an RFC 2119 halten, übernommen worden und sollten auch exakt so verstanden werden.
Die wichtigsten Schlüsselworte wurden/werden nach folgendem, in RFC2119 definierten Sinn übersetzt:

• Autoloading Standard - Er zielt darauf ab, ein standardisiertes Dateiformat sowie Klassennamen und Namespace Konventionen bereitzustellen, die Plug&Play Code ermöglichen. Seit 2014-10-21 ist PSR-0 als unerwünscht markiert. PSR-4 ist jetzt als Alternative empfohlen.
• Basic Coding Standard - Hiermit soll ein möglichst hoher Grad an Kompatibilität von PHP-Code aus unterschiedlichen Quellen erreicht werden.
• Extended Coding Style Enthält Anweisungen, die dafür sorgen, dass PHP-Code immer eine standardisierte optische Erscheinung hat.
• Improved Autoloading - Eine modernere Interpretation automatischen Ladens, die die weiteren Fortschritte im Ökosystem reflektiert.
• WebsiteBaker-Adaption - Generelle Anpassung der PSR-Standards an spezielle Bedingungen von WebsiteBaker.

Mit jeder weiteren Version von WebsiteBaker entfernt sich der Programmierstil immer weiter vom bisherigen, seit 15 Jahren gewohnten, 'anarchischen' Stil, hin zu einer immer modulareren, jedoch zwangsweise auch an strenge Schnittstellen gebundenen Programmierweise. Das wird vor allem von Addon-Programmierern ein konsequentes Umdenken erfordern.
Derzeit, also bis zur 2.10 ist die Einhaltung vieler Regeln noch freiwillig, in der 2.12 wird vieles bereits deprecated und nach der 2.12 werden nach und nach viele der Vorgaben zwingend werden. Das alles hört sich für viele sehr einschränkend an, was aber gerne in Kauf genommen wird, da genau diese Einschränkungen letztendlich für eine stabile Modularität, für stabile Flexibilität und für Austauschbarkeit, Wiederverwendbarkeit und vor allem Wartungsfreundlichkeit von Code sorgen werden.

.. die eigentlich so, unabhängig von WB, in jedem halbwegs professionellen Projekt gelten sollten und Grundlage jeder ernsthaften Programmierer-Ausbildung sind.

Addons…

1. … dürfen weder den Core noch andere Addons triggern, sondern werden grundsätzlich vom steuernden Core getriggert
2. … dürfen den Ablauf des Gesamtsystems nicht stören
3. … ist im Normalfall keine direkte Verbindung zur Außenwelt gestattet
4. … dürfen niemals schreibend auf Datenbereiche anderer Addons oder des Core zugreifen
5. … dürfen niemals den Code anderer Addons oder des Core ändern (gilt auch für Installation und Upgrade)
6. … dürfen ausschließlich über den Responder des Core Daten zum Browser etc. senden
7. … dürfen keine globalen Variablen oder globalen Konstanten definieren.
8. … dürfen niemals eine indirekte Adressierung verwenden oder zulassen!

für spätere Versionen (nach 2.10.x) werden noch weitere Einschränkungen kommen. Siehe die jeweiligen Abschnitte dieser Dokumentation.