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 erstellenok, fertige html seite aus dem RAM wär natürlich der jackpot :)
Ja wo ist das Problem. Genau so läuft es doch. Jedes moderne Betriebssystem hat einen Filesystem-Cache. Also werden die vom Cache-Plugin generierten statischen Seiten ggf. auch nicht mehr von der Festplatte geladen.
Gruß
Ingo
Der "Trick" ist die Abfrage mit /?author=1 (oder einer anderen Zahl). Sind die Permalinks aktiv, wird man auf eine URL /author/name/ weitergeleitet. Man kann das aber unterbinden:
http://forum.wpde.org/allgemeines/13…html#post584961
Gruß
Ingo
Damit die Website funktioniert, sind nur Leserechte erforderlich, also für Verzeichnisse 555 und für Dateien 444.
Wie meinst Du das mit "brauche ich ja auch kein 755"? Wenn Du Dateien per FTP hochlädst, müssen Verzeichnisse und Dateien zumindest für den Eigentümer beschreibbar sein, also 755 bzw. 644.
Selbst 555 und 444 ist bei Servern, wo PHP im Kontext des Benutzers läuft, nicht sicher, denn ein Angreifer kann sich mit chmod() da auch einfach wieder Schreibrechte geben.
Gruß
Ingo
...
- Was ist die beste oder sicherste Rechtevergabe für Wordpress? Ich nehme an dass die Mutation an den Templates durch die Berechtigung 777 reingekommen ist!?
...
Das kann man so pauschal nicht sagen. Es hängt in erster Linie davon ab, wie der Webserver und PHP konfiguriert sind.
Läuft PHP wie z.B. bei Strato und 1&1 als CGI/FastCGI im Kontext des FTP-Benutzers, bietet auch 755 keinen besseren Schutz gegen Angriffe von außen. Denn auch so hat ein ein Angreifer Schreibrechte auf alle Dateien und Verzeichnisse.
Aber 777 für Ordner, in denen PHP-Dateien liegen, ob nun Plugins, Themes oder WP selbst, ist keine gute Idee.
Gruß
Ingo
Wenn auf der Hauptseite schon etwas anderes läuft, geht das so natürlich nicht.
Wenn Wordpress im Verzeichnis /blog/ installiert ist, dann ist das quasi die Wurzelebene, auf die alles andere aufbaut, eben auch die URLs. Selbst wenn man mit irgendwelchen Tricks (.htaccess) oder Plugins das /blog/ entfernen würde, gäbe es vermutlich trotzden Konflikte mit der Hauptseite.
Woher weiß dann z.B. der Webserver ob die URL /das-ist-eine-url zur Hauptseite oder zum Blog gehört?
Ich sag mal so, es geht nicht wirklich.
Gruß
Ingo
Also Wordpress selbst gibt da normalerweise selbst nichts fest vor. Könnte an einem Plugin oder dem Theme liegen.
Ach neee, jetzt sehe ich ja erst, Du hast Wordpress im Unterverzeichnis /blog installiert. Dann geht das so nicht. Nur die Artikel-URLs ohne /blog wird nicht funktionieren.
Was ist denn auf der Hauptseite? Du könntest mit dem ganzen Blog auf die Hauptseite ohne /blog umziehen. Wie das geht, findest Du hier:
http://faq.wpde.org/wordpress-trot…chnis-aufrufen/
Gruß
Ingo
Ja klar, Du mußt nur bei den Permalink-Einstellungen das /blog aus der benutzerdefinierten Struktur entfernen.
Gruß
Ingo
Das liegt daran, daß bei der Kategorieseite oder Archivseite rechts keine Scrollbar zu sehen ist (weil es noch nicht viel zu sehen gibt). Ja nach dem, ob die Scrollbar angezeigt wird oder nicht, verkleinert oder vergrößert sich die Anzeigefläche und damit die Zentrierung.
Ob und was man dagegen tun kann, weiß ich nicht.
Gruß
Ingo
Wie ich schon vermutet habe, die Speichergrenze (Out of memory) liegt bei ca. 30M. Das war bei den alten 1&1-Webhostingpaketen für alle, egal wie teuer, der Standard.
Abhilfe bringt nur ein Paket-Upgrade oder eben auch ein Hoster-Wechsel.
Preislich vergleichbar mit Deinem aktuellen Paket wäre das "Unlimited" (€ 9,90). Allerdings gibts da auch nur ca. 80M Speicher. Das "Unlimited Plus" mit 120M kostet dann schon 19,90.
Die Entscheidung kann ich Dir nicht abnehmen. :-) Aber mit dem aktuellen Paket wirst Du nicht mehr glücklich.
Und wie gesagt, überlege auch, ob Du die Bilder nich vor dem Hochladen verkleinerst. Oder gibt es einen besonderen Grund, die Bilder in voller Größe hochzuladen?
Gruß
Ingo
Ja, ich habe mal ein kurzes PHP-Skript geschrieben, welches die Speichergrenze testet.
Du kannst es am Ende dieses Blogartikels downloaden.
Gruß
Ingo
Ganz einfach, dort wird nur das eingestellte PHP-Memory-Limit angezeigt. Die Speicherbegrenzung bei 1&1 wird aber Betriebssystemseitig realisiert.
Leider funktioniert bei "WP System-Health" die "Test-Suite" nicht mehr. Da wurde nämlich der tatsächlich zur Verfügung stehende Speicher ermittelt.
Gruß
Ingo
...
1&1 Business 5.0 ...
Genau da liegt das Problem. Das ist ein sehr altes Paket. Bei der Generation "5.0" gab es für alle Pakete eine Obergrenze von 32M Speicher. Ein Bild der Größe 5472 × 3648 benötigt für die Verarbeitung schon ca. 60M Speicher.
Du könntest ein Upgrade in das aktuelle "Unlimited"-Paket vornehmen. Da stehen dann wenigstens 80M zur Verfügung. Beim "Unlimited Plus" sind es dann 120M.
Außerdem wäre zu überlegen, ob Du die Bilder vor dem Upload nicht verkleinerst.
Gruß
Ingo
...Der Fehler erscheint nicht mehr und die Bilderthumbs werden geladen. WP erstellt aber im Uploadsordner kein resize img. Sprich ich kann in WP-Post oder Sites keine Größen mehr wählen es gibt nur Vollegröße.
Dann scheint der Speicher trotzdem nicht auszureichen. Das keine Fehlermeldung kommt, ist technisch bedingt.
Wie groß sind denn die Bilder in Pixel (Breite x Höhe)? Die Dateigröße sagt nichts über den tatsächlichen Speicherbedarf aus.
Bei manchen Seiten habe ich das größte Hostingpaket da dürfte nichts fehlen.
Größtes Paket bedeutet erstmal gar nichts. In den älteren Paketen gab es selbst bei den größten eine Speichergrenze von 32M.
http://goo.gl/lkiVFa
Du müßtest schon konkret die Pakete nennen.
Gruß
Ingo
Du benötigst keine FTP-Daten, wenn Du das hier beachtest:
http://forum.wpde.org/installation/1…html#post537403
Gruß
Ingo
Es liegt am je nach 1&1-Hostingpaket (welches hast Du?) zu geringen PHP-Arbeitsspeicher. Eventuell hilft dir dieses Plugin weiter:
https://schnurpsel.de/wordpress-plugins/123-image-resize/
Die Änderungen in der .htaccess solltest Du wieder entfernen und die php.ini löschen.
Gruß
Ingo
...
Bin nach der Anleitung gegangen und habe per FTP den neuen Ordner Child Theme erstellt und dort drin style.css und in diesen Ordner dann den Code geschrieben bzw. kopiert
...
Diese [COLOR ...]-Sachen stehen da in der style.css aber nicht drin, oder?
http://forum.wpde.org/design/134883-…html#post583423
Wenn ja, das muß da raus, das gehört da nicht rein.
Gruß
Ingo
Ein häufiger Grund ist, daß keine oder nicht die richtige Datei als Default-Index konfiguriert ist. Meistens kann man das in der .htaccess-Datei festlegen. Für Wordpress muß als Default-Indexdatei index.php konfiguriert sein. z.B. so:
DirectoryIndex index.phpGruß
Ingo
Es liegt möglicherweise am www/nicht-www.
Die sichtbaren URLs werden mit www erzeugt, die für Resourcen (CSS, JavaScript usw.) aber ohne.
Du solltest bei den Wordpress-Einstellungen in beiden Feldern (Wordpress-Adresse und Seiten-Adresse) dasselbe eintragen.
Gruß
Ingo
...
bei jedem Bild einfach die rot hervorgehobenen Zahlen gelöscht habe (die Lösung fand ich in einem Forum).
...
Das ist keine gute Idee, denn nun werden die Bilder in voller Größe geladen und nur per HTML/CSS für die Anzeige verkleinert. Da Du ja nicht nur ein Bild, sondern 10 bis 15 im Artikel hast, wird alles sehr langsam.
Die Thumbnails sehen aus, als wären sie mit einer ganz schlechten JPEG-Qualität von nur 10% oder so erzeugt worden. Hast Du im Theme oder einem Plugin dazu eine Option, also sowas wie JPEG-Qualität einstellen?
Gruß
Ingo
Echt nicht?
Ich klick da so etwa dreimal am Tag drauf. :-)
Gruß
Ingo
