WebsiteBaker Community Forum
WebsiteBaker Support (2.13.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: masju on October 03, 2024, 05:26:00 PM
-
Hallo zusammen,
mir ist gerade ein reproduzierbarer Fehler in die Hände gefallen im Zusammenhang mit dem "Limit der Seitenebenen".
WB 2.13.5 r220
Seiten, die auf der untersten Ebene gemäß der Einstellung 'Limit der Seitenebenen' erstellt werden, erhalten einen falschen Pagecode. Ich hatte das Limit auf 4 festgelegt und Seiten in Ebene 4 angelegt. Diese Seiten erhielten alle den Pagecode 1, anstatt eines eigenen, eindeutigen Codes.
Man kann den Fehler erst einmal umgehen, wenn man das Limit hochsetzt auf "gewüscht + 1". Den falschen Pagecode habe ich manuell in der DB (Tabelle wb_pages) korrigiert, um die Seiten nicht noch einmal anlegen zu müssen.
Wenn ich das Limit jetzt wieder heruntersetze, ist der Fehler wieder da.
Viele Grüße
masju
PS: Wofür ist das DB-Feld "page_trail" eigentlich da?
-
Kein Fehler, nur unterschiedliche Denkweisen :wink:
die Entwickler gehen davon aus, das die Linkziele in mehrsprachigen Seiten, die nicht der Sprache zugehörig sind, die in den WB-optionen eingestellt ist (die Hauptsprache), vom User manuell eingestellt werden, weil Seitenbäume eben nicht immer in jeder Sprache identisch sind.
Die Unterseite der Hauptsprache bekommt immer ihre Page-ID als Pagecode. Unterseiten anderer Sprachen entweder die 1 oder die Null. Beides für dazu, das auf die erste Seite, die angelegt wurde, verlinkt wird aus anderen Sprachen.
Zum PageTrail: vorrangig dient er zur Darstellung des Breadcrumb-Menüs. Die erste Zahl ist immer die Ausgangsseite im Level Null, der sog ROOT_PARENT. Die Letzte Zahl ist immer die eigene Page-ID, die vorletzte Zahl die Elternseite, der PARENT
Seiten, die auf der untersten Ebene
du meinst sicher die oberste Ebene. Start-Ebene ist Level 0 (Null), dann Level 1, 2, 3 usw
-
Okay, wo ist oben, wo unten :wink:
Nochmal das konkrete Problem:
Wenn man als Limit für die Seitenebenen 4 eingestellt hat
- ist auf Seiten der Ebene 4 ist das Pulldownmenü zur Festlegung des Pagescodes zerschossen. Es wird genau eine Seitenebene zu wenig angezeigt, nämlich maximal die anderen Seiten der Ebene 3 (und nicht wie es korrekt wäre 4).
- Frisch angelegte Seiten der Primärsprache in Ebene 4 bekommen falsche Pagecodes zugewiesen, nämlich 1 statt eines eigenen
Stelle ich das Limit auf 5 oder 6, läuft alles wieder korrekt in Ebene 4.
Danke für die Info zum Pagetrail.
-
Okay, wo ist oben, wo unten
Naja, Null ist unten, 10 ist oben - aufsteigend halt. Aber zugegeben, in der Seitenübersicht sieht es dann anders herum aus ;-)
Egal, Hauptsache, wir wissen beide, was gemeint ist ;-)
Hier mal meine Seitenübersicht, eine etwas neuere WB-Version,, Hauptsprache ist deutsch (DE), Limit der Seitenebenen steht auf 5
(https://i.gyazo.com/03f4cf3e0b9366d1ece9c6c33b2ecee6.png)
das Ganze in der Datenbank nach Hinzufügen der letzten Seite "DE Seite 1-1-1-1" im Level 4 (Ebene 5). Der Eintrag im Pagecode-Feld mit der Page-ID == 17 erfolgt korrekt, sowohl im Feld page_trail wie auch im Feld page_code
(https://i.gyazo.com/7a424e9e26e9aec97abe20bf15cdc273.png)
Recht hast du beim Auswahlfeld für den Pagecode in den Seiteneinstellungen . Es ist bei mir nicht zerschossen, aber es fehlt ein Level. Wundert mich, das dies bisher nicht aufgefallen ist.
(https://i.gyazo.com/d12267927b726315ac7b11ae02b7dea8.png)
Ich werd mal schauen, wo das zusammengestellt wird, ich vermute, das der Array da falsch gezählt wird oder das der Level da herangezogen wurde, der ja immer eins weniger ist als die Ebene
Noch zum Thema: Hab die Stelle noch nicht gefunden, wo ab und an beim Pagecode eine Null eingetragen wird. Lt. Code wäre es eigentlich eine 1 für Seiten, die nicht zur Hauptsprache gehören. Was funktioniert, wäre die Funktion hinter dem Pagecode-Link (das Verlinkte Wort "Pagecode" in den Seitenenstellungen bei aktivierter Mehrsprachigkeit). Hier wird die Pagecode-Spalte neu "sortiert" und ungültige Pagecodes, z.b. nach Löschung der Zielseite mit der Page-ID dieser Seite (bei Hauptsprache) oder mit der 1 korrigiert.
-
Okay, wo ist oben, wo unten ;)
Nochmal das konkrete Problem:
Wenn man als Limit für die Seitenebenen 4 eingestellt hat
- ist auf Seiten der Ebene 4 ist das Pulldownmenü zur Festlegung des Pagescodes zerschossen. Es wird genau eine Seitenebene zu wenig angezeigt, nämlich maximal die anderen Seiten der Ebene 3 (und nicht wie es korrekt wäre 4).
- Frisch angelegte Seiten der Primärsprache in Ebene 4 bekommen falsche Pagecodes zugewiesen, nämlich 1 statt eines eigenen
Stelle ich das Limit auf 5 oder 6, läuft alles wieder korrekt in Ebene 4.
Du hast die Lösung ja selber gepostet und m.E. ist es kein Fehler.
Wenn Level 0 schon eine Ebene ist und das Limit auf 4 steht, ist bei Ebene 3 dann Schluß
Das erklärt ja auch, dass eine Erhöhung das Problem löst.
Werde der Entwicklung vorschlagen, dass Limit bei Auslieferung und Neuinstall auf 6 zu stellen.
Ob dass beim Update-sript greift weis ich aber nicht.
Und übrigens:Wir suchen auch weitere aktive Beta-Tester.Wenn das was für dich ist, schreib uns einfach eine PM ;D
-
@hgs: nicht nur die Hälfte lesen... da ist schon was faul
Recht hast du beim Auswahlfeld für den Pagecode in den Seiteneinstellungen . Es ist bei mir nicht zerschossen, aber es fehlt ein Level. Wundert mich, das dies bisher nicht aufgefallen ist.
(https://i.gyazo.com/d12267927b726315ac7b11ae02b7dea8.png)
Ich werd mal schauen, wo das zusammengestellt wird, ich vermute, das der Array da falsch gezählt wird oder das der Level da herangezogen wurde, der ja immer eins weniger ist als die Ebene
-
Werde der Entwicklung vorschlagen, dass Limit bei Auslieferung und Neuinstall auf 6 zu stellen.
Die Frage ist: wozu ist er da? Ist es noch zeitgemäß? Angesichts der ganzen Verknüpfungen im Core, wäre es wohl ungeschickt, ihn gänzlich zu entfernen
Zur Problematik: wie vermutet, ein Denk- oder Tipfehler in admin/pages/settings.php in dieser Zeile (bei mir Z 398)
if ($page['level']+1 < PAGE_LEVEL_LIMIT)
liest die Seiten für dieses Auswahlfeld aus, solang die Bedingung wahr ist.
Richtig wäre
if ($page['level']+1 <= PAGE_LEVEL_LIMIT)
-
Guten Morgen zusammen!
Den Fix
admin/pages/settings.php Zeile 398:
if ($page['level']+1 <= PAGE_LEVEL_LIMIT)
kann ich bestätigen, geändert und alles ist okay.
Das Seitenlimit ist auf 4 gesetzt (Level 0, 1, 2, 3) und das Pagecode-<Select> in den Pagesettings hat nun auch die ursprünglich fehlende Ebene.
Vielen Dank für die Hilfe!
masju
-
Gut, dass die Endwicklung mit liest, dann kann dieses Fix noch mit in die nächste Version 2.13.6 ;D
@ sternchen8875 + masju
Danke für euer dranbleiben und lösen von Fehlern, die uns beim testen immer mal wieder durchgehen.
Das brauchen wir, um noch besser zu werden. (Y)
-
Gut, dass die Endwicklung mit liest
ist das so?
-
Mal ne Frage zwischendurch.
Ich sehe in der DB die richtigen Werte. page_trail (88,327,510), page_code (215) sind korrekt hinterlegt. Trotzdem verlinkt das Flaggenmenü nur zur Ebene 0. Die Unterseite verlinkt also nicht zu der gewünschten Unterseite der anderen Sprache. Im Backend stimmts, da klappt das Auslesen der DB wohl, aber nicht im Frontend. Wo müsste ich mir den Code mal ansehen? (Der Fehler besteht auch im DefaultTemplate).
Ist schon seit einigen WB-Versionen so.
-
Ich sehe in der DB die richtigen Werte. page_trail (88,327,510), page_code (215) sind korrekt hinterlegt. Trotzdem verlinkt das Flaggenmenü nur zur Ebene 0.
Kann ich nicht bestätigen, bei mir funktioniert es, auch über verschiedene WB-Versionen, also auf unterschiedlichen Domains
Voraussetzung ist aber die korrekte Einstellung in den Seiteneinstellungen jeder Seite und jeder Sprache, die nicht Hauptsprache ist. Dabei nicht auf den Job der automatischen Korrektur hinter dem Link "Pagecode" verlassen. Der korrigiert nur Seite ohne gültige PageCode-ID, d.h. eine in der DB eingetragene ID im Feld page_code, die dann nicht mehr vorhanden ist, weil die Seite gelöscht wurde, wird mit der Page-ID der ersten Seite korrigiert, die sichtbar ist, d.h. nicht die Sichtbarkeit "keine" hat
Page_Trail und Page_Code sind dabei unterschiedliche Sachen. Ersteres zeigt dabei den Weg auf, den Trail, über welche Stationen man zur gewünschten Seite gelangt.
Der PageCode hat ausschließlich den Zweck, das Linkziel im Zweig der Hauptsprache und im Flagmenü zu ermitteln, in deinem Fall dann die Page-ID 215
Noch zur allgemeinen Klarstellung (damit es mal gesagt wurde)
Die gesamte Pagecode-Geschichte funktioniert nur im Flagmenü, nicht aber in einem offenen Showmenu2-Aufruf, der alle Seiten und Seitensprachen anzeigt
Mal meine aktuelle Testumgebung, vier Sprachen, DE ist Hauptsprache. DE und NL haben 5 Ebenen, SE und EN nur 4. Jede Ebene der anderen Sprachen ist mit der DE-Seite gleicher Ebene verlinkt. Da SE und EN nur 4 Ebenen haben, erscheint dort im Flagmenü ein Link zur Startseite dieser Sprachen, also SE.php und EN.php
Ein Bild dazu hier -> https://i.gyazo.com/c0f1a961cf296fae60932c48e55c56ff.png (https://i.gyazo.com/c0f1a961cf296fae60932c48e55c56ff.png)
Der Code für das gesamte Flagmenü kommt aus dem Modul WBLingual, das meiste davon aus der Lingual.php. Das sind eine Reihe von Funktionen, aus deren Summe dann das Flagmenü zusammengestellt wird.
Sollte sich dort ein Fehler verstecken, müßten ihn alle Benutzer haben, denk ich
ICH würde zuerst in der Seitenübersicht schauen, alle Zweige aufklappen und dann ganz rechts die Spracheinstellungen kontrollieren. Im Frontend-Betrieb merkt man es wohl recht schnell, wenn da im Showmenu2 eine Seite fehlen würde, aber es ist auch schnell passiert, das sich eine Seite mit falscher Spracheinstellung in einen anderen Seitensprachzweig verirrt, z.b. wenn sie manuell verschoben wird.
dein Problem ließe sich leicht erklären, wenn eine früher als Pagecode eingestellte Seite später entfernt wurde. Ich hatte z.b. mal die Menulink-Seiten statt DE und EN mit deutsch und english benannt und als Typ Wysiwyg erstellt. So wurden dann auch alle Unterseiten in den Pagecodeeinstellung en justiert. Später hab ich dann auf Typ Menulink gewechselt, dazu zwei neue Startseiten erstellt und die Bäume entsprechend verschoben, aber den Pagecode hatte ich vergessen. Und so landet man dann auf der Startseite :-D
Du bist versiert im Umgang mit der DB. Ich würde mir die pages-Tabelle mal nach Level sortieren lassen. Sofern nicht anders gewünscht und eingestellt, sollten pro Level mindestens eine Seite aus jeder verwendeten Sprache auf das Äquivalent der Hauptsprache zeigen, also im Pagecode die Page-ID dieser Zielseite haben. Ich hab auch ein Projekt, das zwar 45 deutschsprachige Seiten hat, aber nur 8 englisch-sprachige. Da wird es mit der level-Sortierung zwar schnell unübersichtlich, geht aber mit der Sortierung nach Feld language ganz gut.
Wäre im genannten Projekt die Hauptsprache == englisch, wäre es sicher so, das das Feld page_code ziemlich viele, gleiche Werte enthält, aber in einem gut sortierten Projekt mit identischer Struktur wäre es wahrscheinlich, das jeder pagecode-Wert nur in der Anzahl der verwendeten Sprachen auftaucht.
Im Allgemeinen ist es aber eine ziemliche Fummelei, das in einem komplexen mehrsprachigem Projekt Seite für Seite alles einzustellen.
Ich hab mir da ein Modul gebaut, das basiert auf Stefek's SEO-Modul, hat auch diese SEO-Funktionen noch, dient mir aber vorrangig zum Suchen von Section, Page-ID's und Modultyp-Abschnitten. Dort ist auch der Pagecode mit angegeben. Ist noch nicht ganz public-fähig, aber aussagekräftiger als die Ansicht in der Datenbank
(https://i.gyazo.com/44540b9b2e2a8f40e4769aedbe7e3700.png)
-
Ich kann sagen, dass der Menübaum schon ziemlich oft durchgeschüttelt wurde.
Aktuell mit Menülinks, aber es heiß ja auch mal, dass es mit normalen Seiten geht als DE,EN usw.
Gelöscht und verschoben (mal DE oben und mal EN), weil neue Kategorien, ist schon öfter passiert.
Komisch, dass es bei manchen Seiten keine Probleme gibt, auf anderen aber eben grundsätzlich bei jeder Flagge domain.de/sprache/ angezeigt wird (geht also um shorturl). Da hilft auch kein Neuspeichern oder pagecode link klicken.
In der DB sehe ich bei der Sprachenspalte keine Probleme, passt alles. Denke mal die DB ist ok, schon weil das Backend bzw. das Menü korrekt angezeigt wird bzw. die Seiteneinstellungen stimmen. Es muss also irgendwo auf dem Weg aus der DB ins Flaggenmenü ein Problem bei mir geben.Werde die Tipps mal durchgehen, danke.
-
Gelöscht und verschoben (mal DE oben und mal EN), weil neue Kategorien, ist schon öfter passiert.
Gelöschte Zielseiten sind dann schon ein Problem, weil man jedes Mal danach ALLE Unterseiten der anderen Sprachen neu einstellen muß. Das Gleiche gilt dann, wenn sich die Hauptsprache im System ändert
Vielleicht sollte man ein kleines AdminTool erstellen, das den kompletten Seitenbaum in Listenform darstellt und nur auf den Pagecode ausgerichtet ist, denn selbst wenn man nur insgesamt 100 Seiten hat, ist die Kontrolle von 3/4 davon eine elendige Klickerei
-
In der DB haben sie alle die richtigen Werte.
Bis jetzt ist es weiter unklar. Manche Seiten verlinken zur anderssprachigen Seite, manche nur zur Ebene 0.
Auch bei neuangelegten Seiten tritt das auf, mal klappts mal nicht. Als ob da noch irgendwas dazwischen sitzt, was die Ausgabe beeinflusst.
Ist eine Testseite, die schon 100 WB-Upgrade-Versionen durchgemacht hat und sicher auch Dateileichen sammelt.
Der Menübaum im Backend ist aber korrekt, Sprachen stimmen, kommt ja aus der DB, deshalb würde ich da den Fehler ausschließen. Die Page_IDs gehen bis 511. Ist viel, aber nicht zu viel denke ich.
-
Gut, dass die Endwicklung mit liest
ist das so?
Ja, in der aktuellen Testversion von 2.13.6 ist der Bug schon gefixt ist.
-
Der Menübaum im Backend ist aber korrekt, Sprachen stimmen, kommt ja aus der DB, deshalb würde ich da den Fehler ausschließen.
bin wieder etwas schlauer, auch, wenn ich den Sinn hier noch nicht ganz verstehe und es bei deinem Problem kaum weiterhilft.
Anders als oben von mir beschrieben, korrigiert der Pagecode-Link in den Seiteneinstellungen nicht etwa den kompletten Seitenbaum und er kontrolliert auch nicht auf ungültige bzw nicht mehr vorhandene Pagecode-ID's
Er trägt auf den Klick hin bei jeder Seite des Hauptsprachen-Zweigs die jeweilige Page-ID in das Pagecode-Feld ein, auf deutsch: einmal Tabula Rasa im jeweiligem Sprachzweig.
Daraus folgt: möchte ich in einem Mehrsprachen-Projekt die ganzen Pagecode-Einträge resetten, sucht man sich einen verwendeten Sprachzweig heraus, welcher, ist egal, stellt diese Sprache in den WB-Optionen als Hauptsprache ein, sucht sich dann irgendeine Seite mit dieser Sprache heraus und klickt in den Seiteneinstellungen auf den PagecodeLink.
Das wiederhole ich für jede verwendete Sprache einmal und hab im Anschluß ein sauberes Pagecodesystem, bei dem dann alle Unterseiten anderer Sprachen als die aktuelle Hauptsprache auf die Startseite dieser Hauptsprache verlinken.
Nun könnte man jede Unterseite der Nebensprachen neu einstellen, bei 500 + X Seiten aber keine schöne Aufgabe
Nach einem Reset schaut das dann so aus -> https://i.gyazo.com/e747ca88c831d5a79db02845fe086a39.png
Ich dachte, es wäre praktisch, wenn man das gleich in ein schon fast fertiges Tool einbaut, aber er gefällt mir weder optisch, noch von der Funktion her. Und hat man ein größeres Projekt, wird es richtig unhandlich. Vielleicht ist ein separates AdminTool da besser geeignet, das den Seitenbaum nur pro Sprache anzeigt, nicht komplett
-
Soo, ich trau mich mal.....
das oben schon mal erwähnte AdminTool zur Einstellung der Pagecodes für mehrsprachige Seiten, getestet mit einer WB 2.13.5 -r213 und der neuesten Testversion WB 2.13.6 -r235 und diversen PHP 8.3.x-Versionen
Eingelesen wird der komplette Seitenbaum, in mehrsprachigen Projekten getrennt nach Sprachen. Nach dem Einlesen sind alle Sprachzweige offen, sie können durch Klick auf das blaue Dreieck ganz links sprachzweigeweise geschlossen werden. Der oberste Sprachzweig entspricht der Hauptsprache auf den WB-Optionen.
In der linken Spalte die Page_Title der Seiten, in der rechten Spalte ein Auswahlfeld zu allen Unterseiten der jeweiligen Hauptsprache. Ist der Page_Title rot dargestellt, ist zu dieser Seite in der Datenbank eine ungültige Pagecode-ID hinterlegt. Das ist dann entweder eine 0 (Null) oder der Pagecode zu einer anderen als die Hauptsprache. In diesen Fällen verlinkt das WB-System auf die Startseite der Hauptsprache.
Ganz rechts noch ein paar Icons mit Links zu den Seiteneinstellungen, der Sectionsverwaltung, der Inhaltsbearbeitung und ein Frontendlink
Ein Klick auf den Speichern-Button ganz unten, speichert für jede Seite den im Auswahlfeld angezeigten Pagecode. Alle Seiten, die zum Zeitpunkt des Speicherns noch einen ungültigen Pagecode haben, werden automatisch zur Startseite der Hauptsprache verlinkt. Das heißt, mit einem Mausklick könnte man ein mit der Zeit "verwirrtes" System, bei dem auf Grund von Seitenverschiebunge n oder Löschungen viele früher eingestellte Pagecodes nun ungültig sind, dann reparieren, zumindest so, das alle Seiten wieder gültige Pagecodes haben. Die genauen Linkziele kann man ja nach und nach exakt einstellen.
Deepl-Translate:
the AdminTool mentioned above for setting the page codes for multilingual pages, tested with a WB 2.13.5 -r213 and the latest test version WB 2.13.6 -r235 and various PHP 8.3.x versions.
The complete page tree is read in, in multilingual projects separated by language. After importing, all language branches are open and can be closed by language branch by clicking on the blue triangle on the far left. The top language branch corresponds to the main language in the WB options.
In the left-hand column, the Page_Title of the pages, in the right-hand column a selection field for all sub-pages of the respective main language. If the Page_Title is displayed in red, an invalid page code ID is stored for this page in the database. This is then either a 0 (zero) or the page code for a language other than the main language. In these cases, the WB system links to the start page of the main language.
On the far right are a few more icons with links to the page settings, section management, content editing and a frontend link
Clicking on the Save button at the bottom saves the page code displayed in the selection field for each page. All pages that still have an invalid page code at the time of saving are automatically linked to the start page of the main language. This means that a system that has become “confused” over time, in which many previously set page codes are now invalid due to page moves or deletions, can be repaired with a mouse click, at least so that all pages have valid page codes again. The exact link targets can be set exactly bit by bit.
(https://i.gyazo.com/6caff129daa1dc79363a09997926441d.png)
Ist das Projekt bis hierhin nur einsprachig, braucht es dieses Tool eigentlich nicht. Damit es aber nicht eine leere Seite anzeigt, wird hier die Seitenübersicht dargestellt
Deepl-Translate:
If the project is only monolingual up to this point, this tool is not really needed. However, so that it does not display an empty page, the page overview is shown here
-
Danke für's Bereistellen (Y)
Nach der Installation sehe ich in 95% der Dropdowns die Seite Procalender eingestellt. Komische Sache.
Irgendwo hab ich dann mal den pagecode Link geklickt, dann sah es besser aus. Allerdings ist der Menübaum im Dropdown bei mir total durcheinander. Schwer die richtige Seite zu finden. Ein Suchfeld wäre da hilfreich.
In der Pagecodecheck.php hast du noch 2x get_user_id() drin. Aber bei meinem Problem half auch die Korrektur nicht.
Gespeichert habe ich dann auch mal das Ganze. In den Seiteneinstellungen einer Seite sah ich dann beim pagecode, dass dort mehrere Seiten ausgewählt, also blau, waren in dem Dropdown.
Erste Tests erstmal, vielleicht finde ich noch was.
-
Danke fürs Testen und das Feedback.
In meinem "Musterprojekt" schaut der Seitenbaum analog zum Seitenbaum auf der Seitenübersicht aus. Hab das Addon jetzt mal bei einem Kunden-Backup laufen lassen, wo es Seiten mit unterschiedlichsten Sichtbarkeiten gibt, da gehts wild durcheinander. Ich werde da das WB-eigene Script einsetzen, das läuft auf der Single-Seite, wenn nur eine Sprache verfügbar ist. Das benötigt aber einige Anpassungen
Was meinst du: wenn der Seitenbaum dem der WB-Seitenübersicht entspricht, bräuchte es dann ein Suchfeld?
In der Pagecodecheck.php hast du noch 2x get_user_id() drin
Wie stoplert man denn da drüber? :-D
Hatte jetzt ein paar Tage damit gearbeitet, aber den Code weder gesehen, noch Fehlermeldungen dazu erhalten, wohl, weil ich immer der superAdmin war. Der Code zum Seitenbaum stammt aus einem älteren Addon, typischer Copy&Paste-Fehler :oops:
Ich denk, ich werd erst nach dem Wochenende wieder dazukommen, Familientreffen ist angesagt.
-
Was meinst du: wenn der Seitenbaum dem der WB-Seitenübersicht entspricht, bräuchte es dann ein Suchfeld?
Dann wäre ein Suchfeld unnötig. Gibt es ja in der WB-Seitenübersicht auch nicht. Obwohl da schon seit Jahren der Wunsch besteht nach Page_IDs und Section_IDs suchen zu können (auch nur relevant in umfangreichen Projekten).
Wie stoplert man denn da drüber?
Wollte nur schauen ob ich was sehe, dass den Menübaum so durcheinander bringt. Aber nix gefunden.
-
Nächster Versuch - aus Zeitgründen hab ich die (kopierte) WB-eigene Funktion zum Auslesen des Seitenbaum so gelassen wie sie war - Ergebnis ist da aber "nur" eine Liste aller Seiten und kein verschachteltes Array wie es vorher war. Damit entfällt dann aber leider die Funktion zum Einklappen der Sprachzweige und mehr Scrollen ist notwendig.
Der Rest ist wie oben beschrieben
-
Mein Menübaum im Dropdown bleibt weiter kreuz und quer. Das ist die gleiche Funktion wie in Seiteneinstellungen das Dropdown?
-
Ist das "betriebsblind"???
Das ist die gleiche Funktion wie in Seiteneinstellungen das Dropdown?
Nein, die im Dropdown rechts. Der Seitenbaum in der linken Spalte nutzt die identische Funktion, die im Form und News zur Auswahl der Datenschutz- oder der Erfolgreichseite genutzt wird. Der linke Seitebaum ist jetzt aber okay?
-
Ich hätte mal gleich ein Bild mitschicken sollen. Linke Seite war immer ok.
https://www.screenpresso.com/=LPTQhyt8UVB3
-
Hab jetzt links und rechts identische Seitenbäume
Eigentlich müßte die Sichtbarkeits-Information ins Dopdown, gefällt mir alles nicht wirklich
(https://i.gyazo.com/62401d4084a9220c72350ded518b7f2d.png)