Backend -Seitenaufbau nach Update von 2.7 auf Version 2.8 träge-

[hermarcar]

Hallo Leute,

nach dem erfolgreichen Update von der Version 2.7 auf 2.8 trat folgendes Problem im Backend auf.

Bei jedem Wechsel eines Bereiches (Optionen, Benutzerverwaltung, Medienordner, Einstellungen etc.) auf den Menüpunkt "Seiten", wurde der Aufbau der Seiten träge. Eine sofortige Weiterbearbeitung (Aufruf einer Seite) war nicht möglich. Es dauerte ungefähr eine bis drei Sekunden bis der Ladebalken in der Statuszeile verschwand. Erst danach war ein Seitenaufruf zum Bearbeiten möglich.

Auch die Versuche auf der Linux-Ubuntu Maschine den MYSQL-Server zu stoppen und neu zu starten, den Apache2 zu stoppen und neu zu starten, brachte keinen Erfolg.

Ein gezielte Nachforschung bei den Einstellungen im Backendbereich brachte schließlichen den Erfolg.
Schuld an diesem Dilemma war eine Einstellung bei den Admin-Tools. Und zwar im Bereich der Javaeinstellungen.
Hier wird festgelegt ob sich WB den geöffneten Seitenbaum merkt oder nicht, ob eine Sortierung per Drag und Drop der Seiten oder der Abschnitte möglich sein darf. Genau da liegt das Problem. Als das Häkchen, Sortierung per Drag und Drop für die Seiten entfernt wurde, klappte der Seitenaufbau wie gewünscht und gewohnt. Rasch und flott.

Woran kann dies liegen? Hat da jemand eine Idee??

Danke 

Herbi

[doc]

Hi,

wäre gut zu wissen, wieviele Seiten bei Dir im Backend verwaltet werden. Reden wir über 20 Seiten, 200 oder 2000?

Ab ca. 50 Seiten tritt in der Tat eine Performanceverschle chterung ein, wenn "JS-Admin" aktiviert ist. Abhilfe verschafft wohl nur eine Überarbeitung des Javascript Codes hinsichtlich Performance.

Dieses Tool wird über kurz oder lang wohl eh angepasst, bzw. vom YahooUI JS Framework auf jQuery umgestellt werden. Mehr Infos beim Development Team erfragen.

Doc

[hermarcar]

Hallo Doc,

danke für deine Antwort.

Wir reden über ein Web >150 Seiten.

Wo könnte man im Javascript , für diese Performance, den Code anpassen?

Aber, mit der momentanen Lösung kann ich auch gut leben.
Muss ich mir halt vorher über die Seitenstruktur Gedanken machen. 

Dies sollte eigentlich auch ein Hinweis an andere WB-User sein, dass da evtl. ein kleines Problemchen liegen könnte.

Danke

Herbi

[doc]

Hi,

JSAdmin ist als Modul ausgelegt und findet sich in /modules/jsadmin. Die Datei jsadmin_backend_inc lude wird automatisch vom WB Core eingebunden. Alle nötigen Dateien finden sich im erst genannten Ordner.

Doc

[hermarcar]

Hi,

danke für den Hinweis.
Werde ich mir mal ansehen.

Gruss


Herbi

[Waldschwein]

Hallo!

Wie doc schon gesagt hat, liegt es wirklich an YUI. Ob es allerdings mit jQuery anders aussieht bezweifle ich stark.
Ich denke eher, dass das Rad neu erfunden werden muss. Für kleiner Seiten reicht es durchaus, aber wenn man mit Installationen >100 Seiten arbeitet ist es je nach Browser gar nicht (IE8 wegen YUI Bug) oder schwer (alle anderen) möglich. Am besten alles Javascript ausschalten, auch wenn es nicht besonders schön ist.

