Schlagwort-Archive: Plugins

Alternativen zu Akismet und WordPress Stats

Nach dem es in letzter Zeit vermehrt „Unruhen“ in Sachen Datenschutz hinsichtlich diverser Plugins gab, habe ich mich entschlossen, mich vorerst von den Plugins „Akismet“ und „WordPress Stats“ zu trennen. Und nach dem ich heute bei Perun.net gelesen habe, dass es ohnehin scheinbar Probleme mit den WordPress Stats gibt, ist mir die Entscheidung nicht so schwer gefallen.

Als Alternative zu Akismet habe ich nun wieder AntiSpam Bee und statt der WordPress Statistiken nun das Plugin „Statify“ – beide von Sergej Müller – aktiviert.

Ausge(wp-)grinst

In der letzten Zeit fällt mir auf, dass das Laden der Webseite ständig zäher wird.

Das hat zum einen damit zu tun, dass ich in der jüngeren Vergangenheit das eine oder andere neue Plugin aktiviert habe, zum anderen dass offensichtlich mein Webspace-Provider ebenfalls erhebliche Antwortzeitprobleme aufweist.

Anhand des Firefox Plugins „Load Time Analyzer“ stellte ich fest, dass es zunächst teilweise 5, in Ausnahmefällen sogar 10 (!!!) Sekunden dauert, bis sich der Webserver überhaupt meldet (da kann ich aber erstmal nichts dran machen) und dann im Laufe des Seitenaufbaus nochmal erheblich Zeit vertrödelt wird um bestimmte Dateien und Skripte abzuarbeiten.

Ein bestimmtes Skript stach dabei massiv ins Auge und betraf das Laden der prototype.js (ca. 80 KB), welche durch das Plugin „WP-Grins“ (von WordPress-Mitentwickler Alex King) bei JEDEM Seitenaufruf – unabhängig ob auf der Seite ein Kommentarfeld mit klickbaren Smilies angezeigt wird oder nicht – neu geladen wird.

Aus dem Grund recherchierte ich nach einer Alternative zu WP-Grins und kam so einem Beitrag „Smiley-Skript austauschen“ auf »Peruns Weblog«. Mit dem dort beschriebenen Alternativskript „Smiley JS Button“ werden für die klickbare Anzeige der Smilies in den Kommentaren keine 80 KB geladen sondern nur etwa 3-4 KB — und die auch nur, wenn die Seite ein Kommetarfeld aufweist.

Auf Umfang der angezeigten Smilies hat dies keine Auswirkung, ich bekomme nachwievor alle — auch meine eigenen hinzugefügten — angezeigt. Ich kann nun sogar steuern, WO die Smilies jetzt beim Textfeld angezeigt werden. WP-Grins stellte diese IMMER direkt über das Textfeld.

Ich werde nun beobachten, ob dies der Weisheit letzter Schluß ist, oder ob ich noch weitere Optimierungen umsetzen muss, z.B. die ggf. vollständige Entfernung Reduzierung der in der Sidebar angezeigten „Buttons“.

Werbefrei:heit

aber nur scheinbar :-)

Wer regelmäßig hier liest, dem wird aufgefallen sein, dass mitunter nur noch wenige bis gar keine Werbebanner mehr angezeigt werden. Grund hierfür ist das Plugin „Who See Ads„, mit welchem man mit selbst zu definierenden Regeln bestimmen bzw. steuern kann, wem welche Werbeblöcke angezeigt werden.

Sämtlicher Werbe-Code etwaiger Anbieter kann samt entsprechender Regeln als sogenannter „Context“ gespeichert werden. Statt des Bannercodes wird dann eben das Plugin aufgerufen. Anhand der zuvor definierten Regeln (welche man für jeden erstellten Kontext selbst bestimmen kann) wird bei der Generierung der Seite entschieden, ob der besagte Werbebanner nun angezeigt wird oder eben nicht.

Für die meisten meiner Werbebanner habe ich nun konfiguriert, dass die Werbung nur angezeigt wird, wenn der Leser von einer Suchmaschine kommt. „Normalen Lesern“, die binnen 10 Tagen min. zweimal auf dem Blog waren wird hingegen der Banner nicht angezeigt.

Zudem sollen bestimmte Werbeblöcke auch nur gezeigt werden, wenn der Beitrag älter als 30 Tage ist – somit sollten auch GoogleReader Nutzer nicht gleich mit Werbung erschlagen werden, wenn sie aktuelle Beiträge kommentieren möchten.

P.S. Ein Manko gibt es derzeit allerdings. Nach Aktivierung von „Who See Ads“ funktioniert „Add Quicktags“ von Frank Bültge nicht mehr. Die Quicktags sind dann seltsamerweise „funktionslos“ :-(

Nachtrag:
Im Plugin „Who See Ads“ kann man über die myoptions.php einzelne Funktionen separat konfigurieren und somit die WSA-Quicktags generell deaktivieren. Ich persönlich brauche die Quicktags an der Stelle – also im Beitragstext – ohnehin nicht und könnte etwaige Ads auch manuell über <!--wsa:context_name--> einbinden.

Rückblicke…

Nachdem ich nun herumgewerkelt habe die ganze Sidebar „entwidgetisiert“ … nun ja ich habe mich ein wenig des Codes aus der widget.php bemächtigt, um die Dropdown-Boxen wieder zu erhalten, die WordPress-Template-Tags waren nicht ganz so praktisch… habe, konnte ich das zuvor benannte Plugin „A Year before“ nun auch gleich auf althergebrachte Weise einbinden.

Nun kann man man immer sehen, was sich in diesem Blog vor einem Jahr so getan hat…

Vielleicht finde ich auch eine Einstellung, dass nur ein zufälliger Post angezeigt wird und nicht alle vom besagten Tag…