Webseiten-Infos.de » Plugins

Vorsicht beim Updaten von Plugins!

Dieter — Sun, 27 Jun 2010 20:40:00 +0000

Gelegentlich zeigt mir der Administrationsbereich (das Backend) meiner WordPress-Installation an, dass neue Versionen von Plugins verfügbar sind.

Wie es sich gehört, schaute ich erst einmal unter Detail der Version x.x ansehen nach, was denn diese neuen Versionen kennzeichnet.

Zu meiner Überraschung musste ich bei

feststellen, dass diese mindestens WordPress 3.0 voraussetzen.

Das finde ich ausgesprochen unglücklich, da ich noch WordPress 2.9.2 im Einsatz habe. Hätte ich mir nicht die Beschreibung der Plugins vorher angesehen, hätte ich wahrscheinlich ein Kompatibilitätsproblem bekommen.

Daher mein Tipp: Vor einer Aktualisierung (einem Update) eines WordPress-Plugins immer erst einmal vorsichtshalber die Mindestversion überprüfen.

Kommentare

30. Juni 2010, Tanja schreibt: *kicher* ja, so kann es gehen. Wer einfach nur blind jedem Update hinter her läuft, der kann auch mal böse aufwachen ;-) Ich lasse mir die verfügbaren Updates gar nicht mehr anzeigen (hab doch ein Plugin dazu), damit setze ich mich auch nicht mehr unter Druck und ähnliches. Ständig irgendwo diese roten Markieren etc. sind mir dann doch zu doof ;-) und... ich bin wohl doch nicht die letzte, die noch nicht auf 3.0 umgestiegen ist :-)
30. Juni 2010, Dieter schreibt: @Tanja Da werde ich mal nachschauen, welche Plugins es noch von Dir gibt. ;-) und ... nein, Du bist nicht die letzte, die noch nicht auf WordPress 3.0 umgestiegen ist. Ich teste bisher WordPress 3.0 lokal und werde es erst online testen sowie Datensicherung betreiben, bevor ich es auf mein Testblog loslasse. ;-)
30. Juni 2010, Tanja schreibt: Kannst Du ganz einfach hier http://wordpress.org/extend/plugins/profile/crazy-girl sehen ;-) Ich hab noch nicht mal mit dem Testen angefangen ;-) Liegt daran, dass meine Tage derzeit 48 Stunden lang sein müssten :-(
30. Juni 2010, Dieter schreibt: @Tanja Ist ja der helle Wahnsinn! Du hast schon 5 WordPress-Plugins geschrieben. Wow! Auch bei mir müsste der Tag derzeit 48 Stunden haben. Habe ein dringendes Schlaf-Nachholbedürfnis. :-(
30. Juni 2010, Tanja schreibt: "Heiliger Strohsack" fällt mir dazu nur ein *lacht*. Ja, es sind tatsächlich schon 5 Plugins, aber schon lange kein neues mehr. Einfach keine Zeit... :-(
30. Juni 2010, Dieter schreibt: @Tanja Zeit hat man nicht, Zeit nimmt man sich. Ich habe im Moment sehr viel Arbeit und deswegen auch ein verstärktes Zeitproblem.
1. Juli 2010, Tanja schreibt: Da gabs doch mal den super dämlichen Spruch "Zeit ist Geld, Geld ist Luxus und Luxus kann ich mir nicht leisten". Da muss sich defintiv was ändern daran, positiv denken ist angesagt ;-)
1. Juli 2010, Kimi schreibt: Gott sei dank, sowas hab ich nicht :D
1. Juli 2010, Maverick schreibt: Besonders praktisch finde ich in diesem Zusammenhang, wenn man bereits eine Lokalinstallation von WordPress hat, so dass man beim aktualisieren von WordPress selbst und Plugins oder auch bei Theme-Design-Änderungen kein unnötiges Risiko eingehen muss. Mit dem "WampServer" WordPress Lokal auf eigenem Laptop bzw. Desktop zu installieren und laufen zu lassen, ist eine saubere und einfache Sache. Bin persönlich jedenfalls damit sehr zufrieden.
2. Juli 2010, Dieter schreibt: @Tanja Jepp, think pink. ;-) @Kimi Was meinst Du mit "sowas"? Zeit? Geld? Luxus? :roll: @Maverick Ich habe XAMPP lite für die lokale WordPress-Installation(en) im Einsatz. Der lokalen Installation traue ich nicht alleine, weil manche Plugins nur auf dem Webspace funktionieren (z.B. wpMAPS und Amazon Machine Tags) und deshalb lokal nicht getestet werden können. Zudem kann es durch unterschiedliche PHP-, MySQL-Versionen bzw. Einstellungen lokal und auf dem Webspace ebenfalls zu nicht erkennbaren Kompatibilitätsproblemen kommen. Gleichwohl bin ich inzwischen der Überzeugung, dass lokal testen auch Sinn macht.
2. Juli 2010, Tanja schreibt: @Maverick und Dieter: Ich spiegel mir die gesamte WP Installation auf eine andere Domain (oder Subdomain wenn man keine überflüsige Domain hat) und teste dann dort. Das gibt in der Regel die aussagekräftigsten Ergebnisse.
2. Juli 2010, Kimi schreibt: @Dieter haha. Die Drei habe ich leider nicht :( Ich meinte aber die Plugins. die du beschrieben hast, die habe ich nicht :) Ich benutze nicht viele Plugins.
2. Juli 2010, Kimi schreibt: Ich hab fast vergessen zu fragen: Ist es jetzt ein Major Update, dass mein PR 2 von Google PR? zurück ist?
4. Juli 2010, Dieter schreibt: @Kimi Ein neues richtiges PageRank-Update hat es meines Wissens bisher noch nicht gegeben. Das würden wir bestimmt durch Artikel in der Blogosphäre mitbekommen.
5. Juli 2010, Kimi schreibt: @Dieter, ah okay, weil mein PR ist wieder 2. Ich hab gedacht, das Update ist schon erfolgt. Danke für die Antwort ;)
5. Juli 2010, Maverick schreibt: @Dieter XAMPP Lite ist natürlich ebenfalls eine tolle Lösung. Was die Funktions- und Verhaltenweisen von einigen Plugins im quasi Live-Einsatz und lokal betrifft, so möchte ich dir voll und ganz zustimmen, ohne, dass natürlich eine WP-Lokalinstallation ihre Quasi Daseinsberechtigung verlieren würde.
5. Juli 2010, Dieter schreibt: @Maverick Viele WordPress-Nutzer testen vor einer Aktualisierung die neue WordPress-Version überhaupt nicht. Andere nur lokal (so wohl beispielsweise Frank Bültge) oder nur mit einer Testinstallation auf dem Webspace (so wohl beispielsweise Vladimir Simovic aka Perun). Da bin ich mit meinem Testen lokal und auf dem Webspace wohl eher der Übervorsichtige. ;-)

Twitterseite mit PageRank 4

Dieter — Sun, 18 Apr 2010 11:30:33 +0000

Vor 11 Monaten habe ich angefangen Twitter zu nutzen (siehe hierzu meinen Blogbeitrag “Webseiten-Infos.de auch auf Twitter“).

Mit dem Update des Google PageRanks (PR) zu Ostern (siehe hierzu meinen Blogbeitrag “PageRank-Suche zu Ostern!“), dachte ich noch, dass die Twitterseite WebseitenInfos keinen PageRank habe (siehe hierzu meinen Kommentar).

Entweder hatte ich da auf die falsche Seite geschaut oder inzwischen erhielt die Twitterseite WebseitenInfos den PageRank 4.

Wie auch immer, ich freue mich über diesen zusätzlichen Backlink mit PageRank 4!

Schon erstaunlich wie schnell sich das Web und meine Einstellung zu manchen Webdiensten wie Twitter ändert.

Ursprünglich wollte ich Twitter ignorieren (siehe hierzu meinen Blogbeitrag “Wie Twitter mein Leben veränderte!“).

Dann nutzte ich schließlich Twitter mittels dem WordPress-Plugin Feed2tweet doch als zusätzlichen Kommunikationskanal um neue Blogbeiträge bekannt zu machen.

Schließlich fand ich bei Twitter immer mehr interessante Infos und kommt es hin und wieder inzwischen auch zu gelegentlichen Frage-Antwort-Spielchen mit anderen Twitterern.

Wesentlich zur stärkeren Twitter-Nutzung hat auch mein neues Smartphone Motorola Milestone beigetragen. Dort habe ich die Android App Twidroid PRO installiert, die auch unterwegs – wie etwa in öffentlichen Verkehrsmitteln – ein komfortables Twittern ermöglicht.

Twitterst Du auch?

Und falls ja, wie nutzt Du Twitter und welchen PageRank hat Deine Twitterseite?

Kommentare

18. April 2010, Burkhard schreibt: Bin immer noch nicht auf den "Twitter-Zug" aufgesprungen. Auch deshalb, weil ich darin für mich keinen relevanten Nutzen sehe. Auch wenn Twitter mittlerweile ständig präsent ist, scheint die Twitterwelle schon wieder etwas abzuflachen. Aber vielleicht sehe ich den Nutzen auch deshalb (noch) nicht, weil ich selbst nicht twittere. Vielleicht sollte ich es doch mal testen :-)
18. April 2010, Dieter schreibt: @Burkhard Ausprobieren kostet außer Überwindung und etwas Zeit nichts. Ich war auch erst sehr skeptisch. Einfach mal testen. ;-)
18. April 2010, Max schreibt: Twittere auch schon ein Weilchen, aber mit PageRank kann ich aktuell noch nicht dienen. Aber das ist mir auch nicht wirklich wichtig, denn was bringt das schon?
19. April 2010, Dieter schreibt: @Max Bei mir brachte das Twittern insbesondere: 1. Zusätzliche Besucher für meine Website 2. Nun auch einen Backlink mit PageRank 4
2. Mai 2010, Alex L schreibt: Hi Dieter, schon eine Weile her als ich zum letzten Mal bei dir kommentierte. Nun ja, erstmal Glückwunsch meinerseits zu dem erlangten PR 4 deines Twitter-Accounts. Das geht dort ziemlich schnell vonstatten, soweit meine Erfahrungswerte dies belegen. Man kann auch die Backlinks für einen Twitter-Account checken, indem man bei Google folgendes eintippt: link:http://twitter.com/webseitenInfos Dieser Wert sollte einer reinen Info als und für Webmaster dienen. Ich nutze Twitter sogut wie aus dem externen Twitter-Client namens TweetDeck heraus. Twitter.com surfe ich hin und wieder an, um meinen neuen Followern teilweise zurückzufolgen oder wenn ich neue Listen erstellen möchte bzw. einen Twitterer zu solchen hinzufügen will. Nach einem Jahr bei Twitter möchte ich auf diesen Dienst nicht wirklich verzichten wollen. Immerhin ist mittlerweile ein gewisses Netzwerk bereits vorhanden ;-).
2. Mai 2010, Dieter schreibt: @Alex Ein wichtiges Detail hatte ich bei meinem Blogbeitrag vergessen, aber daran erinnere ich mich aufgrund Deines Kommentars nun wieder: Dank Deines Blogbeitrags "1 Jahr Twitter: Fazit" hatte ich noch einmal nach dem PageRank meines Twitter-Accounts nachgeschaut. Dadurch bin ich überhaupt erst auf den PageRank 4 von WebseitenInfos aufmerksam geworden. Danke für den Tipp mit dem Backlink-Check. Da scheint es für WebseitenInfos noch nicht viele Backlinks zu geben. Dass Du mit Tweetdeck twitterst, konnte ich als Dein Follower schon sehen. Vielleicht probiere ich Tweetdeck auch mal aus. Auch ich möchte auf Twitter nicht mehr verzichten. ;-)
2. Mai 2010, Alex L schreibt: @Dieter, es freut mich, dass ich dich dazu inspirieren konnte. Der BL-Check für Twitter funktioniert also demnach, was man auch auf die einzelnen Tweets eines Twitter-Accounts beziehen kann. So sieht man welche Tweets bereits im Google-Index gelandet sind. Dafür nutzt du anstatt link: das Präfix site:. Bei dir müssten sich derzeit um die 50 Tweets im Index befinden. Sowas wie SeesmicDesktop hatte ich auch schon im Einsatz, aber inzwischen ist mir TweetDeck am liebsten. Viel Spass damit wenn du es ausprobieren möchtest und Merci an dieser Stelle für die Verlinkung.
3. Mai 2010, Dieter schreibt: @Alex Ja, Du konntest mich erneut inspirieren. Wir lernen voneinander und das finde ich schön und spannend. :-) Google weist für site:http://twitter.com/WebseitenInfos 94 Ergebnisse aus. Scheinen schon ein paar Tweets mehr im Index zu sein. :-) TweetDeck scheint sehr beliebt zu sein, aber auch Adobe AIR vorauszusetzen bzw. ebenfalls zu installieren. Deswegen lasse ich dann doch die Finger davon. Von Seesmic hatte ich dagegen bisher noch nichts gehört, setzt aber leider ebenfalls Adobe AIR voraus. Ich habe einfach keine Lust meinen PC mit weiteren Anwendungen noch langsamer zu machen.
22. Juli 2010, Andreas schreibt: Ich habe auf meinem Twitterprofil einen PR5 Es freut einen, wenn man sieht das "twittern" nicht nur Spaß macht, sondern auch noch was für den PR bringen kann. By the way, ich nutze auch Tweetdeck und den Gratis URL-Shortener um die Links klein zu kriegen. Die Tweets werden auf der HP eingebunden, was mir jeweils neue Follower bringt, denke ich zumindest =) Jedoch dranbleiben ist wichtig, also freu mich über @andreas_bolli Nachrichten und nette Tweets zu lesen. Cheers Andreas
23. Juli 2010, Dieter schreibt: @Andreas PageRank 5 für das Twitterprofil ist beachtlich. Herzlichen Glückwunsch. Ich habe inzwischen einen neuen PC und inzwischen auch Adobe AIR drauf. Wenn ich mal Zeit habe, werde ich dann doch mal Tweetdeck nutzen. URL-Shortener brauche ich nicht. Das macht doch Twitter von selbst. Also ich habe keine Tweets auf meiner WordPress-Website eingebunden und trotzdem erhöht sich langsam, aber kontinuierlich die Zahl meiner Follower. ;-) Ich gebe aber zu, dass ich über andere Maßnahmen zur Verknüpfung von Webseiten-Infos.de und meiner Twitterseite nachdenke. Da habe ich noch so eine Idee. ;-)
20. August 2010, patrick schreibt: Habe bis jetzt noch keinen PR auf meinem Twitterprofil, aber ich bin guter Dinge, dass sich das mit dem nächsten PR-Update von G* ändern wird.
20. August 2010, Dieter schreibt: @patrick Dann drücke ich Dir mal den Daumen für das nächste PR-Update. Habe auf Deinem Blog keinen Hinweis auf eine (zugehörige) Twitterseite gefunden. Würde ich an Deiner Stelle mal ändern.
13. Dezember 2010, Gerry schreibt: Erstaunlich, dass ihr ein PageRank von 4 oder gar 5 für euer Twitterprofil vorweisen könnt. Letztlich hat das aber auch was gekostet: eure Zeit.
13. Dezember 2010, Dieter schreibt: @Gerry Jepp, genauso wie der PageRank unserer Websites. ;-)
14. Dezember 2010, Andreas schreibt: Ich bin soeben nochmals den PR meines Twitter-Profils anschauen gegangen und habe festgestellt, dass es einen PR 9 hat. Also ich würde dem nicht all zu große Bedeutung schenken. ;-) Obwohl es schon cool aussieht.
16. Dezember 2010, Dieter schreibt: @Andreas Nach meinem Firefox-Addon hat Dein Twitter-Profil derzeit einen PageRank von 5. Herzlichen Glückwunsch dazu! Ist zwar kein PR 9, aber gleichwohl besser als der aktuelle PageRank meines Twitter-Profils: 4. Und immerhin ist das ein Backlink. :-)
10. Februar 2011, Matthias Kolb schreibt: Nutze seit neuestem TweetDeck und muss sagen super Sache :)
11. Februar 2011, Dieter schreibt: @Matthias Da ich inzwischen einen neuen und leistungsstärkeren PC habe, habe ich nun auch TweetDeck getestet. Und ja: TweetDeck finde ich ebenfalls super! :-)

Spamschutz nur mit Antispam Bee

Dieter — Tue, 09 Mar 2010 21:07:21 +0000

Seit etwa zwei Wochen schützt als einziges Plugin Antispam Bee 1.4 von Sergej Müller die WordPress-Installation von Webseiten-Infos.de vor Spam (genauer: vor automatischen Spam-Kommentaren sowie falschen Track- und Pingbacks).

Auslöser dafür war der Kommentar von Ute zu meinem Blogbeitrag “Empfehlenswerte externe Dienste“, dass Sie gerne auf externe Webdienste wie Akismet verzichten würde.

Das nahm ich zum Anlass meine Einstellungen von Antispam Bee zu überprüfen und dann testweise Akismet zu deaktivieren.

Diesen Test hat Antispam Bee hervorragend bestanden und so setze ich die fleißige Biene nun als einziges Plugin zur Spamabwehr ein. Im Hinblick auf meine Bestrebungen die Zahl meiner aktiven Plugins möglichst zu reduzieren eine erfreuliche Entwicklung.

In dem Zusammenhang sei auch erwähnt, dass Sergej das Plugin in den letzten Monaten mit zusätzlichen Optionen weiter verbessert hat. Meine aktuellen Einstellungen von Antispam Bee zeigt der folgende Screenshot:

Den Spam lasse ich von Antispam Bee übrigens lediglich markieren und nicht automatisch löschen, damit ich die Spammails nach häufig auftretenden IP-Adressen überprüfen kann. Besucher mit solchen IP-Adressen sperre ich dann mittels der .htaccess-Datei künftig von Webseiten-Infos.de vollständig aus (siehe hierzu auch meinen Blogbeitrag “Spam-Schutz auf Webseiten-Infos.de“).

Wichtig für den optimalen Spamschutz Deiner WordPress-Installation ist, dass Du Dir die Beschreibungen der Funktionen von Antispam Bee durchliest und dann Deine Einstellungen vornimmst. Ich hatte das anfangs nicht beherzigt und deshalb auch ein kleines Problem mit der fleißigen Biene (siehe hierzu meinen Blogbeitrag “Antispam Bee: Einstellungen geändert“).

Sehr praktisch ist, dass die Einstellungsmöglichkeiten des Plugins im Administrationsbereich (Backend) von WordPress mit den jeweiligen Erläuterungen der Funktion verlinkt sind.

Ein herzliches Dankeschön an Sergej für dieses und seine vielen weiteren tollen Plugins für WordPress wie beispielsweise Antivirus (siehe hierzu meinen Blogbeitrag “Antivirus-Plugin verbessert Sicherheit“) und wpMAPS (siehe hierzu meinen Blogbeitrag “Karte mit WordPress-Plugin wpMAPS“).

Da ich aktuell Akismet deaktiviert habe, habe ich auch meine Datenschutzerklärung insoweit angepasst, sprich um das Wort “eventuell” ergänzt.

Mein persönliches Fazit:

Für mich reicht Antispam Bee bei meinen WordPress-Installationen als einziges Plugin zum Schutz vor automatischem Kommentar-Spam und vor falschen Track- und Pingbacks.

Ich kann dieses Plugin besten Gewissens auch als “Einzelkämpfer” empfehlen.

Gegen manuellen Kommentar-Spam schütze ich mich durch Moderation der Kommentare.

Kommentare

