Recent Posts

1

General Help & Support / Re: WebsiteBaker 2.13.10 Security Update - developer issues

« Last post by hgs on Today at 08:24:53 AM »

Welcome to the WebsiteBaker family


We’re working hard on further developing WebsiteBaker—you can get a sneak peek here—but security has always been a core part of WebsiteBaker.


And we’ve already kicked off a new development project; you can read about it here.


Perhaps you could tell us a little about the planned modules—feel free to send an email to board@WebsiteBaker.org.

2

General Help & Support / Re: WebsiteBaker 2.13.10 Security Update - developer issues

« Last post by dbs on August 28, 2026, 04:08:46 PM »

Hi, we introduced these restrictions because installation and update scripts run with high privileges. A compromised or malicious module could otherwise modify files outside its own directory, execute dangerous functions, or install a backdoor. CodeGuard therefore uses conservative rules to reduce the attack surface and protect existing WebsiteBaker installations.

For modules and templates, mkdir() is blocked in install.php and update.php because CodeGuard cannot reliably prove that dynamically built paths remain inside the module or template directory. Path traversal, manipulated input, or symlinks could otherwise allow writes elsewhere.
The recommended alternatives are:

• Include required fixed directories directly in the module/template ZIP.
• Use fixed, pre-created subdirectories.
• Create dynamic subdirectories later during normal module operation, using a strictly controlled base path.

$auditDenied() is a variable function call. Because the variable can contain any function name, it could potentially execute dangerous functions.
Use a direct call instead: auditDenied()
For several permitted actions, use explicit if/switch branches rather than dynamic callbacks.

3

General Help & Support / WebsiteBaker 2.13.10 Security Update - developer issues

« Last post by FerRik on August 28, 2026, 01:43:39 PM »

Updating security is always a good thing.
But sometimes it’s hard to understand why certain decisions were made....

Why is it no longer possible to use the `mkdir` command in `install.php` and `update.php`?

Why can’t the `$auditDenied()` variable be called anymore?

We’ve created several modules and templates that were supposed to be released in the coming months. Unfortunately, that’s on hold for now.

4

Hilfe & Support (deutsch) / Re: Fehlermeldung wbstats/class.count.php on line 303

« Last post by hgs on August 24, 2026, 09:38:25 PM »

Ich habe mich mal ein wenig mit den Meldungen von CodeGuard beschäftigt, diese haben mich zu zwei Problemen geführt.


1. Problem war die Datei Thumbs.db im Verzeichnis /js
Fehlermeldung war ja

Code: [Select]

....Nicht erlaubte Dateiendung .db in js/Thumbs.db

Nachdem die Datei Thumbs.db gelöscht wurde, wurde das 2. Problem mit der nachfolgenden Fehlermeldung sichtbar.


Die Fehlermeldung lautete:

Code: [Select]

24-08-2026 20:05 SEC-20260824-180531-2205 module file_scan blocked class.count.php :: Variable function call is forbidden: $find()

Die Ki hat dann den Code von class.count.php umgestalltet und damit ließ sich das Modul fehlerfrei installieren.


Die geänderte Datei ist als class.count.php.zip angehängt.
Die Änderungen fangen bei zn 953 an und gehen bis zum Ende.

5

Hilfe & Support (deutsch) / Re: Fehlermeldung wbstats/class.count.php on line 303

« Last post by hgs on August 23, 2026, 07:24:17 PM »

Hallo Ruud
wegen zwei Sicherheitslücken haben wir eine WebsiteBaker 2.13.10 herausgebracht und fangen die gemeldeten Lücken unter anderem mit einem CodeGuard ab.
Beim Versuch wbstats_v0.2.5.9.zi p zu installieren, kommt es zu dieser Fehlermeldung vom CodeGuard:

Code: [Select]

[327] CodeGuard hat diese Aktion aus Sicherheitsgruenden gestoppt.CodeGuard-ID: CG-20260823-171448-AFDEArchiv: Nicht erlaubte Dateiendung .db in js/Thumbs.dbKannst du damit was anfangen und ggf. fixen, Danke





Hallo Ruud,
vanwege twee beveiligingslekken hebben we WebsiteBaker 2.13.10 uitgebracht en pakken we de gemelde lekken onder andere aan met CodeGuard.
Bij een poging om wbstats_v0.2.5.9.zi p te installeren, verschijnt deze foutmelding van CodeGuard:


Kun je hier iets mee doen en het eventueel oplossen? Bedankt.

6

Hilfe & Support (deutsch) / Re: Upgrade: Version 2.13.10 r26

« Last post by dbs on August 23, 2026, 03:11:40 PM »

Hallo, bleib ruhig bei PHP 8.4.
Du machst dir aber nichts kaputt, wenn du 8.5 testest. Sollte was nicht gehen oder zuviele Fehlermeldungen im Log auftauchen, dann gehst wieder zurück.
Wir arbeiten im Hintergrund an WB 2.14, welches vieles besser macht. Dauert noch paar Wochen.

7

Hilfe & Support (deutsch) / Upgrade: Version 2.13.10 r26

« Last post by deb01 on August 23, 2026, 11:41:58 AM »

Vielen Dank für die neue Version und die unermüdliche Arbeit.
Das Upgrade funktionierte.

Frage: ist PHP 8.4 (ausgewählt beim Provider) die richtige Einstellung bzw. kann man PHP 8.5 auch schon probieren.
Oder anders gefragt: gibt es für die Kompatibilität mit PHP 8.5 schon einen großen Zeitplan?

Viele Grüße und nochmals besten Dank
Bernd

8

Development 2.10.x and up / MOVED: Offizielle Neuentwicklung für WebsiteBaker - Brainstorming und Diskussion

