Beiträge von Putzlowitsch

Ich vermute aber eher, das der Server/PHP beim Fehlen der Werte für "Expires" und "Last-Modified" diese selber setzt. Und zwar auf das Datum der index.php im WP-Wurzelverzeichnis (diese wird ja aufgerufen). Oder es ist ein großer Zufall, daß diese Datei index.php als Dateidatum den 19.11.2006 07:56 hat, zumindest wird das bei mir lokal so angezeigt

Nachtrag: Oder anders herum. Also der Server setzt im Response-Header zunächts die Werte, z.B. Last-Modified auf das Dateidatum der aufgerufenen index.php. Da WP diese Werte normalerweise nicht ändert, bleiben sie also so stehen. Es könnte also doch funktionieren, wenn man diese einfach am Anfang der header.php wieder zurücksetzt.

Es dürfte sich also um ein Konfigurationsproblem von Server/PHP handeln.

Gruß
Ingo

Zitat von marX

Ja. Dafür wirst du jetzt sicher einen ziemlichen Anstieg des Website-Datenaufkommens beobachten, da die Daten eben nicht mehr aus dem Cache kommen, sondern jedesmal neu von deiner Seite geladen werden.

Bei WP werden die Seiten, von Feeds mal abgesehen, grundsätzlich nicht aus dem Cache geladen, weil der Last-Modified Wert normalerweise ganz fehlt. Besser wäre also wahrscheinlich, die Werte anstelle des Aufrufes von nocache_headers() einfach zu löschen:

<?php
  @header('Expires:'); 
  @header('Last-Modified:'); 
  @header('Cache-Control:'); 
?>

Gruß
Ingo

Die nocache_headers()-Funktion hat nichts mit WP-Cache-Plugins zu tun.

Last-Modified: Wed, 09 Apr 2008 07:28:55 GMT

sieht doch erstmal gut aus
Allerdings ist das nur ein Workaround, damit wird zwar die Auswirkung "bekämpft", aber die Ursache bleibt leider im Dunkeln. Konkret stellt sich halt die Frage, wer oder was eigentlich das falsche Last-Modified setzt.

Gruß
Ingo

Nein, du kannst normalerweise direkt auf 2.5 gehen. Ich habe erst kürzlich von 2.0.11 auf 2.5 upgedated (oder geupdated?). Hat problemlos funktioniert. Probleme können eventuell Plugins oder Themes bereiten, die nicht mit neueren WP-Versionen kompatibel sind.

Gruß
Ingo

Die Seite sendet einen falsches Datum im Response-Header:

Expires: Thu, 19 Nov 1981 08:52:00 GMT
Last-Modified: Sun, 19 Nov 2006 06:56:06 GMT

Das hat zur Folge, daß der Browser, beim nächsten Aufruf den Server mit

If-Modified-Since: Sun, 19 Nov 2006 06:56:06 GMT

das nächste mal den Server befragt, der aber mit

HTTP/1.x 304 Not Modified

antwortet.
Warum das so ist, ist schwer nachvollziehbar. Verwendest Du irgendein WP-Cache-Plugin?
Ansonsten könntest Du versuchsweise mal folgende Zeile ganz am Anfang noch vor dem '<!DOCTYPE html PUBLIC...' in der Datei header.php des Themes einfügen:

<?php nocache_headers(); ?>

Davor oder danach dürfen keine Leerzeilen oder Leerzeichen stehen.

Gruß
Ingo

Zitat von codestyling

Es gibt Probleme in WP 2.5 mit:

Code

[B][COLOR=Red]/index.php[/COLOR][/B]/%postname%/

Das solltest du nicht mehr benutzen zum Umschreiben deiner Seiten.

Zumindest für Trackbacks funktioniert es noch unter 2.5. Das war mal mein Workaround für den 404er-Trick bei fehlendem mod_rewrite bei Strato. Gewissermaßen Pseudo-Permalink-Trackbackadressen anstelle von /wp-trackback.php?p=123.

Gruß
Ingo

Zitat von prokik

Sind nicht die "Tags" ein Garant für Double Content. Oder hat jemand damit gute Erfahrungen?

Lg
Prokik

Nach meiner Erfahrung sind Tags nur tagsüber ein Problem, nachts eher nicht

Gruß
Ingo

Das Admin-Passwort steht eigentlich nie in der wp-config.php drin. Man bekommt es ja bei der Installtion angezeigt (mit dem Hinweis, es sich zu notieren) und dann noch per E-Mail zugeschickt.
Das Datenbankpasswort muß natürlich in der wp-config.php stehen, gar keine Frage.

Gruß
Ingo

Das liegt daran, das der IE eine eigene "Platzhalter-Leerseite" ausgibt, wenn vom Server nichts zurückkommt. Das hat also nichts damit zu tun, was der Server gesendet (oder eben nicht) hat.

