Welche Plugins speichern in Datenbank? Übersicht schaffen

[Czorneboh]

@hagenroewer

Du hast das Zeug in der DB mitgeloggt?

Das war keine bewusste Entscheidung von mir. Ich habe nur Plugins installiert und nichts mit der Datenbank gemacht, bisher (beim alten Hoster. Was mein Kumpel in der Datenbank für mein Blog getan hat, hat er mir gewöhnlich nicht erklärt).

@Matsches
Gute Idee, Punkte für eine Checkliste zu sammeln!

Was ist ein CLI-Tool?

Mein neuer Hoster hat, da die erste Installation Spammails versendet(e), was ich nicht bemerk(t)e, noch mal neu installiert, aber nur mit wenigen Plugins. Wie er die wenigen Plugins ausgewählt hat, frage ich mich. Die anderen meldeten auf der Plugin-Übersichtsseite im Backend Fehler und im Frontend in der Seitenleiste. Die installierte ich neu (ohne Kopieren vom alten Blog). Absicht dahinter war, Skripte loszuwerden, die von Hackern für das Spammen misbraucht werden. - Ist dieser Punkt schon auf Deiner Checkliste?

@Czorneboh
Hast du das oben erwähnte "verify" Plugin mal ausprobiert?

entryproperties cache-Konfiguration habe ich gerade noch nicht gefunden. Wo befindet die sich?

Das simple cache - Plugin (auch) noch nicht.

Kurzbeschreibung zum simple cache plugin:

... Only dynamic plugins like the karmavoting should be positioned before this plugin.)

Das sagt mir, dass eine Plugin-Übersicht (siehe Thema dieses Threads) mit Klassifizierungen (wie "dynamische Plugins") und Funktionalitäten ("schreibt (dies und jenes) in die Datenbank", "erstellt im Admin-Backend einen eigenen Menüpunkt") auch die Information in einer Spalte enthalten sollte, welche Plugins dynamisch sind oder dynamische Inhalte erzeugen und welche nicht.

Dieses simple cache-Plugin würde ich (als Ersatz für einen Varnish-Cache-Server?!) auf Empfehlung von Timbalu ausprobieren, nämlich nach dem oben angesprochenen Aufräumen der Datenbank.

***

Habe jetzt meinen neuen Hoster gefragt, ob wir die 2. Blog-Installation (jetzt noch im geschützten Bereich) auf die Domain meines Blogs stellen und die erste damit ersetzen.

Denn beim Speichern einer statischen Seite im geschützten Blog gab es eine Fehlermeldung, die vermutlich darauf zurückzuführen ist, dass bestimmte Bereiche (bewusst) blockiert sind.

Will mir die Auswirkung des Löschens von Datenbanklogs auf die Ladezeit meines Blogs live ansehen, mit Messung der Ladezeit (wenn ich soviel Geduld aufbringe).

[Timbalu]

Dieses simple cache-Plugin würde ich (als Ersatz für einen Varnish-Cache-Server?!) auf Empfehlung von Timbalu ausprobieren, nämlich nach dem oben angesprochenen Aufräumen der Datenbank.

event cachesimple: Keine Empfehlung, eher versuchter Vorschlag (ohne einschlägige Erfahrung)

entryproperties cache-Konfiguration habe ich gerade noch nicht gefunden. Wo befindet die sich?

Erweiterte Eigenschaften von Artikeln (serendipity_event_entryproperties). In der Plugin config den Cache anstellen, sowie den weiteren Link in der backend sidebar ("Cachen aller Artikel").

Da ich wegen der SPAM-Mail-Versender-Geschichte immer noch glaube, dass die Database und Plugins die eher unwahrscheinlichen Orte der Ursache sind, würde ich das "verify" Plugin zur Einzeldatei-Analyse und Auflistung aller nicht per Core gelieferten Daten ruhig mal laufen lassen.

[Czorneboh]

Erweiterte Eigenschaften von Artikeln (serendipity_event_entryproperties). In der Plugin config den Cache anstellen, sowie den weiteren Link in der backend sidebar ("Cachen aller Artikel").

Plugin "Erweiterte Eigentschaften von Artikeln" bei mir:
"Cachen aller Artikel" war / ist noch abgeschaltet. Befürchtung bei der Nutzung waren natürlich mögliche Auswirkungen auf andere Plugins.

"Verwende erweiterte Datenbankabfragen" war / ist eingeschaltet
Erzeugt diese Funktion extra eine Spalte bzw. ein Log in der Datenbank (, die man auch jetzt löschen könnte?)?

Ich werde beide Funktionen mit der 2. Installation testen.
Das Austauschen der beiden Installationen auf meiner Domain wird (wegen Größe der Datenbank) vielleicht 2 h dauern, schreibt mein Hoster. Wenn das passiert ist, gebe ich hier Bescheid.

Piwik zur Einsparung von weiteren Plugins?
Mal sehen. Beschäftigung damit setze ich auf meine Todo-Liste.

[Timbalu]