10. März 2010, Ute schreibt: Klasse, :hurra: dank dir fürs drüber schreiben, da werde ich doch bei Gelegenheit mal wieder putzen und testen müssen. Aber so wie du schreibst, gibt es da wohl kein Problem mehr, prima! :)
10. März 2010, Dieter schreibt: @Ute Gern geschehen! Du hast mir den letzten Anstoß dazu gegeben, mal auf Akismet testweise zu verzichten und nur noch Antispam Bee einzusetzen. :-) Und selbst mit meinen Archivseiten, die auch ein Kommentarfeld haben und insoweit exotisch sind, verschluckt Antispam Bee keine richtigen Kommentare mehr. In der zweiwöchigen Testphase war mir kein einziger Fehler durch Antispam Bee aufgefallen. Automatischer Spam wurde korrekt als Spam markiert und über manuelle Kommentare wurde ich aufgrund meiner WordPress-Einstellungen unter Einstellungen > Diskussion im Administrationsbereich (Backend) per Mail benachrichtigt. Manuelle Kommentare waren dann freizuschalten bzw. bei bereits bestätigten Kommentatoren wie Dir erscheinen direkt. :-)
10. März 2010, Sergej Müller schreibt: Dieter, du verwöhnst mich aber wirklich - Danksagung auf dem höchsten Niveau. Ich danke dir. Im Hintergrund forsche ich an dem Plugin weiter, experimentiere und teste. Wir sind noch nicht am Ziel, aber gut drauf unterwegs ;)
10. März 2010, Dieter schreibt: @Sergej Ehre, wem Ehre gebührt. Inzwischen ist für mich Antispam Bee perfekt. Bei meinen übrigen WordPress-Installationen werde ich ebenfalls Akismet deaktivieren und nur noch Antispam Bee als Antispam-Plugin einsetzen. Ich weiß überhaupt nicht, was Du da noch forschen, experimentieren und testen könntest. Für mich ein weiterer Beleg für Deinen Ideenreichtum. Bin schon jetzt gespannt wie ein Flitzebogen, welche Pfeile Du da noch gegen die Spamplage abschießen wirst.
8. April 2010, plerzelwupp schreibt: Also ich verfahre da wie Du und nutze auch "nur" AntispamBee. Die Einstellungen sehen bei mir zwar ein klein wenig anders aus, doch verrichtet die Biene auch bei mir saubere Arbeit. Ein paar zusätzliche Regeln hab ich in der WordPress Kommentar-Blacklist erstellt, da ich zuletzt mit "essays", "supremessays" usw. zugemüllt wurde. Das sind aber wirklich ein paar "durchgerutschte" Ausnahmen. Aber vielleicht wäre das auch ein kleiner Denkanstoß für Sergej, eine kleine Schnittstelle zur WP-White- und Blacklist zu schaffen (direkt im Plugin). Ansonsten brauch ich keine zusätzliche Software oder Captchas gegen Spam. Die leichte Biene reicht vollkommen aus.
8. April 2010, Dieter schreibt: @plerzelwupp Auch ich nutze neben Antispam Bee und der .htaccess-Datei zudem die WordPress interne Blacklist. Bei mir sieht sie aktuell wie folgt aus: mail.ru rambler.ru profiles.friendster.com/ casino dealerbeat.com unlock iphone unlockiphone22.com Ich werde sie bestimmt weiter ergänzen. Whitelist als WordPress-interne Funktion kenne ich nicht. Hast Du da ein WordPress-Plugin im Einsatz? Bei mir hat - wie bereits im Blogbeitrag geschrieben - Antispam Bee keinen Spamkommentar durchrutschen lassen. Das gilt auch weiterhin.
8. April 2010, plerzelwupp schreibt: Eben kam ein Kommentar per E-Mail an, den ich hier noch nicht sehe. Nun - ich sag's mal in's Leere. Mit der Whitelist hab ich mich getäuscht - da war ich wohl zu schnell. Ich selbst nutze nur die Blacklist - das andere Feld ist dafür da, um Kommentare in direkt in die Moderation zu verschieben. Da hab ich mich gerade nochmals vergewissert. Bei mir stehen in der Blacklist Begriffe wie: supremeessays.com primedissertations essaysprofessors gogetessays master-dissertations essayslab quality-papers.com rate-loans primeessays primewriting essays Ich hoffe, dass diese Worte keine der legitimierten Benutzer in den Mund nimmt. ;-)
8. April 2010, Dieter schreibt: @plerzelwupp Ursächlich für den nicht direkt zu sehenden Kommentar dürfte das hier eingesetzte WordPress-Plugin DB Cache Reloaded sein. Ich werde mal schauen, ob sich dieses Caching-Problem beheben lässt. Zur Blacklist: Ich hatte bisher einen ganzen IP-Bereich wegen eines automatischen Keyword-Spamers mit lowest-rate-loans gesperrt. Nun tauchen trotzdem schon wieder Spams von diesem Spamer bei den von Antispam Bee als Spam erkannten Kommentaren auf. Ich habe deshalb dieses Wort nun ebenfalls in die Blacklist aufgenommen. Und natürlich hoffe ich, dass auch hier kein normaler Kommentarscheiber eines dieser Worte verwendet.
9. April 2010, Sergej Müller schreibt: Ich plane in einer der kommenden Version, eine Kontinentalprüfung einzubauen. Damit meine ich Folgendes: Man kann als Plugin-Admin bestimmte Regionen als eigenständige Blacklist festlegen (z.B. RU und/oder CN). Der Kommentator bzw. sein Herkunftsland wird beim Abschicken des Kommentars mit dieser Liste abgeglichen. Denn: Ein in China oder Russland verfasster Kommentar hat als Reaktion auf einem deutschsprachigen Blog sehr, sehr selten etwas Sinnvolles zu suchen. Gibt natürlich Ausnahmen bei dem Muster, aber als Option in den Plugin-Einstellungen macht die Funktion sicher eine gute Figur und würde jede Menge Spam abfangen. Grüße vom Entwickler, Sergej
10. April 2010, Dieter schreibt: @Sergej Das klingt sehr interessant. Zwar kann man theoretisch auch die IP-Bereiche für bestimmte Länder mittels .htaccess-Datei blockieren, aber das bläht die .htaccess-Datei wohl kräftig auf und kann die Performance der Website beeinträchtigen. Ich bin sehr gespannt und stelle mich auch gerne als Beta-Tester zur Verfügung.
11. April 2010, Sergej Müller schreibt: Genau, die Regeln der htaccess werden auf jeden Request angewandt. Da macht eine Prüfung nur beim Absenden eines Kommentar mehr Sinn und sorgt für mehr Effizienz.
11. April 2010, Dieter schreibt: @Sergej Das verspricht eine weitere intelligente Lösung aus der WPCoder-Schmiede zu werden. Ich freue mich schon jetzt wie ein kleiner Junge auf Weihnachtsgeschenke darauf. :-)
30. Mai 2010, dirk schreibt: Ich würde ganze Länder nicht sperren. Es gibt z.B. viele Expats, die im Ausland leben und sich aus Langeweile den ganzen Tag im Internet herumtreiben. Spamvermeidung ist wichtig, aber ganze Länder würde ich niemals kicken wie es Sergej gerne machen würde.
30. Mai 2010, Dieter schreibt: @dirk Sergej plant das als Option anzubieten. Das ist in meinen Augen eine sinnvolle Erweiterung. Warum? Weil es Blogs gibt, die mit Spam aus bestimmten Ländern überschwemmt werden. Russland und China sind insoweit nach meiner Erfahrung leider führend. Da werden dann - wenn ich das richtig verstanden habe - alle Kommentare von Besucher einschließlich Expats aus aktivierten (!) Blacklist-Ländern restriktiver gehandhabt werden können (!). In Abhängigkeit davon, ob der Antispam Bee-Nutzer die Option "Spam markieren, nicht löschen" aktiviert hat oder nicht, kann er manuell nachsteuern oder nicht. Das Aufrufen der Webseiten ist dagegen weiterhin möglich. Damit ist diese Spamschutz-Maßnahme auch nicht so heftig wie eine länderbasierte IP-Sperre mittels .htaccess-Datei. Deren Vorteil ist jedoch, dass sie zugleich auch gut vor Hackerangriffen aus solchen Ländern schützt. Der einzelne Antispam Bee-Nutzer muss halt die Vor- und Nachteile abwägen, die mit dem Aktivieren dieser Länderoption verbunden sind. PS: Ich habe Deinen Link entfernt, da ich kein Impressum finden konnte, dass Dich als Betreiber des verlinkten Blogs ausweist. Da bin ich konsequent!
30. Mai 2010, Sergej Müller schreibt: Steht dabei auch jedem frei, ob er das macht oder nicht. Eine Option hat die Eigenschaft, abgewählt zu werden. Wobei in den Standard-Einstellungen diese eh nicht aktiv ist, müsste also vom Blogger aktiv hinzugeschaltet werden. Mit all seinen Bedenken im Hintergrund.
30. Mai 2010, Dieter schreibt: @Sergej Herzlichen Dank für Deine kompetente Erläuterung. Ich finde es gut, das Du beabsichtigst, die Länder-Blacklist nicht als Standard-Einstellung zu aktivieren.
30. Mai 2010, Sergej Müller schreibt: Würde ich nie machen, da die Funktion schon eher was für Blogs mit extrem viel Spamaufkommen ist - "Normalsterbliche" brauchen sie eigentlich nie. Selbst in meinen Tests hat der Länderfilter lediglich 5% vom Gesamtspam aussortiert, den Rest haben bereits implementierte Methoden zuverlässig erkannt. Auf Twitter hast du sicherlich mitbekommen, dass ich noch eine weitere Abwehrtechnik eingebaut habe, auf die ich echt stolz bin. Stichwort "Honig für Biene" ;)
30. Mai 2010, Dieter schreibt: @Sergej Ja, auf Twitter habe ich mitbekommen, dass Du und die Biene Honig mögen. Ich bin aber zuversichtlich, dass Du bald das Geheimnis lüften wirst. Oder habe ich da schon etwas verpasst?
30. Mai 2010, Sergej Müller schreibt: Ich hatte den Screenshot gezeigt und den Link in die Doku gesetzt, wo ich die zukünftigen Funktionen bereits ausführlich beschreibe. Das Update erscheint dann die Tage. Vielleicht am Dienstag.
30. Mai 2010, Dieter schreibt: @Sergej Screenshot hatte ich gefunden, indem ich Deine Tweets der letzten Tage durchgegangen war. Doku hatte ich noch nicht nachgesehen, aber natürlich jetzt mal gleich nachgelesen. Klingt richtig gut.
10. April 2011, Rolf schreibt: Also ich persönlich hatte noch keine Probleme mit Spam, aber das liegt wohl am Bekanntheitsgrad des Blogs. Gut zu wissen, dass es eine Möglichkeit gibt dem entgegen zu wirken. Danke für den Artikel!!!! Gruß Rolf
10. April 2011, Dieter schreibt: @Rolf Auch inwieweit man seine Blogbeiträge über Pingdienste bekannt macht, spielt für das Spamaufkommen eine Rolle. Denn viele Spammer scheinen auf Pingdienste als Informationsquelle zurückzugreifen. Gruß zurück Dieter
21. Dezember 2011, Empfehlenswerte externe Dienste | Webseiten-Infos.de schreibt: [...] auf das WordPress-Plugin Antispam Bee von Sergej Müller (siehe hierzu meinen Blogbeitrag “Spam-Schutz nur mit Antispam Bee“). Deshalb habe ich Akismet in der Aufzählung dieses Blogbeitrags [...]

Webseiten-Infos.de auf WordPress 2.9.2 aktualisiert

Dieter — Tue, 16 Feb 2010 20:39:27 +0000

Seit gestern ist WordPress in der Version 2.9.2 verfügbar (siehe hierzu die Beiträge “WordPress 2.9.2 veröffentlicht” im Blog von WordPress-Deutschland.org und “WordPress 2.9.2 ist da” bei perun.net sowie den Beitrag “WordPress 2.9.2” im WordPress-Blog).

Da es sich um ein kleines Sicherheitsrelease handelt, habe ich Webseiten-Infos.de zeitnah von WordPress 2.9.1 auf 2.9.2 aktualisiert. Dies obwohl mich diese Sicherheitslücke derzeit nicht betrifft, denn neben mir gibt es keine anderen Autoren auf Webseiten-Infos.de und laut dem Blogbeitrag von WordPress-Deutschland.org und Vladimir Simovic (Perun) ist lediglich eine entsprechende Sicherheitslücke geschlossen worden. Ich zitiere vom Blogbeitrag auf WordPress-Deutschland.org:

Diese Version ist ein Sicherheitsrelease und behebt einen Fehler durch den es unter Umständen möglich ist auf Beiträge anderer Autoren, die sich im Papierkorb befinden, zuzugreifen.

Erst hatte ich das Update auf dem Server mit einer Testinstallation von WordPress ausprobiert.

Normalerweise sichere ich bei Updates erst einmal die Dateien und Datenbank. Da es sich aber um ein kleines Sicherheitsrelease mit wenigen Dateien und ohne Änderungen an der Datenbank handelt, habe ich es wie Vladimir Simovic (Perun) getan und die Update- und zusätzlich die neuen Sprachdateien nach Aktivierung des Plugins “!Wartungsmodus” von Frank Bueltge einfach hochgeladen, sprich “drübergebügelt”.

Die ganze Prozedur dauerte mit allen vier WordPress-Installationen und einer Testinstallation insgesamt lediglich eine Viertelstunde.

Da verzichtete ich gerne auf das automatische Update über den Administrationsbereich (das Backend).

Diesmal wurden auch die Smilies nicht überschrieben, so dass ich die eingesetzten GreenSmilies nicht wieder in die Unterordner wp-includes/images/smilies kopieren musste. Auch die Datei cron.php im Ordner wp-includes blieb diesmal unberührt.

Obwohl es sich lediglich um eine kleine Sicherheitslücke handelt, die zudem nur bei mehreren Autoren relevant ist, empfehle ich allen WordPress-Nutzern das Update möglichst zeitnah vorzunehmen.

Kommentare

16. Februar 2010, Jeffrey schreibt: Mich betrifft die Lücke eigentlich auch nicht, doch ich werde das Update in den nächsten Tagen (manuell, so wie du) einspielen.
16. Februar 2010, Dieter schreibt: @Jeffrey Ja, Vorsicht ist die Mutter in der Porzellankiste. ;-) Schön, dass ich mit dieser Denke nicht allein bin. Kann ja sein, dass sich plötzlich Mitautoren finden und dann wäre diese Sicherheitslücke relevant.
16. Februar 2010, Jeffrey schreibt: @Dieter Auf jeden Fall :) Ich installiere die Updates von WordPress generell (je nach Typ) meist innerhalb von einer Woche. Der Vorgang dauert in den meisten Fällen ja eh nicht mehr wie 10 Minuten.
17. Februar 2010, Dieter schreibt: @Jeffrey Ich installiere nur Sicherheitsupdates meist innerhalb weniger Tage. Bei den größeren Versionswechsel mit neuen Funktionen und ohne Sicherheitsupdate wie beispielsweise von 2.8.6 auf 2.9 warte ich regelmäßig das erste Bugfix-Release ab (z.B. 2.9.1). Ich habe die Erfahrung gemacht, dass die größeren Versionsnummern oft noch "Kinderkrankheiten" haben.
19. Februar 2010, WordPress-Update 2-9-2 | Internet und Webpromotion schreibt: [...] mit dem Update, die Sicherheit in Verbindung mit dem Papierkorb wiederhergestellt sei. Dieter von Webseiten-infos.de führte das Update trotzdem durch, obwohl die Sache mit dem Papierkorb sein Blog gar nicht [...]

RSS-Feed auch für statische Seiten

Dieter — Sun, 14 Feb 2010 13:30:15 +0000

Aktuell bin ich zwecks Minimierung der Ladezeit eher geneigt die Zahl meiner WordPress-Plugins möglichst zu reduzieren.

Eine Ausnahme machte ich allerdings heute. WordPress bezieht die “statischen” Seiten nicht in seinen RSS-Feed ein.

Sofern Du mit WordPress lediglich ein Blog betreibt, ist das völlig in Ordnung. Setzt Du aber WordPress als klassisches Content-Management-System (CMS) ein, wie ich hier auf webseiten-infos.de, dann fehlt der RSS-Feed für “statische” Seiten.

Meines Wissens gibt es in WordPress noch keine Einstellungsmöglichkeit dafür. Aber es gibt ja die Suchmaschine meines Vertrauens und Tausende von Plugins für WordPress. Und siehe da, ich wurde fündig.

Das WordPress-Plugin RSS Includes Pages fügt die “statischen” Seiten ebenfalls dem RSS-Feed dazu. Einfach aus dem Plugin-Verzeichnis von WordPress installieren und aktivieren. Einstellungsmöglichkeiten gibt es keine und sind auch nicht erforderlich.

Gegebenenfalls musst Du noch beim RSS-Reader die Feeds aktualisieren, damit bereits veröffentlichte “statische” Seiten ebenfalls sichtbar werden.

Kommentare

