Skip to content

Texte in anderer Größe als der Rest - WordPress - Formatierung

Screenshot WordPress-Editor tinymce - weitere Formatierungen einblendenDer WordPress-Editor, insbesondere der visuelle ermöglicht es ja ganz einfach Texte zu schreiben, ohne überlegen zu müssen, wie solch ein Text im Quelltext später aussieht. Immer mal wieder werde ich gefragt, was in einem betreuten Blog kaputt sein könnte, wenn Text plötzlich nicht so aussieht, wie gewünscht. Mal ist ein Teil des Textes zu groß, mal zu klein, mal sieht ein ganzer Beitrag nicht so aus wie gewohnt.
"Texte in anderer Größe als der Rest - WordPress - Formatierung" vollständig lesen

WordPress: Kategorie nicht im Haupt-Feed - nicht auf Startseite

WordPress-Admin KategorienNoch ein letzter Tipp in der Runde zum WordPress-Gebastel auf uteles Blog. Der erste Artikel war eher allgemein, im zweiten ging es um Änderungen und Bugs, im dritten um den Bilderservice im Blog, statt eines Fremdservice.

Gefunden habe ich unzählige Tipps zum Ausschließen einer Kategorie, ein bisschen überlegen musste ich, um das zu bekommen, was ich wollte.

  • Kategorie nicht im Gesamtfeed
  • Kategorie nicht auf der Startseite
  • Kategorie-Einzelfeed möglich für Interessierte
  • Artikel der Kategorie im Archiv anzeigen
"WordPress: Kategorie nicht im Haupt-Feed - nicht auf Startseite" vollständig lesen

WordPress-Gebastel - Bilderecke statt Fremdservice

uteles Blog die Kategorie Bildle statt Bilderservice - ScreenshotNoch eine Runde zum WordPress-Gebastel  auf uteles Blog. Der erste Artikel war eher allgemein, im zweiten ging es um Änderungen und Bugs.

Mein Ziel war eine Bilderecke, in der ich per Mail Bilder posten kann. Zum Hintergrund mehr auf uteles Blog. Ich möchte Bilder selbst posten können, ohne Services wie twitpic, twitter, identi.ca, pikchur, oder ähnliche zu nutzen. Um das in einem bestehenden Blog umzusetzen, ohne die Stammleser zu nerven, brauchte es einige Voraussetzungen:


"WordPress-Gebastel - Bilderecke statt Fremdservice" vollständig lesen

WordPress-Gebastel - Änderungen und Bugs

die 404 auf utele.eu ScreenshotIch schrieb ja schon eine erste Runde zum WordPress-Gebastel auf uteles Blog. Dieses Mal ein bisschen was zu den Änderungen und diversen Bugs.

  • WordPress passt selbst manches an: Gut gemeint, aber aus meiner Sicht zumindest irritierend. Ich suchte, warum sich keine Seiten aufrufen ließen, sobald irgendwelche Permalinks - außer der Standardvariante - eingestellt waren. Vergleichen mit einem Blog welches ähnlich aufgebaut ist, aber noch nicht auf dem gleichen Updatestand ist, hielt ich für eine gute Idee. Im Admin rief ich die Seite Permalinks auf, um nachzusehen, was da eingestellt ist. Dabei fiel mir dann auf, dass WP hierbei den Eintrag in der .htaccess ergänzt. Klar unterm Strich lag es nicht an den Umleitungsregeln, trotzdem mag ich es nicht, wenn eine Software ungefragt und ohne Info etwas ändert.

"WordPress-Gebastel - Änderungen und Bugs" vollständig lesen

WordPress-Blog überarbeitet

Screenshot utele.eu Design ab April 2013WordPress-Gebastel: Nein, nicht hier, das ist kein WordPress mehr, das ist ein Serendipity. Bei eigenen Seiten mag ich möglichst viele verschiedene Systeme, ich bleibe so in Übung und kann Neues erstmal selbst ausprobieren, bevor ich es in Kundenprojekten nutze. Mein persönliches Blog uteles Blog ist daher immernoch ein WordPress. In den letzten Jahren hat sich da manches bewegt und ich nutze es mittlerweile auch anders, als beim Start 2007.

Anfangs legte ich Kategorien an, die mir sinnvoll erschienen. Manche haben sich bewährt, sie enthalten dutzende Beiträge, die ein oder andere Kategorie hatte jedoch nur eine Handvoll Artikel. Ich ging einmal gründlich durch und passte da einiges an. Eine Kategorie kam neu hinzu, sie soll eine Bilderecke werden.


