Support WebsiteBaker
91
General Help & Support / Re: Feature Request: Hide pages in the backend
« Last post by crnogorac081 on September 15, 2025, 08:01:50 PM »It Is doable, the display would be same way as my search works (1 Level) https://ibb.co/py9cnTx
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
92
General Help & Support / Re: Feature Request: Hide pages in the backend
« Last post by sternchen8875 on September 15, 2025, 04:13:40 PM »english by Deepl
In principle, it's an idea I could live with. And... it could be made switchable in the WB options or something like that.
From a purely technical point of view, it would probably slow down the current page tree, as one more check would be necessary for each field in a row. I see problems more in terms of clarity. In a test installation, for example, I have 8 possible levels. If I now set levels 7 and 6 for an editor named Bob, he would have to see the page tree up to that point. If I have to display it anyway, does the idea still make sense?
A "radical" solution might be to dispense with a tree or the staircase-shaped nesting as such. In the end, Bob has 5 pages to edit and Steve has 5 others, and where these are located in the tree could be displayed differently. That would probably mean having to say goodbye to the current page overview. But if I, as a super admin or administrator group, can define this, all that is needed is a different way of processing the data.
So it's technically feasible, and I've wanted this a few times, but since I've always been the super admin and editor in all my projects, the need for such a solution wasn't so great that I had to pursue it.
In the end, the question is really, is this what Steve and Bob should see? A list of approved pages, nothing more?
german
Vom Grundsatz her eine Idee, mit der ich gut leben könnte. Und.. es ließe sich ja schaltbar machen in den WB-Optionen oder so
Rein technisch würde es wohl den aktuellen Pagetree langsamer machen, da für jedes Feld in einer Zeile eine Prüfung mehr nötig wäre. Probleme sehe ich eher in der Übersichtlichkeit. In einer Testinstallation habe ich z.b. 8 mögliche Level. Wenn ich nun Level7 und Level6 für einen Bearbeiter Bob festlege, muß der wohl den Seitenbaum bis dahin sehen. Wenn ich den sowieso darstellen muß, macht die Idee dann noch Sinn?
Eine "radikale" Lösung wäre vielleicht, auf einen Tree bzw die darstellende Verschachtelung in Treppenform als solche zu verzichten. Am Ende hat Bob 5 Seiten zu bearbeiten und Steve 5 andere, wo diese im Tree liegen, ließe sich ja anders darstellen. Das hieße wohl, das man sich vom Bild der aktuellen Seitenübersicht verabschieden muß. Aber wenn ich als SuperAdmin oder Administratorgruppe das so festlegen kann, braucht es nur eine andere Aufbereitung der Daten.
Also technisch durchaus umsetzbar und ein paar Mal hab ich mir das auch schon gewünscht, da ich aber in alle meinen Projekten auch immer SuperAdmin und Redakteur war, war der Zwang zu solcher Lösung nicht so groß, das man sich dahinter klemmt
Die Frage ist am Ende wirklich, ist es das, was Steve und Bob sehen sollen? Eine Liste mit den zugelassenen Seiten, nicht mehr?
In principle, it's an idea I could live with. And... it could be made switchable in the WB options or something like that.
From a purely technical point of view, it would probably slow down the current page tree, as one more check would be necessary for each field in a row. I see problems more in terms of clarity. In a test installation, for example, I have 8 possible levels. If I now set levels 7 and 6 for an editor named Bob, he would have to see the page tree up to that point. If I have to display it anyway, does the idea still make sense?
A "radical" solution might be to dispense with a tree or the staircase-shaped nesting as such. In the end, Bob has 5 pages to edit and Steve has 5 others, and where these are located in the tree could be displayed differently. That would probably mean having to say goodbye to the current page overview. But if I, as a super admin or administrator group, can define this, all that is needed is a different way of processing the data.
So it's technically feasible, and I've wanted this a few times, but since I've always been the super admin and editor in all my projects, the need for such a solution wasn't so great that I had to pursue it.
In the end, the question is really, is this what Steve and Bob should see? A list of approved pages, nothing more?
german
Vom Grundsatz her eine Idee, mit der ich gut leben könnte. Und.. es ließe sich ja schaltbar machen in den WB-Optionen oder so
Rein technisch würde es wohl den aktuellen Pagetree langsamer machen, da für jedes Feld in einer Zeile eine Prüfung mehr nötig wäre. Probleme sehe ich eher in der Übersichtlichkeit. In einer Testinstallation habe ich z.b. 8 mögliche Level. Wenn ich nun Level7 und Level6 für einen Bearbeiter Bob festlege, muß der wohl den Seitenbaum bis dahin sehen. Wenn ich den sowieso darstellen muß, macht die Idee dann noch Sinn?
Eine "radikale" Lösung wäre vielleicht, auf einen Tree bzw die darstellende Verschachtelung in Treppenform als solche zu verzichten. Am Ende hat Bob 5 Seiten zu bearbeiten und Steve 5 andere, wo diese im Tree liegen, ließe sich ja anders darstellen. Das hieße wohl, das man sich vom Bild der aktuellen Seitenübersicht verabschieden muß. Aber wenn ich als SuperAdmin oder Administratorgruppe das so festlegen kann, braucht es nur eine andere Aufbereitung der Daten.
Also technisch durchaus umsetzbar und ein paar Mal hab ich mir das auch schon gewünscht, da ich aber in alle meinen Projekten auch immer SuperAdmin und Redakteur war, war der Zwang zu solcher Lösung nicht so groß, das man sich dahinter klemmt
Die Frage ist am Ende wirklich, ist es das, was Steve und Bob sehen sollen? Eine Liste mit den zugelassenen Seiten, nicht mehr?
93
General Help & Support / Re: Feature Request: Hide pages in the backend
« Last post by ruebenwurzel on September 15, 2025, 02:52:13 PM »Hallo,
Probleme sehe ich bei verschachtelten Strukturen. Wenn Bob nur Seiten der Hauptebene bearbeiten darf und Steve nur jeweils die Unterseiten dieser Hauptseiten und ein dritter nur einzelne Unterseiten der Unterseiten, wie will man das dann darstellen. Alles auf einer Ebene? Wie sieht dann der Admin, der Zugriff auf alle Seiten hat, den Seitenbaum?
Finde es gar nicht so schlecht, dass die Redakteure die gesamte Seitenstruktur sehen, so wissen sie wenigstens wo sie sich gerade befinden.
Gruß
Matthias
Probleme sehe ich bei verschachtelten Strukturen. Wenn Bob nur Seiten der Hauptebene bearbeiten darf und Steve nur jeweils die Unterseiten dieser Hauptseiten und ein dritter nur einzelne Unterseiten der Unterseiten, wie will man das dann darstellen. Alles auf einer Ebene? Wie sieht dann der Admin, der Zugriff auf alle Seiten hat, den Seitenbaum?
Finde es gar nicht so schlecht, dass die Redakteure die gesamte Seitenstruktur sehen, so wissen sie wenigstens wo sie sich gerade befinden.
Gruß
Matthias
94
General Help & Support / Feature Request: Hide pages in the backend
« Last post by CodeALot on September 15, 2025, 01:08:37 PM »Situation: Ich habe eine Website mit mehreren Redakteuren erstellt.
Redakteur Bob kann nur auf die Seiten 1 bis 4 zugreifen, um sie zu bearbeiten.
Redakteur Steve kann nur auf die Seiten 5 bis 10 zugreifen, um sie zu bearbeiten.
Etcetera.
Wäre es nicht schön, wenn Bob und Steve die Seiten, die sie ohnehin nicht bearbeiten können, gar nicht erst sehen würden? Diese Seiten sind derzeit noch aufgelistet, nur nicht anklickbar. Warum sie nicht einfach ausblenden?
----
Situation: I built a website that has several editors.
Editor Bob can only access pages 1 to 4 to edit
Editor Steve can only access pages 5 to 10 to edit
Etcetera.
Wouldn't it be nice if Bob and Steve would never even SEE the pages that they can't edit anyway? Those pages are now still listed, just not clickable. Why not hide them?
Redakteur Bob kann nur auf die Seiten 1 bis 4 zugreifen, um sie zu bearbeiten.
Redakteur Steve kann nur auf die Seiten 5 bis 10 zugreifen, um sie zu bearbeiten.
Etcetera.
Wäre es nicht schön, wenn Bob und Steve die Seiten, die sie ohnehin nicht bearbeiten können, gar nicht erst sehen würden? Diese Seiten sind derzeit noch aufgelistet, nur nicht anklickbar. Warum sie nicht einfach ausblenden?
----
Situation: I built a website that has several editors.
Editor Bob can only access pages 1 to 4 to edit
Editor Steve can only access pages 5 to 10 to edit
Etcetera.
Wouldn't it be nice if Bob and Steve would never even SEE the pages that they can't edit anyway? Those pages are now still listed, just not clickable. Why not hide them?
95
Modules / Re: Duplicate entry '0-' for key 'wb_mod_news_groups.ident_news'
« Last post by sternchen8875 on September 10, 2025, 03:43:16 PM »Habe mal in den alten ZIPs recherchiert: die oben beschriebene Technik, erst einen Nuller-Eintrag anzulegen, der dann im nächsten Schritt modifiziert wird, wurde im News-Modul das letzte Mal in WB 2.8.2 angewandt. Das läßt die Vermutung zu, das es sich eine gewachsene alte Installation handelt. Und im speziellem Fall der Tabelle mod_news_groups kommt dazu, das hier irgendwann mal das Anlegen einer News-Gruppe abgebrochen wurde ohne den CANCEL-Button zu benutzen (Fenster schließen oder eine andere Aktion durchführen)
Es gäbe wohl eine technische Lösung, die beträfe jedes page-Modul im Core-Paket, also code, droplets, form, news, menu_link und wysiwyg. Da Fremdmodule nicht in der Whitelist stehen, also nicht Teil des großen Upgrades sind, wären die raus und werden nicht berücksichtigt.
Nun müßten alle Tabellen auf solche Leereinträge durchsucht werden und diese müssen entfernt werden, sofern sie denn doppelt vorhanden sind, z.b. weil das Modul in der Vergangenheit mehrfach als Sektion benutzt wurde. Das hieße: UpgradeScript unterbrechen, Löschbestätigung einholen, dann Löschen und das Script fortsetzen.
Ein Laie wird kaum wissen, was dann gemeldet wird und was er bzw das Script nun löschen soll, also klickt er auf den Button. Nun kann es technische Probleme immer geben, ein Risiko bleibt und die einfache Frage: will man das Risiko eingehen, weil es seit 2011 nur einen einzigen Fehler-Report dazu gab, der die core-Module betraf? Ich wäre eher dagegen, viel Aufwand für eine ganz kleine Gruppe von Anwendern. Dann lieber ein Fix, eine geänderte upgrade.php für genau diesen Benutzer und genau diese eine Installation
Ich kenne durchaus User, die das, wie oben beschrieben, über das Auskommentieren in der WhiteList lösten und sich so von Upgrade zu Upgrade durchhangeln. Hat funktioniert, weil es speziell im News-Modul seit mindestens 10 Jahren nix mehr zum Upgraden der Datenbank gegeben hat
Hier ein Code, der speziell für obige Fehlermeldung direkt in PhpMyAdmin o.ä. im SQL-Fenster eingefügt und ausgeführt werden kann. Der hier rot markierte TablePrefix muß dabei mit dem dort verwendeten ersetzt werden
Resultat ist entweder eine leere Liste (was bei den allermeisten Usern so sein wird) oder eine Liste mit Einträgen, die dann geprüft werden können.
Es gäbe wohl eine technische Lösung, die beträfe jedes page-Modul im Core-Paket, also code, droplets, form, news, menu_link und wysiwyg. Da Fremdmodule nicht in der Whitelist stehen, also nicht Teil des großen Upgrades sind, wären die raus und werden nicht berücksichtigt.
Nun müßten alle Tabellen auf solche Leereinträge durchsucht werden und diese müssen entfernt werden, sofern sie denn doppelt vorhanden sind, z.b. weil das Modul in der Vergangenheit mehrfach als Sektion benutzt wurde. Das hieße: UpgradeScript unterbrechen, Löschbestätigung einholen, dann Löschen und das Script fortsetzen.
Ein Laie wird kaum wissen, was dann gemeldet wird und was er bzw das Script nun löschen soll, also klickt er auf den Button. Nun kann es technische Probleme immer geben, ein Risiko bleibt und die einfache Frage: will man das Risiko eingehen, weil es seit 2011 nur einen einzigen Fehler-Report dazu gab, der die core-Module betraf? Ich wäre eher dagegen, viel Aufwand für eine ganz kleine Gruppe von Anwendern. Dann lieber ein Fix, eine geänderte upgrade.php für genau diesen Benutzer und genau diese eine Installation
Ich kenne durchaus User, die das, wie oben beschrieben, über das Auskommentieren in der WhiteList lösten und sich so von Upgrade zu Upgrade durchhangeln. Hat funktioniert, weil es speziell im News-Modul seit mindestens 10 Jahren nix mehr zum Upgraden der Datenbank gegeben hat
Hier ein Code, der speziell für obige Fehlermeldung direkt in PhpMyAdmin o.ä. im SQL-Fenster eingefügt und ausgeführt werden kann. Der hier rot markierte TablePrefix muß dabei mit dem dort verwendeten ersetzt werden
Quote
SELECT section_id, title, COUNT(*) as anzahl
FROM `{TABLE_PREFIX}mod_news_groups`
GROUP BY section_id, title
HAVING anzahl > 1;
Resultat ist entweder eine leere Liste (was bei den allermeisten Usern so sein wird) oder eine Liste mit Einträgen, die dann geprüft werden können.
96
Modules / Duplicate entry '0-' for key 'wb_mod_news_groups.ident_news'
« Last post by sternchen8875 on September 10, 2025, 01:17:13 PM »Ab und an gibt es beim Upgrade seit WB 2.10.0 zu irgendeinem Nachfolger bis hin zur aktuellen Version Abbrüche bei der Ausführung des UpgradeScripts mit dieser Fehlermeldung:
Dabei können die jeweiligen Tabellennamen unterschiedlich sein und es kann auch andere Module betreffen.
Ursache ist die "alte WB-Krankheit", immer zuerst einen leeren Eintrag zu produzieren, z.b. direkt bei der Installation oder beim Anlegen einer neuen oder auch weiteren Section des betreffenden Moduls, hier das News-Modul, Tabelle mod_news_groups
Auslöser für den jetzigen Fehler ist diese Codezeile
Aufgabe ist es, einen auf die beiden genannten Felder (hier section_id und title) bezogenen Index zu erstellen, der zum einem die Einmaligkeit (unique) eines speziellen Eintrages sicherstellt, zum anderen dafür sorgt, das Einträge schneller gefunden werden
Im vorliegendem Fall ist es so, das doppelte Einträge vorliegen, hier speziell mit der section_id == 0 (so die Fehlermeldung: Duplicate entry '0-'). Solch Index kann auf Grund der Anweisung nicht erstellt werden, das Script bricht ab.
Und weil im manuellem Upgrade der identische Code verwendet wird, führt auch das nicht zum Erfolg.
Eigentlich gibt es nur eine richtige Lösung: die (doppelten) Nuller-Einträge entfernen. Aktuell gibt es dafür keine Automatisierung. Mir persönlich wäre das auch etwas zu risikobehaftet, weil beim Upgradescript viele Tabellen durchlaufen werden, aber egal, ist nichts, was wir aktuell haben.
Im großem UpgradeScript lautet der Report in der Regel so:
Im Ordner install gibt es eine Datei ModuleWhiteList, zu öffnen mit jedem Editor (bitte aber keine Office-Programme nutzen, Notepad oder Notepad++ reichen aus)
In der Datei eine Liste mit Modulnamen. Hier muß das in der Fehlermeldung genannte Modul der Liste entnommen werden. Speichern, UpgradeScript erneut starten, fertig
damit wird das Modul vom Upgrade ausgeschlossen, natürlich keine optimale Lösung. Eine Bessere wäre es, die Ursachen zu beseitigen.
Wie behebt man nun das Ganze?
Nur in der Datenbank selbst. PhpMyAdmin ist der Freund. Man sucht die in der Fehlermeldung genannte Tabelle heraus, hier wb_mod_news_groups
nun sortieren wir die Spalte section_id. Jeden Eintrag mit section_id == 0 löschen wir.
Erledigt
engl. Translation by Google AI
Occasionally, when upgrading from WB 2.10.0 to any later version, up to the current one, the upgrade script aborts with the following error message:
Note that the specific table names can vary, and this issue can also affect other modules.
The cause is a long-standing issue in WB: the tendency to create an empty entry first. This happens, for example, during the initial installation or when creating a new or additional section for the module in question—in this case, the News module and its mod_news_groups table.
The trigger for the current error is this line of code:
The purpose of this command is to create an index on the two specified fields (section_id and title). This serves two functions: first, it ensures the uniqueness (unique) of each specific entry, and second, it helps to find entries more quickly.
In this specific case, the problem is that duplicate entries already exist, specifically with section_id == 0 (as indicated by the error message: Duplicate entry '0-'). Because of these duplicates, the index cannot be created as instructed, and the script aborts. Since the manual upgrade uses the identical code, it will also fail for the same reason.
There is really only one correct solution: remove the duplicate zero-value entries. Currently, there is no automated process for this. Personally, I would also consider it a bit too risky because the upgrade script processes many tables—but regardless, it's not a feature we have at the moment.
In the main upgrade script, the report typically looks like this:
In the install folder, there is a file named ModuleWhiteList, which can be opened with any text editor (please do not use office programs like Word; Notepad or Notepad++ are sufficient).
The file contains a list of module names. You need to remove the module mentioned in the error message from this list. Save the file, run the upgrade script again, and you're done.
This excludes the module from the upgrade process, which is, of course, not an optimal solution. A better approach would be to fix the root cause.
So, how do you actually fix the problem?
Only within the database itself. phpMyAdmin is your friend. Find the table mentioned in the error message, in this case, wb_mod_news_groups.
Now, sort by the section_id column. Delete every entry where section_id == 0.
That's it.
Quote
There was an uncatched exception
Duplicate entry '0-' for key 'wb_mod_news_groups.ident_news'
in line (836) of (/framework/class.database.php)
Dabei können die jeweiligen Tabellennamen unterschiedlich sein und es kann auch andere Module betreffen.
Ursache ist die "alte WB-Krankheit", immer zuerst einen leeren Eintrag zu produzieren, z.b. direkt bei der Installation oder beim Anlegen einer neuen oder auch weiteren Section des betreffenden Moduls, hier das News-Modul, Tabelle mod_news_groups
Auslöser für den jetzigen Fehler ist diese Codezeile
Code: [Select]
ALTER TABLE {TABLE_PREFIX}mod_news_groups ADD UNIQUE ident_news ( section_id,title(127)) USING BTREE;Aufgabe ist es, einen auf die beiden genannten Felder (hier section_id und title) bezogenen Index zu erstellen, der zum einem die Einmaligkeit (unique) eines speziellen Eintrages sicherstellt, zum anderen dafür sorgt, das Einträge schneller gefunden werden
Im vorliegendem Fall ist es so, das doppelte Einträge vorliegen, hier speziell mit der section_id == 0 (so die Fehlermeldung: Duplicate entry '0-'). Solch Index kann auf Grund der Anweisung nicht erstellt werden, das Script bricht ab.
Und weil im manuellem Upgrade der identische Code verwendet wird, führt auch das nicht zum Erfolg.
Eigentlich gibt es nur eine richtige Lösung: die (doppelten) Nuller-Einträge entfernen. Aktuell gibt es dafür keine Automatisierung. Mir persönlich wäre das auch etwas zu risikobehaftet, weil beim Upgradescript viele Tabellen durchlaufen werden, aber egal, ist nichts, was wir aktuell haben.
Im großem UpgradeScript lautet der Report in der Regel so:
Quote
[06] : Upgrade module form from version 3.5.1 to version 3.5.1 OK
[07] : Upgrade module jsadmin from version 2.1.4 to version 2.1.4 OK
[08] : Upgrade module menu_link from version 3.0.4 to version 3.0.4 OK
There was an uncatched exception
Duplicate entry '0-' for key 'wb_mod_news_groups. ident_news'
in line (836) of (/framework/class.database.php):
Im Ordner install gibt es eine Datei ModuleWhiteList, zu öffnen mit jedem Editor (bitte aber keine Office-Programme nutzen, Notepad oder Notepad++ reichen aus)
In der Datei eine Liste mit Modulnamen. Hier muß das in der Fehlermeldung genannte Modul der Liste entnommen werden. Speichern, UpgradeScript erneut starten, fertig
damit wird das Modul vom Upgrade ausgeschlossen, natürlich keine optimale Lösung. Eine Bessere wäre es, die Ursachen zu beseitigen.
Wie behebt man nun das Ganze?
Nur in der Datenbank selbst. PhpMyAdmin ist der Freund. Man sucht die in der Fehlermeldung genannte Tabelle heraus, hier wb_mod_news_groups
nun sortieren wir die Spalte section_id. Jeden Eintrag mit section_id == 0 löschen wir.
Erledigt
engl. Translation by Google AI
Occasionally, when upgrading from WB 2.10.0 to any later version, up to the current one, the upgrade script aborts with the following error message:
Quote
There was an uncatched exception
Duplicate entry '0-' for key 'wb_mod_news_groups.ident_news'
in line (836) of (/framework/class.database.php)
Note that the specific table names can vary, and this issue can also affect other modules.
The cause is a long-standing issue in WB: the tendency to create an empty entry first. This happens, for example, during the initial installation or when creating a new or additional section for the module in question—in this case, the News module and its mod_news_groups table.
The trigger for the current error is this line of code:
Code: [Select]
ALTER TABLE {TABLE_PREFIX}mod_news_groups ADD UNIQUE ident_news ( section_id,title(127)) USING BTREE;The purpose of this command is to create an index on the two specified fields (section_id and title). This serves two functions: first, it ensures the uniqueness (unique) of each specific entry, and second, it helps to find entries more quickly.
In this specific case, the problem is that duplicate entries already exist, specifically with section_id == 0 (as indicated by the error message: Duplicate entry '0-'). Because of these duplicates, the index cannot be created as instructed, and the script aborts. Since the manual upgrade uses the identical code, it will also fail for the same reason.
There is really only one correct solution: remove the duplicate zero-value entries. Currently, there is no automated process for this. Personally, I would also consider it a bit too risky because the upgrade script processes many tables—but regardless, it's not a feature we have at the moment.
In the main upgrade script, the report typically looks like this:
Quote
: Upgrade module form from version 3.5.1 to version 3.5.1 OK
: Upgrade module jsadmin from version 2.1.4 to version 2.1.4 OK
: Upgrade module menu_link from version 3.0.4 to version 3.0.4 OK
There was an uncatched exception
Duplicate entry '0-' for key 'wb_mod_news_groups. ident_news'
in line (836) of (/framework/class.database.php):
In the install folder, there is a file named ModuleWhiteList, which can be opened with any text editor (please do not use office programs like Word; Notepad or Notepad++ are sufficient).
The file contains a list of module names. You need to remove the module mentioned in the error message from this list. Save the file, run the upgrade script again, and you're done.
This excludes the module from the upgrade process, which is, of course, not an optimal solution. A better approach would be to fix the root cause.
So, how do you actually fix the problem?
Only within the database itself. phpMyAdmin is your friend. Find the table mentioned in the error message, in this case, wb_mod_news_groups.
Now, sort by the section_id column. Delete every entry where section_id == 0.
That's it.
97
General Help & Support / Re: New update script made upgrading now impossible
« Last post by sternchen8875 on September 08, 2025, 04:39:46 PM »
and Thanks for this replay 98
General Help & Support / Re: New update script made upgrading now impossible
« Last post by CodeALot on September 08, 2025, 04:35:55 PM »with this file from my last post???
not possible (i think), sorry
Sorry! I didn't see you posted an even newer version. It works now. Thank you!
99
General Help & Support / Re: New update script made upgrading now impossible
« Last post by CodeALot on September 08, 2025, 04:33:04 PM »No, in the "older" way of upgrading, I could trick the script and keep it from overwriting my config.php with 'nothing'. After that first step, I changed it back to 0644 and continued the upgrade.Quoteby setting config.php to 444 temporarilyyou mean temporarily to 644
In the new situation, this is no longer possible.
100
General Help & Support / Re: New update script made upgrading now impossible
« Last post by sternchen8875 on September 08, 2025, 04:29:32 PM »with this file from my last post???
not possible (i think), sorry
not possible (i think), sorry