Beiträge von Putzlowitsch

Genau, der Free-Mode sollte dem Nutzer nach meinem Verständnis nur die Arbeit abnehmen, alles selbst per FTP hochzuladen und zu konfigurieren.

Außerdem wird durch die Installation über das App-Center keine Datenbank aus dem Hostingpaket "verbraucht". Das kann ein Vorteil sein, falls man mit Datanebanken eher knapp dran ist. Nachteil ist allerdings, daß man keinen bequemen Zugriff auf die Datenbank in der Datenbank-Verwaltung im Control-Center hat.

Da muß man sich dann mit einem selbst installierten phpMyAdmin weiterhelfen.

Gruß
Ingo

Zitat von 1&1 Internet

...
Wenn Ihr WordPress direkt bei der Neuinstallation als Free Mode einrichtet, sollte es gar nicht zu den beschriebenen Problemen kommen.
...

Das muß ich widersprechen. Ich hatte, um der Sache auf den Grund zu gehen, bei mir ein Wordpress direkt im Free-Mode installiert. Genau da stand diese Zeile eben in der wp-config.php drin.

Es sollte also nicht nur die Umwandlung, sondern auch die direkte Installation im Free-Mode in die Lösung einbezogen werden.

Gruß
Ingo

"Create Database" sollte nicht aktiviert werden.

Das funktioniert bei den meisten Shared-Webhosting-Paketen sowieso nicht, weil dort Datenbanken nur im Kundenmenü erstellt werden können.

Gruß
Ingo

Zitat von krimserei

Hallo!
Ich möchte gerne auf Blogspot Post kommentieren, allerdings ist das meistens nicht möglich...

Blogspot/Blogger.com ist ein Produkt von Google. Wie man dort kommentieren kann, solltest Du bei Google fragen. Das hat mit Wordpess gar nichts zu tun.

Vermutlich geht es am einfachsten, wenn Du bei Google angemeldet und eingeloggt bist.

Gruß
Ingo

gericoach

Ist halt Spam. Die Spammer suchen sich gerne alte Threads für ihre Beiträge raus.

Deshalb unterstütze ich auch den Vorschlag von mensmaximus, alte Threads, bei denen lange nichts mehr passiert ist, zu schließen:
http://forum.wpde.org/feedback-und-a…schliessen.html

Gruß
Ingo

Hille
Ja, ist schon sehr lange her. Ich hatte das nur irgendwo im Hinterkopf gespeichert.

Aber die Sache mit dem FTP-Binary-Modus könnte ein Hinweis sein. Leider gibt es zu Problemen beim Laden der Sprachdatei keine Fehlermeldung von Wordpress. Müßte man vielleicht im Errorlog des Servers/von PHP mal nachsehen, ob da was zu finden ist.

Gruß
Ingo

Zitat von Hille

Das hat damit nichts zu tun, ob 32-Bit- oder 64-Bit-Ausführung. ...

Es gab früher mal tatsächlich Probleme bei 64-Bit Systemen. Gibt sogar einen FAQ-Artikel dazu:
http://faq.wpde.org/wieso-zeigt-wo…ischen-text-an/

Eventuell helfen ja auch die anderen Hinweise dort weiter (z.B. FTP Binary-Mode).

Gruß
Ingo

Für solche Fragen ist der Support von wordpress.com zuständig:
http://de.support.wordpress.com/

Hier im Forum geht es um selbstgehostete WP-Installationen.

Gruß
Ingo

Meinst Du das hier: http://store.wordpress.com/plans/premium/
Wobei das was von 99$ steht.

Falls es bei wordpress.com ist, mußt Du Dich dort an den Support wenden: http://de.support.wordpress.com/

Hier geht es um selbstgehostetes Wordpress.

Gruß
Ingo

Gute Idee.

Gruß
Ingo

Zitat von mensmaximus

Korrekt. Wenn Du das so umsetzt, sind die Probleme zu 99.5% Vergangenheit.

Auch ein Angreifer über eine WP-/Plugin-/Theme-Sicherheitslücke hat dann keine Probleme mehr, auf alle PHP-Dateien der WP-Installation schreibend zuzugreifen und seinen Schadcode unterzubringen.