14. Februar 2010, Fritz schreibt: Hm, das versteh' ich nicht recht. Statische Seiten sind Seiten, die einmal veröffentlich wurden, und sich nie mehr ändern. Also z. B. Blogposts. Und um die in deinem Feed zu veröffentlichen, braucht WordPress doch wohl kein Plugin? Oder denkst du bei statische Seiten an Sachen wie Kontakt, Impressum usw.? Dann versteh' ich wieder nicht, was die in einem Feed zu suchen haben. Ich bin mir sicher, dass du mich aufklären wirst.
14. Februar 2010, Dieter schreibt:
Statische Seiten sind Seiten, die einmal veröffentlich wurden, und sich nie mehr ändern.
Soweit die Theorie. Zum einem sind statische Seiten auf Webseiten-infos.de wie beispielsweise Suchmaschinenoptimierung (SEO) sehr wohl auch gelegentlich zu aktualisieren und zum anderen, tauchen sie sonst überhaupt nicht in den RSS-Feeds auf. Das spricht m.E. schon für den Einsatz des Plugins RSS Includes Pages. Das Ganze ist halt dem Umstand geschuldet, dass ich WordPress hier auch als "klassisches" Content-Management-System (CMS) einsetze. Blogbeiträge wie dieser Blogbeitrag sind dagegen automatisch im RSS-Feed.
Oder denkst du bei statische Seiten an Sachen wie Kontakt, Impressum usw.?
Diese Seiten sind bei mir auch mit "statischen" Seiten realisiert. So gesehen, ist das suboptimal und wäre es nicht verkehrt, wenn man diese Bestandteile der Basisinavigation gesondert von den RSS-Feeds ausschließen könnte. Hast Du da eine Idee? An den Seiten der Basisnavigation verändere ich aber in der Tat selten etwas, so dass deren in der Regel einmaliges Erscheinen in den RSS-Feeds zu verkraften sein dürfte.
Ich bin mir sicher, dass du mich aufklären wirst.
Ich hoffe, das trug zur Aufklärung bei.
18. Februar 2011, Name-gelöscht schreibt: Danke, ich finde den Tipp ausgezeichnet. Z.B. habe ich auf meiner Seite ein wachsendes Photovoltaiklexikon mit statischen Seiten - da das aber auch immer wieder auf die aktuellen Entwicklungen reagiert, möchte ich gern, dass die Lexikonartikel in meinem Newsfeed sind. Deshalb habe ich das Plugin gerade heruntergeladen. Ich bin gespannt, wie es sich macht. Die Einstellmöglichkeit, bestimmte Seiten (Impressum usw.) auszuschließen, fände ich allerdings nicht übel. Vielleicht findet sich ein PHPler, der weiß, wo/wie man die entsprechende !(is_page(xy)) einbaut? Dann wäre das Plugin wirklich perfekt.
19. Februar 2011, Dieter schreibt: Das Einfachste ist es dem Entwickler vorzuschlagen sein Plugin entsprechend zu erweitern. Auf seiner Seite zum Plugin findest Du übrigens einen Lösungsvorschlag mit einem weiteren Plugin, der mit WordPress 2.9.2 erfolgreich getestet wurde. Ob es auch mit der aktuellen WordPress-Version funktioniert, musst Du selbst ausprobieren.
19. Februar 2011, Solarfan schreibt: Danke, Dieter, für die schnelle Antwort! Ich habe das Plugin sofort installiert - laut Entwickler (unter http://coffee2code.com/wp-plugins/stealth-publish/ ) ist es inzwischen bis WP 3.05 getestet. Installation und Integration verlief problemlos - ob es auch im RSS-Feed funktioniert, wird man sehen. Falls nicht, ergänze ich die Info hier noch.
19. Februar 2011, Dieter schreibt: Danke für Deine Rückmeldung! Drücke die Daumen, dass das Plugin auch mit dem RSS-Feed funktioniert.
19. Februar 2011, Solarfan schreibt: Danke. Off topic und nebenbei - was hast du gegen Photovoltaik-Websites? Ich frage wegen der Namenslöschung. Aber verstehe mich nicht falsch: Ich beschwere mich nicht. Dein Blog - deine Regeln. Ich finde es nur ungewöhnlich.
19. Februar 2011, Dieter schreibt: OT: Ich habe nichts gegen Photovoltaik und entsprechende Websites. Vielmehr habe ich sogar mal im Bundesumweltministerium gearbeitet und bin ein Freund der regenerativen Energiegewinnung. Allerdings sind meine Kommentarregeln streng. Keywords im Namen des Kommentierenden akzeptiere ich grundsätzlich nicht. Je nach Qualität des Kommentars gibt es da im Regelfall folgende Reaktionen von mir: - Kommentar wird nicht freigegeben, sondern gelöscht. - Kommentar wird freigegeben, aber Name wird in Name-gelöscht geändert, Link entfernt und URL unter Einstellungen -> Diskussion den zu moderierenden Kommentaren hinzugefügt. Das ist in der Tat ungewöhnlich, da eher selten. Gründe dafür gibt es aber auch. Insbesondere vermeiden - von schlechter Nachbarschaft (bad neighbourhood) und - von Kommentaren wegen Backlinks mit SEO-Keywords.

Webseiten-Infos.de auf WordPress 2.9.1 aktualisiert

Dieter — Tue, 12 Jan 2010 21:18:40 +0000

Seit einer Woche ist WordPress in der Version 2.9.1 verfügbar (siehe hierzu den Beitrag “WordPress 2.9.1 veröffentlicht” im Blog von WordPress-Deutschland.org und meinen Blogbeitrag “WordPress 2.9.1 verfügbar“).

Nun habe ich Webseiten-Infos.de von WordPress 2.8.6 auf 2.9.1 aktualisiert.

Zuvor hatte ich das Update auf dem Server mit einem Testblog ausprobiert. Natürlich habe ich auch dort erst die Dateien und Datenbank gesichert. Beim Testblog funktionierte aber das automatische Update über den Administrationsbereich (das Backend) nicht. Also führte ich das Update dort manuell durch (siehe hierzu die Doku Upgrade auf wordpress-deutschland.org).

Erfreulicherweise klappte das dann auf dem Testblog. Statt alle Plugins zu deaktivieren, aktivierte ich lediglich das Plugin “!Wartungsmodus” von Frank Bueltge. Gleichwohl gab es keine Probleme mit meinen vielen Plugins. Allerdings gab es in den letzten Wochen auch auffällig viele Updates von Plugins. Dabei wurden auch einige Plugins noch mit WordPress 2.9.x kompatibel gemacht.

Auf Webseiten-Infos.de funktionierte dann sogar das automatische Update über den Administrationsbereich (das Backend). Lediglich die eingesetzten GreenSmilies habe ich wieder in die Unterordner wp-includes/images/smilies kopiert und in der Datei cron.php im Ordner wp-includes habe ich vorsorglich in Zeile 229 den Wert 0.01 durch 1 ersetzt (siehe hierzu auch meinen Blogbeitrag “Pingback-Problem bei WordPress 2.7 beheben“).

Auch diesmal bin ich mit meiner Strategie gut gefahren, mit dem Update auf eine neue Version von WordPress etwas zu warten, wenn sie lediglich neue Funktionen mitbringt, aber keine Sicherheitslücken schließt. Das war hier mal wieder der Fall. Deshalb habe ich die Version 2.9 übersprungen (zu dieser Version und den Update-Problemen siehe meine Blogbeiträge “WordPress 2.9 erschienen” und “Problemlösungen für Update auf WordPress 2.9“).

Und nun bin ich mal gespannt, ob die Webseiten von Webseiten-Infos.de mit WordPress 2.9.1 wirklich schneller im Browser zu sehen sind. Einige Nutzer von WordPress berichteten davon, dass die Version 2.9 schneller sein sollte. Schön wäre es ja.

Wer Probleme beim Update hat, dem empfehle ich das Forum von wordpress-deutschland.org zu nutzen. Da fand ich schon oft eine Lösung oder einen Hinweis darauf und wurde mir bereits häufig geholfen.

Kommentare

15. Januar 2010, Alex L. schreibt: Hi Dieter, willkommen im Club bei den WordPresslern von 2.9.1 :) Ich konnte auch nur bei der WP-Installation auf dem Testblog automatisch updaten. In meinem eigentlichen Blog gings nur manuell. Ob die jetzige Version viel schneller geworden ist, kann ich genau nicht beantworten und langsamer ist es meiner Ansicht nach nicht geworden. Du hast ja jetzt auch hier 2.9.1 und wie schaut es bei dir mit den bloginternen Pingbacks und Pingbacks/Trackbacks zu anderen Blogs aus?
16. Januar 2010, Dieter schreibt: Hi Alex,
willkommen im Club bei den WordPresslern von 2.9.1 :)
Danke. Es war die Zeit gekommen... ;-)
Ich konnte auch nur bei der WP-Installation auf dem Testblog automatisch updaten. In meinem eigentlichen Blog gings nur manuell.
Alex, bei mir war es auf Webseiten-Infos.de genau anders herum. Ich habe die vage Vermutung, dass das etwas mit meinem htaccess-Passwortschutz für die Testinstallation zu tun hat.
Ob die jetzige Version viel schneller geworden ist, kann ich genau nicht beantworten und langsamer ist es meiner Ansicht nach nicht geworden.
Also meine Geschwindigkeitsmessungen für die Webseiten (Frontend) haben bisher keine auffälligen Geschwindigkeitsänderungen zutage gefördert. Beim Administrationsbereich (Backend) habe ich aber schon den Eindruck, dass die Seiten sich etwas schneller aufbauen, sprich das Ganze etwas flüssiger wirkt.
Du hast ja jetzt auch hier 2.9.1 und wie schaut es bei dir mit den bloginternen Pingbacks und Pingbacks/Trackbacks zu anderen Blogs aus?
Habe ja auch wieder die Änderung bei der cron.php vorgenommen, wenn auch nur vorsorglich. Pingbacks/Trackbacks scheinen zu funktionieren. Einzige mir bisher aufgefallene Ausnahme war der Pingback/Trackback zu Deiner Seite. :confused: Da frage ich mich inzwischen schon, ob das vielleicht an Deiner Seite als Empfänger gelegen hat. Was denkst Du? Könnte das sein?
16. Januar 2010, Alex L. schreibt: Zusätzlich habe ich noch auf meinem Webspace bei All-inkl. in der WP-Installation unter wp-settings.php das Memory-Limit von 96 MB auf 128 MB erhöht. Vorher waren es dort 32 MB und das war mir alles zu langsam. Immerhin habe ich einiges an Plugins, welche bestimmt etwas Speicher in Anspruch nehmen. Aber das läuft jetzt ganz gut, ausser das die Kommentar-Vorschau im neuen Theme nicht mehr funktioniert. Ich habe diese Funktion so gemocht. Ja du, es kann durchaus sein, dass meine eigene WP-Installation bei den eingehenden Pingbacks/Trackbacks schlecht abschneidet. Aber wie finde ich es heraus? Ich weiss, dass sogar die TBs von Blogger.com ankamen und interne Verlinkungen als Pingback funktionieren. Würde dir was ausmachen, den letzten Beitrag wo du mich verlinkt hattest, den Artikel nochmal zu aktualisieren. Vll. klappt es jetzt mit dem TB, da ich auch ein anderes Blogtheme habe. Es kann ja alles Mögliche sein. Ansonsten tappe ich wegen diesen TBs im Dunkeln :(. Muss ich wohl so akzeptieren, da es ja doch ein vereinzeltes Blogproblem ist.
16. Januar 2010, Dieter schreibt:
Zusätzlich habe ich noch auf meinem Webspace bei All-inkl. in der WP-Installation unter wp-settings.php das Memory-Limit von 96 auf 128 MB erhöht.
Wow, ich habe das WordPress-Memory-Limit von meinen WordPress-Installation bei alfahosting.de unter wp-config.php "nur" auf 64 MB erhöht. Im Backend meines Kundenbereichs bei Alfahosting.de kann ich für alle PHP-Anwendungen das PHP-Memory-Limit bis auf 48 MB einstellen. Das würde wegen des fast doppelten Speicherbedarfs von 64bit-Systemen (siehe hierzu meinen Blogbeitrag "Ursache des enormen Speicherbedarfs gefunden!") aber dort für WordPress nicht reichen. Mit 64 MB komme ich jedoch gut hin. Plugins wie TPC! Memory Usage und WP System Health zeigen mir einen PHP-Speicherbedarf im Administrationsbereich (Backend) von etwa 54 MB (also rd. 85%) an. Interessant, dass Du das Speicherlimit in der wp-settings.php festlegst, während ich die wp-config.php verwende. Hast Du da eine Quelle für die Nutzung der wp-settings.php? Mir war bisher diese Datei noch nie aufgefallen.
Vorher waren es dort 32 MB und das war mir alles zu langsam. Immerhin habe ich einiges an Plugins, welche bestimmt etwas Speicher in Anspruch nehmen.
32 MB funktioniert bei mir auch nur bei one.com. Ein Blog dort muss sogar noch mit 24 MB auskommen. Das schränkt natürlich den Einsatz von Plugins ein. Zudem ist da automatisches Update von WordPress und selten auch von einem Plugin nicht möglich. Grrh! Aber der Umzug der Seiten bei one.com zu alfahosting.de ist in Vorbereitung. :-)
Aber das läuft jetzt ganz gut, ausser das die Kommentar-Vorschau im neuen Theme nicht mehr funktioniert. Ich habe diese Funktion so gemocht.
Ich mag auch eine Kommentar-Vorschau, allerdings bin ich nicht dafür bereit Geschwindigkeitseinbußen hinzunehmen. Dass Du schon wieder das Theme gewechselt hast, dürfte für das baldige Wiedererlangen eines grünen Balkens nicht förderlich sein, zumal Deine Webseiten dadurch anscheinend noch mehr Validierungsfehler aufzuweisen scheinen. Auch die Verwendung von (i)Frames könnte sich da ungünstig auswirken, ist aber auf jeden Fall unter dem Gesichtspunkt der Zugänglichkeit (Accessibility) nachteilig.
Würde dir was ausmachen, den letzten Beitrag wo du mich verlinkt hattest, den Artikel nochmal zu aktualisieren.
Macht mir nix aus und habe ich vor einigen Minuten erledigt (Blogbeitrag "Google PageRank-Update Dezember 2009" mit Pingback zu Deinem Blogbeitrag "Pagerank-Update zum Jahresausklang 2009"). Ich hoffe, nun ist der Trackback/Pingback angekommen. Wenn nicht: Schau mal im Forum von WordPress-Deutschland.org nach, ob dort schon mal Dein Problem behandelt wurde. Falls nein, kannst Du ja dort mal nachfragen. Dort ist mir schon oft weitergeholfen worden.
19. Januar 2010, Alex L. schreibt: Hi Dieter, der Wert in der wp-settings.php zeigt so wie ich es hier und da gelesen habe, die vom Webhoster aus festgelegte Speichergrenze. Es standen bei mir bei All-inkl. immer 32 MB und ich habe mit jeder WP-Version versuchsweise immer wieder erhöht. Die Veränderungen zeigt mir deinerseits gemeintes Plugin ja auch und meine WP-Installation mit dem ganzen Kram verbraucht 56.18 MB(also fast wie bei dir). Dass man das Speicherlimit mittels wp-config.php festlegt weiss ich, aber irgendwie hatte ich es bisher unter der wp-settings.php geändert. Ist das dann falsch? Die Speicherwert-Korrektur wird mir ja durch das Plugin "System Health" angezeigt. 64 MB reichen scheinbar auch aus. 24 MB Speicher zur Verfügung zu haben, vor allem mit einer WP-Installation, das ist sehr hart und knapp. Das muss ich schon zugeben. Das mit dem neuen Theme lasse ich erstmal. Ich habe nun vermutet, dass zu viele Schwarztöne im alten Theme die Werbekunden abschrecken könnten.(es hat an allen Ecken nachgelassen, aber wohl auch mitunter wegen dem PR-Abfall) Jetzt sind es viel angenehmere Farben im Blog zu sehen. Danke für die Hinweise und das wird nicht mein letztes Theme sein. Derzeit lädt es ganz gut, was mir Google Page Speed zeigt. Ja, das mit dem Green-Balken schiebe ich erstmal auf die lange Bank und wenn es zum Grün kommt, werde ich mich natürlich freuen. Wenn nicht, auch egal. Mit den Trackbacks ist das mal wieder eigenartig. TBs anderer Blogs kommen an, soweit ich weiss. Diese Problematik muss ich mir mal ernsthaft rannehmen. Dennoch Danke, dass du es mit dem TB ein erneutes Mal versucht hast. Zwar vergebens, aber ich weiss, dass es nun wahrscheinlich an meinem WP liegen könnte.
27. Januar 2010, Dieter schreibt: Hi Alex,
der Wert in der wp-settings.php zeigt so wie ich es hier und da gelesen habe, die vom Webhoster aus festgelegte Speichergrenze.
Habe erst jetzt wahrgenommen, dass in der wp-config.php die wp-settings.php aufgerufen wird. Habe in die wp-config.php Folgendes geschrieben: define('WP_MEMORY_LIMIT', '64M'); Das geht anscheinend wegen der if-Abfrage der Einstellung in der wp-settings.php vor, die danach aufgerufen wird: if ( !defined('WP_MEMORY_LIMIT') ) define('WP_MEMORY_LIMIT', '32M'); Wieder etwas dazu gelernt. :-)
24 MB Speicher zur Verfügung zu haben, vor allem mit einer WP-Installation, das ist sehr hart und knapp. Das muss ich schon zugeben.
Deshalb kann ich derzeit das Blog auf Jurafernstudium.de nicht von WordPress 2.8.6 auf 2.9.1 aktualisieren. :-( Aber: Ich beabsichtige eh einen Relaunch und werde den dann mit einem Umzug von one.com auf alfahosting.de verbinden.
Das mit dem neuen Theme lasse ich erstmal.... Danke für die Hinweise und das wird nicht mein letztes Theme sein. Derzeit lädt es ganz gut, was mir Google Page Speed zeigt.
Ja, internetblogger.de lädt jetzt nicht mehr so langsam. Empfinde ich auch mit DSL 6000 als deutlich angenehmer.
Mit den Trackbacks ist das mal wieder eigenartig. TBs anderer Blogs kommen an, soweit ich weiss. Diese Problematik muss ich mir mal ernsthaft rannehmen. Dennoch Danke, dass du es mit dem TB ein erneutes Mal versucht hast. Zwar vergebens, aber ich weiss, dass es nun wahrscheinlich an meinem WP liegen könnte.
Das ist in der Tat sehr seltsam, zumal bei mir alle anderen Trackbacks anzukommen scheinen. Nur wer die Trackback-Funktion deaktiviert bzw. ganz herausgeworfen hat wie beispielsweise Thomas Scholz aka toscho zeigt auch keine Trackbacks.

Kommentarvorschau deaktiviert

Dieter — Fri, 18 Dec 2009 20:27:38 +0000

Erst vor zwei Monaten hatte ich auf Webseiten-Infos.de eine Kommentarvorschau eingerichtet. Diese basiert auf dem WordPress-Plugin Live Comment Preview (siehe hierzu meinen Blogbeitrag “Kommentarvorschau auf Webseiten-Infos.de“).

Da ich damals die Funktion mit einer if-Abfrage in die Template-Datei comments.php eingebunden hatte, gab es beim Deaktivieren des Plugins keine Probleme.

Aber warum habe ich diese Funktion deaktiviert?

Drei Gründe:

Die Vorschau flackerte bei viel Text und es war dann nur noch schwer möglich den Mauszeiger (Cursor) an das Ende des Kommentarfeldes zu setzen.
Die Kommentarvorschau ist zwar nett (nice to have), aber keine zwingend erforderliche Funktionalität. Die Implementierung der Kommentarvorschau führte nicht zu einer auffälligen Änderung bei der Anzahl oder Qualität der Kommentare auf Webseiten-Infos.de.
Gewichtiger und ausschlaggebend war für mich aber, dass das Plugin die Ladezeit der Webseiten mit Kommentarfeld um über eine halbe Sekunde verlängerte. Ursächlich hierfür war das zusätzlich zu ladende JavaScript. Das stellte ich mit dem Addon Firebug für den Browser Firefox fest. Ich hatte zwar im JavaScript die Kommentare und überflüssigen Leerzeichen entfernt, aber die Ladezeit verkürzte sich dadurch leider nicht nennenswert.

Wie auch immer, nun ist die Kommentarfunktion wieder weg und Webseiten-Infos.de ist noch besser für einen möglichen Bonus bei den Suchergebnissen mit der neuen Google Caffeine Suchmaschine gerüstet.

Mag sein, dass ich den Eindruck eines Geschwindigkeitssüchtigen vermittle, aber Geschwindigkeit zählt (speed matters). Dies zeigt auch die Einführung von Website-Leistung unter Google Labs in den Google Webmaster Tools (siehe hierzu auch die Blogbeiträge “Wie schnell ist meine Site?” und “Anzeige der Website-Performance in den Webmaster-Tools” bei der Google Webmaster-Zentrale).

Findest Du auch das Geschwindigkeit (so) wichtig ist?

Was tust Du, damit Deine Webseiten schneller laden?

Kommentare

18. Dezember 2009, Micha schreibt: Kurze Ladezeiten sind schon wichtig. Ich habe grade heute das Redesign von wpengineer.com hochgeladen. Dabei habe ich HTML Markup reduziert, CCS Bilder zu sinnvollen Sprite-Gruppen zusammengefasst. Natürlich läuft dort mein Stylesheetkompressor, der 4 CSS Dateien mit 35k zu einer mit 21k macht. Leider wirken sich die Avatare und auch die Buysellads negativ aus, aber ein ganz nacktiges Blog wollte ich nicht haben und 300$ im Monat sind mir doch etwas wichtiger als die Ladezeit ;) .
19. Dezember 2009, Dieter schreibt: Lieber Micha, das Redesign von wpengineer.com gefällt mir gut. Der Wiedererkennungswert ist erhalten geblieben. Zudem habe ich den Eindruck, dass die Seiten nun noch übersichtlicher geworden sind. Irritiert hat mich allerdings, dass das Logo nicht (mehr?) mit der Startseite verlinkt ist. Ist für mich ein Quasi-Standard, den ich gewohnt bin. Hast Du den Whitespace-Anteil (leicht) erhöht und/oder das Design simplified? Deine Maßnahmen zur Geschwindigkeitsoptimierung sind erkennbar erfolgreich (laut Firebug braucht die Startseite bei mir mit DSL 6000 nur rd. 1,5 Sekunden und laut websiteoptimization.com gibt es nur 12 HTTP-Requests). Aus meiner Sicht hast Du schon fast alle wesentlichen Optimierungsmaßnahmen für die Ladezeit von WordPress-basierte Websites im Einsatz. Trotz Avatare (Gravatare) und Buysellads lädt die Startseite von wpengineer.com erfreulich schnell. Eine WordPress-spezifische Beschleunigungsempfehlung wird es noch in einem meiner nächsten Blogbeiträge geben. Soviel sei schon mal verraten: Sie zielt auf die Reduzierung der Wartezeit für die Antwort des Servers (response time). Da besteht nach meiner Einschätzung voraussichtlich noch eine Optimierungsmöglichkeit für wpengineer.com (derzeit rd. 0,8 Sekunden). Auf Deinen Stylesheet-Kompressor, der ja in Deinem Premium-Theme zu Ehren kommen soll, bin ich genauso wie auf das Premium-Theme selbst schon sehr gespannt. Beste Grüße Dieter
19. Dezember 2009, Micha schreibt: Ja, das Logo :) Ich wollte das Logo als Image loswerden, damit bei abgeschalteten Stylesheets die Grafik nicht zu sehen ist. Der Whitespace-Anteil wurde erhöht, vorher war es ein bischen eng, vor allem in der Sidebar. Die Kommentare muß ich noch mal überarbeiten. Irgendwie gefällt mir das noch nicht so richtig...
19. Dezember 2009, Dieter schreibt: Das Logo als Hintergrund-Grafik? Dann klappt das Verlinken natürlich nicht mehr. Andererseits wird man Grafiken, auch Hintergrund-Grafiken, doch mit Grafiken ausblenden / nicht laden los. :confused: Ich hatte anfangs auf Webseiten-Infos.de sogar mal das Logo entfernt gehabt (siehe meine Blogbeiträge "Wo ist das Logo?" und "Das neue Logo ist da!"). Ute hatte mich dann aber davon überzeugt, doch wieder ein Logo einzubauen. Ja, Whitespace (Typografischer Weißraum, Leerraum) ist wohl ein, wenn nicht das mächtigste Mittel zur Gestaltung einer Website. Richtig dosiert profitiert davon jede Webseite. In der Sidebar von wpengineer.com würde ich mal mit einem noch leicht größeren vertikalen Abstand zwischen den Listenpunkten experimentieren und den Abstand von Zeilen bei mehrzeiligen Listenpunkten testweise leicht verringern. Ich muss zu meiner Schande eingestehen, dass ich auf die Schnelle mit Firebug keine entsprechenden CSS-Anweisungen gezaubert bekommen habe.
19. Dezember 2009, Micha schreibt: So Dieter, jetzt kannst du wieder wie gewohnt auf die Grafik klicken um zur Homepage zu gelangen. Ich wollte sie nicht loswerden im Sinne von nicht mehr laden. Ich wollte sie nur als Hintergrundbild um sie im print und bei abgeschalteten Stylesheets nicht mehr angezeigt haben.
19. Dezember 2009, Dieter schreibt: Micha: Danke! :-D So ist es für mich wieder vertraut. Der Mensch ist halt ein Gewohnheitstier. ;-) Ausblenden für das Drucken per CSS geht doch aber auch mit normalen Grafiken. Ist hier auf Webseiten-Infos.de im Stylesheet mit @media print {#header img {display: none}} realisiert. Nicht mehr Anzeigen bei abgeschalteten Stylesheets funktioniert allerdings wirklich nur mit Hintergrund-Grafiken. Wie hast Du denn das Logo als Hintergrund-Grafik anklickbar gemacht?
19. Dezember 2009, Micha schreibt: Nur ein Anker um den leeren Span, der die Hintergrundgrafik hält.
19. Dezember 2009, Dieter schreibt: Wow, den Kniff kannte ich noch nicht! Danke für die Erläuterung!
4. März 2010, Ulf. Mehr oder minder täglich Privatkram. schreibt: Ich HASSE diese idiotische Linkvorschau bei WordPress!... Hasst Ihr sie auch so sehr, diese aufpoppenden Vorschaufensterchen für Links, die den eigentlichen Text verdecken und schlecht lesbar machen? Meint Ihr auch, dieser Mist gehört abgeschafft? Wozu soll......

Kommentarvorschau auf Webseiten-Infos.de

Dieter — Thu, 15 Oct 2009 14:28:39 +0000

Und schon wieder gab mir Thomas Scholz aka toscho einen guten Tipp: Kommentarvorschau mit dem WordPress-Plugin Live Comment Preview.

Die Installation und Aktivierung des Plugins ist einfach:

Im Administrationsbereich (Backend) über Plugins > Installieren oder auf den Rechner herunterladen (downloaden), ZIP-Datei entpacken und mit einem ftp-Programm den Ordner live-comment-preview einschließlich der darin enthaltenen Dateien in den Unterordner wp-content/plugins/ auf Deinem Webspace kopieren.
Anschließend im Administrationsbereich (Backend) über Plugins > Verwalten das Plugin aktivieren und fertig.

Folgende Anpassungen habe ich hier am Code des Plugins (live-comment-preview.php) noch vorgenommen:

Zum einem habe ich den Code für die Darstellung des Gravatars (siehe hierzu meinen Blogbeitrag “Bild oder Foto beim Kommentar“) in der Vorschau entfernt (Zeilen 42 und 43). Bei Thomas beschwerten sich Leser, die eine langsame Internetverbindung haben: Der Gravatar wurde immer wieder neu geladen.
Das Wort “Says” habe ich in der Zeile 42 (vorher 44) gelöscht.
In der Zeile 40 habe ich die Angaben bezüglich style wie folgt geändert:
1
style="clear:both;margin:.5em 0 -1em -1em;"
In der Zeile 258 (vorher 260) habe ich in
Kommentarvorschau eingefügt:

Kommentarvorschau

Meine CSS-Datei habe ich um folgenden Code ergänzt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#commentPreview
{
margin: 0 0 1em 0;
padding: 0;
}
#commentPreview
{
border: 1px solid #736355;
background: #fff;
padding: 3px;
color: #111;
}
#commentPreview
{
width: 90%;
}

In der Template-Datei comments.php des von mir modifizierten Themes YAML Green habe ich folgende Ergänzung unmittelbar oberhalb des Codes für die Quicktags (Fett, Kursiv etc) vorgenommen, damit die Kommentarvorschau nicht unter, sondern über dem Kommentarfeld erscheint:
1
if (function_exists('live_preview')) live_preview(); ?>

Im Plugin-Verzeichnis von WordPress ist zwar nur die Kompatibilität des Plugins bis zur Version 2.5 angegeben, das dürfte aber daher rühren, dass die letzte Aktualisierung (Update) des Plugins vom April 2008 ist (Version 1.9). Bei mir scheint es aber auch mit WordPress 2.8.4 problemlos zu funktionieren.

Meinungen und Verbesserungsvorschläge für die hier nun eingesetzte Kommentarvorschau sind jederzeit gerne willkommen.

Einfach einen Kommentar schreiben.

Nachtrag:

Die Kommentarvorschau habe ich wieder deaktiviert und die Gründe in meinem Blogbeitrag “Kommentarvorschau deaktiviert” aufgeführt.

Kommentare

14. April 2010, Leo schreibt: Geniales Plugin. Hab ich auch direkt installiert.
14. April 2010, Dieter schreibt: @Leo Dann bin ich mal gespannt, wann Du es - wie ich - auch wieder deinstallierst. ;-)