Kleiner Tipp: Es gibt Frontend-Droplets / CodeSnippets, mit denen man eingeloggt direkt auf die jeweilige Seite geleitet wird zum Bearbeiten. Bei größeren Seiten finde ich ist das die einzig sinnvolle Alternative, wenn es auch nicht das Seitenanlegen ermöglicht.  

Gruß Michael

PS: Schöne Grüße von Stein nach Oberasbach. 

[hermarcar]

Hi Waldschwein,

Danke für den Hinweis.
Werde dies mal ausprobieren.

Ohne Java geht es, wengistens in dieser Beziehung, auch.
In den JavaScript´s suchen, finden und evtl. eine Lösung erproben, ist mir ehrlich gesagt zu mühsam.
Macht man evtl. mehr kaputt als das es nützt.

Danke für die Grüße aus der "Großen Nachbarstadt".
 

herbi

[Waldschwein]

Hallo!

Ich habe einmal kurz mir die Seite (mit yslow) etwas genauer betrachtet, und es fällt eines auf: Diese Tabellen müssten weg. Denn ich habe im Moment mit ca. 250 Seiten einen Seitenquelltext mit 15.500 Zeilen und einer Größe von 761kb (ohne Javascript und Bilder!).
Man müsste in Zukunft darauf achten wenn man eine neue Seitenübersicht entwirft, dass man (wenn man nicht alles komplett ändert von Anfang an) unbedingt nicht bei jeder einzelnen Seite jedes Bild, jedes Element einzeln lädt.
Javascript macht das ganze nur noch zusätzlich langsamer (und hier werden viele Datein aufgerufen wo ich mich frage, was man die hier braucht...)

Es wäre also schon sehr viel getan, wenn man auf die Tabelle verzichtet, zudem auf alles Javascript (dafür gibt es z.B. Links auf die man weiterleiten kann um sich dort eine weitere "Bestätigung" zu holen, in Verbindung mit einer Batchsache), auf alle Inline-Styles die es nur irgendwo gibt usw. Dann wäre die Seitenübersicht schon einmal deutlich schneller, egal ob mit oder ohne YUI.

Aber: Da muss teilweise das Rad neu erfunden werden.

Gruß Michael

[tiesy]

Den langsamen Seitenaufbau nach dem Update kann ich nur bestätigen, sollte wirklich dringend behoben werden. Außerdem verhält sich das News-Modul auch merkwürdig: In der News-Übersicht springt der Browser immer zum letzten Eintrag, man muss also jedesmal wieder zum Anfang zurückscrollen, um einen neuen Beitrag einzustellen. Wenn man mehrere Hundert Einträge in der Liste hat, dann ist das ein ziemlich nerviges Verhalten.

[Stefek]

Hallo!

Ich habe einmal kurz mir die Seite (mit yslow) etwas genauer betrachtet, und es fällt eines auf: Diese Tabellen müssten weg. Denn ich habe im Moment mit ca. 250 Seiten einen Seitenquelltext mit 15.500 Zeilen und einer Größe von 761kb (ohne Javascript und Bilder!).
Man müsste in Zukunft darauf achten wenn man eine neue Seitenübersicht entwirft, dass man (wenn man nicht alles komplett ändert von Anfang an) unbedingt nicht bei jeder einzelnen Seite jedes Bild, jedes Element einzeln lädt.
Javascript macht das ganze nur noch zusätzlich langsamer (und hier werden viele Datein aufgerufen wo ich mich frage, was man die hier braucht...)

Es wäre also schon sehr viel getan, wenn man auf die Tabelle verzichtet, zudem auf alles Javascript (dafür gibt es z.B. Links auf die man weiterleiten kann um sich dort eine weitere "Bestätigung" zu holen, in Verbindung mit einer Batchsache), auf alle Inline-Styles die es nur irgendwo gibt usw. Dann wäre die Seitenübersicht schon einmal deutlich schneller, egal ob mit oder ohne YUI.

Aber: Da muss teilweise das Rad neu erfunden werden.

