Support WebsiteBaker
11
General Help & Support / Re: WB-Version herausfinden wenn es nicht mehr läuft
« Last post by crnogorac081 on September 28, 2025, 11:17:53 AM »Hello, post your wb info (wb and php version ) and error log
News
WebsiteBaker 2.13.9 R24 is now available!
R.I.P Dietmar (luisehahne) and thank you for all your valuable work for WB
https://forum.websitebaker.org/index.php/topic,32355.0.html
Support WebsiteBaker
Your donations will help to:
- Pay for our dedicated server
- Pay for domain registration
- and much more!
You can donate by clicking on the button below.
Recent Posts
12
General Help & Support / WB-Version herausfinden wenn es nicht mehr läuft
« Last post by gba on September 28, 2025, 11:11:02 AM »Hallo zusammen,
eine meiner Installationen, die ich leider nur sehr selten ansehe, läuft nicht mehr.
Und zwar gar nicht mehr, auch das Backed nicht. Einfach nur ein weißer Bildschirm.
In der log-Datei steht:
[05-Aug-2024 22:14:53 UTC] PHP Fatal error: __autoload() is no longer supported, use spl_autoload_regist er() instead in /pages/68/d0/d0013785/home/htdocs/dm-indoor2016/include/phpmailer/PHPMailerAutoload.php on line 45
Ich habe das mal versuchsweise gemacht, aber dann gibt es weitere Fehlermeldungen.
Meine Vermutung ist, dass ich noch eine alte WB-Version habe, die von PHP8.x noch nie etwas gehört hat. Aber ohne Backend kann ich das nicht nachsehen.
Wie kann ich jetzt herausfinden welche Version ich habe, damit ich ein Update machen kann?
Und Nebeninformation: Leider habe ich nur geringe PHP-Kenntnisse.
Gruß Gerhard
eine meiner Installationen, die ich leider nur sehr selten ansehe, läuft nicht mehr.
Und zwar gar nicht mehr, auch das Backed nicht. Einfach nur ein weißer Bildschirm.
In der log-Datei steht:
[05-Aug-2024 22:14:53 UTC] PHP Fatal error: __autoload() is no longer supported, use spl_autoload_regist er() instead in /pages/68/d0/d0013785/home/htdocs/dm-indoor2016/include/phpmailer/PHPMailerAutoload.php on line 45
Ich habe das mal versuchsweise gemacht, aber dann gibt es weitere Fehlermeldungen.
Meine Vermutung ist, dass ich noch eine alte WB-Version habe, die von PHP8.x noch nie etwas gehört hat. Aber ohne Backend kann ich das nicht nachsehen.
Wie kann ich jetzt herausfinden welche Version ich habe, damit ich ein Update machen kann?
Und Nebeninformation: Leider habe ich nur geringe PHP-Kenntnisse.
Gruß Gerhard
13
General Help & Support / Re: Make /admin forbidden for one particular user (user_id ==2)
« Last post by crnogorac081 on September 20, 2025, 06:16:59 PM »Long time ago i tried to create new users class for this, new user and group table, $_SESSION["FE_User_Id"] insted User_id , but I stoped developing that Long time ago
14
General Help & Support / Re: Make /admin forbidden for one particular user (user_id ==2)
« Last post by CodeALot on September 19, 2025, 03:18:10 PM »We are not so much 'separated' in our wishes 
That would give the option to leave the frontend part out completely (in case you need one password for all) or embed it if you want all individual logins. What remains is the original wish: no access to backend.
Quote
My "wish" is to have all that in the frontend. No access to the backend. Like you change your data in your Amazon account. For example
That would give the option to leave the frontend part out completely (in case you need one password for all) or embed it if you want all individual logins. What remains is the original wish: no access to backend.
15
General Help & Support / Re: Make /admin forbidden for one particular user (user_id ==2)
« Last post by sternchen8875 on September 19, 2025, 02:16:18 PM »Das ist das, was uns trennt, mein Freund:
du suchst eine Lösung: ein Password für alle, kein Admin-Bereich
Ich suche eine Lösung für WB - Frontend-User können sich anmelden, registrieren und erhalten kein Backend-Zugang, aber sehr wohl Zugang zum eigenem Profil (im Frontend)
Ich sagte ja, Obiges ist nur ein erster Schritt - der nächste war, das Backend zu sperren durch das neue Recht. Die Loginmaske bleibt, ohne Recht erfolgt eine direkte Ummeldung ins Frontend. Was nun bleibt, ist die Möglichkeit, über das Frontend (mein 1. Bild oben) die Profildaten zu ändern.
Bedeutet aber, jeder User kann SEIN Passwort, sein Profil ändern.
Wenn das nicht gefällt, bin ich raus
engl. Translation
This is what separates us, my friend:
You're looking for a solution: one password for everyone, no admin area.
I'm looking for a solution for WB - front-end users can log in, register, and don't get back-end access, but they do get access to their own profile (in frontend).
I told you, the above is just a first step - the next step was to block the back-end using the new permission. The login mask remains; without authorization, you are redirected to the frontend. What remains now is the ability to change profile data via the front-end (my first image above).
But that means every user can change THEIR password, their profile.
If I don't like that, I'm out.
Admin Comment: add the red marked info - is important on this place
du suchst eine Lösung: ein Password für alle, kein Admin-Bereich
Ich suche eine Lösung für WB - Frontend-User können sich anmelden, registrieren und erhalten kein Backend-Zugang, aber sehr wohl Zugang zum eigenem Profil (im Frontend)
Ich sagte ja, Obiges ist nur ein erster Schritt - der nächste war, das Backend zu sperren durch das neue Recht. Die Loginmaske bleibt, ohne Recht erfolgt eine direkte Ummeldung ins Frontend. Was nun bleibt, ist die Möglichkeit, über das Frontend (mein 1. Bild oben) die Profildaten zu ändern.
Bedeutet aber, jeder User kann SEIN Passwort, sein Profil ändern.
Wenn das nicht gefällt, bin ich raus
engl. Translation
This is what separates us, my friend:
You're looking for a solution: one password for everyone, no admin area.
I'm looking for a solution for WB - front-end users can log in, register, and don't get back-end access, but they do get access to their own profile (in frontend).
I told you, the above is just a first step - the next step was to block the back-end using the new permission. The login mask remains; without authorization, you are redirected to the frontend. What remains now is the ability to change profile data via the front-end (my first image above).
But that means every user can change THEIR password, their profile.
If I don't like that, I'm out.
Admin Comment: add the red marked info - is important on this place
16
General Help & Support / Re: Make /admin forbidden for one particular user (user_id ==2)
« Last post by CodeALot on September 19, 2025, 01:04:08 PM »Is this a decision the customer made based on WB's circumstances, or one they would like to have regardless of the CMS used? As far as I know, this solution (one password for everyone) doesn't exist in any modern CMS.Ehm... Yes, it's very easy: create one user called "visitor" and give it a password. Tell everyone about the name and password. Done.
But I know, that's just a very simple 'barrier' to prevent a site to be 100% public. And that's all they needed in this case.
Quote
I followed your suggestion; it's an idea we've been discussing here for a long time: a new permission, with the example name "backend_user." This leaves the user with the backend login and the option to only change their profile data.
https://i.gyazo.com/7ecb68d722b9ebb23d645fbe8d2df867.png
That is the same as creating a user without any permissions - but they still can access /admin and change their profile. My "wish" is to have all that in the frontend. No access to the backend. Like you change your data in your Amazon account. For example
17
General Help & Support / Re: Make /admin forbidden for one particular user (user_id ==2)
« Last post by sternchen8875 on September 19, 2025, 12:13:12 PM »Quote
I agree, although in this case it's a website for elderly people, locked behind at least some sort of security to prevent people from 'outside' to be able to access the website. Getting them to use the website is a task in itself, and the client decided not to make things more complicated by issuing every single user a separate login...
Is this a decision the customer made based on WB's circumstances, or one they would like to have regardless of the CMS used? As far as I know, this solution (one password for everyone) doesn't exist in any modern CMS.
I followed your suggestion; it's an idea we've been discussing here for a long time: a new permission, with the example name "backend_user." This leaves the user with the backend login and the option to only change their profile data.
https://i.gyazo.com/7ecb68d722b9ebb23d645fbe8d2df867.png
The same options are then available in the frontend.
https://i.gyazo.com/a71882219c8121dd18fc1a6f9ab405bf.png
But that means: every user has their own password.
It's currently just a "rough fix," not a professional solution, and it's only a first step. If you go through with this, you'll have to secure every admin subpage, rewrite the frontend login, etc.
So it's not something that can be completed in 10 minutes.
-------------------------------
Ist das eine Entscheidung, die der Kunde auf Grund der Gegebenheiten von WB getroffen hat oder ein, die er, unabhängig vom verwendetem CMS gern hätte?. Meines Wissens gibt es diese Lösung (ein Passwort für alle) in keinem modernen CMS.
Ich bin mal deinem Vorschlag gefolgt, ist ja eine Idee, die wir hier schon lange diskutierten, einem neuen Recht, als Bespielname "backend_user". Damit bleiben dem User der Backend-Login und dort die Möglichkeit, lediglich die Profildaten zu ändern
https://i.gyazo.com/7ecb68d722b9ebb23d645fbe8d2df867.png
im Frontend dann die gleichen Optionen
https://i.gyazo.com/a71882219c8121dd18fc1a6f9ab405bf.png
Heißt aber: jeder User hat sein Passwort
Ist aktuell nur "rein gewurstelt", keine Profi-Lösung und es ist nur ein erster Schritt. Zieht man das durch, muß man so jede Admin-Unterseite absichern, den Frontend-Login neu schreiben usw
Also nichts, was in 10 min fertig ist
18
General Help & Support / Re: Make /admin forbidden for one particular user (user_id ==2)
« Last post by CodeALot on September 19, 2025, 11:46:51 AM »I don't think much of the solution: one access for everyone in the frontend, one password that everyone shares. That's no protection. It's just a solution born out of necessity.I agree, although in this case it's a website for elderly people, locked behind at least some sort of security to prevent people from 'outside' to be able to access the website. Getting them to use the website is a task in itself, and the client decided not to make things more complicated by issuing every single user a separate login...
19
General Help & Support / Re: Make /admin forbidden for one particular user (user_id ==2)
« Last post by sternchen8875 on September 19, 2025, 10:41:09 AM »The old problem: backend users vs. frontend users
Web administration is one of the most secure areas of any CMS. What it lacks, and has been since the beginning, is the separation of frontend and backend permissions. Many of us who have addressed this issue have been dismissed with the words: "It's not possible without completely redesigning the CMS." I've had my share of experience with this, too.
My idea was not to weaken the system, but rather to add a few more permissions, frontend user permissions.
I don't think much of the solution: one access for everyone in the frontend, one password that everyone shares. That's no protection. It's just a solution born out of necessity. I'm of the opinion that a registered user must always be able to change their own data, their profile; a freely selectable password, an email address—that must be mandatory.
But it's not something you can quickly add with three lines of code, so at the moment we can only offer one solution: use .htaccess/.htpasswd to protect the admin folder. This requires a double login for the admins, but it's the only viable option at the moment.
What we can do in this thread is gather ideas for how things could proceed.
---------------------------
Das alte Problem: Backend-Nutzer vs. Frontend-Nutzer
Der WB-Admin-Bereich ist einer der sichersten Bereiche aller CMS. Was ihr seit jeher fehlt, ist die Trennung von Frontend- und Backend-Berechtigungen. Viele von uns, die sich mit diesem Thema befasst haben, wurden mit den Worten abgetan: „Ohne eine komplette Neugestaltung des Codes geht das nicht.“ Auch ich habe damit meine Erfahrungen gemacht.
Meine Idee war nicht, das System aufzuweichen, sondern ein paar zusätzliche Berechtigungen hinzuzufügen, Frontend-Nutzerberechtigungen.
Ich halte nichts von der Lösung: Ein Zugang für alle im Frontend, ein gemeinsames Passwort. Das ist kein Schutz. Es ist nur eine aus der Not geborene Lösung. Ich bin der Meinung, dass ein registrierter Nutzer jederzeit seine eigenen Daten, sein Profil, ändern können muss; ein frei wählbares Passwort, eine E-Mail-Adresse – das muss Pflicht sein.
Da sich das aber nicht schnell mit drei Zeilen Code hinzufügen lässt, können wir derzeit nur eine Lösung anbieten: Verwende .htaccess/.htpasswd, um den Admin-Ordner zu schützen. Dies erfordert zwar eine doppelte Anmeldung für die Administratoren, ist aber derzeit die einzige praktikable Option.
Wir können in diesem Thread nur Ideen sammeln, wie es weitergehen könnte.
Web administration is one of the most secure areas of any CMS. What it lacks, and has been since the beginning, is the separation of frontend and backend permissions. Many of us who have addressed this issue have been dismissed with the words: "It's not possible without completely redesigning the CMS." I've had my share of experience with this, too.
My idea was not to weaken the system, but rather to add a few more permissions, frontend user permissions.
I don't think much of the solution: one access for everyone in the frontend, one password that everyone shares. That's no protection. It's just a solution born out of necessity. I'm of the opinion that a registered user must always be able to change their own data, their profile; a freely selectable password, an email address—that must be mandatory.
But it's not something you can quickly add with three lines of code, so at the moment we can only offer one solution: use .htaccess/.htpasswd to protect the admin folder. This requires a double login for the admins, but it's the only viable option at the moment.
What we can do in this thread is gather ideas for how things could proceed.
---------------------------
Das alte Problem: Backend-Nutzer vs. Frontend-Nutzer
Der WB-Admin-Bereich ist einer der sichersten Bereiche aller CMS. Was ihr seit jeher fehlt, ist die Trennung von Frontend- und Backend-Berechtigungen. Viele von uns, die sich mit diesem Thema befasst haben, wurden mit den Worten abgetan: „Ohne eine komplette Neugestaltung des Codes geht das nicht.“ Auch ich habe damit meine Erfahrungen gemacht.
Meine Idee war nicht, das System aufzuweichen, sondern ein paar zusätzliche Berechtigungen hinzuzufügen, Frontend-Nutzerberechtigungen.
Ich halte nichts von der Lösung: Ein Zugang für alle im Frontend, ein gemeinsames Passwort. Das ist kein Schutz. Es ist nur eine aus der Not geborene Lösung. Ich bin der Meinung, dass ein registrierter Nutzer jederzeit seine eigenen Daten, sein Profil, ändern können muss; ein frei wählbares Passwort, eine E-Mail-Adresse – das muss Pflicht sein.
Da sich das aber nicht schnell mit drei Zeilen Code hinzufügen lässt, können wir derzeit nur eine Lösung anbieten: Verwende .htaccess/.htpasswd, um den Admin-Ordner zu schützen. Dies erfordert zwar eine doppelte Anmeldung für die Administratoren, ist aber derzeit die einzige praktikable Option.
Wir können in diesem Thread nur Ideen sammeln, wie es weitergehen könnte.
20
General Help & Support / Re: Make /admin forbidden for one particular user (user_id ==2)
« Last post by CodeALot on September 19, 2025, 09:43:44 AM »No, my goal was to prevent them from having access to /admin alltogether. I solved it now with a redirect in the admin templates based on a user_id. Not the most elegant way but OK.
Which brings me to a new suggestion:
When you create a user, you can specify what that user can do. View pages, edit pages, view media etc etc. This is all based on the assumption that every logged in user has a role in maintaining the website.
Now what if there is a checkbox that says "Allow user access to admin-screens"? Like a "on/off" switch for users that have some sort of admin-role and those who only need a login to access the website?
Giving those users access to the /admin will only confuse most of them since it's a completely different environment. I prefer to handle login and change password stuff within the website (frontend) itself.
------------------------
Nein, mein Ziel war es, ihnen den Zugriff auf /admin insgesamt zu verwehren. Ich habe das Problem nun mit einer Weiterleitung in den Admin-Vorlagen auf Basis einer user_id gelöst. Nicht die eleganteste Lösung, aber OK.
Das bringt mich zu einem neuen Vorschlag:
Wenn Sie einen Benutzer anlegen, können Sie festlegen, was dieser Benutzer tun darf. Seiten anzeigen, Seiten bearbeiten, Medien anzeigen usw. Dies basiert alles auf der Annahme, dass jeder angemeldete Benutzer eine Rolle bei der Pflege der Website hat.
Was wäre nun, wenn es ein Kontrollkästchen mit der Bezeichnung „Benutzerzugriff auf Admin-Bildschirme zulassen” gäbe? Wie ein „Ein/Aus”-Schalter für Benutzer, die eine Art Admin-Rolle haben, und solche, die nur eine Anmeldung benötigen, um auf die Website zuzugreifen?
Diesen Benutzern Zugriff auf /admin zu gewähren, würde die meisten von ihnen nur verwirren, da es sich um eine völlig andere Umgebung handelt. Ich ziehe es vor, die Anmeldung und die Änderung des Passworts innerhalb der Website (Frontend) selbst zu handhaben.
Übersetzt mit DeepL.com (kostenlose Version)
Which brings me to a new suggestion:
When you create a user, you can specify what that user can do. View pages, edit pages, view media etc etc. This is all based on the assumption that every logged in user has a role in maintaining the website.
Now what if there is a checkbox that says "Allow user access to admin-screens"? Like a "on/off" switch for users that have some sort of admin-role and those who only need a login to access the website?
Giving those users access to the /admin will only confuse most of them since it's a completely different environment. I prefer to handle login and change password stuff within the website (frontend) itself.
------------------------
Nein, mein Ziel war es, ihnen den Zugriff auf /admin insgesamt zu verwehren. Ich habe das Problem nun mit einer Weiterleitung in den Admin-Vorlagen auf Basis einer user_id gelöst. Nicht die eleganteste Lösung, aber OK.
Das bringt mich zu einem neuen Vorschlag:
Wenn Sie einen Benutzer anlegen, können Sie festlegen, was dieser Benutzer tun darf. Seiten anzeigen, Seiten bearbeiten, Medien anzeigen usw. Dies basiert alles auf der Annahme, dass jeder angemeldete Benutzer eine Rolle bei der Pflege der Website hat.
Was wäre nun, wenn es ein Kontrollkästchen mit der Bezeichnung „Benutzerzugriff auf Admin-Bildschirme zulassen” gäbe? Wie ein „Ein/Aus”-Schalter für Benutzer, die eine Art Admin-Rolle haben, und solche, die nur eine Anmeldung benötigen, um auf die Website zuzugreifen?
Diesen Benutzern Zugriff auf /admin zu gewähren, würde die meisten von ihnen nur verwirren, da es sich um eine völlig andere Umgebung handelt. Ich ziehe es vor, die Anmeldung und die Änderung des Passworts innerhalb der Website (Frontend) selbst zu handhaben.
Übersetzt mit DeepL.com (kostenlose Version)