Beiträge von Putzlowitsch

Ich habe keine Ahnung, wie das geht.

Gruß
Ingo

Zitat von selm

..und das bekomm ich nicht weg? :(

Nein, wenn Du Widgets verwendest, nicht ohne weiteres. Du könntest bestenfalls den Widget-Code patchen oder versuchen, das <br /> per CSS "unschädlich" zu machen. Da hab ich aber erstmal keine Idee.

Gruß
Ingo

Möglicherweise ist er das, wenn man keine Widgets verwendet.
Zumidenst sieht das bei dir so aus:

<div>
<input type="text" name="s" id="s" size="15" />[B]<br />[/B]
<input type="submit" value="Suchen" />
</div>

Da ist hinter dem Eingabefeld ein Umbruch.
Nachtrag: Hab es grad mal getestet, ohne Widgets, also im Auslieferungszustand, ist er tatsächlich daneben. Sobald man aber Widgets verwendet, nicht mehr.

Gruß
Ingo

Der "Suchen"-Button wird vom Widget explizit mit einem <br> auf die nächste Zeile umgebrochen. Da kann man so auf die Schnelle nichts machen. Zudem wäre er neben dem Suchfeld auch zu breit.

Gruß
Ingo

selm
Bitte immer mit angeben, ob man Widgets verwendet oder nicht. Bei Widgets muß man das natürlich bei den Widget-Optionen einstellen (so es sie gibt).

Gruß
Ingo

Hmm, das ist natürlich schlecht, der 1. Januar 1970 liegt schon sehr weit zurück. Gab es da überhaupt schon das Internet? :-)

Dann wirst Du es vorerst bei dem nocache_headers() belassen müssen. Ist allerdings schon komisch, man müßte herausfinden, wo die anderen Werte herkommen. Da habe ich jetzt aber erstmal auch keinen Ansatzpunkt.

Gruß
Ingo

Eine weitere Seite, z.B. "Blog" anlegen und dann der Option "Beitragsseite" zuweisen:
Schnurpsel » Wordpress ab 2.1 - Optionen für die Startseite

Gruß
Ingo

Letztendlich wird ja über das Veröffentlichungsdatum festgelegt (absteigend sortiert), welche Artikel im Feed drin sind. Man müßte also nicht nach dem Veröffentlichungsdatum, sondern dem Änderungsdatum sortieren.
Sowas wäre mit einem Plugin machbar, welches sich vor der Ausgabe des Feeds einklinkt (z.B. mit add_action('rss2_head', ...); ) und dort die Abfrage per

query_posts( $query_string.'&orderby=modified' );

oder so ähnlich entsprechend modifiziert.

Gruß
Ingo

Die Anführungszeichen werden von WP umkodiert als

& #8220; bzw. & #8221;

Andere Feedreader haben damit eigentlich keine Probleme.

Gruß
Ingo

Bei Feeds ist das einfach, da kann WP direkt aus der Datenbank auslesen, wann es die letzte Änderung gab. Bei den Seiten selber allerdings nicht, gerade wegen einer Vielzahl möglicher dynamischer Inhalte, die irgendwo in der Sidebar oder sonstwo im Theme oder über Plugins eingefügt sein können.

Ich denke mal, das die Variante mit dem Löschen der Header in der header.php am paraktikabelsten ist, wenn sie funktioniert. Nur als Workaround versteht sich, der eigentlichen Ursache sollte man schon auf die Schliche kommen.

Gruß
Ingo

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