Antispam Bee: Einstellungen geändert

Dieter — Sun, 20 Sep 2009 19:41:09 +0000

Von Fritz Weisshart erhielt ich per Kontaktformular den Hinweis, dass ein Kommentar von ihm als Spam zurückgewiesen wurde.

So etwas geht natürlich gar nicht! Ich hatte mich deshalb unverzüglich auf die Fehlersuche begeben. Dabei fand ich Folgendes heraus:

Dieser Fehler trat nur auf, wenn Du versucht hattest, einen Kommentar zu schreiben und die Seite noch als Suchergebnis beziehungsweise als Archivseite angezeigt wurde.

Auslöser für das Problem war meine ungewöhnliche Modifizierung des WordPress-Themes YAML Green.

Da ich bei den Archiv- und Suchergebnisseiten gleich die Blogbeiträge im Volltext anzeigen lasse, gibt es dort auch ungewöhnlicherweise bereits das Kommentarfeld (siehe hierzu den Blogbeitrag “Archiv- und Suchergebnisseiten mit Kommentarfunktion“).

Leider werden aber Kommentare, die dort geschrieben und abgesandt werden, von dem WordPress-Plugin Antispam Bee als Spam angesehen.

Im Administrationsbereich (Backend) von WordPress besteht glücklicherweise über Einstellungen > Antispam Bee die Möglichkeit dies zu ändern. Indem ich dort das Häckchen bei Spam markieren, nicht löschen setzte, werden diese Kommentare nun nicht mehr geblockt und direkt gelöscht. Vielmehr kann ich sie nun manuell genehmigen. Zwar muss ich dann auch tatsächlichen Spam manuell löschen, aber das stellt bei dem bisherigen Spamaufkommen auf Webseiten-Infos.de und aufgrund weiterer Spamschutz-Maßnahmen kein Problem für mich dar.

Nun sollte das Problem behoben sein.

Ein herzliches Dankeschön an

Fritz Weisshart für seinen Hinweis per Kontaktformular und
Sergej Müller für sein WordPress-Plugin Antispam Bee mit Einstellungsmöglichkeiten.

Kommentare

20. September 2009, Micha schreibt:
gibt es dort auch ungewöhnlicherweise bereits das Kommentarfeld.
Dieter, was hast Du denn da gebaut? ;)
20. September 2009, Dieter schreibt: @Micha Das kommt davon, wenn ich so ein flexibles WordPress-Theme auf YAML-Basis wie YAML Green in die Finger bekomme und dann mein Spieltrieb mit mir durchgeht. ;-)
20. September 2009, Micha schreibt: Das Kommentarfeld in der index.php ist glaub ich keine gute Idee.
20. September 2009, Dieter schreibt: @Micha Wieso index.php? Für Archive gibt es doch archive.php und für Suchergebnisseiten die search.php. Diese Dateien habe ich um $withcomments = 1; sowie comments_template(); ergänzt (siehe hierzu auch meinen Blogbeitrag mit dem Titel "Archiv- und Suchergebnisseiten mit Kommentarfunktion"). Ist ungewöhnlich, aber dem Umstand geschuldet, dass ich auch auf den Archiv- und Suchergebnisseiten immer die vollständigen Blogbeiträge einzeln anzeigen lasse.
21. Dezember 2011, Spamschutz nur mit Antispam Bee | Webseiten-Infos.de schreibt: [...] Wichtig für den optimalen Spamschutz Deiner WordPress-Installation ist, dass Du Dir die Beschreibungen der Funktionen von Antispam Bee durchliest und dann Deine Einstellungen vornimmst. Ich hatte das anfangs nicht beherzigt und deshalb auch ein kleines Problem mit der fleißigen Biene (siehe hierzu meinen Blogbeitrag “Antispam Bee: Einstellungen geändert“). [...]
21. Dezember 2011, Spam-Schutz auf Webseiten-Infos.de | Webseiten-Infos.de schreibt: [...] hier nur kurz ergänzend der Hinweis auf meinen Blogbeitrag “Antispam Bee: Einstellungen geändert“. Dort erkläre ich, warum ich hier auf Webseiten-Infos.de bei den Einstellungen von Antispam [...]

WordPress: Wider dem Katastrophen-Gerede

Dieter — Tue, 08 Sep 2009 18:45:29 +0000

1. Hintergrund

Auf praegnanz.de erschien am 6. September 2009 der Blogbeitrag “WordPress – wann kommt es zur Katastrophe?“.

Dazu habe ich auch bereits einen Kommentar geschrieben. Gleichwohl habe ich aufgrund der apokalyptischen Stimmung, die mit diesem Artikel und einigen der dortigen Kommentare verbreitet wird, das Bedürfnis noch selbst Position zu Vor- und Nachteilen (Pros und Cons) von WordPress zu beziehen.

Vorsorglich noch der Hinweis, dass die Auflistung von Vor- und Nachteilen natürlich subjektiv ist und nicht abschließend sein kann.

Vor diesem Hintergrund sind Aktualisierungen und Ergänzungen

aufgrund von Anmerkungen und Diskussionen in den Kommentaren sowie
Geistesblitzen

möglich. Sie werde ich dann selbstverständlich kenntlich machen.

2. Vorteile von WordPress

Die Vorteile (Pros) von WordPress im Einzelnen:

lässt sich leicht und schnell installieren (sog. 5 Minuten Installation),
erzeugt validen Code,
verfügt über eine ausgesprochen intuitive Oberfläche im Administrationsbereich (Backend),
gibt eine sehr aktive und hilfreiche WordPress-Gemeinde (Community) unter WordPress.org (englisch) und WordPress-Deutschland.org (deutsch),
ist gut dokumentiert (Codex, Handbuch und deutsche Dokumentation),
gibt viel und gute bis hervorragende Literatur dazu,
ist Open-Source-Software (kostenlos und der Quelltext ist frei, sprich öffentlich zugänglich),
gibt Hunderte von (kostenlosen) CSS-Layouts (sog. Themes) dafür,
gibt Tausende von (kostenlosen) Erweiterungen (sog. Plugins) dafür,
wächst mit meinen Bedürfnissen mit (von der reinen Blog-Software zu einem Content-Management-System (CMS)),
gibt mehrere Themes auf YAML-Basis (Blitzblank, Simplex Theme, YAML Green, YAML Coffee)
viele Arbeiten lassen sich mit WordPress und Plugins automatisieren (insbesondere Navigation, Anlegen neuer Seiten, Schlagwortwolke (tag cloud), ähnliche Artikel, Sitemap, XML-Sitemap für Suchmaschinen).

3. Nachteile von WordPress

Kommen wir zu den Nachteilen (Cons) von WordPress:

weist in der Standardinstallation - vergleichbar mit früheren Windows-Versionen - Sicherheitslücken ein defensives Sicherheitskonzept auf. Dieses lassen lässt sich jedoch durch Handarbeit sowie mit Plugins und zeitnahen Aktualisierungen (Updates) von WordPress schließen verbessern (siehe hierzu insbesondere meinen Blogbeitrag “Sicherheit von WordPress verbessern“),
gibt wegen Sicherheitslücken (siehe hierzu meine Blogbeiträge “Angriffe auf alte WordPress-Installationen” und “Kritische Sicherheitslücke in WordPress“) und Weiterentwicklungen häufig Aktualisierungen (Updates), die möglichst zeitnah vorgenommen werden sollten (siehe hierzu meine Blogbeiträge “Webseiten-Infos.de auf WordPress 2.8.4 aktualisiert“, “Webseiten-Infos.de auf WordPress 2.8.3 aktualisiert“, “Webseiten-Infos.de auf WordPress 2.8.2 aktualisiert” und “Webseiten-Infos.de auf WordPress 2.8.1 aktualisiert“),
benötigt immer mehr PHP-Speicher im Administrationsbereich (Backend), so dass aufgrund des PHP-Speicher-Limits für eine Aktualisierung (Update) ein Wechsel des Hosters notwendig werden kann (siehe hierzu meine Blogbeiträge “Ursache des enormen Speicherbedarfs gefunden!“, “Umzug zu einem anderen Webhoster” und “In eigener Sache: Umzug zu Alfahosting“),
ist im Administrationsbereich (Backend) aufgrund des massiven Einsatzes von JavaScript relativ träge. Durch den Einsatz von modernen Browsern mit einer schnellen JavaScript-Engine (wie beispielsweise aktuell Google Chrome 2 und Firefox 3.5) kann man dem etwas entgegenwirken.
Es ist schon lustig! Aktuell wird über WordPress hergezogen, weil es nicht sicher sei. Dabei ist die aktuelle Version 2.8.4 (ein Sicherheitsrelease!) von dem Wurmangriff nicht betroffen, weil mit ihr eben schnell eine Sicherheitslücke geschlossen wurde. Vor 2 1/2 Jahren stellte sich die Sicherheitsfrage viel drängender: Damals hatte es ein Cracker geschafft, sich Zugang zu einem Server von WordPress.org zu verschaffen und hatte zwei Dateien der zum Herunterladen bereitstehenden WordPress-Version 2.11 verändert (siehe dazu den Blogbeitrag “WordPress 2.1.1 und der “worst case”” bei WordPress-Deutschland.org).

4. Mein persönliches Fazit

Jeder muss selbst abwägen und entscheiden, ob sie oder er WordPress angesichts der oben genannten Vor- und Nachteile einsetzen will.
Sicherheitsmaßnahmen sind sehr wichtig. Wer nicht bereit ist dafür einschließlich zeitnahes Einspielen von Aktualisierungen (Updates) Zeit zu investieren, lebt mit einem höheren Risiko, dass seine WordPress-Installation gehackt wird. Alternativ kannst Du auch auf eine andere Software umsteigen und Du lässt gleich die Finger von eigenen Web-Anwendungen.
WordPress wird immer mehr als Content-Management-System (CMS) oder als CMS mit integriertem Blog nutzbar und auch genutzt.
Beliebte und stark verbreitete Open-Source-Software wie WordPress und der Browser Firefox werden verstärkt Ziele von Angriffen. Gefundene Sicherheitslücken werden dort aber regelmäßig schnell geschlossen. Diesbezüglich sei für den Firefox auf meinen Blogbeitrag “Sicherheitslücken: Internet Explorer besonders gefährdet” hingewiesen.

Das musste ich jetzt einfach mal raus lassen und bloggen.

Kommentare

