Artikel editieren: Langes Warten auf assets

  • Hallo,
    auf einer meiner Joomla-Seiten dauert der Aufruf zum Editieren eines Artikels im Backend eeeeewwwwwwwiiiiiiggggggg. Genauso das Abspeichern. Leider werde ich aus der Debug-Meldung nicht schau. Irgendein Abruf in der _assets dauert jeweils mehrere Sekunden. Ich vermute, dass da ein Eintrag in der Tabelle fehlt? Versteht vielleicht jemand das Problem und kennt einen Lösungsansatz? Dank vorab!


    Die Debug-Meldung (Auszug)



    Und oben beim Debuggen:


  • Upps, sehe erst jetzt, dass doch eine Antwort erfolgt ist. Vielleicht ist die Benachrichtigungsmail im Spam gelandet ...


    Zunächst danke für die Nachfrage.


    Das Langsamkeits-Problem im Backend zieht sich nun schon mehrere Updates durch. Ich weiss nicht mehr, bei welcher Joomla Version es zuerst auftrat. Ich hoffte immer, dass es mit irgendeinem Update wieder verschwindet. Bleibt aber beharrlich :-(


    Datenbank habe ich schon mehrfach repariert, dabei ändert sich nichts.


    Joomla 3.6.5
    PHP: 7.0.13. Trat aber auch schon bei PHP 5.x auf.
    Mysql: mysqlnd 5.0.12-dev
    Gut 3.000 Beiträge
    Einige Erweiterungen im Einsatz. Auch immer mal wieder welche deinstalliert. Ich vermute, daher rührt das Problem. Beim Editier-Aufruf wartet Joomla vielleicht auf eine Extension, die noch in der assets erwähnt ist. Das ist aber ins blaue fantasiert.


    Hilft das?

    • Hilfreich

    Vielleicht hast du die Benachrichtigung nicht aktiviert?
    Schau in deinem Profil unter Einstellungen.
    Wenn etwas soooo lang dauert sind eher die Kategorien bzw. deren assets schuld. Ich kann jetzt nicht sagen wie du das einfach diagnostizieren oder direkt beheben könntest.


    Was ich versuchen würde:
    backup anlegen, dann in inhalte / kategorien auf "Wiederherstellen" klicken. Vielleicht hilft das schon.
    Wenn nicht:
    Eine Kopie deiner Seite lokal oder auf einer Subdomain einrichten. Anstelle deiner Datenbank eine frische Joomla-Datenbank unterjubeln. Dann Inhalte mit xml2J von der alten in die neue Datenbank übertragen. Das sollte einen Neuaufbau der assets erzwingen.

  • Hallo Christiane,
    danke dir. Die Benachrichtigung war tatsächlich in den Einstellungen deaktiviert.


    Das Wiederherstellen der Kategorien hat nichts gebracht.


    Aber ... Dennoch brachte mich dein Hinweis weiter und führte (anscheinend) zur Lösung des Problemes. Mir half der Hinweis auf:
    http://www.itoctopus.com/creat…sets-table/comment-page-1


    Der da lautete, den folgenden Befehl in der Datenbank auszuführen:

    Zitat

    DELETE FROM #__assets WHERE `name` LIKE '%com_content.article.%';


    #_ muss natürlich mit dem eigenen Präfix ersetzt werden. Vorher habe ich sicherheitshalber die _assets-Tabelle kopiert gehabt.


    Da wurden bei mir glatt mal 80 % der _assets Einträge (rund 3.800) gelöscht. Nun ist die Geschwindigkeit auf dieser Seite beim Anlegen von Neuartikeln und beim Bearbeiten von Alt-Artikeln wieder normal.


    Nochmals: Danke! Wer viel in Joomla arbeitet kann wohl nachvollziehen, wie nervig das Problem war.

  • Hi, ich hoffe, dass niemand das nachmacht.
    In den Assets sind die Berechtigungen definiert. Wenn du Zugriffsrechte gesetzt hattest, sind sie jetzt weg.
    Daher mein Hinweis "Ein neuspeichern sollte einen Neuaufbau der assets erzwingen".


    Viele Assets machen normalerweise keine Probleme, 3000 Beiträge ist nichts Besonderes und 100.000 assets verursachen von sich aus keine Performance-Probleme, sonst würden meine Seiten alle nicht funktionieren. Ich denke, dass bei dir im Lauf der Migrationen und Updates mit der Zeit sich falsche Verweise eingeschlichen haben, die endlose Suche in er Datenbank produzierten.

  • Noch Fundsache:
    Jedenfalls kommen die lft-, rgt-Werte des übergeordneten com_content-Eintrags durcheinander. Was und ob das irgendwann/wo aufschlägt/aufschlagen kann, weiß ich aber nicht. Jedenfalls ist da in meiner Testdatenbank jetzt eine Lücke "nach links", die ich auch nach "langem Zureden" nicht wegbekomme und bei evtl. auftretenden Problemen nicht wüsste, wie man sie händisch zu korrigieren hat.

  • Worauf beziehst du dich da?


    Ich habe in einer Testseite (Staging) alle assets für Beiträge (com_content.article...) in der DB gelöscht nach der Anleitung oben. Dann "Wiederherstellen" im Backenend (Keine Ahnung, ob Zusammenhang). Danach hat der Assetseintrag der Mutter-Komponente com_content diese Lücke nach links (hat einen lft von 88, aber kein Kind mit lft 89 usw (wie zuvor). Irgendwo mittendrin geht stattdessen das lft der Kinder los. Irgendwas um die 105 als Start.)


    Wenn ich halt wüsste, wovon ich da rede ;-) Ich spick mir das bei jeder neuen Datenbank wieder aus schlauen Büchern ab und mal dann erst mal doll viel Pfeile und Zahlen aufs Papier.

  • Hi, danke für die Information und deine todesmutige Aktion! Ich habe mich immer davor gehütet, asset-Sätze zu löschen. Oder irgendwas mit sql zu löschen was asset-Sätze hat, eben weil die nested sets von Hand sehr schwer zu reparieren sind wenn es mal mehr als ein Dutzend ist.
    Ich kann die Konsequenzen auch nicht abschätzen, würde das Löschen der asset-Sätze aber keinesfalls empfehlen. Wenn man da später mal ACL aktiv verwenden will, keine Ahnung was dann passiert.