"Verwende erweiterte Datenbankabfragen" war / ist eingeschaltet
Erzeugt diese Funktion extra eine Spalte bzw. ein Log in der Datenbank (, die man auch jetzt löschen könnte?)?

Warum ist das denn überhaupt an? Ist das Kinetic spezifisch?

Wenn aktiviert, werden zusätzliche Datenbankabfragen ausgeführt. Damit wird es möglich, dauerhafte, nicht in Artikelübersicht aufgeführte und im RSS-Feed versteckte Artikel zu verwenden. Wenn diese Funktionen nicht benötigt werden, kann das Abschalten der Abfragen die Geschwindigkeit verbessern.

[mattsches]

@Matsches
Gute Idee, Punkte für eine Checkliste zu sammeln!

Was ist ein CLI-Tool?

Das ist ein Programm, das auf der Kommandozeile ausgeführt wird, unter Linux also in einer Shell. Ich entwickle das aktuell, um gewisse Administrations-Aufgaben für Serendipity durchführen zu können, ohne den Browser bzw. Webserver zu benutzen.

Zielgruppe sind hauptsächlich Serendipity-Entwickler und -Admins.

[garvinhicking]

Hi!

Warum ist das denn überhaupt an? Ist das Kinetic spezifisch?

Wenn aktiviert, werden zusätzliche Datenbankabfragen ausgeführt. Damit wird es möglich, dauerhafte, nicht in Artikelübersicht aufgeführte und im RSS-Feed versteckte Artikel zu verwenden. Wenn diese Funktionen nicht benötigt werden, kann das Abschalten der Abfragen die Geschwindigkeit verbessern.

Nö, das kommt aus dem s9y Kern. Wenn das aktiviert ist (standardmäßig der Fall) werden SQL-Joins auf die access und entryproperties-Tabellen alle von haus aus durchgeführt, was aber halt nicht in allen fällen immer benötigt wird. Spart etwas Performance wenn man es deaktiviert, aber man verliert halt features.

Grüße,
Garvin

[Timbalu]

Ups, ich hatte immer angenommen, use cache und extended joins wären standardmäßig AUS.
Aber default:true stimmt!

[Czorneboh]

Von der 1. Installation (dem mit Spammern) beim neuen Hoster habe ich mir eben auf der Seite
http://www.webpagetest.org
die Ladezeiten geben lassen.

Hier habe ich auch noch messen lassen, mit unterschiedlichen Bandbreiten:
http://www.seo-ranking-tools.de/ladezeit-check.html

Daraus erkenne ich weitere Aufgaben.
Das ist meine Vergleichsgrundlage für die 2. Installation.

Jetzt gebe ich dem Hoster grünes Licht zum Umtausch der Installationen auf der Domain (1. Installation soll demnach in einen geschützten Bereich wandern) und messe wieder und probiere mal die Cache-Funktionen...

[Czorneboh]

Die 2. Installation ist jetzt erreichbar.
http://blog.ost-impuls.de/

Lädt im Vergleich zur 1. merklich schneller. Morgen kümmert sich mein Hoster weiter darum. Ist ja Feierabend.

[bernd_d]

Wenn ich mir die Seite so ansehe, würde ich folgende Dinge ändern...

• Archiv-Widget raus und einen Link in die Navigation
• Feed-URLS für Kategorien deaktivieren
• Kalender-Widget raus (dafür gibt es doch das Archiv )
• Statistik-Widget raus (interessiert doch eh keinen Besucher)
• diverse einzelne Elemente in einen Sammel-HTML-Container werfen (CC-Lizenz, Banner für Ostsee-Fähren, etc)

Da könnte man schon ein bisschen was an Ladezeit sparen.

Aber das ist nur meine unprofessionelle Meinung dazu.

[Czorneboh]

Nach dem Austausch der Installationen auf der Homepage-Domain:

Weiter oben habe ich die Ergebnisse des Plugins dbclean dargestellt.
Jetzt rufe ich das wieder auf. Nur ein Datum hat sich geändert:

visitors: 1.346.193

Die anderen Werte sind gleich geblieben.

Mir fiel jetzt ein, dass ja auch das Plugin versioning of entries in die Datenbank speichert. Das müsste ja auch ziemlich umfangreich sein. Vielleicht könnten die Sicherungen älterer Artikelversionen auch noch in das dbclean-Plugin aufgenommen werden?
Oder, sagen wir (da es hier ja darum geht, die letzten Versionen von jedem Artikel aufzuheben), könnte ein Hinweis aufgenommen werden, dass man hier die Datenbank auch noch aufräumen könnte.

[Czorneboh]

Ladezeiten, gemessen mit Webpagetest (siehe oben):

1. Messung, der 1. Installation, 13.8.13 (jetzt nur noch im versteckten Bereich, demzufolge dürfte hier kein Kommentarspam mehr kommen):
38,94 sec

2. Messung, der 2. Installation, 14.8.13:
13,5 sec.

Nächste Schritte:
Datenbank mit dbclean aufräumen.

Webpagetest bzw. Firebug weist einige 404-Meldungen aus. Kostet auch Ladezeit. Da off-topic, stelle ich extra Frage.