8. September 2009, Thomas Scholz schreibt: Welche Sicherheitslücken hat denn die Standardinstallation? Hast du dazu einen Bug gemeldet? Welche Nummer hat er? Das würde ich schon gerne wissen.
9. September 2009, Dieter schreibt: @Thomas In der Standardinstallation ist - der Zugang zum Login ungeschützt aufrufbar, - wird automatisch der Nutzer Admin angelegt und - gibt es keine Begrenzung der Anzahl der Login-Versuche. Wenn man da nicht mittels - Passwortschutz über die .htacess-Datei, - Löschen des Nicks Admin, - Plugin die Anzahl der Login-Versuche begrenzt oder vergleichbare Maßnahmen ergreift, dann dürften das leider gute Rahmenbedingungen für eine Brute-Force-Attacke sein oder habe ich da als Laie einen Denkfehler? Wenn dann noch ein schwaches Passwort für den Administrator Admin gewählt wird, dann dürfte das m.E. kritisch sein. Zwar bekomme ich im Administrationsbereich (Backend) inzwischen angezeigt, ob ein Passwort schwach, mittel oder stark ist, aber ich glaube, schwache Passwörter werden von WordPress trotzdem zugelassen. Das habe ich allerdings allein schon aus Sicherheitsgründen nicht ausprobiert. ;-)
9. September 2009, Thomas Scholz schreibt: Das Paßwort, das WordPress bei der Installation erzeugt, ist schon recht stark. Es dürfte selbst mit Rainbow-Tables kaum in absehbarer Zeit zu knacken sein. Das Verstecken des Logins und das Umbenennen des Administrators fallen unter »Security by obscurity«. Kann man machen, bringt aber kaum echte Sicherheitsvorteile. Wer eine Brute-Force-Attacke wagt, der läßt sich davon nicht abschrecken. »Sicherheitslücken« sind weder der Login noch das Standardkonto, es sei denn, du führst den Beweis dafür.
9. September 2009, Dieter schreibt: @Thomas Das automatisch generierte Passwort dürften wohl die wenigsten WordPress-Administratoren belassen. Stattdessen wird dann ein eigenes Passwort gewählt, das auch schwach sein kann. Hier wäre meines Erachtens ein zusätzlicher Sicherheitsmechanismus, der den bequemen Nutzer schützt, weil er beispielsweise kein schwaches Passwort zulässt, hilfreich. Sicherheit durch Unklarheit (Security through obscurity) würde ich auch nur ergänzend einsetzen. Der zusätzliche Passwortschutz mit der .htaccess-Datei erscheint mir da wichtig. Du scheinst Dich an der Verwendung des Begriffs "Sicherheitslücken" zu stören. Wäre Schwachstellen im Sicherheitskonzept treffender oder hast Du einen anderen passenden Begriff?
9. September 2009, Thomas Scholz schreibt: Ja genau, an dem Ausdruck reibe ich mich. »Sicherheitslücke« heißt: Es existiert ein bekanntes und nachvollziehbares Einbruchsszenario, dessen Ursache im WordPress-Code liegt. Aber das ist derzeit nicht der Fall. Wer seine Paßwörter vereinfacht, nimmt weniger Sicherheit bewußt in Kauf. Daran ist nicht WordPress schuld. Man kann bestimmt ein paar Details verbessern. Aber wenn WordPress die Benutzer zu sehr gängelt, wird auch wieder geschimpft. Im Moment regen sich all die Updateschlampen auf, zeigen mit dem Finger auf allen anderen und werfen mit halbgaren Vorschlägen um sich. Irgendwo habe ich sogar gelesen, WordPress solle doch einfach mal den Core neu schreiben. Hallo? Das wäre noch dämlicher als ein Jahr auf Updates zu verzichten. Wenn also so viele Leute ihren Verstand ausknipsen, dann sollte doch der Rest – und dazu möchte ich dich gerne zählen – auf harte Fakten pochen und wieder Sachlichkeit in die Debatte bringen. Übertreibungen nützen niemand. WordPress’ derzeitiges defensives Sicherheitskonzept ist keine »Lücke«, sondern schlicht der Weg, dem einzelnen Nutzer die Details zu überlassen. Ob das gut ist oder nicht, kann und sollte man diskutieren; aber bitte ohne Panikmache.
9. September 2009, Dieter schreibt: @Thomas Danke für Deine sachliche und konstruktive Kritik. Ich habe den Begriff "Sicherheitslücke" im ersten Kugelpunkt (bullet point) unter "3. Nachteile von WordPress" durch "defensives Sicherheitskonzept" ersetzt und den Text angepasst. Ich hoffe, das berücksichtigt hinreichend Deine berechtigte Kritik an der Verwendung des Begriffs Sicherheitslücke. Ich suche auch nicht die Schuld bei WordPress, denn da gibt es viele andere wichtige Faktoren wie etwa die Konfiguration des Servers oder Webspaces sowie von PHP (Stichworte: safe_mode, open_basedir, register globals) sowie eben den WordPress-Betreiber selbst (Stichwort: Das Problem sitzt meistens 30cm vor dem Bildschirm ;-) ).
Updateschlampen
:lachtot: :lachtot: :lachtot: Damit hast Du den Nagel auf den Kopf getroffen. :!: Den Vorschlag den Core von WordPress neu zu schreiben habe ich im Blogbeitrag "WordPress – wann kommt es zur Katastrophe?" von Gerrit van Aaken gelesen. Das war übrigens der Auslöser für meinen Blogbeitrag (siehe 1. Hintergrund). Ich gebe zu, dass ich die Sinnhaftigkeit den Core von WordPress neu zu programmieren nicht beurteilen kann. Deshalb hatte ich mich auch einer Aussage dazu enthalten. Ich teile Deine Auffassung, dass harte Fakten und Sachlichkeit die Grundlage der Debatte sein sollten. Sprachliche Genauigkeit ist da eine zwingende Voraussetzung. Hierzu gehört Dein Hinweis auf den nicht korrekten Gebrauch des Begriffs Sicherheitslücken. Er war für mich erhellend und äußerst hilfreich. Ich würde es begrüßen, wenn künftige WordPress-Versionen den Nutzer durch intelligente Lösungen bei Sicherheitsfragen unterstützen (beispielsweise indem nur starke Passwörter zugelassen werden). Werde mal auf meine ToDo-Liste die Beschäftigung mit dem Vorschlagswesen bei WordPress.org setzen.
5. Dezember 2009, Trierer schreibt: Das Problem mit dem PHP-Speicher ist eigentlich ein ziemlich großes. Bei einem großen Provider, der gerade vom rosa Riesen mit dem T aufgekauft wurde, verursacht das regelmäßig Probleme, nicht nur bei WordPress, sondern auch bei Joomla. Ansonsten ist WordPress eigentlich sehr zu empfehlen, lässt sich intuitiv und schnell bedienen. Dass aber die Entwickler dieses PHP-Speicherproblem nicht anders lösen, ist mir schleierhaft.
5. Dezember 2009, Dieter schreibt: Das PHP-Speicherproblem habe ich für Webseiten-Infos.de durch einen Providerwechsel von one.com zu Alfahosting.de gelöst (siehe hierzu auch meine Blogbeiträge "In eigener Sache: Umzug zu Alfahosting" und "Umzug zu einem anderen Webhoster"). Die Entwickler können nur bedingt etwas am Speicherbedarf verbessern. Meine persönliche Vermutung ist, dass der höhere Speicherbedarf zum einem aus dem Einsatz von objektorientierter PHP-Programmierung resultiert und zum anderen aus dem ständig steigenden Funktionsumfang neuer WordPress-Versionen. Im Übrigen empfehle ich Dir meinen Blogbeitrag "Kommentar-Spam bekämpfen" zur Lektüre. ;-)
5. Dezember 2009, Thomas Scholz schreibt: @Trierer: Das Problem des Arbeitsspeichers liegt nicht beim PHP-Code, sondern beim Hoster. RAM ist so billig – 6 GB kosten nicht einmal 100 € – daß eine Begrenzung auf 32 MB oder weniger nur noch als Totalversagen des Anbieters bezeichnet werden kann. Der erhöhte Speicherbedarf moderner Webanwendungen ist unausweichlich, und er hilft den Kunden, die Versager leichter zu erkennen. Deshalb finde ich ihn nützlich.
5. Dezember 2009, Dieter schreibt: @Thomas Du hast in der Sache Recht, auch wenn ich Deine Formulierungen wie Totalversagen und Versager für zu kraftvoll halte. ;-)
30. Juni 2010, Dirk schreibt: Auch wenn es etwas spät für diese Diskussion ist aber evtl. hat Thomas diesen Thread ja abonniert. Was mich an WP stört ist das es immer noch keine automatisierte Datenbank-Sicherung gibt, die dann auch gekoppelt an ein Autoupdate wäre. Dazu eine Automail (du wurdest im Blog xxx geupdatet ) und alle wären glücklich, denn was die meisten wohl nur stört ist das Sichern und das Updaten. Beides lässt sich aber automatisieren. Ich betreibe ca 280 Blogs; rate mal was ich mich über jedes Update freue.
30. Juni 2010, Thomas Scholz schreibt: Dirk, ich habe diesen Beitrag tatsächlich abonniert. Hatte ich ganz vergessen. Ich würde Backup-Funktionen nicht unter dem Schlagwort »Sicherheit« ablegen. Ein fehlendes Backup – so ärgerlich das manchmal sein mag – heißt ja noch nicht, daß jemand einbrechen könnte. Es gibt Plugins für Backups, die einigermaßen funktionieren, auch hier natürlich nicht immer und überall. Und genau so soll es auch sein: Systemspezifische Lösungen gehören nicht in den Core. WordPress wird in den unterschiedlichsten Umgebungen benutzt: Intranets, Communities, lokal … Da gibt es keine für alle gleichermaßen sinnvolle Methode. Manche Datenbanken sind viel zu groß, um per Mail verschickt zu werden, andere Installationen benutzen mehrere Server und wieder andere bloggen vielleicht fünfmal im Jahr. Oft bietet auch auch der Hoster schon ein automatisches Backup an. Die Menge der potentiell eingeführten Bugs steht in keinem Verhältnis zum Nutzen. Man kann sich ja einfach per SSH bei MySQL anmelden und automatisiert einen Dump ziehen. So ginge ich jedenfalls bei der Menge vor, die du zu verwalten hast. Auf diesem Weg läßt sich auch WordPress aktualisieren. dazu braucht man kein Plugin; ein Bash-Script genügt.
1. Juli 2010, Dieter schreibt: @Thomas Ich würde nicht Backup-Funktionen, aber eine gute Backup-Strategie auch, aber nicht nur unter dem Stichwort Sicherheitskonzept einsortieren. Dein Artikel "Website gehackt – und nun?" war und ist für mich ein wichtiger Gedanken Schubser zu einem besseren Sicherheitskonzept. Nach meinem Verständnis gehört dazu auch eine Backup-Strategie mit regelmäßigen Backups. Mit Skripts und Shell arbeiten überfordert mich leider (noch?).
1. Juli 2010, Thomas Scholz schreibt: Ich meine Sicherheit vor Einbrüchen; die sind ja Thema deines Artikels. Sicherheit bei Ausfällen umfaßt selbstverständlich auch das Backup. Dabei spielt es ja keine Rolle, was den Ausfall verursacht hat.
1. Juli 2010, Dirk schreibt: Wie man sich täuschen kann; da habe ich doch wirklich nicht gewusst, dass es die Möglichkeit eines Plugins gibt. Wir haben zwar mittlerweile einen Extra Backup Server der wöchentlich alle Server abklappert, aber um das manuelle Updaten kommt man halt trotzdem nicht herum. Spätestens bei den großen Updates... Für mich ging es bei der Diskussion auch nicht um WP nieder zu machen, sondern eher um ein nice to have. Etwas was man sich wünscht und was einem (nicht nur mir) eine Menge Arbeit abnehmen könnte. Die Tatsache, dass ich meine Blogs alle mit WP betreibe, spricht eigentlich dafür, dass ich mit WP zufrieden bin.
2. Juli 2010, Dieter schreibt: @Thomas Die verschiedenen Sicherheitsaspekte im Kontext mit WordPress sind ein interessantes Thema. Wäre doch mal was für einen Blogbeitrag. ;-) @Dirk Vielleicht hilft eines der Backup-Plugins für WordPress beim automatisierten Sichern. ;-) Ca. 280 Blogs und alle mit WP betrieben ist jedenfalls definitiv ein eindeutiges Bekenntnis für WP. :-) Willkommen im Club der WordPress-Anhänger. Auch beim WordCamp in Berlin am 3.7. dabei?
2. Juli 2010, Dirk schreibt: Ne du. ich lebe schon lange in den Philippinen und viel zu träge um mich noch mal nach Europa zu bewegen. Wenn mein Link nicht gelöscht werden würde. könntest du dir einen Blog von mir anschauen. Obwohl ich nicht verstehe warum. dürfte doch eh nofollow sein.
2. Juli 2010, Dieter schreibt: @Dirk Ich habe mir den Link angeschaut und dann gelöscht. Meine Gründe: - Kein Impressum, d.h. es ist nicht offensichtlich, dass Du der Verantwortliche bist. - Hier müssten bei den Kommentaren alle Links ohne nofollow sein. Bei mir gibt es für Kommentare hier nur Link oder kein Link. Solltest Du bei den Kommentaren einen Nofollow-Link finden (Ausnahme: Wikipedia), wäre ich für einen entsprechenden Hinweis dankbar. - Du hast kein Gravatar mit Deiner Mailadresse verknüpft.
3. Juli 2010, Dirk schreibt: Wie man ein Gravatar mit einer Mailadresse verknüpft weiß ich nicht, aber da werde ich mich gleich wohl mal schlau machen. Impressum brauchste nur als Deutscher Staatsbürger, egal wo du lebst, die Domains gehören aber meine Frau, also brauche ich keins. Die werden trotzdem sauber geführt, schleßlich sollen sie langfristig als Wissensdatenbank herhalten.
3. Juli 2010, Dieter schreibt: @Dirk Für Avatare siehe http://www.gravatar.com und hier habe ich dazu auch einen Blogbeitrag geschrieben.
21. September 2010, Siggi schreibt: Hey Dieter - auch mein Lieblingswort in diesem Beitrag/bzw. im Kommentarbereich ist *Updateschlampen* ...sehr sehr cool!
22. September 2010, Dieter schreibt: @Siggi Ja, die plastische Formulierung Updateschlampen von toscho gefällt mir auch. Inzwischen ist allerdings WordPress 3.0 mit einem noch höheren Speicherbedarf erschienen, so dass ich für eine Website noch zu alfahosting.de wechseln muss, bevor ich auf WordPress 3.0 updaten kann.
26. Dezember 2011, Die 10 größten Web-Security-Mythen | Webseiten-Infos.de schreibt: [...] Zum vorherigen Beitrag [...]

WordPress 2.8.x und PHP 5.3

Dieter — Mon, 07 Sep 2009 18:26:44 +0000

In der Zeitschrift Internet INTERN September – November 04/09 wird unter anderem PHP 5.3 vorgestellt. Ferner werden dort Lösungen für Probleme von Web-Anwendungen wie WordPress (siehe Seite 44 der Zeitschrift) mit PHP 5.3 aufgezeigt.

Um es vorweg zu nehmen: Ältere Versionen von WordPress wie 2.7 erzeugen jede Menge Fehlermeldungen mit PHP 5.3. Sie sind also unter PHP 5.3 nicht lauffähig (siehe hierzu auch den Kommentar von Heiko im Blogbeitrag “WordPress und PHP 5.3“).

PHP 5.3 führt aber selbst bei WordPress 2.8 zu zahlreichen Fehlermeldungen. Diese Fehlermeldungen kommen direkt durch WordPress, können aber teilweise auch durch das aktive Theme und WordPress-Plugins hervorgerufen werden.

Die Ursache für die Fehlermeldungen mit WordPress 2.8.x ist, dass PHP ab Version 5.3 eine korrekte Zeitzone erwartet. Es hagelt Fehlermeldungen, sofern diese nicht in der Datei php.ini der Serverinstallation enthalten ist. Für die deutsche Zeitzone ist folgender Eintrag erforderlich:

1	date.timezone="Europe/Berlin"

Sofern Du keinen Zugriff auf die Datei php.ini hast (das ist regelmäßig der Fall, wenn Du nicht über einen Server, sondern lediglich über ein shared Webspace-Paket bei einem Hoster verfügst), kannst Du das stattdessen auch durch folgende Ergänzung der wp-config.php Deiner WordPress-Installation erreichen:

1	date_default_timezone_set('Europe/Berlin');

Diese Ergänzung der wp-config.php beeinflusst übrigens nicht die Einstellungen der verwendeten Zeitzone im Administrationsbereich (Backend) von WordPress.

Ich habe meine wp-config.php schon mal vorsorglich entsprechend erweitert, auch wenn mein Hoster Alfahosting.de noch kein PHP 5.3 einsetzt.

Nebenwirkungen konnte ich noch keine feststellen.

Weitere Linktipps zu dem Thema:

Schon PHP 5.3 beim Hoster ? bei geheimtipplimmer.de (Website derzeit nicht erreichbar, da gesperrt)
Migrating to PHP 5.3 bei techportal.ibuildings.com
Neue PHP Version 5.3 bei puhbaer.eu

Kommentare

7. September 2009, Ute schreibt: Na, und wieder mal wirft WP Fehler... ;)
8. September 2009, Dieter schreibt: Nur, wenn der Apache-Server nicht den Anforderungen von PHP 5.3 entsprechend konfiguriert ist. :-P Und selbst für den Fall, dass Du nur Shared Web-Hosting und keinen Zugriff auf die php.ini hast, kannst Du die neue Zeitzonen-Anforderung von PHP 5.3 einfach lösen, indem Du wp-config.php ergänzt. :-) Probleme von Plugins und Themes mit PHP 5.3 können allerdings leider auch auftreten. Da wird es dann erst richtig schwierig. :-(
15. September 2009, Ute schreibt: Dieter, es ging mir nicht drum, dass sich nicht die meisten Probleme irgendwie beheben lassen. Ich finde ein System was Mut einer Fünf-Minuten-Installation für Dummies wirbt, darf nicht schlussendlich an vielen Stellen eben doch Fachkenntnis erfordern, um genutzt werden zu können.
15. September 2009, Dieter schreibt: @Ute
Ich finde ein System was Mut einer Fünf-Minuten-Installation für Dummies wirbt, darf nicht schlussendlich an vielen Stellen eben doch Fachkenntnis erfordern, um genutzt werden zu können.
Das hier beschriebene PHP 5.3-Problem kann man WordPress nicht anlasten. Das tritt nur auf, wenn die php.ini nicht beim Wechsel auf PHP 5.3 oder Einichten desselben an die PHP 5.3-Anforderungen angepasst wurde. Im Moment wird viel über das neu erschienene PHP 5.3 berichtet. Ich hoffe und gehe davon aus, dass Hoster und Administratoren nur nach entsprechend erfolgreichen Tests auf die neue PHP-Version wechseln oder diese als Option anbieten. Und das sollte nicht der gleiche Personenkreis sein, der WordPress nur nach der 5 Minuten-Installationsmethode einsetzt / einsetzen kann. ;-) Aber vielleicht wird in einer der nächsten WordPress-Versionen von vorneherein mit entsprechend ergänzter wp-config.php angeboten. :idea:
15. September 2009, Ute schreibt: Jein, für mich ist WP an einigen Stellen nicht sauber programmiert. Wenn eine neue PHP-Version kommt, dann werden auch solche Änderungen bekannt gegeben. Eine gute Applikation setzt die Zeitzone, denn es kann auch Gründe gegen, warum in der php.ini zwar eine Zeit gesetzt ist, aber nicht die, die Applikation braucht. Klar ein vernünftiger Hoster hat in jedem Fall auch eine php.ini mit Zeitzone... ;)
15. September 2009, Dieter schreibt: @Ute
Jein, für mich ist WP an einigen Stellen nicht sauber programmiert.
Ich kann nicht programmieren, sondern nur past-and-copy und try-and-error. Hast Du denn konkrete Beispiele für einige Stellen, an denen WP nicht sauber programmiert ist? Wäre doch was für ein Blogbeitrag und als Verbesserungsvorschlag an die Programmierer von WordPress. Das Einzige, was mir einfällt, ist die zu kurze Zeiteinstellung für Pings und Trackbacks sowie der mit JavaScript-Effekten überladene Administrationsbereich (Backend).
19. September 2009, Hans schreibt: Danke für den Tipp mit der date_default_timezone in der wp-config.php!
19. September 2009, Dieter schreibt: @Hans Und nochmals bitte schön! ;-) Übrigens: SEO-Namen und Links akzeptiere ich nicht! Sie entferne ich entweder, lösche den Kommentar oder markiere ihn als Spam! :tongue:
21. September 2009, Fehlermeldungen beim Einsatz von WordPress unter PHP 5.3News » webwork-magazin.net schreibt: [...] selected 'Europe/Paris' for '2.0/DST' instead in Verzeichnis/Datei.php Zeile Das Problem liegt laut Dieter Welzel daran, dass PHP 5.3 in der php.ini das setzen einer/der richtigen Zeitzone erwartet. Ist das nicht [...]
2. Oktober 2009, Matthias schreibt: Eine Frage: ist das egal an welche Position date_default_timezone_set('Europe/Berlin'); in der wp-config.php kommt? Ich bin auch nur ein "past-and-copy und try-and-error Programmierer" :)
3. Oktober 2009, Dieter schreibt: @Matthias Bei PHP 5.2.x und WordPress 2.8.x hilft und stört es anscheinend unabhängig von der Position in der wp-config.php nicht. Ich habe es unmittelbar vor den Datenbankeintrag define('DB_NAME', ...) geschrieben. Ich denke, dass das bei PHP 5.3 die oder eine richtige Position sein müsste. ;-)
3. November 2009, Erik schreibt: Hallo! Super hilfreiches Posting, aber wo kann man andere Zeitzone "ersehen", wenn Berlin nicht die gewünschte Zeitzone ist? date_default_timezone_set('Thailand/Bangkok'); ?????
3. November 2009, Dieter schreibt: @Erik Ganz einfach: Im Administrationsbereich (Backend) von WordPress ab Version 2.8 kannst Du unter Einstellungen > Allgemein über das Pulldowm-Menü bei Zeitzone Asien > Bangkok auswählen und dann "Änderungen übernehmen" anklicken. ;-)
15. November 2009, Markus schreibt: Danke für den Beitrag. Hab es nun auch schon eine weile so laufen. Ich hab einen eigenen Server den ich neuinstalliert hatte und diesen Eintrag auch in der php.ini gemacht habe, leider wurde das trotzdem nicht von WP genommen und ich musste den Eintrag noch in die config eintragen. Weißt Du evtl. an was das liegen könnte?
15. November 2009, Dieter schreibt: @Markus Interessant und für mich aufgrund des Artikels in der Zeitschrift Internet INTERN September – November 04/09 verwunderlich, dass bei Dir der Eintrag in der php.ini nicht reichte. Ich bin leider kein PHP-Experte und kann Dir auch nicht sagen, warum Du noch den Eintrag in der wp-config.php brauchst. Es funktioniert ja erfreulicherweise jetzt bei Dir. Wenn Du gleichwohl noch der Frage nachgehen willst, rege ich eine entsprechende Nachfrage im WPD- oder einem PHP-Forum an.
15. November 2009, Markus schreibt: Danke für die rasche Antwort. Ich kann es mir auch nicht wirklich erklären. Den Hinweis auf WPD find ich lustig, da ich dort ja sehr oft bin, kannst Du ja nicht wissen, klar. Ich denke ich werd wenn ich mal Zeit hab ein paar Server Foren durchforsten. Vielleicht hab ich auch einfach nur einen Bock in der Server Config geschossen.
16. November 2009, Dieter schreibt: @Markus Bitte schön. Im WPD-Forum ist mir schon oft geholfen worden und finde ich immer wieder hilfreiche Tipps. Deshalb hatte ich auch darauf hingewiesen. Wenn Du da sehr oft bist, umso besser. ;-) Server-Foren ist sicherlich auch nicht verkehrt, zumal es sich ja danach anhört, als ob etwas nicht mit Deiner Serverkonfiguration stimmt.
18. Mai 2010, Brad Cooley schreibt: Huhu, hat geklappt! Die Fehlermeldung erscheint nicht mehr! – Bei der Gelegenheit hab ich wenigstens auch gleich noch eine Sicherung gemacht! :-)
18. Mai 2010, Dieter schreibt: @Brad Freut mich! Datensicherung ist ein gutes Stichwort. Werde ich gleich auch mal endlich wieder machen. :-)

