Beiträge von Putzlowitsch

Ich rate zwar normalerweise davon ab, aber hier sehe ich im Moment keine andere Möglichkeit, als einen Eingriff in die WP-Datei query.php (im wp-includes Verzeichnis) durchzuführen. An der oben bereits gezeigten Stelle folgende Änderung vornehmen:

// Category stuff for nice URLs
        if ( '' != $q['category_name'] /*&& !$this->is_singular*/ ) {
            $reqcat = get_category_by_path($q['category_name']);

Also den zweiten Teil im if(...) in Kommentarklammern /* ... */ enschließen. Ich kann nun auch nicht sagen, ob das eventuelle noch andere Nebenwirkungen hat, also auf eigenes Risiko machen und mich dann bitte nicht verklagen, wenn was schief geht :-)

Gruß
Ingo

Weder noch, das Umsetzen der aufgerufenen URL, also das Auflösen des Permalinks, macht Wordpress intern.
In der query.php ab Zeile 1818 (WP 2.7) ist dann auch die Ursache für das beobachtete Verhalten zu finden:

// Category stuff for nice URLs
        if ( '' != $q['category_name'] && !$this->is_singular ) {
            $reqcat = get_category_by_path($q['category_name']);
             ...

Hier wird die Prüfung der Kategorie nur dann ausgeführt, wenn es sich nicht um eine einzelne Seite handelt (&& !$this->is_singular). Warum das dort ausgeschlossen wird, weiß ich nicht. Ich würde es für einen Fehler halten.

Wenn man die Prüfung auf Einzelartikel ausklammert, wird bei nicht vorhandener oder falscher Kategorie per 301er auf die richtige URL weitergeleitet.

Gruß
Ingo

Interessanterweise sind die Artikel aufrufbar, egal was da als Kategorie steht, z.b. auch:
- example.com/xyz/innenpolitisches-glaskugelsehen/
- example.com/blafasel/innenpolitisches-glaskugelsehen/
- example.com/hustendrops/innenpolitisches-glaskugelsehen/
- ...

Habe die originale Domain nur durch example.com ersetzt, es sollen ja nun nicht unendlich viel "Doppelter Content" entstehen.

Ist wohl ein ähnlicher Effekt wie Verwendung der Artikel-ID in der Permalinkstruktur, da darf die Adresse ein beliebiger Text sein, wenn nur die ID an der richtigen Stelle steht (z.B. am Anfang oder Ende).
Nachtrag: Bei der Sache mit der ID scheint sich was getan zu haben, das funktioniert bei WP 2.7 nicht mehr. Bei WP 2.5.x konnte man Artikel mit der ID im Permalink noch mit jedem beliebigen Linktext aufrufen.

Gruß
Ingo

Ähmmm, also bei mir kommt eine etwas andere Fehlermeldung (Unknown modifier '/'), tschuldigung.
Aber das Probem gab es hier schon mal:
http://forum.wordpress-deutschland.org/konfiguration/…preg_match.html

Gruß
Ingo

Du kannst den Delimiter nicht maskieren. Du darfst bei den Permalinkeinstellungen nur kein !-Zeichen verwenden.

Gruß
Ingo

An der Stelle werden die Rewriterules aufgelöst. Wenn nun z.B. bei Kategorie-Basis oder Tag-Basis in den Permalinkeinstellungen ein !-Zeichen reingerutscht ist, kommt genau dieser Fehler. Ich kann den so bei mir reproduzieren.
Ist letzendlich aber ein WP-Fehler, denn das als Delimiter verwendeten Zeichen muß natürlich maskiert werden.

Gruß
Ingo

Man wird Dir da dann vermutlich zu einem VServer oder Server raten. Ein Problem ist meiner Meinung nach auch, daß PHP bei Strato (und z.B. 1&1) als CGI und nicht als Servermodul läuft.

Gruß
Ingo

Liegt am Strato-Webhosting, da wird man außer mit Cache-Plugins nicht viel machen können.

Gruß
Ingo

Naja, dann könnte man davon ausgehen, das irgendwas im Browser (aber was?) oder auf dem Weg ins Internet (Firewall,Router,Proxy) die URL verändert. Das müßte man dann rauszufinden.
Wenn es aber keine diesbezüglichen 404er im Logfile gibt, wurde nicht mal der Versuch unternommen, die Seite aufzurufen, das wäre dann aber schon sehr seltsam.

Gruß
Ingo

Ja genau, das hängt vom Webhoster ab, wo die liegen und ob man da überhaupt darauf zugreifen kann.

Gruß
Ingo

Vieleicht ist ja irgendwas in den Serverlog-Dateien zu sehen. Zumindest sollten die fehlerhaften Zugriffe da als 404er auftauchen. Dann könnte man sehen, ob z.B. die URL irgendwie verändert wird oder so.

Gruß
Ingo

Das Feld term_group ist bei mir in der Tabelle wp_terms z.B. immer 0, keine Ahnung, wofür das gedacht ist.
Die Zuordnung der Terms zum Typ (taxonomy) erfolgt in der Tabelle wp_term_taxonomy.
Es ist also eigentlicher kein Fehler, sondern eher ein Feature :-)

