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 erstellen... Welches Paket hast Du denn bei uns? ...
Hat er doch geschrieben, 1&1 Business 5.0. :-)
Und das ist eins von den ganz alten Paketen, wo es immer die 30MB Speichergrenze gab, egal ob "Business" oder "Business Pro" oder was auch immer.
Ich habe ihm ja schon den Wechsel in "Unlimited" nahegelegt, welches preislich seinem aktuellen Paket ensprechend würde.
Gruß
Ingo
...
Nach der Umstellung auf PHP5.6 hat ein Testupload von einem großen Bild funktioniert. Ich werde es mal an Sie weitergeben in der Hoffnung das es nun klappt.
...
Vermutlich geht PHP 5.6 etwas sparsamer mit dem Speicher um und gleicht so den größeren Speicherbedarf von Wordpress aus. Somit liegen die großen Bildern nun wieder knapp unterhalb der Grenze und es geht gut. Fragt sich halt nur, wie lange. :-)
Gruß
Ingo
...
ich bin eigentlich davon ausgegangen, dass es nicht am memory_limit liegt. Laut dem Memory Overview meines Wordpress nutze ich nur ~ 26 MB von verfügbaren 120 MB.
...
Vermutlich handelt es sich um ein älteres (5.0, Smart Web L) oder kleines (Starter) 1&1-Paket. In diesen Paketen gibt es eine betriebssystemseitige Speicher-Grenze von ca. 30MB.
Hier hilft nur ein Paket-Upgrade oder ein Hoster-Wechsel.
Gruß
Ingo
Die Fotos haben eine Abmessung von 4912 x 3264 und liegen in der Regel zwischen 5-8 MB.
An der Abmessung kann es doch eigentlich nicht liegen wenn bis vor paar Tagen der Upload noch problemlos lief.
Falls das automatische Wordpress-Update der letzten Tage eingespielt wurde, kann es schon daran liegen. Wordpress benötigt in der neuen Version selbst etwas mehr Speicher und zuvor hat es mit den Bildern gerade so an der Speichergrenze geklappt.
Du hattest ja auch geschrieben, daß es früher auch schon mal Probleme gab. Je nach Veränderungen in Wordpress, im Theme oder bei Plugins ändert sich der Speicherverbrauch und wenn die Bilder gerade so an der Grenze "langschrammen", funktioniert es, oder eben machmal auch nicht.
Lange Rede, kurzer Sinn, du mußt die Bilder vor dem Upload verkleinern, z.B. auf 2000 x 1500 Pixel.
Gruß
Ingo
...
Leider habe ich unter Strato die Statistik nicht finden können. Der Punkt Statistik fehlt auf der Linken seite im Reiter.
...
Mein Fehler, im kleinsten Paket "Starter" gibt es leider keine Statistik und keine Logfiles.
Ich vermute mal, daß bei größeren Bildern (Abmessungen in Pixel, nicht Dateigröße!) der Arbeitsspeicher nicht ausreicht, um die Bilder in den anderen Größen zu erstellen. Dann wird das Bild selbst zwar hochgeladen, aber erscheint nicht richtig in der Mediathek und es gibt eine Fehlermeldung.
Welche Grenzen bei welchen PHP-Versionen existieren, kann man hier nachlesen:
http://goo.gl/Eg3leX
Wenn es noch PHP 5.2 wäre, würde die Umstellung auf PHP 5.5 oder 5.6 eine leichte Verbesserung bringen.
Aber das grundsätzliche Problem (zu große Bilder) läßt sich so nicht lösen.
Gruß
Ingo
Im Strato-Kundenbereich findest Du unter dem Menüpunkt "Statistik" einen Unterpunkt "Logfiles" und dort "Errorlogs". Mit [Error-Logfile anzeigen] kannst Du das Fehlerprotokoll ansehen. Möglicherweise findet man dort Hinweise zur Fehlerursache.
Werden denn die Bilder hochgeladen und nur die Thumbnails fehlen? Wie groß sind die Bilder von der Dateigröße her und von den Abmessungen (Breite x Höhe in Pixel)?
Gruß
Ingo
Sofern das Webhosting-Paket bei Strato nicht älter als 5 Jahre ist, sollte mod_rewrite verfügbar sein.
Üblicherweise ist auch die .htaccess-Datei bei Strato problemlos von Wordpress beschreibbar, da PHP dort als CGI/FastCGI im Kontext des FTP-Benutzers läuft.
Gruß
Ingo
Die Symptome sprechen eher für einen Mangel an Arbeitsspeicher, der für die Erstellung des Thumbnails und der Bilder in anderen Größen benötigt wird. Je nach Webhoster kann man da selber etwas anpassen oder auch nicht.
Gruß
Ingo
Bei Wordpress.com gibt es ein eigenes Forum:
http://de.forums.wordpress.com/
Du solltest Dein Problem dort schildern.
Hier bei wpde geht es nur um selbstgehostete Wordpress-Blogs.
Gruß
Ingo
Preislich vergleichbar mit Deinem alten Paket wäre das aktuelle Paket "Unlimited" für 9,99 Euro.
Bei einem Upgrade mußt Du selbst technisch nichts weiter machen. Problematisch ist es nur, wenn Du Features der alten Pakete wie CGI-Programme oder die Content-Module verwendest, die es mittlerweile nicht mehr gibt.
Im aktuellen Paket hast Du insgesamt mehr Leistungen enthalten. Die PHP-Ressourcen sind mit 80MB Memory-Limit, 40 Sekunden Scriptlaufzeit und 15 Prozessen zwar nicht überragend, aber ausreichend, würde ich sagen.
Gruß
Ingo
Fatal error: Out of memory (allocated 28573696) (tried to allocate 36 bytes) in /homepages/17/d13395111/htdocs/wordpress/wp-includes/option.php on line 174
...
Du scheinst ein älteres 1&1 Paket (5.0, Smart Web L) oder Starter zu haben, bei denen es eine Speichergrenze von ca. 30MB gibt. Da hilft eigentlich nur ein Paket-Upgrade oder ein Wechsel des Webhosters.
Gruß
Ingo
Welches Hostingpaket hast Du denn bei 1&1. Da gibt es schon einige Unterschiede bei den zur Verfügung stehenden Ressourcen.
Gruß
Ingo
Gut, dann frage ich mal konkret, welches Webhostingpaket Du bei 1&1 hast. Da gibt es schon Abstufungen bei den zur Verfügung stehenden Ressourcen.
Mein Testblog läuft in einem 1&1 Paket "Basic" (60MB Memory-Limit, 20 Sekunden Skriptlaufzeit, 10 Prozesse) ohne Probleme. Beim Paket "Starter" oder älteren Hostingpaketen kann es durchaus Probleme mit den Ressourcen gegen.
Gruß
Ingo
...
WordPress telefoniert nirgendwo hin...
Kann man so auch nicht sagen. Wordpress "telefoniert" zweimal täglich nach Hause um festzustellen, ob es neue Updates gibt. :-)
Gruß
Ingo
...
Du verwendest mod_php5 und warum benötigt Wordpress dann FTP-Zugang? Da stimmt was nicht! Mit mod_php hat PHP die Rechte von dem WebServer und läuft als Teil des Webservers. kann somit ohne Probleme Dateien kopieren, speichern und ändern.
...
Nein, das ist üblicherweise genau anders herum.
Der Nutzer installiert WP per FTP, folglich gehören alle Dateien dem FTP-Nutzer. Wenn PHP als Apache-Modul läuft, hat der Nutzer wwwrun oder wie immer er heißen mag, eben keine Schreibrechte auf die Daten des FTP-Nutzers.
Wenn PHP als CGI/FastCGI konfiguriert ist, läuft es im Kontext des FTP-Benutzers und hat Schreibrechte auf alles.
Gruß
Ingo
maddin1502
Im letzten Screenshot steht zumindest "Content-Encoding" = gzip.
Das könnte das Problem sein, zumindest kenne ich es von älteren WP-Versionen.
Es dürfte schon reichen, wenn man für den /wp-admin/-Order die Ausgabekomprimierung deaktiviert.
Gruß
Ingo
...
User-agent: *
Disallow: /wp-admin/
...
Das war vermutlich die virtuelle robots.txt, die Wordpress erzeugt. Falls es irgendwie Probleme mit Wordpress, z.B. mit der Datenbank gibt, wird eben auch diese robots.txt nicht erzeugt.
Eine echte robots.txt-Datei ist in jedem Fall besser.
Gruß
Ingo
Früher gab es mal ein Problem, wenn die Ausgabe per mod_deflate (o.Ä.) komprimiert wird.
Wenn die Ausgabe per flush direkt in den HTTP-Antwort-Stream erfolgt, ist natürlich nichts zu sehen, weil die Ausgabekomprimierung warten muß, bis die Seite vollständig erzeugt wurde.
Wie die Ausgabe aktuell in WP erfolgt, weiß ich aber nicht.
Gruß
Ingo
...
Das es am Hoster liegt, glaube ich aber auch nicht, da vermutlich Wordpress bei tausenden anderen problemlos läuft.
Genau, ich betreibe Wordpress 4.0 mit PHP 5.6 bei 1&1 und es gibt keine der beschriebenen Probleme.
Gruß
Ingo
...dass man durch ein Anhängen von "?author=N" (probieren von 1, 2, 3 usw.) oben in die Adresszeile “http://www.logname.de/?author=N” alle Artikel des Autors mit der ID N sehen kann, wobei dann auch der Name in der Adresszeile auftaucht...
Genau das hatte ich ja geschrieben, aber schön, wenn Du es nun selbst rausgefunden hast. :-)
Gruß
Ingo