Gruß Michael

Was Du schreibst, kann ich nur bestätigen.

Im PageTree selbst gibt es ZU viele verschachtelte Tabellen.
Das wurde gemacht, um die Abstände richtig hinzubiegen, denn die einzelnen "Seiten" in denen sich die Tabelle befindet einfache ListItems (<li>) sind.
Aber mit ein wenig CSS kann man auf die Tabellen verzichten und nur die ListItems belassen. Mit span und guten CSS Kenntnissen ist das ganze machbar. Nicht ganz einfach, aber machbar.

Die beste Sache wäre tatsächlich auf jQuery umzusteigen in diesem Bereich.
Aber auch dann müßte man sich des Tabellen Problems annehmen.

Man müsste in Zukunft darauf achten wenn man eine neue Seitenübersicht entwirft, dass man (wenn man nicht alles komplett ändert von Anfang an) unbedingt nicht bei jeder einzelnen Seite jedes Bild, jedes Element einzeln lädt.

Das könnte möglicherweise mit jQuery gelöst werden.

Hier ein Auszug einer einzigen "Seitenleiste", der kompletten Reihe:

Code:

<li class="p0">
    <table class="pages_view" border="0" cellpadding="0" cellspacing="0">
        <tr>
            <td valign="middle" width="20" style="padding-left: 7px;">
                <a href="javascript: toggle_visibility('p1');" title="Erweitern/Reduzieren">
                    <img src="http://localhost/templates/dte_theme/images/plus_16.png" onclick="toggle_plus_minus('1');" name="plus_minus_1" border="0" alt="+" />
                </a>
            </td>
            <td class="list_menu_title">
                <a href="http://localhost/admin/pages/modify.php?page_id=1" title="&Auml;ndern">
                    <img src="http://localhost/templates/dte_theme/images/visible_16.png" alt="Sichtbarkeit: &Ouml;ffentlich" class="page_list_rights" />
                    <span class="modify_link">Testseite</span>
                </a>
            </td>
            <td class="list_page_title">Testseite</td>
            <td class="list_page_id">1</td>
            <td class="list_actions">
                <a href="http://localhost/pages/testseite.php" target="_blank" title="Ansicht">
                    <img src="http://localhost/templates/dte_theme/images/view_16.png" border="0" alt="Ansicht" />
                </a>
            </td>
            <td class="list_actions">
                <a href="http://localhost/admin/pages/settings.php?page_id=1" title="Optionen">
                    <img src="http://localhost/templates/dte_theme/images/modify_16.png" border="0" alt="Optionen" />
                </a>
            </td>
           
                <!-- MANAGE SECTIONS AND DATES BUTTONS -->
               
            <td class="list_actions">
                <a href="http://localhost/admin/pages/sections.php?page_id=1" title="Abschnitte verwalten">
                <img src="http://localhost/templates/dte_theme/images/noclock_16.png" border="0" alt="Abschnitte verwalten" /></a>    
            </td>
            <td class="list_actions">        </td>
            <td class="list_actions">
                <a href="http://localhost/admin/pages/move_down.php?page_id=1" title="Abw&auml;rts verschieben">
                    <img src="http://localhost/templates/dte_theme/images/down_16.png" border="0" alt="Abw&auml;rts verschieben" />
                </a>
            </td>
            <td class="list_actions">
                <a href="javascript: confirm_link('Sind Sie sicher, dass Sie die ausgew&auml;hlte Seite l&ouml;schen m&ouml;chten?', 'http://localhost/admin/pages/delete.php?page_id=1');" title="Entfernen">
                    <img src="http://localhost/templates/dte_theme/images/delete_16.png" border="0" alt="Entfernen" />
                </a>
            </td>
            <td class="list_actions">
                <a href="javascript:add_child_page('1');" title="Hinzuf&uuml;gen">
                    <img src="http://localhost/templates/dte_theme/images/plus_16.png" name="addpage_1" border="0" alt="Add Child Page" />
                </a>
            </td>
        </tr>
    </table>