elotse
Ohne "AddHandler php5-fastcgi .php" hast Du auch weiterhin auf alle Dateien der WP-Installation per FTP-Zugriff, wenn Du nur das Upload-Verzeichnis, wie von mir oben beschrieben, änderst. Nur die über die WP-Mediathek hochgeladenen Dateien kannst Du dann nicht einfach per FTP löschen.

Gruß
Ingo

Guck mal in die wp-config.php, da findest Du die Zeile:

define('DISALLOW_FILE_EDIT', true);

Ändere das in false und dann sollte die Bearbeitung funktionieren.

Gruß
Ingo

Zitat von mensmaximus

Richtig. Dafür kannst Du dann per FTP keine Daten mehr hochladen...

Ja gut, das ist aber auch nicht wirklich problematisch, weil ich das WP-Uploads-Verzeichnis nur über WP befülle. Genau dafür ist es ja da.

Gruß
Ingo

mensmaximus
Danke für den Link! Das bringt mich auf eine Idee.

Man kann bei All-Inkl auch selbst in der mod_php-Konfiguration auf 777 verzichten, wenn man dem Upload-Ordner den Owner "www-data" verpaßt. Wie es geht, kann man hier nachlesen:
http://all-inkl.com/wichtig/anleit…-chown_380.html

Dann hat der Webserver Schreibrechte, auch wenn diese nur auf 755 stehen. Muß ich gleich mal ausprobieren...

Gruß
Ingo

Ich sag mal so: Ich bin seit vielen Jahren Webhosting-Kunde bei All-Inkl und habe das von Anfang an so gehandhabt, daß nur der Uploads-Ordner die 777 bekommen hat und ich die Seiten normal im mod_php-Modus laufen lasse. Ich empfinde das zumindest als ein klein wenig sicherer, als den FastCGI-Modus, bei dem PHP auf alle Dateien Schreibzugriff hat.

Andererseits gibt es auch Webhoster wie z.B. Strato und 1&1, bei denen PHP schon immer im FastCGI-Modus läuft. Auch dort bin ich glücklicherweise noch nie Opfer einer Attacke geworden.

Entscheidender für die Sicherheit ist eher, immer mit Wordpress, dem Theme und den Plugins auf dem neusten Stand zu bleiben. Man kann auch mal drüber nachdenken, ob man wirklich alle Plugins benötigt, die man so installiert hat. Je weniger Plugins man verwendet, um so geringer ist auch die Möglichkeit eines Angriffs über ein fehlerhaftes Plugin.

Kurz gesagt, ja.

Gruß
Ingo

Die Rechte 755 und der FastCGI-Modus sind die bequemere Variante, sicherer ist das aber nicht. Ich würde es sogar als unsicherer ansehen, weil nun ein Angreifer über eine Sicherheitslücke schreibenden Zugriff auf alle Dateien des WP-Installation hat (auch die PHP-Dateien) und auch alle sonstigen Daten, die per FTP hochgeladen wurden.

Wenn ich bei der mod_php-Konfiguration, so wie es z.B. bei All-Inkl voreingestellt ist, nur für den Uploads-Ordner Schreibrechte erteile, passiert zumindest den PHP-Dateien nichts.

Gruß
Ingo

Ja, sowas habe ich hier mal geschrieben. Das wäre auch mein nächster Vorschlag zur Problemlösung gewesen.

Gruß
Ingo

$_SERVER['PHP_SELF'] gibt aber das aktuell ausgeführte PHP-Script zurück, was bei Wordpress (fast) immer index.php ist, auch bei konfigurierten Permalinks. Ziel für das Formular wäre dann nicht die Permalink-URL, sondern die index.php, was nicht funktionieren wird.

Gruß
Ingo

Zitat von Tollebella

... Den Hoster hab ich gefragt, das Limit konnte ich hochsetzen, allerdings nur auf 29 MB. Reicht ja vorn und hinten nicht...

Du willst Bilder und MP3-Dateien hochladen, die größer als 29MB sind? Was hast Du vor?

Gruß
Ingo

Du mußt auch beim action= im Formular den Permalink mit echo ausgeben, sonst steht da gar nichts drin und deshalb wird beim Absenden die aktuelle URL inklusive #Anker genommen.

Gruß
Ingo