Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenIch denke, das ist alles zu wenig meine Welt und werde wohl doch beim Plugin bleiben, wenngleich es mir recht gewesen wäre, auf ein weiteres Plugin verzichten zu können.
Wenn man über mysqldump eine zuverlässige DB-Sicherung machen kann und immer noch SSH/rsync dabei nutzt, warum gilt dann trotz dieser offenbar guten Methode rsync noch immer nicht als zuverlässige Backup-Methode auch für Dben?
Auf Dateisytem-Ebene?
Ich habe gelesen, dass rsync einen sog SSH-Zugriff braucht. Spielst du darauf an, weil das meist nur bei höheren Tarifen dabei ist und viele den Linux-Befehlskram außerdem nicht verstehen?
SSH könnte ich optional dazunehmen.
Was meinst du mit "mitsyncen"?
Wenn sich die DB nicht sichern und restoren ließe, dann wäre rsync vermutlich überhaupt keine akzeptable Methode. Inwiefern klappt das nicht "ordentlich"?
Bisher hat es mich nicht betroffen, ist auch keine aufwendige Site. Trotzdem danke für den Hinweis.
Vielleicht wäre es einen eigenen Thread wert, aber hat jemand Erfahrung mit rsync-Backups von WP? Wusste bis vor einigen Minuten noch nicht mal, dass es das überhaupt gibt und scheint nicht so bekannt zu sein, obwohl es viele Vorteile hat. Weiß jemand warum es sich nicht wirklich durchgesetzt hat und stattdessen Millionen lieber Plugins verwenden?
Dachte ich mir auch, denn beides sind unabhängig voneinander oft empfohlene Sicherheitstipps. Ich vermute, viele machen beides.
Du hast oder kennt Sites, die beides nutzen und bei denen die automatischen Backups nicht durch den htaccess PW-Schutz ausgehebelt werden?
Hallo,
ich möchte mir UpdraftPlus installieren und damit automatische Backups zu best. Zeitpunkten machen lassen.
Ich habe mir einen zusätzlichen Passwortschutz per htpasswd-file eingerichtet, eine durchaus sinnvolle und gängige Sicherheitsmaßnahme, d.h., um ans Backend (Adminbereich) zu kommen, muss ich mich jetzt zwei mal einloggen.
Wenn ich https://updraftplus.com/faqs/my-schedu…w-stops-midway/ unter Punkt 6 lese, dann scheint ein solcher PW-Schutz aber den "Wordpress scheduler" außer Kraft zu setzen und den braucht das Plugin für automatische Backups. Oder ist in dem Artikel nur eine für Besucher PW-geschützte Website gemeint ("entire website...")?
Grüße,
Martin
Also ich könnte mit phpMyAdmin ganz direkt die Art von Bereinigung durchführen, die das Plugin nicht macht.
Die je 2 MB Overhead in der Tabelle "...posts" und "...options", also insgesamt 4 MB, sind deiner Vermutung nach tatsächlich verdächtig viel, d.h., irgendwas ist da nicht ganz koscher. Aber praktisch gesehen hat es keine Auswirkung und dementsprechend wohl auch die Optimierung nicht?
"Optimization of the database tables on-disk is not available" steht da. Wie ich bereits geschrieben habe.
Die Frage ist, ob die je 2 MB "o.k." sind, sprich, die Mühe nicht lohnen, sich nach anderen Möglichkeiten umzuschauen (phpMyAdmin, andere Plugins ect.), zumal ich nur Laie bin.
Oder ob das doch verdächtig viel ist und bereinigt werden sollte. Wie schon gesagt, bei der anderen Website war da so gut wie gar kein Overhead, obwohl beide Sites recht ähnlich sind. Und 4 MB Overhead bei einer so kleinen Website... ich tu mich schwer, das zu bewerten, aber andere haben vielleicht mehr Erfahrung.
Hallo,
ich habe eine kleine, alte HTML-Website mit 19 Seiten und insgesamt ca. 100 Bilder zu je ca. 20 Kb auf WP umgestellt. Habe nur ein einziges kleines Plugin.
Mit dem Plugin WP-Optimize wollte ich dann mal schauen, was sich an der DB verbessern lässt.
Das Plugin WP-Optimize löscht überflüssige drafts, revisions ect., bringt aber auch die DB-Tabellen auf Vordermann. Bei mir zeigt das Plugin aber auch nach einem erfolgten Lauf in den beiden WP-Tabellen ...options und ...posts immer noch je 2 MB "Overhead". Siehe Bild anbei.
Zum einen kommt mir das relativ viel vor, zum anderen lässt sich das mit dem Plugin nicht erledigen, weil es sich um "InnoDB"-Tabellen handelt und die rührt das Plugin nicht an. Bei der letzten (durchaus vergleichbaren) Website war der Overhead nur minimal, ein paar KB.
Soll ich das einfach so belassen oder wie lässt sich das beseitigen?
Kennt sich jemand mit so etwas aus?
Autor33
Wie ich schon bei wpbeginner.com erwähnt habe, ist der einfachere und deutlich weitergehende Schutz das Einfügen des folgenden Codes in die .htaccess Datei:
Code<ifModule mod_headers.c> Header set X-XSS-Protection "1; mode=block" Header always append X-Frame-Options SAMEORIGIN Header set X-Content-Type-Options: "nosniff” </ifModule>Damit wird es unter anderem unmöglich die eigene Seite und deren Inhalte auf fremden Seiten per iFrame einzubinden. Und das ist was das Embbeding tut.
Der htaccess-Code berührt aber nicht:
-Das eigene Einbetten von fremden WP posts auf der eigenen Website und
-Die Erzeugung der JavaScript-Dateien usw. im Ausgabe-Code, siehe http://www.netprofit.de/blog/wordpress…aktivieren.html, was mit dem neuen oEmbed-Feature automatisch bei allen Seiten immer geschieht (auch wenn ich keine WP posts einbette bei mir)?
Bezüglich letzterem weiß ich nicht, inwieweit das tatsächlich eine Code-Aufblähung darstellt, die der Ladezeit beeinflusst, aber brauchen tue ich das neue embed-feature jedenfalls nicht.
Hallo,
das responsive image feature soll ja automatisch wirksam sein und auch Bilder in bereits bestehenden posts/pages responsive machen. Also Bilder in posts, die zum Zeitpunkt des Updates bereits vorhanden sind.
Passt das Ergebnis dann immer, wenn auf diese Weise ältere Beiträge automatiert und unkontrolliert "nachbearbeitet" werden?
Meine Sites sind nicht so groß, aber wenn man auf einer Site tausende posts hat und überall automatisch nachträglich die Bilder responsive gemacht werden... wird das wohl nicht immer optimal ausfallen.
Es ist eine ganz neue WP-Installation und ich habe jetzt bislang nicht weitergemacht, also mit der eigentlichen WP-Installation per Browser (Zugangsdaten der DB usw....).
Offenbar findet Filezilla die gleiche Datei, weil sie Sekunden vorher schon mal hochgeladen wurde (ins exakt gleiche Verzeichnis oder anderes?).
Hallo,
ich habe gerade WP 4.2.2 mit Filezilla in den betreff. Ordner hochgeladen, alle WP-Verzeichnisse und Dateien auf ein Mal. Auf der linken Seite in Filezilla alle ausgewählt und dann "Hochladen".
Das dauert ein paar Minuten, doch während des Prozesses kam ein Mal die Frage, ob eine schon vorhandene Datei (irgendein webfont von Twentyfourteen) überschrieben werden soll, weil er schon vorhanden sei!?
Nachdem alles hochgeladen war, habe ich alles gelöscht und nochmal neu hochgeladen. Dieses Mal kam zwei Mal während der Übertragung die Frage, ob eine schon vorhandene Datei überschrieben werden soll, es waren aber andere Sachen, irgendwas mir smileys und icons.
Ich habe das Überschreiben immer bejaht, bin aber etwas verwirrt, weil ich beim Hochladen von WP in ein leeres Verzeichnis noch nie mit "bereits vorhandenen Dateien" konfrontiert war.
Kennt das jemand und ist das Überschreiben richtig gewesen?
Ich habe bei http://www.sir-apfelot.de/wordpress-lade…er-caching-683/ einen post zum Thema gelesen, wo - ohne nähere Begründung - betont wird, den Code unterhalb des WP-Standard-Codes einzufügen.
36 Kommentare sprechen von keinerlei Problemen damit. Deswegen hat es mich gewundert, dass die Plazierung unterhalb Ursache für das Nicht-Funktionieren bei danielbIn gewesen sein soll. Zumal mir nicht klar ist, warum Browser-Caching und Standard-Code voneinander abhängig sein sollten.
1. das alles gehört vor dem Eintrag von WP
also immer ganz nach oben
ausprobieren => gucken..
Warum muss das vor den WP-Eintrag? Sind das nicht zwei getrennte Sachen?
Es lag an einem Teil des Codes, den mein Hoster nicht unterstützt bzw. anbietet, nämlich
php_flag display_errors off
Da hätte ich jetzt viel Geld beim Wetten verloren...
Trotzdem danke.
Ich weß ja nicht, was du in der .htaccess geändert hast. Für einen Umzug musst du da nichts ändern.
Nenne die .htaccess mal um, dann sollte es wieder gehen.
"Müssen" zwecks Umzug vielleicht nicht, aber ein paar Sicherheitsdinge und der Redirect der Unterseiten-URLs kann ich nur in der .htaccess machen.
Ich habe dann alles wieder rückgängig gemacht, sprich, alles wie vor der (versuchten) Umstellung. Das schließt auch die htaccess ein, d.h., dort ist jetzt wieder die einfache Standard-Version mit den 8 Zeilen Standard-Code von Wordpress, sonst nichts.
Anschließend erstellst du eine neue .htaccess in dem die die permalinks neu einstellst und speicherst.
Kannst du das bitte genauer erklären? Die bisherige htaccess löschen (oder umbenennen) und dann die gewünschte htaccess mit den Ergänzungen als Ganzes neu hochladen? Oder gar nichts hochladen und nur WP per Permalink-Modul eine erstellen lassen, die ich dann aber auch wieder ergänzen muss?
Hallo,
mit einer Test-Site auf einer Subdomain will ich nun "live" gehen. Zu diesem Zweck habe ich die Wordpress-URLs in den General Settings geändert und dann im Kundenaccount meines Hosters die Domaineinstellung geändert.
Als ich danach aber die htaccess ergänzt habe - was augenscheinlich ganz normal funktioniert hat - bin ich danach aus Wordpress rausgeflogen mit folgender Meldung und konnte mich nicht mehr einloggen:
500 - Scriptfehler
leider ist ein Problem aufgetreten. Die angeforderte Seite hat einen Script-Fehler verursacht.
Haben Sie sich vielleicht vertippt oder eine alte URL aufgerufen? Wenn nicht, informieren Sie bitte den Webmaster dieser Homepage per Email. Um zu der vorherigen Seite zurück zu kehren, verwenden Sie bitte einfach die "Zurück" - Taste Ihres Browsers.
Woran kann das liegen? Folgende Infos kann ich geben:
-Nach Schließen der FTP-Verbindung und nochmal reingehen per FTP, um die die geänderte htaccess zu prüfen, sah alles ganz normal aus.
-Filezilla öffnet nach Klick auf "Bearbeiten/Ändern" das Windows-eigene Notepad, das für diese Zwecke geeignet sein soll (ASCII-Editor).
-Übertragungstyp "Automode" und "dotfiles wie .htaccess als ASCII-Dateien behandeln" ist aktiviert in Filezilla.
-Rechte für die htaccess: 740.
-Eher kleine Website, ca. 50 Seiten und ca. 50 Bilder zu durchschnittlich 20 KB
-Nur ein einziges Plugin aktiviert, nennt sich Backupbuddy, kostenpflichtig, von "ithemes".
-Code selbst hat ein paar Standardsachen zwecks Sicherheit und ein 301-Redirect für die Unterseiten-URLs, weil die Datei-Endung ".html" wegfallen soll. Der Redirect hatte nicht geklappt. Der Code stimmt aber ziemlich sicher.
Hat jemand eine Idee, kann man wenigstens etwas sicher ausschließen?
Ist Better Search Replace nicht ein Plugin, das auf dem verlinkten Skript basiert oder sind das zwei versch. Sachen? Es bietet einen dry run vorher (!) an und berücksichtigt "serialisierte" Daten. Stichproben können natürlich auch hinterher nie schaden...
