Ich glaube, das war ein Designproblem, das mir wegen meiner Serverkonfiguration entging.
Wir haben ja im Dashboard die Plugin-Updatebenachrichtigungen hinzugefügt. PHP kann keine asynchronen Abfragen. Also wird synchron beim Login nach Spartacusupdates gesucht, und das dauert leider lange. Zusätzlich kann dann auch noch der Serendipity-Upgradecheck laufen.
Bei mir läuft das schnell bzw gar nicht, weil mein Blog für ausgehende Verbindungen kein ipv4 kann. Ich vermute aber, dass als ich das einbaute (war ich das?) oder testete es bei meinem devl-blog schneller lief, also vielleicht spielt da doch die Serverkonfiguration (php-curl aktiv z.B.? Der erste Versuch mit PHPs file_open scheitert, aber erst nach einem ewig langen timeout? Sowas) irgendwie mit rein.
Was man machen müsste:
1.
https://github.com/s9y/Serendipity/blob ... ew.inc.php durchgehen und debuggen, welche Aufrufe genau so viel Zeit fressen. Meine Vermutung ist `serendipity_plugin_api::hook_event('backend_plugins_upgradecount', $output)`.
2. Schauen, ob da irgendwas dummes gemacht wird, was unnötig Zeit veerschwendet.
3. Wenn nicht: Das aus dem Template rausnehmen und stattdessen in Javascript packen. Das Dashboard sollte da einen Ajax-Request abschicken, der den Kern nach der Verfügbarkeit von Updates fragt, unt entsprechend einen Button mit Ladeindikator anzeigen.
Alternativ, und vielleicht besser für dich als Zwischenlösung: Das ganze konfigurierbar machen und die Upgradehinweise deaktivieren.