Der selbe Term ist halt nur einmal vorhanden und wird lediglich den Typen wie Kategorie, Linkkategorie und Tag zugeordnet. Damit ist auch klar, daß sich die Änderung des Terms immer auf alle Typen auswirken muß.

Gruß
Ingo

S.i.T.
So, hab mal mein Wetter wieder eingebaut. Ich will ja nicht daran schuld sein, daß Du über die Kälte in Frankfurt klagen mußt :-)

Außerdem war der eigentliche Grund für das Entfernen eher ein technischer, das Wetter war am 22.10. stehen geblieben und wurde nicht mehr aktualisiert. Ich hatte aber keine Lust gehabt, die Ursache herauszufinden.

Gruß
Ingo

Zitat von Too-Much-Word-Press-ure

...
Wenn wir schon über schlimm oder langweilig reden, finde ich es genauso "schlimm", dass die, die keine Zitate präsentieren, Wetterberichte auf ihren Seiten als Lückenschließer verwenden.
Das finde ich noch viel sinnfreier, denn was interessiert einen Besucher aus dem "globalen Dorf" wie z.B. das Wetter in Braunschweig, Stuttgart oder Frankfurt oder ist...

Genau deswegen habe ich das Wetter nun auch nach zwei Jahren wieder von meiner Seite genommen.

Obwohl ich damit weniger das globale Dorf als vielmehr mich selber beglücken wollte. Immerhin rufe ich mein eigenes Blog wenigstens einmal am Tag auf und hatte so auch immer gleich das Wetter mit auf einen Blick im Auge.

Gruß
Ingo

Aha, also Streams, fopen und fsockopen scheinen bei vielen Hostern der Standard zu sein, manchmal ist auch noch cURL dabei, HTTP Extension hingegen habe ich bisher noch nicht gesehen.

Bei mir war z.B. "Streams" das Problemkind, da hatte ich dann zwar keinen Timeout, dafür aber Verbindungsabbrüche. Sieht so aus, als ob Stream öfter mal Probleme beitet.

Gruß
Ingo

Ja, alles zu deaktivieren ist keine gute Idee, weil dann viele Funktionen (Ping und Trackback, späterer Veröffentlichungszeitpunkt von Artikeln u.Ä.) außer Kraft gesetzt sind. Wenn es mit fsockopen akzeptabel läuft, dann solltest Du das aktiv lassen.
Normalerweise werden z.B. die Versionschecks für WP, Plugins und Themes auch nicht zu häufig ausgeführt (alle 12 Stunden). Wenn sie jetzt einmal abgearbeitet sind, sollte alles auch mit aktivem fsockopen recht schnell funktionieren.

Noch eine Frage, welche Methoden werden denn bei Dir zur Auswahl angezeigt?

Gruß
Ingo

Ich habe irgendwie bei den ganzen Problemen mit extrem langsamen WP 2.7-Versionen den WP-Cron mit den Versions-Checks und die neue HTTP-Klasse im Verdacht. Wenn da eine der formal funktionierenden Methoden in einen Timeout läuft, könnte das zu diesen Verzögerungen führen.
Mein Vorschlag daher, das Plugin "123 HTTP Transport" installieren und testweise alle Methoden deaktivieren bzw. nur fsockopen aktiviert lassen und gucken, ob es was bringt.

Gruß
Ingo

Dann geht wahrscheinlich die Uhr von dem Rechner, mit dem die E-Mail versendet wird, etwa 40 Minuten vor. Der Veröffentlichungszeitpunkt wird aus dem Datum (z.B. 'Date: Mon, 5 Jan 2009 20:04:59 +0100') im E-Mail-Header bestimmt.

Gruß
Ingo

Ich weiß nicht, wie es bei älteren Versionen ist, aber ab Wordpress 2.5 gibt es dafür die Konstante AUTH_COOKIE. Das könnte dann in der wp-config.php etwa so aussehen:

define( 'AUTH_COOKIE', 'wordpress_ehz6r7qrq7tcr466rt5q34956q' );

Normalerweise verwendet WP selbst einen MD5-Hashwert aus der Option 'siteurl'. Das kann ein "Angreifer" natürlich relativ einfach nachbilden.

Die Dateien außerhalb des Documentroots abzulegen bringt eigentlich auch nicht viel, denn die angemeldeten Nutzer hätten dann auch keinen Zugriff. Man müßte sie dann erst wieder per PHP oder so herausholen.

Gruß
Ingo

Ich hab es grad mal getestet. Habe zwar das L-Paket bei HE, aber auch dort ersetzt das Plugin mod_rewrite durch das ErrorDocument, wenn es aktiv ist.
Man muß auf jeden fall die Reihenfolge beachten und eine beschreibbare .htaccess-Datei im WP-Wurzelverzeichnis haben.

1. Plugin "123 No Rewrite Permailnk" installieren
2. Plugn aktivieren
3. Permalinks wie gewünscht einstellen
4. Nachsehen, ob die richtigen Sachen in der .htaccess stehen:

# BEGIN WordPress
# Alle '404 Not Found'-Fehler auf index.php umleiten
# ersetzt die mod_rewrite-Regeln durch ErrorDocument 404
# siehe http://schnurpsel.de/wordpress-bei-strato/wordpress-permalinks.html
ErrorDocument 404 /index.php


# END WordPress

Gruß
Ingo