Leider werden immer noch Spammails versandt.
Mein Hoster kopierte mir in seine letzte Mail Daten zu 16 heute und schreibt, woher bzw. von welchem Skript die versandt werden, lässt sich aus "unseren Logs" nicht ermitteln.

Jedoch entsprechen die Versendezeiten genau den hinterlassenen Kommentaren in Blogartikeln, die in der Kommentarmoderation gelistet sind.
Im Schnitt wird etwa jede Stunde 1 Kommentar hinterlassen. Spamblock-Plugin habe ich so eingestellt, dass nach Hinterlassen eines Kommentars erst wieder nach einer Stunde der nächste Kommentar vom Blog angenommen wird (muss nachsehen, wie die Regel genau lautet).

Mein Hoster hat die ip-Adressen und in der Kommentarmoderation stehen die urls der Absender der Kommentare (bzw. kann ja auch Fake).

Der Spamversand steht also im Zusammenhang mit dem Kommentarfeld.
Deswegen trainiere ich Bayes jetzt nicht mit diesen Kommentaren von heute, vielleicht will sich das jemand noch ansehen...

Übrigens nehme ich jetzt die Log-Datei vom Spamblock-Plugin aus der Bildergalerie, wohin sie wohl mein Supportmann gelegt hat (sichtbar für jeden Fotogaleriebesucher). Ich habe gestern im Plugin-Backend den Pfad um eine Ebene verkürzt und sehe, dass damit eine neue Log-Datei angelegt wurde.

Die alte Logdatei sichere ich mir auf meinen PC.

[onli]

Das sind immer noch fürchterliche Zeiten.

Als Spam-Mails bezeichnet ihr also die normalen Kommentarmoderationmails? Das klärt das ein bisschen auf. Tragen da Kommentatoren falsche Mailadressen ein oder was genau ist das spammige an denen?

[bernd_d]

Spamblock-Plugin habe ich so eingestellt, dass nach Hinterlassen eines Kommentars erst wieder nach einer Stunde der nächste Kommentar vom Blog angenommen wird

Öhm, das ist aber SEHR Besucherunfreundlich, wenn er erst ne Stunde warten muss, bevor er wieder was kommentieren darf. Da vergeht einem ganz schnell die Freude und man sucht sich ne andere Seite.

[Czorneboh]

@onli
Ja, da bin ich mir selber nicht sicher und werde meinen Supportmann noch mal fragen. Den Zusammenhang habe ich ihm letzte Nacht geschrieben und er schrieb dazu, dass er sich deswegen heute vielleicht noch mal meldet.
Das wollte ich auch schon jetzt wissen, ob die vom Blogsystem erzeugte Meldung (über diese Kommentare lasse ich mich derzeit nicht per E-Mail informieren) die Spammail sein soll. Was ich vom Supportmann zum Nachweis von Spammails erhalten war, sieht so aus:

Aug 14 01:21:07 [88.80.20.128] [mein Benutzername]:/home/www/Ordnernummer/Ordnernummer/[mein Benutzername]/.test-blog/index.php

Die ip-Adressen hinter der Uhrzeit sind unterschiedlich. In der Kommentarliste sehe ich dann die Domain, die "beworben Wird" (auf die verlinkt wird), eine E-Mail-Adresse mit einem (Phantasie-)Namen und nachfolgenden Ziffern, häufig bei Gmail oder Gnumail.

Zusätzlich ließen sich noch Erkenntnisse gewinnen, wenn man in der Liste der aktuellen referer (dafür gibt es auch ein Plugin, welches ich nutze) Screenshots macht und die hier stehenden Informationen mit der ip-Adresse, url abgleicht, insbesondere nach gleicher Zeit. In der referer-Liste tauchen bestimmte Server mit schon verdächtigen Namen auf, auch mit country code .pl (was ich vorher nicht hatte).

Wegen der Wirkungen, die das Säubern von Teilen der Datenbank für die Ladezeit haben, will ich noch ein extra posting mit einer Übersichtstabelle mit gemessenen Ladezeiten machen.

Das Thema Website-Optimierung und SEO ist ja, finde ich, im Forum etwas unterrepräsentiert. Aus diesem Bereich könnten sich aber interessante Erkenntnisse als Argumente pro Serendipity ergeben. - Manche erinnern sich vielleicht - ich fragte, wo denn über das Update auf 1.7 berichtet wurde.

Mein Website-Umzug ist gerade eine Chance, Potentiale auszuloten.

@Bernd_d

Öhm, das ist aber SEHR Besucherunfreundlich, wenn er erst ne Stunde warten muss, bevor er wieder was kommentieren darf. Da vergeht einem ganz schnell die Freude und man sucht sich ne andere Seite.

Nanana! Wollen wir mal auf dem Teppich bleiben. Weit weniger als 0,5 % der Besucher setzt überhaupt auch nur einen Kommentar ab.

Besucher sind Personen, die Informationen suchen.
Meine Website ist keine social network-Seite, auf der sich Freunde austauschen wollen.

Es bekommt so gut wie niemand mit, dass es eine Kommentarsperre für gewisse Zeit gibt.