On Page SEO für WordPress

Dieter — Thu, 03 Sep 2009 20:07:37 +0000

Über einen Tweet von Sergej Müller, dem Programmierer des WordPress-Plugins wpSEO, bin ich auf seine pdf-Datei mit dem Titel “On Page SEO für WordPress” aufmerksam geworden.

In Kugelpunkten (bullet points) stellt er sehr kompakt die wesentlichen Aspekte einer effektiven On Page Suchmaschinenoptimierung (SEO) dar.

Diese hilfreiche Zusammenfassung kannst Du bei Sergej unter www.wpseo.de/pdf/WordPress-OnPage-SEO.pdf (912 kB, 9 Seiten) kostenlos herunterladen (downloaden).

Bleibt als mein persönliches Fazit:

Die meisten dort aufgeführten Kriterien beachte ich hier auf Webseiten-Infos.de bereits.
Nur eine inhaltliche Nische habe ich mir nicht gerade ausgewählt.
Dafür macht mir das Schreiben über Infos, Tipps und Tricks für den Erfolg von Webpräsenzen (Websites) Spaß und Links zu empfehlenswerten anderen Webseiten setze ich gerne, denn schließlich sind Links im Internet wie das Salz in der Suppe. Muss halt richtig dosiert werden.

Code anzeigen mit CodeColorer

Dieter — Wed, 02 Sep 2009 05:35:24 +0000

Seit gestern setze ich hier für das Anzeigen von Code(schnippseln) nur noch das WordPress-Plugin CodeColorer ein.

Ursprünglich verwendete ich das Plugin FV Code Highlighter (siehe hierzu meinen Blogbeitrag “Plugin FV Code Highlighter“) und später ergänzend bei Darstellungsproblemen CodeColorer ein (siehe hierzu meinen Blogbeitrag “Code anzeigen in WordPress“).

Folgende Gründe waren für mich für diesen vollständigen Plugin-Wechsel ausschlaggebend:

Das “Und-Zeichen” & wird bei FV Code Highlighter als HTML-Entity & dargestellt.
CodeColorer beherrscht das valide Einfügen von Zeilennummern für den Code. FV Code Highlighter kennt keine Zeilennummern und das von Ute eingesetzte WordPress-Plugin Highlight Source Pro kann zwar Zeilennummern einfügen, aber dann ist der Code nicht mehr valide.
Bei CodeColorer konnte ich durch leichte Anpassung (Modifizierung) des Plugins den CSS-Code in meine bestehende CSS-Datei integrieren. Das ist bei FV Code Highlighter nicht so einfach möglich. Zudem schreibt FV Code Highlighter CSS-Code in den Kopfbereich (Header) und nicht als externe Datei. Das ist für die Ladegeschwindigkeit (Sitchwort: Caching) suboptimal.
CodeColorer setzt auf das HTML-Element für Quelltext (Quältext) auf und benutzt gegebenenfalls eigene Ergänzungen dazu. FV Code Highlighter verwendet dagegen eine eigene Syntax {code} mit eigenen Ergänzungen. Die Verfahrensweise bei CodeColorer dürfte zukunftssicherer sein, da sie auf einem bestehenden HTML-Element beruht.


Den Vorteil von FV Code Highlighter, das es standardmäßig bereits die Farben (Colorierung) des von mir genutzten Webeditors Dreamweaver für den Code einsetzt, werde ich hoffentlich durch entsprechende Anpassungen des CSS-Codes für CodeColorer auch noch hin bekommen.
Also bitte nicht wundern, wenn sich in nächster Zeit die Farben des Codes bei den Codeschnippseln noch ändern.  
Ähnliche Beiträge
Code anzeigen in WordPress
Plugin FV Code Highlighter
Archiv- und Suchergebnisseiten mit Kommentarfunktion
WordPress-Plugin YARPP macht Probleme
Artikel mit gleichen Schlagwörtern zeigen
Copyright © 2010 Dieter Welzel
Dieser Feed ist nur für den persönlichen, nicht gewerblichen Gebrauch bestimmt.
Eine Verwendung dieses Feeds auf anderen Webseiten verstößt gegen das Urheberrecht. Wenn Sie diesen Inhalt nicht in Ihrem News-Reader lesen, so macht sich die Seite, die Sie betrachten, der Urheberrechtsverletzung schuldig. (digitalfingerprint: bbd2a4c375bd3a68829f8cc22c8ac04d (38.107.179.230) )
Permalink |
Kein Kommentar |
Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena

Schlagwörter: CodeColorer, CSS, FV Code Highlighter, Ladezeit, Plugins, Quelltext, WordPress



Artikel mit gleichen Schlagwörtern zeigen
Dieter — Sat, 29 Aug 2009 13:34:47 +0000
Fünf Blogbeiträge aus der gleichen Kategorie werden wurden hier bereits unter dem jeweiligen Blogbeitrag mit der Überschrift “Das könnte Dich auch interessieren” angezeigt (siehe hierzu auch meinen Blogbeitrag “WordPress-Plugin YARPP macht Probleme“).
Diese mit dem WordPress-Plugin “Related Posts by Category” von Sergej Müller realisierte Lösung soll den Leser darauf aufmerksam machen und gegebenenfalls dazu motivieren, dass er noch weitere ähnliche Blogbeiträge aus dieser Kategorie lesen kann. Zudem erhöht und verbessert es die interne Verlinkung der Blogbeiträge untereinander.
Da dieses Plugin auf die Kategorien eines WordPress-Blogs aufsetzt, werden leider statische Seiten nicht erfasst und einbezogen. Ich setze hier WordPress als Content-Management-System (CMS) ein und verwende statische Seiten unter anderem auch für grundlegende sowie längere Artikel. Insoweit deckt das WordPress-Plugin Related Posts by Category meine Bedürfnisse nicht vollständig ab.
Darüber hinaus kommt es auf Webseiten-Infos.de immer wieder vor, dass es auch thematisch sich ergänzende Blogbeiträge gibt, die ich aber verschiedenen Kategorien zugeordnet habe. Bewusst wollte ich hier aber Blogbeiträge immer nur einer Kategorie zuordnen. Thematische Verwandtschaften mache ich dagegen über die Schlagworte (Tags) sichtbar.
Nun wollte ich dafür kein weiteres WordPress-Plugin installieren, aber stellte fest, dass das bereits hier im Einsatz befindliche WordPress-Plugin Simple Tags unter anderem auch die Möglichkeit beinhaltet, ähnliche Artikel mittels Schlagworte (Tags) zu ermitteln und (als Liste) auszugeben.
Hierzu habe ich den folgenden PHP-Code in meine rechte Spalte (Sidebar) eingebunden:
1
 if (function_exists('st_related_posts')) st_related_posts(); ?>
Die if-Abfrage habe ich zusätzlich eingebaut, damit es zu keiner Fehlermeldung kommt, wenn ich das Plugin deaktiviere(n muss).
Im Übrigen sei für die Beschreibung und Parameter auf die englische Dokumentation verwiesen.
Die grundsätzlichen Einstellungen habe ich im Administrationsbereich (Backend) unter Einstellungen > Simple Tags > Related Posts vorgenommen. Sie sehen bei mir wie folgt aus:

Bei “Zeigt automatisch themenverwandte Beiträge in feeds” kein Häckchen setzen.
Bei “Verwandte Artikel in Beiträgen anzeigen:” No auswählen.
Bei “Related Posts Order:” Count desc auswählen.
Bei “Format Beitragslink:” folgenden Code verwendet
1
%post_title%

Bei “Maximum number of related posts to display: (default: 5)” 5 eingegeben.
Bei “Text der angezeigt wird, wenn es keinen themenverwandten Beitrag gibt:” Keine verwandten Seiten eingegeben.
Bei “Titel für die Liste, wenn diese keinen Titel haben soll, dann leer lassen:” folgenden Code verwendet
1
Verwandtes


Zum Schluss sind diese Einstellungen mittels Anklicken des Buttons “Update options >>” noch zu speichern, damit sie nicht verloren gehen.
Damit das Ganze auch noch in meinem Sinne aussieht, habe ich diese Ergänzung in der rechten Spalte (Sidebar) noch mit CSS gestaltet.
Meine Ergänzung der CSS-Datei dafür sehen wie folgt aus:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
.st-related-posts a 

{

padding-left: 18px; 

background: url(../images/sprite.gif) no-repeat left; 

background-position: left -22px;

}

.st-related-posts a:visited 

{

padding-left: 18px; 

background: url(../images/sprite.gif) no-repeat left; 

background-position: left -62px;

}

.st-related-posts a:focus 

{

text-decoration: none; 

color: #FFF; 

background-color: #2f6325;

}

.st-related-posts li 

{

margin: 0; 

border-top: 1px #BFB49B dotted}

.st-related-posts {text-indent: -18px; 

margin-left: 18px;

}

.st-related-posts li 

{

margin: 0; 

padding: 0; 

list-style-type: none !important; 

list-style-image: none;

}

.st-related-posts li 

{

line-height: 1.8em;

}

h3.st-related-posts 

{

margin-bottom: .5em;

}
Das Ergebnis kannst Du in der rechten Spalte (Sidebar) sehen.
Hier zum Abschluss noch als Beispiel ein Bildschirmfoto (Screenshot) davon:

Was hältst Du von dieser Lösung?
Ähnliche Beiträge
Und der Gewinner des Buches ist…
WordPress-Plugin YARPP macht Probleme
Webseiten-Infos.de auch auf Twitter
Externe Links in neuem Fenster öffnen?
Sonderheft OpenSource Extra zu WordPress
Copyright © 2010 Dieter Welzel
Dieser Feed ist nur für den persönlichen, nicht gewerblichen Gebrauch bestimmt.
Eine Verwendung dieses Feeds auf anderen Webseiten verstößt gegen das Urheberrecht. Wenn Sie diesen Inhalt nicht in Ihrem News-Reader lesen, so macht sich die Seite, die Sie betrachten, der Urheberrechtsverletzung schuldig. (digitalfingerprint: bbd2a4c375bd3a68829f8cc22c8ac04d (38.107.179.230) )
Permalink |
Kein Kommentar |
Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena

Schlagwörter: Artikel, Blogbeiträge, interne Verlinkung, Plugins, Schlagwörter, Simple Tags, WordPress




Webseiten validieren mit Validated
Dieter — Sat, 15 Aug 2009 20:43:07 +0000
Ein wichtiges Qualitätskriterium für eine gute Webpräsenz ist die Validität des Quelltextes (Quältext) (siehe hierzu den Abschnitt “6. Die Qualität des Quelltextes” im Artikel “Was macht eine gute Webpräsenz aus?”).
Nun habe ich gestern bei dieser Webpräsenz die Dokumenttyp-Deklaration (den Doctype) von XHTML 1.0 transitional auf XHTML 1.0 strict umgestellt (siehe hierzu meinen Blogbeitrag “Doctype auf XHTML 1.0 strict umgestellt“).
Da ich zu einer strengeren Dokumenttyp-Deklaration (einem strengeren Doctype) gewechselt bin, treten fast automatisch dabei erst einmal Validierungsfehler auf.
Es ist aber ausgesprochen mühsam alle Webseiten der Website einzeln aufzurufen und hinsichtlich ihrer Validität zu überprüfen.
Erfreulicherweise kann der WDG HTML Validator online auch ganze Websites auf Validität prüfen. Dazu musst Du das Häckchen bei “Validate entire site” setzen. Allerdings ist diese Prüfung leider auf maximal 100 Webseiten begrenzt.
Praktischer finde ich es bei einer reinen WordPress-Installation deshalb auf das WordPress-Plugin Validated zurückzugreifen.
Validated überprüft mit dem W3C-Validator im Administrationsbereich (Backend) unter Werkzeuge -> Validation, also während Du als Nutzer angemeldet bist, alle Deine WordPress-Seiten auf ihre Validität.
Da der Validator aber natürlich nicht als Benutzer angemeldet ist, prüft er auch Deine Seiten wie sie in diesem Fall dargestellt werden.
Deswegen kann es passieren, dass Du als Nutzer angemeldet mit dem Firefox Addon HTML Validator eine valide Seite vorfindest, aber nicht angemeldete Besucher eine nicht valide Seite angezeigt bekommen. Wie Du ein eine Validierungswarnung bei der Kommentarfunktion beheben kannst, habe ich in meinem Blogbeitrag “WordPress für angemeldete Nutzer valide machen” beschrieben.
Schön ist bei Validated, dass die auf Validität geprüften Seiten direkt verlinkt sind und Du dann auch einzelne Seiten erneut prüfen kannst. So kannst Du schnell kontrollieren, ob Deine Änderungen im Quellcode (Quälcode) zu dem gewünschten Validierungsergebnis geführt haben.
Es sei vorsichtshalber darauf hingewiesen, dass

dieses WordPress-Plugin während der Validitätsprüfung bei umfangreichen und gut besuchten WordPress-Seiten die Serverauslastung deutlich erhöhen kann und
laut dem Plugin-Verzeichnis bei WordPress die Kompatibilität nur bis WordPress 2.7 geprüft oder gewährleistet ist (Danke an Thomas Scholz aka toscho für diesen Hinweis). Bei meinen WordPress-Seiten (derzeit Version 2.8.4) funktioniert das Plugin Validated übrigens bei zwei verschiedenen Hostern (one.com und Alfahosting.de) problemlos.

Zur Veranschaulichung hier noch ein Bildschirmfoto (Screenshot) von Validated in Aktion:

Die Prüfung der Seiten auf Validität wird übrigens

 automatisch gestartet, wenn Du im Administrationsbereich (Backend) den Menüpunkt Validation anklickst und
automatisch abgebrochen, wenn Du die Seite im Browser neu lädst oder einen anderen Menüpunkt anklickst.

Da fände ich es benutzerfreundlicher, wenn es einen Start- sowie einen Pause- und Beenden-Button gäbe.
Das ändert aber nichts an meiner Empfehlung dieses WordPress-Plugins.
Kommentare
16. August 2009, Thomas Scholz schreibt: Laut Selbstauskunft ist dieses Plugin: »Compatible up to: 2.7«. Das finde ich aber sehr entmutigend.
16. August 2009, Dieter schreibt: @Thomas
Vielen Dank für Deinen Hinweis. Hatte ich leider übersehen.

Es gibt sogar zumindest einen Nutzer, bei dem das Plugin unter WordPress 2.8.1 vor etwa einem Monat nicht lief. Eine Reaktion des Plugin-Entwicklers gibt es leider (noch) nicht.

Bei mir läuft es dagegen unter WordPress 2.8.4.

Werde den Blogbeitrag entsprechend ergänzen.
Ähnliche Beiträge
Landmark roles auf Webseiten-Infos.de
10 Punkte für guten Code
Suchmaschinenoptimierung (SEO)
WAI-ARIA und (X)HTML validieren!
Links überprüfen
Copyright © 2010 Dieter Welzel
Dieser Feed ist nur für den persönlichen, nicht gewerblichen Gebrauch bestimmt.
Eine Verwendung dieses Feeds auf anderen Webseiten verstößt gegen das Urheberrecht. Wenn Sie diesen Inhalt nicht in Ihrem News-Reader lesen, so macht sich die Seite, die Sie betrachten, der Urheberrechtsverletzung schuldig. (digitalfingerprint: bbd2a4c375bd3a68829f8cc22c8ac04d (38.107.179.230) )
Permalink |
2 Kommentare |
Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena

Schlagwörter: Doctype, Plugins, Qelltext, Validated, Validator, W3C, WDG, Webseite, Webseiten, WordPress




Mail-Abos für Kommentare sind weg!
Dieter — Sun, 09 Aug 2009 19:13:59 +0000
Ich benutze auf Webseiten-Infos.de das WordPress-Plugin Gurken Subscribe to Comments.
Dabei handelt es sich um einen Ableger (Fork) des WordPress-Plugins Subscribe to Comments. Im Gegensatz zum Original beherrscht es aber auch das Double-Opt-In-Verfahren. Dabei wird eine Bestätigungsmail an die hinterlegte Mailadresse gesandt und der Empfänger muss den Bezug von Mails, wenn es weitere Kommentare zu dem Blogbeitrag gibt, ausdrücklich durch das Anklicken eines Links bestätigen. Zudem kann der Empfänger dieses Mail-Abo jederzeit wieder kündigen.
Nun wollte ich testweise einen anderen Ableger (Fork) des WordPress-Plugins testen: Subscribe to Double-Opt-In Comments.
Dazu hatte ich kurz Gurken Subscribe to Comments deaktiviert und anschließend Subscribe to Double-Opt-In Comments aktiviert.
Da hätte ich wohl besser vorher eine Datenbank-Sicherung gemacht. Denn das andere Plugin ist bestimmt nicht schlecht, aber mit Gurken Subscribe to Comments bin ich schon vertraut. Deshalb deaktivierte ich wieder Subscribe to Double-Opt-In Comments und aktivierte danach Gurken Subscribe to Comments erneut.
Allerdings waren dann die ganzen bisherigen Mail-Abos verschwunden. Wer also Mail-Abos vor dem 8. August 2009 hatte und diese wieder haben möchte, muss leider noch einmal die Double-Opt-In-Prozedur wiederholen.
Ich bedauere das und bitte meinen Fehler zu entschuldigen.
Ähnliche Beiträge
Kommentare abonnieren
E-Mail-Newsletter abonnieren
Kein E-Mail-Newsletter mehr!
Archiv- und Suchergebnisseiten mit Kommentarfunktion
Datenschutzerklärung
Copyright © 2010 Dieter Welzel
Dieser Feed ist nur für den persönlichen, nicht gewerblichen Gebrauch bestimmt.
Eine Verwendung dieses Feeds auf anderen Webseiten verstößt gegen das Urheberrecht. Wenn Sie diesen Inhalt nicht in Ihrem News-Reader lesen, so macht sich die Seite, die Sie betrachten, der Urheberrechtsverletzung schuldig. (digitalfingerprint: bbd2a4c375bd3a68829f8cc22c8ac04d (38.107.179.230) )
Permalink |
Kein Kommentar |
Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena

Schlagwörter: Gurken Subscribe to Comments, Mail-Abo, Plugins, Subscribe to Comments, Subscribe to Double-Opt-In Comments, WordPress




Neues Layout für Handy und PDA
Dieter — Sun, 09 Aug 2009 16:28:06 +0000
Vor einigen Wochen hatte ich hier das Layout für Handy, PDA und iPhone mittels des Plugins WordPress PDA & iPhone deaktiviert.
Ursächlich dafür war, dass ich auf Webseiten-Infos.de unter Blog auch eine Template-Datei ohne WordPress-Loop einsetze und diese Seite dann beim Betrachten mit Handy oder PDA keinen Inhalt anzeigte. Danke an Ute, die mich hierauf aufmerksam machte. Sie war zwar mit dem normalen Layout auf ihrem iPhone zufrieden, aber andere mobile Geräte haben meistens eine noch kleinere Bildschirmauflösung und dann ist ein reduziertes und angepasstes Layout für diese Geräte sinnvoll.
Thomas Scholz aka toscho brachte mir mit seinem Link zu dem Blogbeitrag “The 5-Minute CSS Mobile Makeover” wieder in Erinnerung, dass ich da eine noch offene Baustelle habe.
Leider wird von vielen mobilen Browsern der Medientyp handheld nicht unterstützt. Deshalb halte ich die Erkennung von mobilen Browsern über den User Agent, wie sie auch von vielen WordPress-Plugins praktiziert wird, derzeit für die bessere, da effektivere Alternative.
Heute habe ich mit Hilfe des WordPress-Plugins WP viewMobile ein neues Layout für Handy und PDA erstellt, also diese offene Baustelle endlich geschlossen.
Die Vorteile des WordPress-Plugins WP viewMobile liegen für mich darin, dass

es mit einem deutschen Theme und deutsch im Administrationsbereich (Backend) daher kommt,
ich eigene Themes hinzufügen und anpassen kann,
sich die Erkennung der mobilen Browser anpassen lässt.

Ein mobiles CSS-Layout sollte aus meiner Sicht insbesondere berücksichtigen, dass

eine kleinere Bildschirmfläche und -auflösung als bei Monitoren von Computern zur Verfügung steht,
in der Regel die Datenübertragungsgeschwindigkeit / -rate niedrig ist und
Funktionalitäten, die lediglich mit Computer genutzt werden können, entfernt werden sollten.

Zur Umsetzung habe ich dafür

das modifizierte WordPress-Theme YAML Green in den Theme-Ordner des WordPress-Plugins WP viewMobile kopiert,
dann YAML Green auf der Seite Optionen für das Plugin WP viewMobile im Administrationbereich (Backend) ausgewählt und die Einstellung entsprechend aktualisiert,
in der functions.php des YAML Green-Themes im Theme-Ordner des WordPress-Plugins WP viewMobile den CSS-Code im Kopfbereich (Header) sowie für die Conditional Comments gelöscht / entfernt,
ein vereinfachtes mobiles CSS-Layout erstellt, das

möglichst den geringen Bildschirmplatz auf Handys und PDAs optimal nutzt,
möglichst wenig Bandbreite benötigt,
die Breite der Formularelemente begrenzt, damit der Opera Mini die Webseiten nicht auf maximale Breite zieht.



Sehr wahrlich

fehlen noch einige User Agents, so dass noch nicht alle mobile Browser erkannt werden, und
gibt es noch Verbesserungsbedarf und -möglichkeiten bei diesem mobilen CSS-Layout.

Getestet habe ich das mobile CSS-Layout

mit dem Opera Mini 4 auf meinem Handy Sony-Ericsson P990i,
mit dem Opera Mini Simulator und
mit dem iPhone-Simulator.

Der iPhone-Simulator funktionierte allerdings erst, nachdem ich mittels dem Firefox-Addon User Agent Switcher und der importierten XML-Liste von Mobilgeräten, als User Agent für den Firefox das iPhone auswählte.
Darüber hinaus probierte ich den Seitentest unter ready.mobi aus. Das Ergebnis war zwar vernichtend, aber die dort zum Emulationstest aufgeführten Mobilgeräte sind aus meiner Sicht eh nicht zum mobilen Surfen geeignet. Vielmehr gehören die schon ins Museum. Anscheinend hat das auch der Betreiber der Website ready.mobi erkannt, denn die Website lies sich nicht mehr  aufrufen (Stand: 24. Mai 2010).
Hier noch der Link zu meiner mobilen CSS-Datei.



Für Verbesserungshinweise und -vorschläge mittels Kommentar oder Mail bin ich jederzeit dankbar.
Kommentare
9. August 2009, Micha schreibt: Ich warte nur noch auf den Tag, an dem du dein erstes Theme veröffentlichst :)
9. August 2009, Dieter schreibt: @Micha
Man soll ja nie nie sagen, aber das überlasse ich lieber Profis wie Dir und Heiko. :-)
Und diesbezüglich hast Du mir ja schon den Mund wässrig gemacht. Ich sage nur Xtreme One-Theme. :-)
9. August 2009, Ute schreibt: Hi Dieter,

