Es dürfte daran liegen, daß bisher keine oder nur sehr wenige von den Spzialisten hier Google Chrome verwenden. ![]()
Ist Chrome nicht sowieso noch Beta?
Gruß
Ingo
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 erstellenEs dürfte daran liegen, daß bisher keine oder nur sehr wenige von den Spzialisten hier Google Chrome verwenden. ![]()
Ist Chrome nicht sowieso noch Beta?
Gruß
Ingo
Seit WP 2.1 wird beim Ändern des Permalinks der alte Permalink in der Tabell wp_postmeta als _wp_old_slug gespeichert und gegebenenfalls dann per 301 auf den aktuellen Permalink umgeleitet. Hat also nichts mit den Revisionen zu tun.
Gruß
Ingo
Ich würd mal denken, das Statpress der Verursacher ist, bei den SQL-Statments findet sich Folgendes:
Statistikplugins, die alle Zugriffe in einer Datenbanktabelle ablegen, erzeugen sehr viele Schreibzugriffe uaf die Datenbank. In den 1&1 FAQ steht auch ausdrücklich, das man die Datenbank dafür nicht nutzen soll:
1&1 Hilfe-Center - Wichtige Punkte für den Einsatz von MySQL-Datenbanken
ZitatVerwenden Sie die MySQL-Datenbanken nicht für sogenannte Hochlastanwendungen (z.B. Chatsysteme, Logauswertungen, Addclicks, Bannertausch und Ähnliches).
Mußt Du Dich wohl nach einem anderen Statistik-Plugin umsehen, eventuell was externes.
Gruß
Ingo
Man muß es leider so sagen, wie es ist. Es liegt an Strato und nicht so sehr an WP 2.7 oder dem Inhalt der Datenbank.
Im Moment ist bei Strato z.B. der Datenbankserver kaum erreichbar. Das sieht man daran, das auch die Datenbankverwaltung im Kundenbereich (WebDatabaseManager) nicht auf die Datenbank kommt (so ist es zumindest bei mir derzeit). Das trifft allerdings nur auf MySQL 5 zu, die 4er DB ist erreichbar.
Für meine Schnurpsel-Seite behelfe ich mir z.Z. mit einer externen Datenbank.
Und noch ein Hinweis, falls Du die Strato-Datenbankverwaltung aus dem Kundenmenü startest und mit Firefox 3 unterwegs bist, verwende beim Export als Komprimierung nicht GZip, das geht in die Hose.
Gruß
Ingo
Es gibt ein Update des html-Plugins, bei dem das Problem mit der Homeseite nicht mehr auftritt.
Ansonsten kann ich zum Ausschließen von Seiten auch das "123 Homelink"-Plugin empfehlen ![]()
Gruß
Ingo
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