"WordPress-Blog überarbeitet" vollständig lesen

WordPress-Angriffen vorbeugen

Screenshot WordPress Passwort Auf twitter ging es heute morgen herum, es gibt Angriffe auf WordPress. Im ersten Moment werde ich immer leicht panisch, lese, schaue nach etwaigen Tipps, überprüfe alle WP-Blogs, die bei uns laufen und stelle dann fest: alles ist gut. :)

Kein von uns betreutes WordPress hat einen Nutzer admin, keins hat ein schwaches Passwort und alle nutzen ein Plugin, welches verhindert, verhindert, dass viele Loginversuche von einer IP möglich sind. Ja, gerade dieses Plugin hat auch schon dazu geführt, dass sich jemand nicht mehr einloggen konnte, weil er einfach mal verschiedene Passwörter probierte. Die Sperre der IP bleibt nicht, es ist einstellbar, wie lange gesperrt wird. Auf einem Blog habe ich inzwischen 1493 Sperrungen. Bis auf zwei, waren es alles Versuche mit dem Nutzer admin.



"WordPress-Angriffen vorbeugen" vollständig lesen

WordPress 3.2 mischt sich bei Browsern ein :(

  • IE6
  • IE5
  • IE8
  • Firefox 3.6 Ubuntu
  • Firefox 4 Win 7
WordPress unterstützt im Adminbereich inzwischen keinen guten alten IE6 mehr. Hätte ich wohl nicht so gemacht, aber das ist akzeptabel, irgendwann wären wir Webautoren das Ding ja schon gern mal los.

Fehlermeldungen in WordPress

Schockiert bin ich dagegen von den Monsterfehlermeldungen im Dashboard. Ich nutze - nicht übertrieben aktuell  aber auch nicht veraltet - einen Firefox 3.6 auf Ubuntu Maverick Meerkat. Für diesen Browser bekomme ich noch regelmäßige Updates. Trotzdem meint WP mit einer Monstermeldung mir sagen zu müssen:
"Dein Browser ist veraltet"
Ja, die Meldung lässt sich ausblenden, ja bei ersten Tests sieht es so aus, als käme sie auch nicht mehrfach. Trotzdem: Ungeübtere Nutzer werden überflüssigerweise erstmal irritiert sein. Ich kann auf die Anfragen warten, wenn ich bei Kunden die neue Version eingespielt habe. WordPress mischt sich hier in etwas ein, was für meinen Geschmack definitiv nicht mehr in Ordnung ist.

IE6

Hier eine dicke rote Meldung mit
"Du verwendest einen unsicheren Browser"
zu bringen, ist in Ordnung, das Ding (Internet Explorer) ist von 2001, da ist allmählich mal Zeit für ein Update.

IE5

Ups, besser IE5 als IE6, denn hier gibt's nur eine ockerfarbene aber keine rote Fehlermeldung. ;)

IE8

"Dein Browser ist veraltet"
Nunja, auf Windows 7 stimmt das, aber auf einem guten alten Windows XP kann gar kein IE9 installiert werden, insofern schon auch fragwürdig.

Firefox 3.6

"Dein Browser ist veraltet"
Das ist nicht in Ordnung, in meiner noch nicht veralteten Version von Ubuntu bekomme ich per automatischem Update keinen aktuelleren Firefox.

Firefox 4 auf Windows

"Dein Browser ist veraltet"
Für mich die Krönung des Ganzen, im Moment ist für mich Firefox 4 auf Windows durchaus, Stand der Dinge, auch wenn es bereits Firefox 5 gibt.

Sonstige Browser

Die Meldungen erscheinen nur bei den Mainstreambrowsern, mein Seamonkey 2.0.11 ist in Ordnung, obwohl es 2.2 bereits gibt.

Nutzer sollen selbst entscheiden

Für mich ist es in Ordnung bei schweren Mängeln zu informieren, gegen sehr veraltete Browserwarnungen innerhalb von WordPress habe ich nichts. Aber das gilt für mich für Internet Explorer kleiner gleich IE7, ebenso bei alten Firefoxversionen, für die es keine Updates mehr gibt. WordPress jedoch teilt die Welt in gut und böse, wie es grad dem jeweiligen Entwickler passend erschien. Das ist für mich Einmischung und ärgerlich. Daran ändern  - wie erwähnt - auch die ausblendbaren Warnungen nichts.

Ups: nicht gut! :( WP-Touch gehackt und WordPress 3.1.4

Wie schon öfter erwähnt, bin ich ja nicht unbedingt begeistert von der Anzahl der Updates bei WordPress, auch jetzt gerade steht ein sicherheitsrelevantes Update vor der Tür: Häufig bin ich eher genervt übers soundsovielte Update.

Pluginverzeichnis auf wordpress.org gehackt

Richtig schlecht ist jedoch das wohl gehackte Pluginsverzeichnis auf Wordpress.org :( Weitere Infos siehe auch: WP-Pluginverzeichnis gehackt Laut den deutschen WordPressentwicklern, haben sich Unbekannte Zugriff auf das offizielle Pluginverzeichnis verschafft und die drei populären Plugins AddThis, WPtouch und W3 Total Cache mit einer Backdoor ausgestattet. Durch diese Hintertür könnte wohl auf das betroffene System zugegriffen werden. Aus Sicherheitsgründen wurde alle Passwörter zurückgesetzt, darüber hatte ich mich gestern noch gewundert, die Meldung las ich jedoch heute eher zufällig, weil ich nach dem Update schaute. :( Wer in den letzten Tagen eins der Plugins aktualisiert oder installiert hat – sollte dringend auf die neue Version aktualisieren und das eigene Passwort ändern.

Passwörter zurückgesetzt

Erstaunlich ist allerdings die schnelle Reaktion mit dem Rücksetzen aller Passwörter. Leider hatte ich es bis heute mittag nicht mitbekommen, dass da ein dickeres Problem ist. Vielleicht erfährt ja jemand durch diesen Artikel davon. Ich habe jedenfalls mal überall die betroffenen Plugins aktualisiert, die eventuell die Backdoor enthalten haben könnten.

Blogs für andere Nutzer anlegen ::: WP-MU mit BuddyPress

  • Soziales Netzwerk mit BuddyPress Blogportal BuddyPress mit WP MU
Ab und zu kommt es vor, dass jemand Probleme beim Blog anlegen hat und ich als Administratorin dann helfen sollte. Mein erster Versuch war nicht so erfolgreich, weil das Blog anschließend mir gehörte und es scheint keine Einstellung zu geben, die den ursprünglichen Besitzer des Blogs nochmal ändern kann. Meine Befürchtung war, dass ich beim Anlegen bereits eine Bestätigung bräuchte, deshalb gab ich meine E-Mailadresse ein. Nachdem es so nicht klappte testete ich nochmal und stellte fest, dass das nicht so ist, selbst dann nicht, wenn noch kein Benutzer existiert. Ganz einfach klappt es auf folgendem Weg:
  • Blog anlegen mit gewünschtem Namen und gewünschter Adresse
  • Mailadresse des Administrators legt den Blogbesitzer fest
Beim Anlegen des ersten Artikels, wird zunächst auch immer der eingeloggte Nutzer als Admin genommen, jedoch kann im Beitrag der Autor geändert werden und so als Beitrag des Blogbesitzers angegeben werden. Jetzt versteht auch BuddyPress korrekt, wem das Blog gehört und ordnet es dem gewünschten Besitzer zu. :) Tja, "kaum macht man's richtig geht's" ;)

Aktualisierungswahnsinn bei WordPress ::: die ständigen Updates

Ich betreue einige WordPress-Blogs und das nicht nur als Hobby. Ich habe mich inzwischen ja auch schon mehr als einmal dazu geäußert, was mich an WordPress deutlich stört, siehe die diversen Artikel auch dazu in der Kategorie WordPress. Ein erster Blick z.B. auf Wikipedia scheint gar nicht so schlimm, denn die neuen Versionen wurden wie folgt veröffentlicht:

WordPress-Versionen 2008 und 2009

  • WordPress Versions- und Pluginupdates Hinweise WordPress aktualisieren
  • WordPress 2.5 erschien im März 2008
  • WordPress 2.6 erschien im Juli 2008
  • WordPress 2.7 erschien im Dezember 2008
  • WordPress 2.8 erschien im Juni 2009
  • WordPress 2.9 erscheint voraussichtlich im  Dezember 2009
Das Ganze sieht schon anders aus, wenn die zwischendurch veröffentlichten kleinen Updates mit dabei stehen; die deutschen Versionen inklusive der Zwischenversionen laut Archiv von WordPress Deutschland:
  • WordPress 2.5 erschien im April 2008
  • WordPress 2.5.1 erschien im April 2008
  • WordPress 2.6 erschien im Juli 2008
  • WordPress 2.6.1 erschien im August 2008
  • WordPress 2.6.2 erschien im September 2008
  • WordPress 2.6.3 erschien im Oktober 2008
  • WordPress 2.6.5 erschien im November 2008
  • WordPress 2.7 erschien im Dezember 2008
  • WordPress 2.7.1 erschien im Februar 2009
  • WordPress 2.8 erschien im Juni 2009
  • WordPress 2.8.1 erschien im Juli 2009
  • WordPress 2.8.2 erschien im Juli 2009
  • WordPress 2.8.3 erschien im August 2009
  • WordPress 2.8.4 erschien im August 2009
  • WordPress 2.8.5 erschien im Oktober 2009
  • WordPress 2.8.6 erschien im November 2009
  • WordPress 2.9 erscheint voraussichtlich im  Dezember 2009
In diesem Jahr waren es damit bereits neun Updates. Meist ging es um Sicherheitsupdates, sprich gerade die Zwischenversionen sind damit wichtig und sollten auf jeden Fall aktualisiert werden.

Plugins und ihre Aktualisierungen

Ich kenne kein WordPress-Blog welches nicht auch einige Plugins einsetzt, um weitere Funktionen hinzuzufügen. Die Plugin-Updates kommen irgendwann zwischendurch und auch hier kann es sein, dass es um Sicherheitsprobleme geht, die gelöst wurden. Anfangs machte ich regelmäßig Plugin-Updates sobald diese veröffentlicht wurden. Doch als ich mehrfach danach einen oder mehrere Fehler hatte, weil die neue Version eines Plugins zu irgendwas anderem nicht passte, hörte ich damit auf. Inzwischen aktualisiere ich Plugins nur in Notfällen, sprich wenn eine Sicherheitslücke zu stopfen ist, ansonsthref="http://miradlo.net/bloggt/index.php?768-s"">Version eines Plugins zu irgendwas anderem nicht passte, hörte ich damit auf. Inzwischen aktualisiere ich Plugins nur in Notfällen, sprich wenn eine Sicherheitslücke zu stopfen ist, ansonsten werden Plugins nur noch gemeinsam mit einem Update aktualisiert. Die Zwischenversionen bestehen ja nur aus einigen Dateien, die überspielt werden können, es ist also keine vollständige Änderung aller Dateien nötig. An sich sollte diese Zwischenupdates daher problemlos funktionieren und keine Seiteneffekte haben. Doch das klappt leider oft nicht, mal ein Beispiel wie es bei einem Update lief, welches schon ein bisschen länger her ist:

Aktualisieren mehrerer Blogs

Wie schon mehrfach beschrieben, ich aktualisiere immer erst lokal, teste dann und spiele erst danach die jeweilige Änderung auch online ein. Einige Male habe ich es auf einem Testblog versucht automatisch zu aktualisieren, es klappte jedoch - wenn überhaupt -nie so, dass ich das bei einem Blog mit echten Inhalten risikieren würde.  Ich begann WordPress auf diversen Blogs zu aktualisieren. Ich lud mir WP 2.8.3 runter, so wie die aktuellen Versionen der genutzten Plugins. Ich hatte das erste Blog gerade aktualisiert und war dabei das zweite zu bearbeiten, als bereits das erste Plugin wieder nicht mehr aktuell war. Also auch da die neue Version runtergeladen. Abends beim Testen lief es auf meinem Rechner lokal erst mal ganz schlecht. Ein noch langsamerer Adminbereich als bisher schon, in weiteren Browsern entweder gleich schlecht benutzbar oder noch weiter verschlechtert. Ich bin schon einiges gewohnt, aber ich brauche wenigstens einen Browser, mit dem sich auch der WordPress-Adminbereich bedienen lässt.  Ich installierte mir einen Firefox ohne Add-Ons, damit ging es dann einigermaßen. Inzwischen liefen zwei Blogs auf 2.8.3 auch online. Noch während ich lokal die Updates für weitere Blogs testete, Plugins aktualisierte und den ein oder anderen Wunsch für Änderungen umsetzte, las ich dass die 2.8.3 auch keine gute Idee sei. Ich hatte jedoch schon die Updates bei 2.8.1 und 2.8.2 auf dem ein oder anderen Blog abbrechen müssen, weil ich bereits lokal feststellte, dass damit das Blog nicht mehr lief. Für die 2.8.3  kamen ständig neue Vorschläge, wie der unsichere Login zu reparieren wäre. Na bravo! Ich blieb also erstmal an den Anpassungen und Erweiterungen die in einigen Blogs zu machen waren. Am dritten Tag beschloss ich jetzt doch noch weiter zu aktualisieren und um das abzuschließen. Zunächst schaute ich was auf dem nächsten zu aktualisierenden Blog noch zu tun ist und: "Juhu! ein Update!" Ja, es ist toll, dass der Fehler damit behoben wird. Das ändert allerdings nichts daran, dass ich jetzt also erstmal die ersten beiden Blogs vom Tag zuvor erneut aktualisieren musste. Dieses Mal probierte ich es ohne nochmaliges Sichern und Plugins abschalten, solange war die letzte Aktualisierung ja noch nicht her, als das lokal lief, riskierte ich es auch online. Ja, die zwei nur von 2.8.3 auf 2.8.4 zu aktualisierenden Blogs waren tatsächlich kein Problem; alles andere aber schon. Ein Blog zickte nochmal bevor es sich überreden ließ, doch so zu tun, als sei alles in Ordnung. Zwischendurch musste ich jeweils wieder die online-Versionen aus Kundenprojekten holen, um nicht versehentlich was zu überschreiben, denn ich kann ein Blog ja nicht über zwei, drei Tage einfach abschalten.

Fazit WordPress nutzen

Die Updates sind in keinster Weise planbar, denn z.B.  die 2.9 war für November angekündigt, ob sie jetzt noch dieses Jahr kommt ist nicht klar. Die Zwischenversionen kommen, wenn einehref="http://miradlo.net/bloggt/index.php?37-s"">aktualisiere immer erst lokal, teste dann und spiele erst danach die jeweilige Änderung auch online ein. Einige Male habe ich es auf einem Testblog versucht automatisch zu aktualisieren, es klappte jedoch - wenn überhaupt -nie so, dass ich das bei einem Blog mit echten Inhalten risikieren würde.  Ich begann WordPress auf diversen Blogs zu aktualisieren. Ich lud mir WP 2.8.3 runter, so wie die aktuellen Versionen der genutzten Plugins. Ich hatte das erste Blog gerade aktualisiert und war dabei das zweite zu bearbeiten, als bereits das erste Plugin wieder nicht mehr aktuell war. Also auch da die neue Version runtergeladen. Abends beim Testen lief es auf meinem Rechner lokal erst mal ganz schlecht. Ein noch langsamerer Adminbereich als bisher schon, in weiteren Browsern entweder gleich schlecht benutzbar oder noch weiter verschlechtert. Ich bin schon einiges gewohnt, aber ich brauche wenigstens einen Browser, mit dem sich auch der WordPress-Adminbereich bedienen lässt.  Ich installierte mir einen Firefox ohne Add-Ons, damit ging es dann einigermaßen. Inzwischen liefen zwei Blogs auf 2.8.3 auch online. Noch während ich lokal die Updates für weitere Blogs testete, Plugins aktualisierte und den ein oder anderen Wunsch für Änderungen umsetzte, las ich dass die 2.8.3 auch keine gute Idee sei. Ich hatte jedoch schon die Updates bei 2.8.1 und 2.8.2 auf dem ein oder anderen Blog abbrechen müssen, weil ich bereits lokal feststellte, dass damit das Blog nicht mehr lief. Für die 2.8.3  kamen ständig neue Vorschläge, wie der unsichere Login zu reparieren wäre. Na bravo! Ich blieb also erstmal an den Anpassungen und Erweiterungen die in einigen Blogs zu machen waren. Am dritten Tag beschloss ich jetzt doch noch weiter zu aktualisieren und um das abzuschließen. Zunächst schaute ich was auf dem nächsten zu aktualisierenden Blog noch zu tun ist und: "Juhu! ein Update!" Ja, es ist toll, dass der Fehler damit behoben wird. Das ändert allerdings nichts daran, dass ich jetzt also erstmal die ersten beiden Blogs vom Tag zuvor erneut aktualisieren musste. Dieses Mal probierte ich es ohne nochmaliges Sichern und Plugins abschalten, solange war die letzte Aktualisierung ja noch nicht her, als das lokal lief, riskierte ich es auch online. Ja, die zwei nur von 2.8.3 auf 2.8.4 zu aktualisierenden Blogs waren tatsächlich kein Problem; alles andere aber schon. Ein Blog zickte nochmal bevor es sich überreden ließ, doch so zu tun, als sei alles in Ordnung. Zwischendurch musste ich jeweils wieder die online-Versionen aus Kundenprojekten holen, um nicht versehentlich was zu überschreiben, denn ich kann ein Blog ja nicht über zwei, drei Tage einfach abschalten.

Fazit WordPress nutzen

Die Updates sind in keinster Weise planbar, denn z.B.  die 2.9 war für November angekündigt, ob sie jetzt noch dieses Jahr kommt ist nicht klar. Die Zwischenversionen kommen, wenn eine Lücke bekannt wird und groß genug ist, um repariert zu werden. Ich kann jedoch in meinen Arbeitslauf nicht ständig vorsichtshalber drei Tage einplanen, in denen ich sofort, wenn ein Update erscheint, alles andere stoppe und absage, um mich dann um WordPress zu kümmern. Unterm Strich kostet mich eine Aktualisierung pro Blog zwischen einigen Stunden bis zu ein oder zwei Tagen, wenn eine Fehlersuche aufwändiger wird. Ginge es hierbei um ein Update pro Jahr, dann wäre es noch akzeptabel, bei einem Update etwa alle sechs Wochen geht das einfach nicht, denn kein Kunde ist bereit das nach Aufwand auch nur annähernd zu bezahlen. Denn selbst bei einem Stundensatz von nur 50 Euro wären das jährlich rund 2500.- Euro nur für Aktualisierungen und kleine Anpassungen. Ich bin deshalb inzwischen dazu übergegangen, dass ich für neu aufzusetzende Blogs WordPress nicht mehr anbiete, eine Ausnahme sind Portale mit WordPress MU und BuddyPress, weil sich da der Aufwand ja auf viele Einzelblogs verteilt und weil es zur Zeit keine echte Alternative dafür gibt.

WordPress Videos valide einbinden

Ich nutze nach wie vor mit Vorliebe XHTML strict, weil ich da am besten auch kleine Macken sofort sehe. Lange habe ich keine Videos in Blogs eingebunden, weil WordPress partout keinen validen Code erzeugen wollte. Versuche in HTML-Ansicht valide einzubinden scheiterten spätestens, falls ich später versehentlich einen solchen Artikel nochmal öffnen wollte. Doch irgendwann las ich von dem Tipp, den Button "Medien einbetten" zu nutzen. Wunderbar, da musste ich nur den Link eingeben und alles andere klappte von selbst.

Wieder nicht mehr valide

Gestern habe ich auf uteles Blog wieder mal ein Video eingebunden und zunächst gar nicht überprüft, ob alles passt, weil ich das an sich ja weiß. Aus einem anderen Grund prüfte ich heute kurz und "ups, Mist, Fehler". Nun gut, mal kurz nachsehen, was ich wohl falsch gemacht habe; Quelltext des Videos, welches Fehler wirft:

<p><object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" height="350" width="425"><param name="src" value="http://www.youtube.com/v/Frx0Wc1cxbo"><embed type="application/x-shockwave-flash" src="http://www.youtube.com/v/Frx0Wc1cxbo" height="350" width="425"><a class="mjedzjfsfvwhkvyhhsjp" href="http://www.youtube.com/v/Frx0Wc1cxbo"></a></object></p>

Ok, stimmt, da steht was von type="application/x-shockwave-flash" also mal nach einem alten Video schauen und sehen, was sich da unterscheidet:

<p><object data="http://www.youtube.com/v/6a_KF7TYKVc" type="application/x-shockwave-flash" height="350" width="425"><param name="src" value="http://www.youtube.com/v/6a_KF7TYKVc"></object><a class="mjedzjfsfvwhkvyhhsjp" href="http://www.youtube.com/v/6a_KF7TYKVc"></a></p>

Fehlersuche

Ich schaute mir das Ganze mal in der HTML-Ansicht von WordPress an und da stand bei beiden Beiträgen dasselbe (außer dem Link zum Video selbst natürlich):

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="425" height="350" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="src" value="http://www.youtube.com/v/MpIOClX1jPE" /><embed type="application/x-shockwave-flash" width="425" height="350" src="http://www.youtube.com/v/MpIOClX1jPE"></embed></object>

Das konnte jedoch irgendwie nicht sein. Ich versuchte es mit einem weiteren Beitrag mit Video und siehe da, da stand was anderes:

<object width="425" height="350" data="http://www.youtube.com/v/Frx0Wc1cxbo" type="application/x-shockwave-flash"><param name="src" value="http://www.youtube.com/v/Frx0Wc1cxbo" /></object>

Reparieren

Ich gab das in HTML-Ansicht des Beitrags ein, und siehe da, schon passt es wieder und die Startseite ist fehlerfrei, die Unterseite hat wie immer den einen Fehler, bei dem der Validator noch nicht auf dem aktuellen Stand ist. Allerdings wieder mit dem alten Problem, nicht mehr auf die visuelle Ansicht umschalten, sonst ist es wieder kaputt. Ich suchte nochmal, denn irgendwas war da komisch und nach erneutem Öffnen des Beitrags, der zwar gleich aussah aber valide war, sah ich das Problem, es gab eine automatische Speicherung, diese zeigte die falsche Version, aber die tatsächlich publizierte Version war eben doch mit anderem Code.

Fazit

Na prima, da konnte WordPress auf ganz einfache Art mal Videos valide einbinden und jetzt ist es wieder kaputt. Ich hab jetzt nicht gesucht, kann sein irgendein Plugin ist schuld, vielleicht ist es auch grad diese Version und die nächste dann wieder nicht... Ganz ehrlich: Es ist mir egal, es nervt einfach.

Spam und Registrierungen bei WP-MU und BuddyPress-Installationen

  • Screenshot Adminbereich WP-MU als Spammer markieren
Je aktiver eine WP-MU-Installation ist, desto beliebter ist sie bei Spammern. BuddyPress, was wir teilweise einsetzen, braucht zwingend ein WP-MU und meist ist das auch sinnvoll, denn es geht ja um ein Netzwerk nicht nur zum Plaudern und sich Austauschen, sondern es geht meist auch um mehrere Blogs. Um den Spam zu bekämpfen könnte man natürlich die Registrierung einfach schließen, aber das hieße bei echten Interessenten, dass ich sie von Hand freischalten müsste. Deshalb ist das auch keine gute Idee, einerseits weil Interessenten dann warten müssten und auch, weil ich nicht jeden Nutzer selbst anlegen möchte. Einiges an Spam lässt sich reduzieren, indem ich die betroffenen IPs, von denen die Spammer kommen, blocke. Bevor ich das machte kamen tatsächlich von nahezu jeder IP mehrere Registrierungen. Akismet kann man laut Adminbereich über die Spammer benachrichtigen. Doch selbst bei sehr hartnäckigen Spammern, mit derselben IP und immer einem nahezu identischen Nutzernamen, die ich auf mehreren Installationen sperrte half es nicht, sie konnten sich immer wieder registrieren, teils sogar mit identischem Benutzernamen. Insofern ist Akismet an dieser Stelle völlig überflüssig. Die Liste der IP-Sperren in .htaccess ist jedoch inzwischen sehr lang geworden und jede IP benötigt einen Eintag: deny from 74.53.xxx deny from 74.53.xxx deny from 74.53.xxx Insofern war ich schon länger auf der Suche nach einer besseren oder zusätzlichen Lösung. Was ich von grafischen Captchas und ähnlichem halte, habe ich ja schon mal erwähnt. In der README der aktuellen WP-MU-Version fand ich Hinweise zum Spamschutz, manches gefiel mir nicht, aber der Hinweis auf Blocken per Referrer ist eine prima Idee. Zu finden ist die Anleitung auch im WP-codex, das habe ich aber erst später entdeckt. Insgesamt ist damit mehr Ruhe, aber es bleibt ein Restrisiko, dass ernsthaft interessierte Nutzer versehentlich geblockt werden. Deshalb jetzt dann mal einen speziellen Artikel dazu. Im Moment leite ich Spammer auf einen Spamartikel um, auf Dauer will ich jedoch den Hinweis hier geben, dass es auch mal jemand treffen kann, der kein Spammer ist. Wer also versehentlich geblockt wurde, bitte melden, per Kommentar, oder über die Impressumsangaben.
tweetbackcheck