Das wäre recht typischer PHP-Code für die alten Plugins. Ich überlege gerade, ob ich mich mal an eine Neufassung des Plugins oder eine grundsätzliche Überarbeitung wage. Nachdem ich jetzt längere Zeit über dem Code meditiert habe, glaube ich, dass eine komplette Überarbeitung sinnvoll wäre. Habt ih...

Nur Interessehalber:
Hast du eine Idee, wann das Plugin original geschrieben wurde? Github reicht nur bis 2011. In meinem S9Y-Buch von 2008 ist das auch schon erwähnt. Frühere Vorkommen habe ich bisher nicht gefunden.

Daneben ist mir unklar, warum der Typ von tag immer mal wechselt:

• Zeile 1559: boolean

  Code: Select all

  function getTagCloudQuery($sort = '', $tag = false)

• Zeile 1566: String

  Code: Select all

  if (is_string($tag)) {

• Zeile 1572: Array

  Code: Select all

  } else if (is_array($tag)) {

Alles innerhalb einer Funktion.

Soweit ich das sehe, ermittelt die originale SQL-Abfrage wirklich nur die Beiträge, die zu den Tags passen. Könnte man das nicht folgendermaßen vereinfachen? SELECT tag, count(entryid) AS total FROM entrytags WHERE tag in (" . $included_tags . ") AND tag not in (" . $excluded_tags . &...

Das war zumindest die Ausgabe von mtop. Daher gehe ich schon davon aus, dass das stimmt. Auch bei meinen Tests mit LEFT JOIN ist schon bei zwei LEFT JOINs eine Verzögerung zu merken, die pro weiterem LEFT JOIN deutlich ansteigt.

DB ist MySQL als MariaDB in der Version 15.1.

LEFT JOIN serendipity_entrytags AS sub1 ON main.entryid = sub1.entryid In der originalen Abfrage sind 14 LEFT JOINs drin. Das dürfte schon ein Problem darstellen. Ich habe testweise mal einige Abfragen mit LEFT JOINs gemacht. Die Ergebniszahl stieg jeweils um den Faktor 7--10. Das Ganze 14-mal brin...

Ich bin nicht wirklich durch die Anfrage durchgestiegen. Wenn ich mal etwas Zeit habe, will ich die nochmal auseinandernehmen. Aber bislang war das leider nicht der Fall. Also die Anfragen mit sehr vielen Tags sehe ich in meinem Blog recht häufig. Bislang hat sich der Server jedoch nicht beschwert. ...

Hallo, in letzter Zeit schlagen bei mir Anfragen auf, die einige Last erzeugen. Diese beziehen sich zumeist auf ältere Beiträge und suchen nach mehreren Tags: https://…/blog/archives/1999/plugin/tag/tag1/tag2/tag3/plugin/tag/tag4 Dabei entsteht eine SQL-Abfrage, die ewig dauert: SELECT neg.tag AS ta...

Das sieht gut aus. Ich kann die Fehlermeldung nicht mehr reproduzieren und in den letzten 500 Requests ist auch keine Meldung mehr zu finden. Danke!

Dies erscheint außerhalb des if. Soweit ich erkennen kann, werden die Bedingungen innerhalb der if-Anweisung nicht ausgeführt.

So ich habe jetzt mal ein wenig weiter gegraben. Dein Vorschlag hat keine Änderungen gebracht. Aber es scheinen nur bestimmte Abfragen diesen Fehler zu erzeugen. Beispiel: https://kubieziel.de/blog/archives/plugin/tag/spam/verlosung/berlin/vim/usa/plugin/tag/vortrag Der var_dump() erbringt dann: NUL...

Ja, das sieht gut aus:

Freie Artikel-Tags
serendipity_event_freetag
Erlaubt das freie Tagging von Artikeln
Weitere Informationen
Autor: Garvin Hicking, Jonathan Arkell, Grischa Brockhaus, Lars Strojny, Malte Paskuda, Ian
Version: 3.70.3

Ich habe in meinem PHP-Errorlog einige Einträge der Art: [23-Nov-2021 12:04:43] WARNING: [pool www] child 7379 said into stderr: "[23-Nov-2021 12:04:43 Europe/Berlin] PHP Warning: Illegal offset type in unset in …/plugins/serendipity_event_freetag/serendipity_event_freetag.php on line 1551"...

qbi wrote: ↑Thu Aug 20, 2020 1:54 pm Ich grab mal ein wenig weiter und versuche, dem Problem auf den Grund zu gehen.

Es war noch eine Altlast vom Umzug der Seite. Die Umleitung zu serendipity_admin.js war nicht korrekt. Ich habe das korrigiert und schon läuft es.

In der Konsole kommt beim Click auf Spam folgende Meldung: serendipity_admin.php?serendipity[adminModule]=comments:239 Uncaught ReferenceError: spam is not defined at HTMLAnchorElement.onclick (serendipity_admin.php?serendipity[adminModule]=comments:239) Ich grab mal ein wenig weiter und versuche, d...