sorry ich schon wieder und das ichphone... 

Leider bin ich schon wieder nicht glücklich. Das Theme lässt mich Beiträge wieder nur mit quer scrollen lesen. Das ist mühsam.

Alles andere sieht gut aus, falls dieser Kommentar auch noch ankommt. ;)
10. August 2009, Dieter schreibt: @Ute
Danke für Deinen Hinweis und die Screenshots.

Ich will ja nicht unken, aber interpretiert das iPhone den Media Querie max-device-width: 480px als width auch für die vertikale Nutzung des Browsers?

Testweise habe ich jetzt mal max-device-width auf 320px geändert und die Seitenvergrößerung (den Zoom) freigegeben. Verstehe sowieso nicht, warum bei "The 5-Minute CSS Mobile Makeover" empfohlen wird diese abzustellen.

Wäre Dir und allen Lesern die ein iPhone haben sehr dankbar, wenn die Zugänglichkeit dieser Seiten mit dem iPhone testet. Scheint ja - im Gegensatz zum Opera Mini - leider mit dem Simulator nicht richtig zu funktionieren. :-(
10. August 2009, Dieter schreibt: So die Benutzerkennungen für das iPhone und den iPod Touch habe ich beim WordPress-Plugin WP viewMobile herausgeworfen. Nun sollten diese mobilen Geräte halt das Standardlayout von Webseiten-Infos.de für Computerbildschirme erhalten (siehe hierzu auch meinen neuen Blogbeitrag "iPhone-Simulatoren sind für die Tonne!").
17. Juli 2011, Susanne schreibt: Also mir gefällt es, schaut auf alle Fälle professioneller aus als bei mir...
17. Juli 2011, Dieter schreibt: Danke!
Nur so als Tipp: Wenn der Benutzername zum Impressum der angegebenen Website gepasst hätte, wäre der Link auch drin geblieben.
10. Dezember 2011, iPhone-Simulatoren sind für die Tonne! | Webseiten-Infos.de schreibt: [...] Gestern hatte ich mein neues Layout für Handy und PDA vorgestellt (siehe hierzu meinen Blogbeitrag “Neues CSS-Layout für Handy und PDA“). [...]
10. Dezember 2011, WordPress-Plugin PDA & iPhone in Deutsch | Webseiten-Infos.de schreibt: [...] die Darstellung von Webseiten-Infos.de auf Handy und PDA kannst Du in meinem Blogbeitrag “Neues Layout für Handy und PDA” [...]
Ähnliche Beiträge
Und der Gewinner des Buches ist…
iPhone-Simulatoren sind für die Tonne!
WordPress-Plugin PDA & iPhone in Deutsch
Layout von Webseiten-Infos.de geändert
Verschenke Buch CSS-Layouts von Dirk Jesse
Copyright © 2010 Dieter Welzel
Dieser Feed ist nur für den persönlichen, nicht gewerblichen Gebrauch bestimmt.
Eine Verwendung dieses Feeds auf anderen Webseiten verstößt gegen das Urheberrecht. Wenn Sie diesen Inhalt nicht in Ihrem News-Reader lesen, so macht sich die Seite, die Sie betrachten, der Urheberrechtsverletzung schuldig. (digitalfingerprint: bbd2a4c375bd3a68829f8cc22c8ac04d (38.107.179.230) )
Permalink |
9 Kommentare |
Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena

Schlagwörter: CSS, Firefox, Firefox-Addon, Handheld, Handy, iPhone, Layout, PDA, Plugins, User Agent, Webseiten, WordPress, YAML, YAML Green




Ursache des enormen Speicherbedarfs gefunden!
Dieter — Mon, 27 Jul 2009 20:11:08 +0000
Das Aktualisieren (Updaten) dieser WordPress-Installation auf WordPress 2.8.x ging mit einem enormen zusätzlichen PHP-Speicherbedarf einher (siehe hierzu meinen Blogbeitrag “Webseiten-Infos.de auf WordPress 2.8.1 aktualisiert“).
Mit WordPress 2.7.1 und vielen Plugins betrug im Administrationsbereich (Backup) der PHP-Speicherbedarf bereits beachtliche 28 bis 30 MB. Bei meinem vorhergehenden Hoster one.com gab es aber eine PHP-Speicherbegrenzung (ein PHP-Memory-Limit) von 24 MB, das nicht erhöht werden konnte. Deshalb war ich zu alfahosting.de gewechselt (siehe hierzu den Blogbeitrag “In eigener Sache: Umzug zu Alfahosting“).
Die PHP-Speicherbegrenzung und -Speicherauslastung kannst Du übrigens beispielsweise mit den Plugins WP Security Scan und WP System Health überprüfen.
Inzwischen hat der Autor des WordPress-Plugins WP System Health, Heiko Rabe, die wohl wichtigste Ursache des enormen zusätzlichen PHP-Speicherbedarfs beim Aktualisieren (Updaten) von manchen WordPress-Installationen auf WordPress 2.8, 2.8.1 bzw. 2.8.2 gefunden:
Sofern der Hoster als Plattform ein 64Bit-System einsetzt, verdoppelt sich beim Wechsel auf WordPress 2.8.x der Speicherbedarf fast. Anscheinend werden dann fast doppelt so große Speicherblöcke durch WordPress belegt (siehe hierzu den Blogbeitrag “Enormer PHP-Speicherverbrauch – Ursache gefunden?!” bei WordPress-Deutschland.org). Mit dem Plugin WP System Health kannst Du über Details beim Server Setup auch feststellen, ob bei Deinem Hoster als Plattform ein 32- oder 64Bit-System zum Einsatz kommt.
Sofern Dein Hoster als Plattform ein 32Bit-System verwendet, musst Du mit einem etwa 4 MB höheren PHP-Speicherbedarf bei einer Aktualisierung (einem Update) Deiner WordPress-Installation von der Version 2.7.x zu 2.8.x ausgehen. Bei einem 64Bit-System ist dagegen der PHP-Speicherbedarf deutlich höher.
Etwas lässt sich der Speicherhunger von WordPress 2.8.x jedoch durch den Austausch der für die Verarbeitung der (deutschen) Sprachdateien zuständigen Datei mo.php durch eine Betaversion von Heiko Rabe reduzieren. Die diesbezüglichen Einzelheiten und die gezippte Datei gibt es im Blogbeitrag “WordPress 2.8 – Sprachdatei Speicherverbrauch minimieren” und eine erste Analyse zu dem Betatest unter “WordPress Sprachdateiverarbeitung Betatest – erste Analysen” auf code-styling.de.
Ich habe übrigens diese geänderte mo.php von Heiko Rabe bereits hier im Einsatz. Sie reduzierte den PHP-Speicherverbrauch um 4,6 MB!
Probleme: Bisher keine!
Kommentare
27. Juli 2009, Ute schreibt: Heftig, dass nur die optimierte Sprachdatei schon so viel ausmacht. Allerdings meine ich ist das ein weiterer Negativpunkt für WordPress. 

Aus meiner Sicht spricht inzwischen schon einiges gegen WP, wäre ein Wechsel nicht so aufwändig, hätte ich es wohl schon getan.

Ich fürchte der hohe Marktanteil tut einfach nicht gut, schade...
27. Juli 2009, Dieter schreibt: @Ute
Seltsam auch, dass der erhöhte Speicherverbrauch bei 64Bit-Systemen erst mit WP 2.8 auftritt. Da müssen die Entwickler wohl etwas unter der Haube verändert haben.

In der Tat hält auch mich der hohe Aufwand von einem Wechsel zu einer anderen Software ab.

Allerdings gibt es für WordPress eine besonders aktive Online-Community und mit Abstand das umfangreichste Literaturangebot. Für mich als Autodidakt ist das wichtig.

Gäbe es das auch für eine andere Blogsoftware bzw. ein anderes CMS würde ich mich wohl leichter aufraffen und mal diese Software ausprobieren.
28. Juli 2009, Ute schreibt: Mich stört massiv, dass die Entwickler selbst bei bekannten Problemen manchmal keine Lösung suchen. Gekrönt von den Trackbackproblemen bis hin zu der Aussage, es wäre nicht nötig etwas zu ändern, weil das Problem ja nicht überall auftrete...

Bezogen auf Literatur ist WP sicher führend, auch hinsichtlich der Größe der Community, aber z.B. bei Serendipity scheint mir die Aktivität sehr hoch. Der direkte Kontakt zu den Entwicklern klappt besser. Außerdem gibt es nicht ständig Updates, die jedesmal ein Glücksspiel sind...

Bleibt noch der Aufwand des Wechselns, der relativiert sich jedoch bei der Updatefrequenz und der häufigen Fehlersuche...
28. Juli 2009, codestyling schreibt: @Ute: Eingangs schreibst du über den Marktanteil. Das ist einer der springenden Punkte. Wenn Serendipity das Plugin und Theme Volumen von WP erreicht, sieht es dort genauso aus. Mit steigender Codegröße (Total) wird es immer schwerer wartbar und erweiterbar und knabbert dann an den gleichen Problemen wie WP.
Sicher hat Serendipity den Vorteil, von Grund auf neu, OOP erschaffen und aus WP Fehlern gelernt zu haben, allerdings ist bei WP genau der OOP Ansatz das, was nun den Speicher kostet. Es ist derzeit schneller, kleiner und effizienter Arrays zu nehmen als Objekte, das wird sich frühestens mit PHP 6 ändern. Der Patch für die Sprachdateien entfernt OOP Code und macht alles wieder traditionell, was den Gewinn u.a. ausmacht.
28. Juli 2009, Dieter schreibt: @codestyling
Danke für Deine Erläuterung, warum WP 2.8.x mehr Speicher benötigt und für Deinen mo.php-Patch. :god: 

Deine Ausführungen zum OOP Code lassen mir die kleine Hoffnung, dass irgendwann auch mal wieder der PHP-Speicherbedarf etwas sinken könnte. 

Zum immens großen Marktanteil von WordPress dürften neben seiner Bereitstellung als Open-Source und der berühmt-berüchtigten 5-Minuten-Installation auch die große Anzahl an vielfältigen Plugins und Themes beigetragen haben. Dadurch ist es möglich WordPress ganz den individuellen Bedürfnissen und Wünschen anzupassen. :hurra:
28. Juli 2009, Ute schreibt: @codestyling s9y gibt es seit 2002, WP seit 2004. S9y hat daher sicher nicht aus WP-Fehlern gelernt. ;)

Der Ansatz ist einfach anders, statt unzählige Plugins für ein und dieselbe Funktion zuzulassen, gibt es nur je eins, welches dann jedoch so eingebunden wird, dass es sicher und stabil läuft.

Damit eignet sich s9y nicht für Spielkinder, die unzählige Features ausprobieren wollen. Es ist auch eher eine reine Blogsoftware und hat nicht den Anspruch alles zu können. 

Insofern sind die Systeme für viele keine Konkurrenten.
28. Juli 2009, codestyling schreibt: @Ute: WP entstand als Branch aus b2, s9y ist neu gegossen worden.
b2 wayback june 2001
WP wayback may 2003
s9y wayback june 2003

Wenn man b2 als WP ansieht, dann wurde daraus schon gelernt.

Ohne Zweifel hat s9y Vorteile, aber die Selbstbeschränkung steht der viralen Verbreitung eben auch im Weg, denn Otto Normalo kann nicht einfach etwas umsetzen, was er sich einbildet. Dazu muss er entweder programmieren können oder jemanden dafür bezahlen.
Bei WP kann man das in den Communities größtenteils umsonst bekommen.
28. Juli 2009, Dieter schreibt: @Ute
Ich habe mich mit Serendipity (s9y) noch nicht beschäftigt.

Wenn ich Dich richtig verstanden habe, dann ist es für mich hier keine Alternative, denn
- ich bin ein Spielkind (das die Vielzahl der Plugins und Themes ausprobiert) und
- ich setze WordPress nicht nur als Blogsoftware, sondern eben auch als CMS ein.

So gesehen wäre die Konkurrenz von WordPress für mich eher bei CMS, die auch Blogfunktionalitäten zur Verfügung stellen.
Aber den Einarbeitungsaufwand dafür scheue ich derzeit.
28. Juli 2009, Ute schreibt: @Dieter ich weiß es nicht, du bist zwar Spielkind, legst aber Wert auf sauberen Code und Geschwindigkeit. Bezogen auf CMS und Blogfunktionalität könnte Drupal noch eine Alternative sein... 

Wer weiß, falls du mal wieder ein neues Projekt startest, könnte es einen Versuch wert sein auch anderes anzuschauen...
28. Juli 2009, Dieter schreibt: @Ute
du bist zwar Spielkind, legst aber Wert auf sauberen Code und Geschwindigkeit
Jepp! Valider Code und gute Performance sind bei mir zentrale Entscheidungskriterien für die Software, Plugins und Themes.

