Beiträge von hakre

    Zuerst einmal war ich der Meinung optimal vorbereitet zu sein, ich hatte ein SQL-Backup der gesamten Datenbank (Stand der Datenbasis 16.02.), hatte mir vorher per FTP den gesamten Webordner heruntergeladen.


    Dieser Schritt und auch das mit dem Löschen des Wordpress Ordners ausser Upload ist absolut richtig gewesen und das dürfte Dir auch helfen, den alten Blog so wie er war wieder aufzusetzen und ggf. genauer gucken zu können, was beim Upgrade schief ging.

    2.6.5 sollte auf 2.7 resp. 2.7.1. upgraden können. Evtl. klemmt es woanders.

    Zu guter Letzt habe ich die config.php durch das alte Original ersetzt und die config-sample.php gelöscht.


    das könnte vielleicht Probleme aufwerfen. Lieber die neue config-sample.php nehmen und die Werte aus der alten - dort wo es passt - darin übernehmen.

    Und als er fertig war, bekam ich nur eine leere weisse Seite, anstatt meines Blogs....

    Die bekannte Weisse Seite deutet auf einen PHP Fehler hin, der Dir nicht angezeigt wird. PHP Fehler werden (manchmal) in einen Error-Log geschrieben und manchmal auch auf den Bildschirm ausgegeben. Manchmal kriegt man von den Fehlern aber auch nichts mit.

    Der erste wichtige Schritt ist herauszufinden, wie PHP auf dem Server wo WordPress liegt eingerichtet ist. Besonders die Fehlereinstellungen. Welche PHP-Error-Typen werden gemeldet, werden diese am Bildschirm ausgegeben oder in ein Logfile? Wenn Logfile, wo liegt dieses?

    In der FAQ gibt es hier einen guten Artikel, Spickzettel hatt ihn bereits gepostet: Wie gehe ich am besten vor, wenn Fehler in meinem Blog auftreten? « WordPress Deutschland FAQ

    Dort ist auch ein weiterer Artikel verlinkt, der sich um die PHP Einstellungen rund um das Error-Reporting kümmert:
    PHP-Errorlog Delta Orionis
    PHP-Loginfos herausfinden Delta Orionis

    Hi Hanns0608,

    anmelden brauchst du Dich nicht:

    Code
    # Non-members may check out a read-only working copy anonymously over HTTP.
    svn checkout [B][I]http[/I][/B]://spam-karma.googlecode.com/svn/trunk/ spam-karma-read-only


    (Deutsch: Nichtmitglieder sind leseberechtigt und können anonym über HTTP den Code per SVN auschecken.)

    SVN steht für Subversion. Mittels Subversion (zB. mittels Tortoise SVN unter MS Windows) kannst Du mit der oben genannten URL das Plugin auf deine Festplatte downloaden (auschecken). Eine Einführung zu SVN kannst Du Dir ergoogeln, ist nicht so komplitziert, allerdings ist es gut die Grundlagen zu kennen und zu wissen wozu das gut ist. Praktische Sache ist es allemal.

    Hi King7, wenn der YouTube Player das kann, dann dürfte es dort dokumentiert sein. Dies ist die offizielle Dokumentation von Google zur Bedienung und Nutzung deren Players. Es gibt auch eine Video-Tutorials.

    Wenn es keine Möglichkeit gibt, die der Player direkt bietet - wie du schreibst - so bliebe nur noch, dass du über das Flash etwas weiteres legst, was den Link abfängt. Dazu musst Du das Flash meine ich auf opaque setzen im wmode.

    Ich meine die Standardtemplate hat sowas als "breite Seite" oder ähnlich. Wie dem aber auch sei, in der Regel muss die Theme nur insoweit angepasst werden, dass die Sidebar rausfliegt. Die ist meist eh eine include, sodass Du mit der Anpassung warscheinlich schneller und glücklicher ans Ziels kommst als mit einer eigenen Theme (mir fällt da zumindest nicht direkt eine passende ein).

    Ich kann bei den wenigen Angaben nur raten, ich vermute mal, du hast die Dateien noch garnicht upgegraded. Gehe bitte so wie in der Anleitung beschrieben beim Update vor.

    WordPress Update - Schritt für Schritt:

    1. Datenbank Backup
    2. Datei Backup
    3. Sämtliche Plugins deaktivieren
    4. Standard Theme aktivieren
    5. Alte Wordpress Version vom Server löschen
    6. Neue Wordperss Version auf den Server kopieren
    7. Theme wieder aktivieren
    8. Plugins wieder aktivieren
    9. Fertig.

    Okay, ich habs mir mal angeschaut. Es liegt auch nicht an der Theme sondern an der Funktion the_content resp. get_the_content. In dieser wird immer die Passwort Form reingeflanscht und diese prüft nur auf Passwort nicht auf User.

    Leider gibts für die Funktion post_password_required keinen Filter den man nutzen kann. Es gibt lediglich den Filter 'the_password_form' welcher gesubclassed werden könnte. Hierbei müsste man die global $post selber nochmal auf Passwort prüfen und falls es nötig ist, den content selber zusammenbauen. Aber auch hier wieder: Leider gibt es keine _eine_ Routine, die dies macht sondern nur den Mischmasch aus get_the_content. Im Grunde also einfach die gesamte Routine verdoppeln und den Teil rausschmeissen, der umgangen werden soll (hier der passwort check). Ist klar, nee?

    Ich habs mal zu Testzwecken und ob des vielen Codes als ein Plugin gebaut. Dabei kam mir die Idee, statt soviel Code zu übernehmen, lediglich dafür zu sorgen, dass der Post nicht mehr Passwort protected ist, falls man ihn aufruft als Admin. Die Template Function the_content ist nach aktivierung des Plugins in der Theme lediglich durch Superuser_Plugin::the_content zu ersetzen. Die Parameter bleiben die Gleichen. Kurz gesagt, einfach Superuser_Plugin:: davor setzen.

    Im Grunde kann die Klasse auch in die eigene Theme übernommen werden.

    Download: http://subfiles.net/wordpress/plug…eruser-v0.1.zip

    *Hüstl* Ja, so könnte man argumentieren. Allerdings würde ich der Sicherheit wegen erstmal in Erwägung ziehen, dass die Automatischen Updates generell auch ausschaltbar sein sollten (gerne auch die Remote Checks), den hierüber lässt sich ja auch noch gefährlicher Code auf den eigenen Server laden.

    Wie dem auch sei, wenn man selbsttätig verhindern möchte, das ein fehlerhaftes WP oder Plugins Code nachlädt um es auf der Platte zu speichern und um es dann als unsichtbares Plugin nachzuladen (wie in diesem Fall), so kann man dies selber bereits mit dem Entzug der Schreibrechte erreichen. Wie ich ja bereits schrieb sprach ich vom normalen Betrieb der Seite und nicht während des Updates.

    Eine weitere Lösung wird wohl auf jeden Fall noch mindestens bis zum nächsten WordPress-Update dauern, da wie berichtet der Fehler noch nicht in aller Gänze behoben wurde. Und so richtig habe ich auch noch keine abschliessende Lösung erarbeiten können, wie die Code-Injection per Optionswert sinnvoller Weise komplett unterbunden werden kann. Schlieslich ist jedes Plugin im Grunde eine Code-Injection.

    Was tun? - Gute Frage! Der erste Ansatz der mir in den Sinn gekommen ist, wäre eine defenitive Liste aller installierten Plugins auszugeben. D.h. einen Fix oder eine Erweiterung für die Plugins Seite im Admin. So besteht zumindest eine besser Kontrollmöglichkeit für WordPress Administratoren, dass Sie sich ein genaueres Bild über die installierten Plugins machen können.

    Desweiteren sollte das Plugin Verzeichnis vor Uploads geschützt werden (keine Schreibberechtigungen für den User, unter dem PHP auf den Webserver läuft).

    Im Grunde genommen müssen Uploads nur in den upload Ordner gehen und nirgendwo anders hin. Alles weitere kann ein Admin dann veranlassen, wenn es nötig ist.

    Falls das Plugin SpamKarma gravierende Sicherheitslücken aufweist und es nicht weiter gepflegt wird, sollte es schleunigst deaktiviert und entfernt werden. Wie es aber aussieht, wird das Plugin weiterhin gepflegt und zwar in einem bei Google gehosteten Repository. Ich selber kenne das Plugin aber nicht und kann deswegen zu seiner Qualität nichts sagen. Generell sind Plugins, die Dinge nachladen und dabei schlampig vorgehen, eine potentiell gefährliche Sache.