Ansonsten wäre es noch eine Idee, dem WP eine benutzerdefinierte Installation unterzuschieben. Das geht mit einer Datei install.php im /wp-content/-Verzeichnis. Wenn diese folgendes enthält:

<?php
echo "Upgrade wird geladen.<br />\n";


function wp_upgrade() {
    echo "Upgrade wird gestartet.<br />\n";
}


function wp_install() {
    echo "Install wird gestartet.<br />\n";
}
?>

wird zwar das Upgrade bzw. die Installation nicht ausgeführt, man sieht aber, wie weit man überhaupt kommt.

Gruß
Ingo

Das ist ansich nicht komisch, denn das Apache-Modul suPHP verhindert nur das direkte ausfühern von PHP-Dateien mit unpassenden Rechten, werden diese aber in anderen PHP-Dateien geladen, hat ja bereits der PHP-Interpreter die Kontrolle und suPHP ist außen vor.

Gruß
Ingo

Diese vorinstallierten Sachen sind zwar ganz nett, meist aber nicht aktuell oder halt nicht genau so, wie man es will.
Du kannst Wordpress auch einfach selbst installieren, eine Anleitung findest Du hier:
5 Minuten Installation − WordDoku

Gruß
Ingo

Es gibt Feed-Templates? Wie sieht denn sowas aus?

Gruß
Ingo

Ein Leerzeichen- bzw. Leerzeilenproblem gibt es aktuell auch in einem anderen Thread. Dort verhält es sich genau so wie hier, wie der Test mit der wp-config.php und wp-settings.php zeigt. Aber vielleicht habe ich ja auch nur einen großen Denkfehler gemacht:
http://forum.wordpress-deutschland.org/installation/3…html#post158861
Und jemand kläre mich bitte darüber auf
Kommando zurück, doch ein Denkfehler
Wenn ich die wp-settings.php direkt aufrufe, bricht PHP an der Stelle ab, wenn das erste mal ABSPATH benötigt wird und kommt damit gar nicht mehr bis zu den Plugins. Schade, ich dachte so könnte man den Fehler einkreise.

Gruß
Ingo

Ich denke schon, daß es die wp-config.php ist. Wenn man diese direkt aufruft, wird die Leerzeile ausgegeben. Ruft man dann die von der wp-config.php geladene wp-settings.php (diese lädt dann die Plugins und alles weitere) auf, kommt keine Leerzeile. Wenn ich jetzt keinen großen Denkfehler gemacht habe, kommt deshalb nur die wp-config.php als Ursache in Frage.
Kommando zurück, doch ein Denkfehler
Wenn ich die wp-settings.php direkt aufrufe, bricht PHP an der Stelle ab, wenn das erste mal ABSPATH benötigt wird und kommt damit gar nicht mehr bis zu den Plugins. Schade, ich dachte so könnte man den Fehler einkreise.

Gruß
Ingo

Die Leerzeile ist nicht nur im Feed, sie ist auch auf der normalen Seite. Ich denke, Du hast die Leerzeile in der wp-config.php vor dem öffnenden <?php oder nach dem schließenden ?> drin.

Gruß
Ingo

Meiner Meinung nach, wird für die Beitragsseite einfach die index.php verwendet, oder wenn vorhanden, eine home.php.
Du solltest deshalb das Template für die Startseite anders nennen, z.B. start.php

Gruß
Ingo

Ich könne mir vorstellen, das da ein Plugin dabei ist, daß in der alten Version nur aus einer PHP-Datei bestand und direkt im Pluginverzeichnis war. Bei der neuen Version ist es aber in ein eigenes Unterverzeichnis gewandert, weil es nun weitere Dateien enthält.

Gruß
Ingo

Dann geht es halt mit dem einfachen Trick nicht. Aber weiter oben wurde ja auch ein Plugin genannte, vielleicht kannst Du das damit ja realisieren (ganz ohne Trick).

Gruß
Ingo

Ja gut, das mit der von WP gecachten tiny_mce Geschichte ist mir auch schon aufgefallen. Aber da hilft halt auch nicht das Löschen des lokalen Browser-Caches, wenn WP der Meinung ist, die bereits "gerenderte" und gepackte Version ausliefern zu müssen. Ich sag nur 'wp-content/uploads/js_cache' in WP 2.5, hat mit zu Anfang einiges Kopfzerbrechen bereitet.

Auch andere Broweser haben so eine "Bedigungsloses Neuladen"-Funktion, beim IE ist es eben Strg+"Neu laden". Opera kenn ich nicht, aber es würde mich wundern, wenn es da nicht auch so etwas gäbe.
All diesen Funktionen ist gemeinsam, das sie einfach im HTTP-Request kein IfModiefedSince mitsenden. Dann muß der Server etwas ausliefern.

Das mit den Cookies hingegen muß man so machen, da kommt man nicht drumrum

Nachtrag: FireBug sieht interessant aus, muß ich mir auch mal ansehen

Gruß
Ingo

Ja danke, mittlerweile ist alles angekommen

Gruß
Ingo