Bezogen auf CMS und Blogfunktionalität könnte Drupal noch eine Alternative sein…
Ich habe schon mal an Typolight oder XOOPS gedacht. Ganz wichtig ist mir zudem ein Theme auf YAML-Basis. Für Drupal und Typolight gibt es das.

Wer weiß, falls du mal wieder ein neues Projekt startest, könnte es einen Versuch wert sein auch anderes anzuschauen…
Man(n) soll ja nie nie sagen, aber ich bekomme ja schon aktuell meine Projekte nicht oder kaum gebacken. Sollte ich ein Projekt aktualisieren, dann würde ich Drupal und Typolight auf jeden Fall als Alternativen prüfen.
29. Juli 2009, Ute schreibt: @codestyling
Mein Traum ist, dass es einfach Module gibt und nicht eine komplette Software. 

Ich hätte gern die Navi x, den Adminbereich y, das Theme z usw. Denn es gibt unzählige Systeme, die jedoch alle nicht genau so sind, wie ich es will. 

Unterm Strich habe ich immer nur die Wahl zwischen den Vor- und Nachteilen, die mir am wichtigsten sind.

Jede Software "erfindet das Rad neu" statt Gutes zu behalten und nur Nachteiliges neu zu entwickeln, werden so neue Fehler eingebaut.

Bis sich mein Traum erfüllt, bleibt es dabei, dass jeder für sich entscheiden muss, welche Software den eigenen Bedürfnissen am nächsten kommt.
3. August 2009, Peter schreibt: > Ich habe schon mal an Typolight ... gedacht 

TYPOlight ist ein tolles CMS, aber in erster Linie hierarchische, seitenbasierte Websites gedacht. Einen Blog kann man damit nicht wirklich betreiben . 

Drupal ist eine eierlegende Wollmilchsau. Der Einstieg ist "die Hölle", aber danach kann man, wenn man den Drupalianern Glauben schenkt, damit alles machen. 

Beide Systeme sind m. E. kein Ersatz für WordPress als Blog. Das ist eine andere Liga. Ersatz für WP wären wohl eher Textpattern, Expression Engine oder S9Y.
4. August 2009, Dieter schreibt: @Peter
Im Interview auf hyperkontext.at hast Du ja schon verraten, dass Du Typolight ausführlich getestet hast. Gibt es denn bei den wohl rd. 200 Plugins kein Plugin mit guter Blogfunktionalität?

Für Drupal gibt es ja schon ein paar Bücher und eine YAML-Integration. Damit sind schon mal für mich wichtige Kriterien erfüllt. Allerdings schreckt mich da ab, dass es wohl relativ viel Ressourcen verbraucht und dann schnell langsam werden soll. Und wenn Du schon auf die Aussage "Der Einstieg ist die Hölle" verlinkst, dann ist das schon eine Warnung für mich.

Ersatz für WP sind aber die anderen Blogangebote nicht, denn für die gibt es nicht viel Literatur, keine YAML-Integration (die Seite für YAML mit der  Expression Engine ist wohl seit über einem Jahr nicht erreichbar), nicht soviele Plugins und die Kombination aus CMS mit Blog ist dort wohl auch nicht so einfach wie mit WP zu realisieren.

Wäre da noch Typo3, aber die Lernkurve dafür soll mir zuviel Ausdauer erfordern und ich habe keine Lust eine eigene Skriptsprache erlernen zu müssen.

Da werde ich also wohl doch lieber bei WordPress bleiben. Kann dann ja dafür hin und wieder über die häufigen (Sicherheits-) Updates und nicht behobenen Problemchen (Speicherverbrauch im Backend, Pingback-Problem etc) mein Leid klagen.
7. September 2009, WordPress und der Speicherverbrauch » Peruns Weblog schreibt: [...] erste Link führt zum Beitrag von Dieter Welzel. Dort werden zwei Gründe aufgeführt warum eine WordPress-Installation verhältnismäßig viel [...]
4. Oktober 2009, Sebo schreibt: Jo genau diese Probs kenne ich auch, hatte sogar mal nen richtig fetten Absturz, es lag an der Speicherreservierung. Zum Glück gibt es ja jede Menge Plugins für WP
4. Oktober 2009, Dieter schreibt: @Sebo
Ich kenne kein Plugin, das das hier beschriebene Problem des hohen Speicherverbrauchs behebt.
Kennst Du eins?

Lediglich zur Ermittlung des Speicherbedarfs im Administrationsbereich (Backend) gibt es ein paar gute Plugins wie beispielsweise das im Blogbeitrag verlinkte WP System Health.
23. Februar 2010, Daniel schreibt: Also ich habe zwar ein Webhosting-Paket mit mehr Arbeitsspeicher, bzw. wo ich mehr davon freischalten lassen kann..allerdings habe auch ich gemerkt, dass da irgendwas nicht stimmt.
Ich finde aber nach wie vor, dass WordPress das perfekte CMS für die "Sterblichen" ist. Drupal, TYPO3 & Co. sind zwar größer und können letztendlich ein bisschen mehr, allerdings sind sie auch viel komplexer und bei weitem nicht so benutzerfreundlich wie WordPress.

Oder seht ihr das anders?
23. Februar 2010, Dieter schreibt: @Daniel
Habe mal Typolight angetestet und den Eindruck, dass der Einstieg in dieses CMS für mich zu aufwändig ist.
WordPress ist einfach einfach. ;-)
21. Dezember 2011, WordPress: Wider dem Katastrophen-Gerede | Webseiten-Infos.de schreibt: [...] (Update) ein Wechsel des Hosters notwendig werden kann (siehe hierzu meine Blogbeiträge “Ursache des enormen Speicherbedarfs gefunden!“, “Umzug zu einem anderen Webhoster” und “In eigener Sache: Umzug zu [...]
Ähnliche Beiträge
Webseiten-Infos.de auf WordPress 2.8.3 aktualisiert
Webseiten-Infos.de auf WordPress 2.8.5 aktualisiert
Webseiten-Infos.de auf WordPress 2.8.4 aktualisiert
Webseiten-Infos.de auf WordPress 3.0 aktualisiert
Angriffe auf alte WordPress-Installationen
Copyright © 2010 Dieter Welzel
Dieser Feed ist nur für den persönlichen, nicht gewerblichen Gebrauch bestimmt.
Eine Verwendung dieses Feeds auf anderen Webseiten verstößt gegen das Urheberrecht. Wenn Sie diesen Inhalt nicht in Ihrem News-Reader lesen, so macht sich die Seite, die Sie betrachten, der Urheberrechtsverletzung schuldig. (digitalfingerprint: bbd2a4c375bd3a68829f8cc22c8ac04d (38.107.179.230) )
Permalink |
19 Kommentare |
Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena

Schlagwörter: Plugins, Speicherbedarf, Sprachdatei, Update, WordPress, WordPress 2.8.x, WP Security Scan, WP System Health




WordPress-Plugin YARPP macht Probleme
Dieter — Fri, 24 Jul 2009 16:55:52 +0000
Das WordPress-Plugin Yet Another Related Posts Plugin (YARPP) ist eine feine Sache. Damit hatte ich bisher zu dem jeweiligen Blogbeitrag passende weitere Blogbeiträge einblenden lassen.
Leider stellte ich mit der Version 3.1.8 des Plugins als auch mit der Beta-Version 3.1.8b2 fest, dass die Seite zum Einstellen der Optionen im Administrationsbereich (Backend) keinen Inhalt mehr anzeigt. Deshalb hinterließ ich im Supportforum für Hacks und Plugins von WordPress.org einen diesbezüglichen Beitrag.
Bei der Suche nach einer Fehlerbehebung bin ich dann auf das Plugin Related Posts by Category von Sergej Müller gestoßen. Dieses funktioniert einwandfrei mit WordPress 2.8.2.
Zwar musste ich bei diesem Plugin PHP-Code in die Template-Dateien single.php, blog.php und archive.php des modifizierten WordPress-Themes YAML Green kopieren, aber das war es auch fast schon.
Noch die Parameter nach meinen Bedürfnissen angepasst, 
, 
,  und 
 sowie den Text ”Das könnte Dich auch interessieren:”
 ergänzt, das Ganze mit CSS gestaltet und fertig ist der Verweis auf ähnliche Blogbeiträge.
Mal wieder bin ich von einem Plugin von Sergej Müller ausgesprochen angetan. Klein, aber fein.
Ich habe von ihm schon die Plugins Antivirus, Antispam Bee und wpMAPS im Einsatz und bin damit sowie seinem Support sehr zufrieden.
Nachtrag vom 25. Juli 2009:
Sergej Müller hat auf der Webseite zum Plugin Related Posts by Category auch die Parameter dafür erklärt.
Aber vielleicht interessieren ja den einen oder anderen Leser auch die von mir verwendeten Parameter, die Ergänzungen im PHP-Code sowie meine Gestaltung mit CSS. Deshalb hier nachträglich noch

der in die single.php, blog.php und archive.php eingebaute PHP-Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21


Das könnte Dich auch interessieren:




 related_posts_by_category(

  array(

    'orderby' => 'post_date',

    'order' => 'DESC',

    'limit' => 5,

    'echo' => true,

    'before' => '',

    'inside' => '',

    'outside' => '',

    'after' => '
',

    'rel' => 'follow',

    'type' => '',

    'message' => 'Noch keine ähnlichen Beiträge'

  )

);

?>




Und der in die green_2col_right.css nur für diese ähnlichen Beiträge eingebaute CSS-Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
.relatedpost 

{

padding: 1em;

border: 1px solid #0C5005;

font-size: 100%;

margin-bottom: 3em;

padding-bottom: .5em;

box-shadow: 5px 5px 5px #888;

-moz-box-shadow: 5px 5px 5px #888;

-khtml-box-shadow: 5px 5px 5px #888;

}

.relatedpost p 

{

font-size: 125%;

font-weight: bold;

margin-bottom: .5em;

}

.relatedpost li 

{

margin-left: .25em;

}
Nachtrag vom 10. Oktober 2009:
Inzwischen setze ich das Plugin Simple Tags auch für das Anzeigen von Blogbeiträgen und Artikeln mit gleichen Schlagwörtern (Tags) unter der Überschrift “Verwandte Themen” in der rechten Spalte (Sidebar) ein (siehe hierzu meinen Blogbeitrag “Artikel mit gleichen Schlagwörtern zeigen“).
Aktuell versuche ich die Komplexität der Seiten von Webseiten-Infos.de zu verringern. Dabei lasse ich mich von dem KISS-Prinzip (“Halte es einfach und leicht verständlich”; sinngemäß: “In der Kürze liegt die Würze”) und dem Gedanken leiten, möglichst das Grundrauschen wieder etwas zu verringern.
Da meine Kategorien thematisch eher breit angelegt sind und manche Blogbeiträge auch mehrere Kategorien betreffen, habe ich heute den Code für das WordPress-Plugin Related Post by Category wieder aus den Theme-Dateien entfernt und dieses Plugin deaktiviert.
Kommentare
24. Juli 2009, Sergej Müller schreibt: Freut mich. Dann hast du bald mehr von meinen Plugins als ich selbst ;)
24. Juli 2009, Micha schreibt: Ja, das Plugin ist schön schlank und schnell. Ich habe es auch bei mir im Einsatz.
24. Juli 2009, Dieter schreibt: @Sergej
Kann schon sein, zumal ich versehentlich Deine Anpassung von Our ToDo List auch noch unterschlagen habe. Das sind inzwischen fünf Plugins von Dir!
Nur von Frank Bueltge habe ich hier noch mehr, nämlich sechs Plugins im Einsatz.

PS: Vorhin fiel mir ein, dass ich auch noch den von mir verwendeten PHP- und CSS-Code posten könnte. Werde ich noch nachholen.
24. Juli 2009, Dieter schreibt: @Micha
Vielleicht bilde ich mir das ja nur ein, aber ich habe den Eindruck, dass nun die Blogseiten schneller laden. Fast so als hätte jemand nach dem Deaktivieren von YARPP und dem Aktivieren von Related Posts by Category die Handbremse gelöst.
24. Juli 2009, Sergej Müller schreibt: Ich kenne das andere Plugin nicht, aber meine Lösung kommt nur mit einer komprimierten Abfrage aus. Und da du nur 7 Kategorien hast, bewegt sich die Abfrage im Millisekundenbereich.
25. Juli 2009, Dieter schreibt: @Sergej
YARPP bot zwar mehr Optionen, aber dafür kann es auch negative Auswirkungen auf die Perfomance haben (siehe FAQ des Plugin-Autors).
Deine Lösung ist also definitiv schneller.
19. September 2009, Hans schreibt: Genau was ich gesucht habe... Thx for sharing! VG, Hans
19. September 2009, Dieter schreibt: @Hans
Bitte schön. ;-)
16. November 2009, elcario schreibt: Danke für den Link zum Supportthread. Ich hatte den YARPP-DISQUS Bug und fand so ein Workaround. Merci!
17. November 2009, Dieter schreibt: @elcario
Bitte schön. Gern geschehen!
13. April 2010, Leo schreibt: Das Problem bei steigender Anzahl an Plugins, dass sich da oft mal eingebundene Javascript Bibliotheken in die Quere kommen. Hatte daher auch schon oft Probleme. Allerdings hat sich mittlerweile jQuery als Standard herauskristallisiert, was mich sehr freut. YARPP gehört übrigens auch zu meinen Favoriten ;-)
13. April 2010, Dieter schreibt: @Leo
jQuery ist sehr beliebt und inzwischen in der Tat schon ein Quasi-Standard als JavaScript-Bibliothek. Gleichwohl verzichte ich aus Performance-Gründen auf Webseiten-Infos.de bewusst auf JavaScript-Bibliotheken.

YARPP gehört übrigens auch zu meinen Favoriten ;-)
Wieso auch gehört? Auch "gehörte" hätte gepasst, den ich setze schon seit einigen Monaten stattdessen auf das WordPress-Plugin Simple Tags (siehe Nachtrag vom 10. Oktober 2009)! ;-)
Ähnliche Beiträge
Artikel mit gleichen Schlagwörtern zeigen
HTML-Kommentare von WordPress-Plugins entfernen
Problemlösungen für Update auf WordPress 2.9
Plugin FV Code Highlighter
Plugin für ToDo-Liste im Administrationsbereich
Copyright © 2010 Dieter Welzel
Dieser Feed ist nur für den persönlichen, nicht gewerblichen Gebrauch bestimmt.
Eine Verwendung dieses Feeds auf anderen Webseiten verstößt gegen das Urheberrecht. Wenn Sie diesen Inhalt nicht in Ihrem News-Reader lesen, so macht sich die Seite, die Sie betrachten, der Urheberrechtsverletzung schuldig. (digitalfingerprint: bbd2a4c375bd3a68829f8cc22c8ac04d (38.107.179.230) )
Permalink |
12 Kommentare |
Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena

Schlagwörter: Blogbeiträge, interne Verlinkung, Plugins, Related Posts by Category, WordPress, YAML Green, YARPP




HTML-Kommentare von WordPress-Plugins entfernen
Dieter — Mon, 20 Jul 2009 05:40:31 +0000
Einige WordPress-Plugins wie beispielsweise All in one SEO Pack und Pagebar schreiben HTML-Kommentare in den Quelltext der WordPress-Seiten.
Inhalt eines solchen HTML-Kommentars ist meistens ein Hinweis auf das Plugin und seine Version.
Bei All in SEO Pack sieht er im Quelltext (Quältext) aktuell wie folgt aus:
1

und
1

Und bei Pagebar sieht er beispielsweise so aus:
1

Diese HTML-Kommentare sind weder für die Nutzung und Funktionsfähigkeit des jeweiligen Plugins erforderlich noch benötige ich sie beim Arbeiten an meinem Blog oder dessen Betrieb.
Vielmehr stellt der HTML-Kommentar von All in one SEO Pack lediglich ein Branding und von Pagebar eine Supportmöglichkeit dar, auf die ich gerne verzichte. Durch deren Entfernen wird der Quelltext der betroffenen WordPress-Seiten von Ballast befreit und Dritte können nicht durch Ansehen des Quelltext erkennen, dass ich diese Plugins verwende. Vorsorglich in diesem Zusammenhang der Hinweis, dass Du die folgende Modifizierung von Plugin-Dateien nur vornehmen solltest, wenn Du beim Einsatz der Plugins keine Probleme hast und schon etwas HTML- und PHP-Code lesen kannst.
Da es jedem – und mir als Nichtprogrammierer im Besonderen – passieren kann, dass man aus Versehen einen Fehler beim Entfernen der entsprechenden PHP-Code-Bestandteile macht, ziehe ich es vor die entsprechenden Codezeilen lediglich auszukommentieren. Hierzu verwende ich // vor den entsprechenden Codezeilen.
Bei der Datei aioseop.class.php des Plugins All in one SEO Pack sehen dann die betroffenen Codezeilen – bei mir Zeilen 203 bis 208 – wie folgt aus:
1
2
3
4
5
6
// echo "\n\n";
und – bei mir die Codezeile 329 -
1
// echo "\n";
und bei der Datei class-basebar.php des Plugins Pagebar – bei mir Codezeile 180 -
1
// echo "";
Nach dem Auskommentieren solltest Du die Funktionsfähigkeit Deines WordPress-Blogs und der Plugins unbedingt noch überprüfen.
Ein Nachteil dieser manuellen Nachbearbeitung von Plugin-Dateien soll allerdings nicht verschwiegen werden: Mit jeder Aktualisierung des jeweiligen Plugins ist eine erneute Nachbearbeitung notwendig. Bei Plugins wie All in one SEO Pack, die häufig aktualisiert werden, kann das schon lästig werden.
Kommentare
21. Juli 2009, Latz schreibt: Diese Kommentare sind nicht nur zum "Branding" da. Im Fall von "pagebar" habe ich diesen Kommentar vielmehr als Supportmöglichkeit eingebaut:
Manchmal haben Benutzer Probleme mit dem Plugin und wissen nicht genau welche Version sie benutzen und wissen manchmal auch nicht, wie sie es herausfinden sollen. Anstatt jetzt umständlich per EMail zu erklären, wie man das macht, kann ich so einfach auf die Webseite gehen und nachsehen.

Wollte ich ein "Branding", so würde ich nicht kyryptisch "pb25p1", sondern "pagebar v2.5 preview 1 by elektroelch" schreiben.
21. Juli 2009, Dieter schreibt: @Latz
Danke für Deinen Hinweis.

Die Variante Supportmöglichkeit für Plugin-Nutzer hatte ich nicht gesehen. Dafür bin ich anscheinend mit WordPress schon zu vertraut und unzulässigerweise von mir ausgegangen.

Ich werde diesen Blogbeitrag entsprechend ergänzen bzw. korrigieren. Nochmals Danke für Deine Klarstellung.
Ähnliche Beiträge
Danke für Eure Kommentare
Mail-Abos für Kommentare sind weg!
Kommentar-Spam bekämpfen
Kommentare abonnieren
Vorsicht beim Updaten von Plugins!
Copyright © 2010 Dieter Welzel
Dieser Feed ist nur für den persönlichen, nicht gewerblichen Gebrauch bestimmt.
Eine Verwendung dieses Feeds auf anderen Webseiten verstößt gegen das Urheberrecht. Wenn Sie diesen Inhalt nicht in Ihrem News-Reader lesen, so macht sich die Seite, die Sie betrachten, der Urheberrechtsverletzung schuldig. (digitalfingerprint: bbd2a4c375bd3a68829f8cc22c8ac04d (38.107.179.230) )
Permalink |
2 Kommentare |
Seite speichern bei Twitter | Mister Wong | del.icio.us | Y!GG | Linkarena

Schlagwörter: Branding, HTML-Kommentar, PHP, Plugins, Support, WordPress