« Last post by hgs on August 16, 2026, 10:05:38 PM »

This topic has been moved to Development 3.x.

https://forum.WebsiteBaker.org/index.php?topic=32517.0

9

Development 3.x / Offizielle Neuentwicklung für WebsiteBaker - Brainstorming und Diskussion

« Last post by Tommy on August 16, 2026, 05:34:06 PM »

1. Einleitung
Ich wurde der Neuentwicklung von WebsiteBaker (WB) zugeteilt. Diese Arbeit hat keinen Einfluss auf die Entwicklung der aktuellen Versionen. Was folgt, ist das Ergebnis umfangreicher Überlegungen und Recherchen zu Problemen von WB und anderen CMS‑Systemen. Der Text dient als Diskussionsgrundlag e – nichts ist final.

2. Warum eine Neuentwicklung?
WB ist in die Jahre gekommen. Der Wartungsaufwand steigt, neue Features lassen sich nur schwer integrieren. Die Codebasis ist für ihr Alter solide, aber langfristig brauchen wir einen Ersatz, bevor WB 2.x an seine Grenzen stößt.

3. Grundprinzipien & Ziele
    • Sicherheit
    • Stabilität
    • Geschwindigkeit
    • Einfache Bedienbarkeit
    • Flexibilität ohne unnötige Komplexität
    • Weiterhin voll lauffähig auf klassischen Webhostern (PHP‑FPM, kein eigener Port)
Moderne Features wie WebSockets sind unter diesen Bedingungen nicht realisierbar – das ist akzeptabel.

4. Entwicklungsprozess
Die Neuentwicklung soll offen erfolgen. Wir sammeln gemeinsam Anforderungen, Wünsche und Ideen – auch solche, die früher technisch nicht möglich waren. Plugin‑Entwickler sollen den Fortschritt sehen können.

5. Technischer Ablauf (Lifecycle)
Request → Boot → Routing → Seitengenerierung → Response
Boot
Konfigurationen und Dienste müssen bei jedem Request neu geladen werden. Ziel: Minimale I/O durch zusammengefasste Konfigurationsdatei en und schnelle Maps. Ein Config‑Cache reduziert unnötige Dateizugriffe.
Routing
Eine einfache Map ordnet Routen den zuständigen Plugins zu. Beispiel: /news → News‑Plugin /api/user → API‑Plugin
Seitengenerierung
Ein flexibles Cache‑Konzept ist zentral: Plugins definieren, wie lange Inhalte gültig sind. Cachebar als Ganzes oder in Teilen – je nach Content.

6. Architektur: Core & Plugins
Der Core enthält nur unverzichtbare Bestandteile:
    • Konfiguration
    • Log‑API
    • Pluginverwaltung
    • Routing
    • Event‑System
    • Abhängigkeitsverwal tung
    • Template‑System (nicht die Engine)
    • Datenbankzugriff
Alles andere – Seiten, Content, Backend‑Module, Userverwaltung – wird als Plugin umgesetzt. Dadurch erhält kein Plugin Sonderstatus und kann vollständig ersetzt werden.
Das System wird mit einem Basissatz an Plugins ausgeliefert, bleibt aber modular.

7. Log‑API
Ein einheitliches Logging für Core und Plugins. Log‑Einträge werden an beliebige Log‑Plugins weitergereicht. Zusätzlich: ein einfaches Core‑Log und ein File‑Log, das ohne Abhängigkeiten schon ab dem ersten Request funktioniert.

8. Pluginverwaltung
Plugins sind die Bausteine des Systems. Wichtig sind:
    • Installation
    • Updates
    • Deinstallation
    • Abhängigkeitsauflös ung
Beispiel: „News 4.5.6 benötigt Foo 4.5, aber Forum 2.2.3 ist nur mit Foo 3.x kompatibel.“
Pluginquellen können flexibel sein: (S)FTP, GitHub Packages, Composer usw.

9. Routing im Detail
Plugins melden sich für bestimmte Routen oder Muster an. Der Core verwaltet eine Map und findet schnell das passende Plugin. Auch das klassische WB‑Page‑System lässt sich damit abbilden.

10. Templates
Templates sind einfach, aber flexibel:

Quellen:
    • Plugin‑Templates
    • Seiten‑Templates
    • Template‑Erweiterungen
    • User‑Templates

Überschreibreihenfo lge:
    1. Plugin
    2. Seite
    3. User

Der Core baut daraus ein virtuelles Template. Plugins beziehen Templates über den Core, z. B.: WB→templates→gibMir(„einzelansichtKlein.html“, „newsModulXY“)
Die Template‑Engine ist austauschbar (Twig oder eigene Engine).

11. Backend
Das Backend ist ein Rahmen mit Menüstruktur. Plugins liefern ihre eigenen Oberflächen. Pages, Log, Pluginmanager, Userverwaltung usw. sind alles Plugins.

12. Abschluss
Mit einer guten Codebasis wird vieles einfacher. Flexibilität entsteht durch klare, einfache Strukturen. Alle erweiterten Funktionen bleiben optional. Das System soll so klein wie möglich bleiben.


Was meint ihr? Welche Ideen oder Wünsche habt ihr für das neue System?

10

Hilfe & Support (deutsch) / Re: Delete Hidden KI Characters

« Last post by markherrmann on August 14, 2026, 10:08:44 PM »

Ja schon, hab mein Template mal angepasst und lass nur noch so ausliefern.
Keine 100% aber nicht mehr ganz so offensichtlich. Bei dem was alles so an Requests kommt (hab derzeit 6k in 30 Tagen,  ca. 25% Googel und Bing, 25% aus DE/AT/CH, Rest Müll aus aller Herren Länder (wobei häufig Asien dabei war)