</li>

Jepp, aus diesem ganzen HTML Gerüst, wird eine EINZIGE "Seitenleiste" im PageTree gerendert.
Einige Dinge die sofort ins Auge fallen:
--> Inline CSS a lá: style="padding-left: 7px;"
--> zu langatmige Klassen Namen a lá: class="list_menu_title"
--> unnötig lange Altattribut Angaben bei Images: alt="Abschnitte verwalten" (als würde jemand das Backend mit ausgeschalteten Bildern bedienen? Mach mal Bilder aus und sieh dir das mal an.
---> Was das hier braucht in jeder Seitenleiste weiß wahrscheinlich nur der, der das da reingebaut hat:
   <!-- MANAGE SECTIONS AND DATES BUTTONS -->

Hmm... da ist noch viel Potenzial drin..

Stefek

[Luisehahne]

Hi tiesy,

gehe mal in Optionen und mache den Abschnitts-Anker Text leer, und teste nochmal die news und sage dann Bescheid

Wegen der Seitenübersicht, da knacke nschon Generationen dran, Es sollte auch in zukunft daran gedacht werden, dass WB auch komplett ohne javascript laufen muss, wenn Barrierefreihaeit angestrebt werden soll.

Kommen noch grosse Aufagben auf uns zu

Dietmar

[tiesy]

Hi Dietmar,

habe es gerade gemacht, hat aber leider nichts gebracht. Noch eine Idee, woran es liegen könnte? Am Browser liegt es jedenfalls nicht, habe IE8, FF 3.5 und Chrome getestet.

Ich habe eine Idee, woran es liegen könnte: Der Browser springt immer dann nach unten, wenn sich noch ein Code-Block unterhalb der Newsliste befindet. Hat also nichts mit News, sondern eher mit Code zu tun.

[gucci]

Hallo zusammen,

habe die selbe Problematik mit dem langsamen Seitenaufbau. Nun ja, jeder weiß wb ist das CMS für kleinere Seiten.
Ein Kunde von mir hat mit 50 Seiten angefangen, im Laufe der Jahre sind es nun schon 400 Seiten (deutsche und eglische Seiten) - was klein anfängt wird im laufe der Zeit immer größer und durch eine weitere Sprache verdoppelt sich so eine kleine Seite sehr schnell.

Nach dem Update von 2.7 auf 2.8 wurde ein deutlich lansamerer Seitenaufbau spürbar (das hängt wohl auch mit dem komplexeren Aufbau des Backends zusammen wie das Auslesen und die Darstellung der Seite-IP´s etc.).
Was auch immer da geändert wurde, das Problem mit dem Backend rollt unweigerlich auf die wb-Gemeinde zu.

Eine Neuprogrammierung wäre ein Ansatz, dauert aber doch seine Zeit und wird in absehbarer Zeit nicht realisiert werden.

Deshalb möchte ich noch einen anderen Lösungsvorschlag ansprechen:

Das Menü Seiten könnte aufgeteilt werden in:

• Aktuelle Seitenstruktur --> Die aktuelle Seitenübersicht wie gehabt
• Neue Seite(n) anlegen --> hier steht alles um eine neue Seiten anzulegen, z.B. das Modul von Vizmotion http://www.websitebakers.com/pages/admin/admin-tools/multiple-page.php
• Gespeicherte Seitenstruktur -->Übersicht die per Button (z.B. Seitenübersicht erstellen) generiert wird. Die generierte Seitenübersicht wird in der Datenbank gespeichert (dadurch wird beim nächsten Aufruf der Aufbau beschleunigt) ansonsten alle Funktionen wie bei "Aktuelle Seitenstruktur" nur das sich beim Klick auf eine Link ein neues Fenster mit dem gewünschten Inhalt öffnet.

Ist das so umsetzbar?.

Grüsse Gucci

[Waldschwein]

Hallo!

Sicherlich ist das umsetzbar, es hat nur einen klitzekleinen Haken: Die von dir angesprochenen Änderungen tragen nicht zu einem merkbar schnellerem Backend bei, zudem bleibt dabei ein wenig die gewohnte Usability auf der Strecke.

Ein Lösungsansatz führt nicht darum herum, den vorhandenen Seitenbaum _von Grund auf_ neu zu schreiben. Es wird einfach viel zu viel HTML (das ist der große Verlangsamer, bei einer Seite die bei mir 4 Sekunden braucht sind bloß 1 Sekunde Javascript - trotz aktiviertem YUI-Drag&Drop-Modul).
Egal was man macht - der jetzige Seitenbaum muss angegangen werden, alles andere wird zu keinem befriedigendem Ergebnis führen.
Entweder es wird nur ein Level anzeigt, und bei "Klick" auf das Kreuz um die Unterseiten zu öffnen werden diese automatisch nachgeladen - oder es wird einfach das ganze Tabellenzeug rausgeworfen und so weit vereinfacht, dass es einfach vieles nur noch einmal lädt anstatt für jede Seite einzeln.

Wie gesagt: 1MB HTML (!) Quellcode für 250 Seiten sind zu viel.

Edit: Datenbankabfragen sind nicht sehr schlimm, da muss man nicht sparen. Die Page_IDs werden so oder so seit WebsiteBaker "V uralt" abgefragt, ob die jetzt nur sichtbar dargestellt werden oder bloß in der URL sichtbar sind bleibt sich an und für sich gleich. Nur nicht dann, wenn deswegen 25 Zeichen für jede Seite geladen werden - das sind immer 25x400=10000. So mal ins Blaue hineingeschossen.  

Gruß Michael

Gruß Michael

[Luisehahne]

Wir sind schon seit Tagen dabei, uns Gedanken zu machen, wie wir das schneller bekommen. Bitte um Geduld.

Dietmar

[WebBird]

Wäre vielleicht jemand bereit, mir seinen Seitenbaum als SQL Dump zur Verfügung zu stellen? (Ohne Inhalte natürlich, nur die pages-Tabelle.) Ich würde zu gern mal ausprobieren, was mein ListBuilder damit macht. Je mehr Seiten, desto besser.

[tiesy]

Konnte schon jemand nachvollziehen, warum in Wb 2.80 der Browser in der Seitenadministratio n immer zum nächsten Code-Abschnitt springt? Das ist ein echt nerviges Verhalten bei umfangreicheren Seiten mit mehreren Blöcken oder vielen Newseinträgen. Bei jedem Aufruf muss man wieder zum Anfang zurückscrollen.

Der Fehler muss dann irgendwo im Code-Modul zu suchen sein, richtig?

[gucci]

Hi,

danke für Eure Anmerkungen.

@Luisehahne
Freut mich sehr, dass Ihr schon an einer Lösung arbeitet.

@WebBird und alle anderen Entwickler
Macht es Sinn, dass ich mal eine Installation mit ca. 1000 leerenDummy-Seiten anlege und Euch zur Verfügung stelle, damit Ihr eine Testplattform habt die Ihr bei Euch lokal installiern könnt?

Falls ja, lasst es mich einfach wissen, dann würde ich sowas mal umsetzen.

Gruss Gucci

[Luisehahne]

Aber gerne, immer für WebBird und mich interessant.

Dietmar

[tiesy]

Ich könnte zum testen einen Dump meiner Website zur Verfügung stellen. Größe ca. 5MB/2000 Seiten, alle mit Inhalt. Wäre das interessant für euch?

[Waldschwein]

Ich könnte zum testen einen Dump meiner Website zur Verfügung stellen. Größe ca. 5MB/2000 Seiten, alle mit Inhalt. Wäre das interessant für euch?

Hallo!

Bestimmt ist das interessant für die Tester / Entwickler, allerdings sollte so ein Dump keinesfalls im Netz herumfliegen, da stehen ja auch z.B. Passwörter drinnen.
Wenn du alle ganz glücklich machen willst, könntest du auch noch einen FTP-Zip von deiner /pages machen und beilegen.  

Gruß Michael

Edit: Ansonsten kommt man den beiden Modulen "Multiple Page Creator" in Verbindung mit "Page Cloner" (Version 0.51 glaube ich geistert hier durch's Forum, die kann auch Unterseiten kopieren) schnell auf viele "echte" Seiten.

[Luisehahne]

Deswegen habe ich ihm meine E-Mail per PM geschickt. Pages brauchen wir nicht, da keine Verzeichnisse abgefragt werden.

Habe heute mal so für mich festgstellt, das natürlich bei vielen Seiten der Aufbau langsam ist, aber auch mein FireFox durch die installierten Add-ons stark abgebremst wird, War ganz erschrocken wie schnell der im abgesicherten Modus ohne Add-ons ist, obwohl 2-3 Sekunden Wartezeit vertretbar sind.

Dietmar

[Waldschwein]

Deswegen habe ich ihm meine E-Mail per PM geschickt. Pages brauchen wir nicht, da keine Verzeichnisse abgefragt werden.

Habe heute mal so für mich festgstellt, das natürlich bei vielen Seiten der Aufbau langsam ist, aber auch mein FireFox durch die installierten Add-ons stark abgebremst wird, War ganz erschrocken wie schnell der im abgesicherten Modus ohne Add-ons ist, obwohl 2-3 Sekunden Wartezeit vertretbar sind.

Dietmar

Oder gleich "den schnellsten": http://www.srware.net/software_srware_iron.php  

Also 3 Sekunden Wartezeit finde ich nicht vertretbar, weil daraus werden schnell 10 Sekunden mit langsameren Browser, und ganz zu schweigen von Leuten wie mir mit langsamer Internetverbindung. ..
Aber: Das soll keine Anschuldigung oder "Macht ma hinne" sein, bitte nicht falsch verstehen. Nur halt der Ansatz sollte generell überprüft werden - aber wie gesagt, das Problem ist nach wie vor HTML, nicht Javascript.

Ich warte bei 300 Seiten im Firefox 3.6 ca. 10-15 Sekunden.

Gruß Michael

[WebBird]

@tiesy - Regel das am besten mit Dietmar, er wird dann alles weitere in die Hand nehmen. Vielen Dank für das großzügige Angebot!

[chio]

Mein Senf noch:

Der wesentliche Übeltäter ist die "Drag/Drop-Sortierung", die Option "Seitenbaum merken"  spielt kaum eine Rolle.

Ich habe grundsätzlich dieses einfache Stückchen Code im Template, meist unterhalb des Menü:

Code:

<?php             
        if ($wb->is_authenticated() AND $wb->get_group_id() < 2) {                    
            echo  '<a href="'.ADMIN_URL.'/pages/modify.php?page_id='.$page_id.'">bearbeiten</a>';                              
        } ?>

(Nebenfrage:  $wb->get_group_id() ist nicht mehr zeitgemäß - was wäre besser?)
Dazu kann man auch gleich einen Aufruf für den PageCloner machen ("Clonen"), wenn man häufig Seite anlegt.

Man gewöhnt sich dann einfach an, die Seiten um Frontend zu suchen und erst zum Bearbeiten direkt ins Backend zu gehen.

Es gibt auch Module, die zb Auswahllisten für Seiten erzeugen, das funktioniert bei 500 Seiten auch nicht mehr so richtig. Da kann man einfach die Liste auskommentieren und stattdessen ein simples Feld für die PageId hinstellen.
Die kann man sich ja im Frontend anzeigen lassen.