Erstaunlich, wie schnell sich Gerüchte in der Blogosphäre verbreiten, ohne dass mal jemand nach dem Sinn fragt. Da brechen einige wenige Blogs unter der Last des Google-Traffic zusammen, und schon fangen Gott und die Welt an ihren Blogs herumzuschrauben – wie anno dunnemal Manni an seinem Manta….
Ich mein’, ist ja schön und gut, sich endlich einmal Gedanken um den Performancehunger mancher Plugins Gedanken zu machen, immerhin haben es schon einige besonders ausgebuffte Profis auf beinahe 5700 Queries zum Laden einer einzelnen Archivseite gebracht – aber meiner Meinung nach ist das nur ein eher nebensächlicher Aspekt, denn viel schlimmer sind die .htaccess-Files von WordPress. Und das der neuen Version 2.0 ist in der Hinsicht erst recht eine Seuche.
Um aber vorher nochmals kurz zu den MySQL-Selects zurückzukommen – MySQL ist weithin bekannt dafür, gerade beim lesenden Zugriff praktisch das schnellste RDBMS der Welt zu sein. Und das führt sich letztlich auf intelligente Caching-Mechanismen zurück, nicht auf besonders toll optimierten C++-Code. Was MySQL vor allen Dingen so rasant schnell macht ist der Verzicht auf Transaktionssicherheit beim Standard-Tabellenformat myISAM – und Transaktionssicherheit braucht bei einem Blog nun wirklich kein Mensch.
Folglich kann eine Reduzierung der MySQL-SELECTs zur Performance-Optimierung nur die halbe Miete sein, ich würde dies tendenziell sogar eher nach hinten in der Prioritätenreihe einsortieren. Aber wie üblich fragt mich ja keiner, ne? 
Wesentlich wichtiger sind hingegen die Aspekte der Größe des ausgelieferten HTML-Codes der einzelnen Seiten, dessen Cachebarkeit (WP Cache ist nicht umsonst ein sehr beliebtes Plugin bei HighTraffic-Blogs) und die PHP-Load, die durch den Zusammenbau der Seiten auf dem Server verursacht wird.
Und hier ist WordPress wirklich eine Seuche. PHP ist prinzipiell nicht eben die langsamste Scriptsprache, aber selbst hier sind gewisse Grenzen gesetzt. Und zu den Sinnlosigkeiten dieser Welt im hinblick auf WordPress zähle ich es, CSS- und JS-Dateien mit der Endung .php zu versehen, selbst wenn überhaupt kein PHP-Code enthalten ist, oder, wie im Beispiel von K2, nur eine einzige Zeile PHP-Code für die Livesuche benötigt wird, die man ebenso problemlos auch aus dem Script herauszerren könnte, den Wert stattdessen in eine globale Variable packt und damit das Script ein solches sein läßt. Denn, das vergessen unsere begabten Meisterblogger in aller Regel (die wenigsten von ihnen sind schließlich professionelle Webentwickler), was keine dynamische Dateiendung hat, können die Browser cachen – und im Fall der Livesuche passiert dies eben dann nicht, sofern das Script noch PHP-Code enthält.
Seuche numero due: die exzessive und oben schon angesprochene .htaccess-Datei, die WP anlegt, sobald man sich für eine Permalinkstruktur entscheidet. Jede statische Seite führt zu fünf bis sechs neuen Einträgen in dieser Datei, und schon ohne statische Pages ist eine erkleckliche Anzahl sogenannter Rewrite-Rules enthalten. Diese haben nun den Nachteil, von einem Teil des Apache namens Rewrite-Engine interpretiert zu werden. Und dieses Modul führt folglich zu einer deutlich erhöhten Last des Apache, verglichen mit der Auslieferung rein statischer Seiten.
WP 2.0 verschlimmert dies durch seine neuen Regeln sogar noch – an eine vorhandene .htaccess werden ein paar neue Regeln angehängt, ohne nach Sinn und Zweck zu fragen, die den gesamten Satz vorhandener Rewriterules sinnlos und überflüssig machen – denn WP2 bringt seine eigene Rewrite-Engine mit. Blöde nur, dass genau diese Regeln in der .htaccess nun erst dann greifen, wenn alle vorherigen Regeln nicht gegriffen haben, ein Request also quasi “bis unten durchfällt”. Nun erfolgt eine (nochmalige) Prüfung, ob zu dem Request-URI eventuell eine echte Datei auf dem Webserver gehört – der Apache muss also ein zweites Mal (!!) nachschaun, ob’s da eventuell eine Datei gibt, die passt, bevor der Request dann endgültig an PHP abgegeben wird. Dieses Prozedere muss nun bei jedem Request – selbst für Bilddateien! – durchgeführt werden – halleluja, ich denke ihr habt begriffen, was das für die Serverlast bedeutet.
Seuche numero drei schlägt nun zu: Auf Webservern, in die PHP als Apachemodul eingebunden ist, wird die Last nun vom Rewrite-Modul ans PHP-Modul weitergegeben, was soweit noch nicht sooo schlimm ist. Da PHP aber dank einer erklecklichen Anzahl Sicherheitslücken unter Webadmins in Verruf geraten ist, läuft PHP auf sicher konfigurierten Servern im sogenannten CGI-Modus – und der ist um bis zu Faktor 30 langsamer als im Modulbetrieb! Man kann sich also bildlich vorstellen, was nun passiert – nachdem sich der Apache in Native-C-Code durch seine Regeln gequält hat, darf nun das “arme” PHP-Paket sein Glück durchs Interpretieren einer Scriptsprache mit reichlich regulären Ausdrücken auch noch einmal versuchen – und da tritt der Grossteil der Last nun auf!
Allererste Maßnahme eines jeden WP-Bloggers, der auf WP2 aufrüstet, sollte also sein, seine .htaccess-Datei aufzuräumen, um wenigstens schon einmal die Rewrite-Engine zu entlasten. Zweite Maßnahme sollte die ernsthafte Überlegung sein, ob man FancyURLs für seine Permalinks denn unbedingt benötigt, und sollte diese Antwort mit “ja” ausfallen, ob es denn unbedingt das komplexe Jahr-Monat-Tag-Titelform-Format sein muss, oder ob es nicht ein deutlich einfacherer Regelsatz schon täte.
Was die WordPress-Entwickler geritten hat, wenn sie schon mit einem massiven Aufgebot von Rewriterules um sich schlagen müssen, diesen Job lieber einer “lahmen” Scriptengine zu übertragen als einem auf Hochperformanz ausbaldowerten Rewrite-Modul des Webservers, entzieht sich meiner Kenntnis; ich kann nur vermuten, dass die Pflege der .htaccess-Rules den meisten Anwendern zu schwierig war und zu kryptisch ausfiel. Dem Webserver tut dies jedenfalls überhaupt nicht gut.
Und: Apache 1.3.x-Server leiden hierunter noch deutlich mehr als ein auf Apache 2.0.x aufsetzender Server!
Hugh! Habe gesprochen!
13 Kommentare
Sven sagt:
17.01.2006 von 07:08 (UTC 0 )
Warum habe ich auf diesen Artikel von dir so sehnlichst gewartet
Da es in mein Blog nicht so ganz reinpasst und ich eh nichts anständiges darüber zustande bekomme, schreibe ich eben hier 
Ich gebe dir da vollstens recht, WP 2.0 ist die absolute Seuche. Ich habe den Fehler gemacht und sofort nach der Veröffentlichung WP 2.0 beta installiert. Die geänderte Datenbankstruktur hat mich jetzt lange daran gehindert wieder auf 1.5.2 downzugraden. Aber nach einem halben Sonntag Arbeit hab ich es geschafft.
Der MySQL-Prozess ging durch irgendeine Last auf dem Server ständig in die Knie und musste neu gestartet werden. Zum Schluß hat das monit übernommen, alle halbe Minute zu prüfen und gegebenenfalls diesen Prozess neu zu starten.
Jetzt läuft seit Sonntag wieder WP 1.5.2 und was soll ich – monit hat mich letzte Nacht kein einziges Mal angemailt, dass MySQL gestartet werden musste. Und die Zugriffszahlen waren nicht niedrig seit Sonntag Abend.
Nebenbei habe ich noch die .htaccess etwas abgespeckt. Dass ich so penibel bin, und sogar den WordPress-Pfad zur CSS-Datei überschreibe und auch meine Smilies ist ein anderes Thema
Vielleicht ändere ich das auch noch. Allerdings nur, wenn ich immer noch Probleme mit der Rechnerleistung habe.
Aber für was in aller Welt brauche ich für WP-statische Seiten, wie zum Beispiel das Impressum, eine Regel, die auf den RSS-Feed weiterleitet? Das man eine Seite in mehrere aufteilt ist in Ordnung, aber auch das wird doch von den wenigsten gemacht, oder? Ich habe einfach die Regeln rausgeworfen, die ich nicht brauche und einfach nur noch zum Beispiel:
RewriteRule ^(impressum)(/[0-9] )?/?$ /index.php?pagename=$1&page=$2 [QSA,L]
stehengelassen. Der Rest ist nur Ballast.
Die WP 2.0 htaccess-Datei enthielt doch nur die Abfrage, ob Ordner oder Dateien physisch auf vorhanden sind, wenn nicht sollte ALLES auf die index.php weitergeleitet werden. Ist das genauso Performancelastig, wie 30 Regeln nacheinander? Für mich kam das eh nicht in Frage, weil ich in der htaccess noch meine eigenen Regeln stehen habe.
An dem Weg: Was heißt eigentlich “klecklich” :nixwiss
Jörg Petermann sagt:
17.01.2006 von 07:15 (UTC 0 )
Was für jeden SINN macht, ist schwer zu beantworten und Du wirst dabei von jedem unterschiedliche Meinungen erleben. Außer Blondinen-Witzen und Klum-Diskussionen gibt es sicher weitaus geistreichere Diskussionen.
Toll finde ich es in dem Zusammenhang übrigens immer, nicht nur seine Meinung zu schreiben, sondern ganz konkret auch Vorschläge zur wirklichen Verbesserung zu machen. DAS macht aus meiner Sicht den Sinn und so habe ich die Szene seiner Zeit in Amerika kennen und wirklich schätzen gelernt.
Es gibt sehr wenig Blogger, die sich erstens um die Optimierung ihrer Blogs kümmern und es dann zweitens auch noch verständlich aufschreiben können. Die allermeisten dürften froh sein, überhaupt das Tool händeln zu können. Sehr unterschiedliche Voraussetzungen also. Die meisten werden Deine Andeutungen nicht verstehen.
Zu den Fancy URLs: Wenn Du allen Ernstes das URL-Design zur Wahl stellst, hinkt Deine Betrachtung ebenso. Wenn Du suchmaschinentechnisch etwas mit dem Blog erreichen willst, BRAUCHST Du diese URLs. Was hilft mir ein schnelles Blog, wenn es keiner mehr lesen kann, weil die Leute es über Google nicht finden???
Gern kannst Du dazu auch mein Tutorial zum URL-Design lesen. Da habe ich das ausführlichst beschrieben, auch die Fragen der Permanenz einer URL, die Du erwähnt hast.
Wie Vorschläge machst Du, effektiv die Misstände zu beseitigen oder abzuschwächen?
Welche Alternativen sind aus Deiner Sicht denkbar?
Jörg Petermann sagt:
17.01.2006 von 09:26 (UTC 0 )
Uups, was machst Du denn mit der Zeichencodierung in Deinen Kommentaren?
CountZero sagt:
17.01.2006 von 09:52 (UTC 0 )
guten morgen zusammen, erst einmal vielen dank für das reichhaltige feedback. ich wusste doch, kaum werd ich endlich mal etwas forscher, gehts hier endlich wieder los
@robert und jörg @umlaute: da ist offenbar in der comment-funktion ne encodierung im sack, muss ich mir heute abend mal anschaun und korrigieren. eure kommentare jag ich dann durch ne routine, die die umlaute repariert, feddich.
@fancy-URLs: die bedeutung eines permalinks für google und co steht hier außer frage – google LIEBT sowas, das setze ich als bekannt voraus. wie man aber an meinem blog sieht, verwende ich die kürzestmöglichen permalinks, die wp überhaupt unterstützt – eindeutige ID plus Titelform. da fackelt weder der indianer noch die wp-eigene rewrite-funktion lange. und nach möglichkeit sollte man auf keinen fall WP selbst den URL-rewrite übernehmen lassen, sondern zusehen, dass diese arbeit beim apache-modul bleibt, weil dieses das spielchen deutlich schneller beherrscht. optimal wäre hier seitens der entwickler ein schalter in WP2, den URL-rewrite komplett abzuschalten.
nochmal zu robert kurz: ja, AJAX im einsatz, is schließlich mein binary-blue-theme
und um kommentarspam zwar nicht zu verhindern, so doch zu erschweren, ist nach absenden eines kommentars das eingabefeld samt absenden-button gelockt. ich werd da aber noch ne option einbauen, die registrierten usern dieses manko nicht auferlegen wird 
@db-optimierung: so sehr ich die arbeit, die robert und jörg euch macht auch schätze, den meist doch eher wenig programmiertechnisch versierten nutzern von WP tipps zur optimierung zu geben; was ich da in euren blogs seit tagen im überfluss lese kann man doch, wenn ihr ehrlich zu euch selbst seid, eigentlich in einem einfachen satz zusammenfassen – bevor du ein plugin in betrieb nimmst, teste seine auswirkungen auf die serverbelastung.
eine wirkliche optimierung der queries liegt im übrigen nicht darin, hier und da ein plugin rauszuwerfen oder auf eine unterseite (am ende noch eine weitere statische seite, ohje) zu verlegen, sondern darin, im zweifelsfall nach eleganter programmierten plugins zu suchen, die die (annähernd) gleiche funktionalität bieten – oder man setzt sich halt hin und schreibt die scripte um und reicht sie ggf (sofern sie noch weiterentwickelt werden) an den “erfinder” eines plugins weiter, um zu einer allgemeinen qualitätsverbesserung des plugins beizutragen.
das wärs für den moment, bin @work und hab daher leider grad nicht so viel zeit, noch mehr zu schreiben
bin aber gespannt auf weiteres feedback 
Webmasterfind sagt:
17.01.2006 von 09:58 (UTC 0 )
Das mag schon stimmen, dass eine Optimierung an anderer Stelle wesentlich sinnvoller ist. Allerdings betreffen dies hauptsächlich Gebiete, wo der einzelne User das entsprechende Fachwissen benötigt, und das ist in den meisten Fällen nicht der Fall. Die meisten sind Blogger und keine Programmierer.
So ist es sicherlich nicht falsch, einmal mit dem unnötigen Ballast anzufangen – den Plugins. Entweder einige deakivieren oder auf eigene Seiten auslagern.
WordPress würde ich eher für Klein- und Mitteltraffic anfallende Blogs verwenden, für extrem stark besuchte Blogs wären andere Blogscripts besser geeignet.
Übrigens. Fancy URLs sind heutzutage in Hinblick der Suchmaschinen Optimierung unverzichtbar.
CountZero sagt:
17.01.2006 von 12:18 (UTC 0 )
@sven: erklecklich heißt soviel wie üppig, eine ganze menge; sorry, da hat mein altdeutsch wieder zugeschlagen
Die WP 2.0 htaccess-Datei enthielt doch nur die Abfrage, ob Ordner oder Dateien physisch auf vorhanden sind, wenn nicht sollte ALLES auf die index.php weitergeleitet werden. Ist das genauso Performancelastig, wie 30 Regeln nacheinander? Für mich kam das eh nicht in Frage, weil ich in der htaccess noch meine eigenen Regeln stehen habe.
das ist nicht nur genauso performance-lastig, sondern wahrscheinlich deutlich schlimmer, weil halt nicht schneller c++-code die regeln überprüft, sondern der PHP-interpreter, der somit prinzipbedingt langsamer ist (auch wenn damit wiederum “ordentlicher” c(++)-code ausgeführt wird). ich mag mich da etwas aus dem fenster lehnen, aber soweit ich das urlrewrite-modul des apache noch in erinnerung habe, ist das gezielt auf diesen zweck optimierter programmcode, während PHP ja eher generisch ist als interpretersprache. das führt zwangsläufig zu laufzeitunterschieden.
@webmasterfind: nein, falsch ist ein aufräumen bei den plugins sicherlich nicht, das wollte ich damit auch nie zum ausdruck bringen. es ist aber letztlich ein herumdoktorn an den symptomen, da sind wir uns sicher einig
ich würde wp jedoch für hightraffic-blogs nicht direkt ausschließen, denn mit mechanismen wie wp cache, die letztlich wohl auf vorgerenderten (also quasi-statischen) seiten basieren, scheint man die last ja problemlos in den griff bekommen zu können. als deutlich wichtiger erachte ich da, schon durch das verwendete theme auf einen schlanken und ressourcenschonenden seitenaufbau zu achten. ich werde mein binary-blue in den nächsten tagen ebenfalls gezielt daraufhin optimieren; offenbar besteht ja aktuell reger bedarf an optimierten lösungen 
@robert: ich habe in den letzten jahren die erfahrung gemacht, daß wegen des sehr einfachen einstiegs in HTML und PHP viele selbsternannte webdesigner am markt sind, die in der tat wenig kenntnisse besitzen, die über die bedienung eines WYSIWYG-editors hinausgehen. leider betrifft dies allzu oft auch entwickler von erweiterungen for die verschiedensten webbasierten anwendungen. wer sich wirklich ernsthaft mit PHP auseinandersetzt, der kommt normalerweise eigentlich nicht um eine ebenso intensive beschäftigung mit mysql herum; hier ist aber, wie du selbst ja auch schon angemerkt hast, dann leider das gefährliche halb”wissen” sehr verbreitet, mysql wäre generell nicht transaktionsfähig – weil auf den meisten hostingpaketen InnoDB schlichtweg nicht zur verfügung steht. ansonsten ist mysql nicht komplexer als jede andere relationale datenbank auch, ich würd’s verglichen mit dem oracle-dreck sogar als deutlich einfacher bezeichnen.
ich sehe ein, dass otto-normal-blogger mit über das rauswerfen von plugins hinausgehenden optimierungen überfordert ist und auch nicht den anspruch erheben sollte, sich allzu intensiv mit der materie befassen zu müssen. ich muss schließlich auch nicht wissen, wie ein motor funktioniert um auto fahren zu können (wenngleich natürlich grundwissen über den aufbau eines verbrennungsmotors nicht schadet, um etwa deutlich spritsparender fahren zu können
).
mit deiner frage nach anderen möglichkeiten als rewrite erwischst du mich definitiv auf dem falschen fuss. da ich mich lediglich mit apache 1.3.x mal intensiver auseinandergesetzt habe (statt selbst am server rumzudoktorn bevorzuge ich es, diesen job halt auch profis zu überlassen, die sich damit auskennen, und miete daher managed webspace an statt selbst nen rootserver-honeypot zu betreiben), hört meine kenntnis von alternativen lösungen bei den von dir genannten festen verdrahtungen direkt in der httpd.conf auf. für apache 2 halte ich es hingegen durchaus für möglich, dass es hier wegen der völlig anderen architektur verschiedene rewrite-module am markt mit unterschiedlichen ausrichtungen gibt. da sollte sich aber mal ein waschechter apache-admin zu melden
Jona sagt:
17.01.2006 von 15:14 (UTC 0 )
Okay, ich muss dir zustimmen. Sicher gibt es bessere Methoden, den Blog auf Vorderman zu bringen. Nur muss man davon erstmal wissen. Ich bin froh, dass ich praktisch mit der Nase drauf gestoßen worden bin, dass da irgendwas nicht so ganz optimal läuft. Und mit den Datenbankabfragen bin ich beschäftigt genug, aber immerhin bin ich da nicht ganz ahnungslos und kann zumindest versuchen, eine Verbesserung zu erreichen.
Jona sagt:
17.01.2006 von 16:16 (UTC 0 )
Nochwas: Die Permalinks. Mittlerweile könnte ich mir in den Arsch treten, weil ich anfangs die komplizierte Standardlösung /jahr/monat/tag/beitrag genommen habe. Falls du eine Lösung kennst, wie man das kürzen/generell ändern kann, ohne zB Links auf ältere Beiträge kaputt zumachen, lass es mich wissen.
CountZero sagt:
17.01.2006 von 16:29 (UTC 0 )
willkommen im Club
den fehler habe ich natürlich auch zu beginn der inbetriebnahme von wordpress schon gemacht 
diese lösung suche ich daher auch noch; ich habe einstweilen, nachdem ich von meinem provider mecker wegen der .htaccess bezogen hatte, bei mir in kauf genommen, daß aufrufe mit der alten permalinkstruktur gegen einen 404 laufen.
sobald mir jemand, der sich schon gut genug mit der wordpress-API auskennt, den trick verrät, wie ich ohne nen zusätzlichen query gegen die datenbank abzusetzen aus der alten permalink-struktur die ID des artikels ermitteln kann, würde ich das plugin “permanent redirect” so umschreiben, dass die besucher nicht nur umgeleitet werden, sondern auch die suchmaschinen wind von der neuen “anschrift” der artikel bekommen.
wenn ich rausbekomm, wie und wo in wordpress 2 die rewrite-engine sitzt, würde ich auch ein kleines plugin schreiben, womit der rewrite komplett abgeschaltet werden kann.
@robert und jörg, wegen der umlaute nochmal: ich habe nun das encoding im blog vorerst generell auf UTF-8 umgestellt (was das recent-comments-plugin übrigens gar nicht mochte), und nun sind die umlaute wieder korrekt. das germanumlauts-plugin muss noch etwas angepasst werden (neue release heute abend), dann sollte das auch eventuelle umlaute in den namen der kommentatoren sauber umsetzen.
Manu sagt:
17.01.2006 von 21:18 (UTC 0 )
Warum macht WP denn überhaupt so viele Einträge in die .htaccess? (Hatte ich glaube ich schon mal gefragt)
Ich kenne WP nicht, kein bisschen sogar. Aber ich habe selbst schon Seiten entwickelt, die nur mit “Permalinks” arbeiten.
Dort wird dann eben alles nach der URL abgefangen, nach Slashes “unterteilt” und dann an die PHP-Datei entsprechend “übergeben”. Mehr als ein paar Zeilen sind das nicht. Warum muss WP also für manche Seiten extra in die .htaccess schreiben?
Liegt es daran, dass WP den Seitenname (Beispiel “impressum”) nicht in der DB hinterlegt hat und es deswegen in die .htaccess schreiben muss?
Ich kenne WP schlichtweg zu wenig, will doch aber behaupten behaupte jedoch, dass das System doch so zu programmieren wäre, dass wenige RewriteRules ausreichen um *alles* zu erfassen.
So what?
CountZero sagt:
17.01.2006 von 22:46 (UTC 0 )
ja, mal so fürn nicht-WP-nutzer:
URL-rewrite kennste ja halt. wordpress is da erpicht, sich so flexibel wie möglich zu zeigen – neben den jahres-, monats- und tagesarchiven gibts da noch die kategorien, die tags, die direktlinks auf artikel, sowie natürlich jeweils die dazu passenden feeds – und eben die pages; das sind spezielle statische artikel. und gerade jene benötigten bis WP 1.5.2 in der htaccess eine gesonderte handhabung, weil diese pages als quasi-statische seiten aufzurufen sein sollen. also kommen in dieser “alten” htaccess für jede statische seite entsprechend einträge hinzu, die VOR allen dynamischen regeln ausgewertet werden müssen. und das ist einer der knackpunkte.
in wp2 haben die entwickler sich von diesem immer größer werdenden moloch von regelsätzen getrennt und stattdessen eine eigene rewrite-engine eingebaut, und der regelsatz in der htaccess beschränkt sich nun darauf, die existenz einer URI zu prüfen und ansonsten einfach alles an die index.html durchzureichen.
wie mir übrigens grad (schau mal auf die uhr) der support meines providers mitteilte (die haben ihrerseits nun geraume zeit die ursache für die last gesucht, die mein blog auf dem server verursacht hat), liegt da der dickste knackpunkt. denn üblicherweise gilt ne htaccess automatisch für alle unterverzeichnisse mit, und wehe du legst auf eines dieser verzeichnisse ne subdomain an. dann versucht der apache beim auswerten der regeln nämlich auch in der subdomain umzuleiten, findet da ggf. die passende datei nicht, und das ist dann sozusagen der gau für den indianer. hab ich auch wieder was zugelernt mit
erik sagt:
27.03.2006 von 23:26 (UTC 0 )
1) mal als DAU gefragt: hab ich die angedeuteten Lösungen nicht verstanden, überlesen oder gibts für WP2 keine vernünftige Abhilfe?
Also “die/netten/URLs” ohne aber die “wp-eigene” version zu verwenden? Ich bitte um DAUfreundliche Formulierungen oder Anleitungen! die wp15-htaccess verwenden?
2) schön dass es geeks gibt, die schon auf die Problematik gestossen sind. Wenn Lightpress schon WP2-tauglich wäre hätte ich kein Problem. Isses aber nicht. Ich kanns nicht umschreiben, und so schlag ich mich mit wp2 rum…
Mein Anliegen ist folgendes (wenns nicht an meinem mangelndem Programmierverständnis läge würd ich das ja gern als Bug melden, aber….)
nun gut. gibts einen weg aus “/search/suchbegriff” (mit aktiviertem nice-search plugin) oder aus “/?s=suchbegriff” (wp2-standard – selbst mit permalinks) so etwas zu machen wie “/suche/suchbegriff”? ich hab mich vergeblich an die rewrite_rules in der db, das nice-search plugin, etc. gemacht. sind permalinks aktiviert ist es ja mit der htaccess ganz aus. keine chance dort etwas an- oder vorauszufügen… In der classes.php ist ja der search_base definiert, aber umbenennen in suche bringt keinen erfolg. ich hatte das für eine kleinigkeit gehalten und möcht nur ungern vor wp2 kapitulieren… was mach ich falsch? tips?
im idealfall gäbs auch für den search-präfix ein feld in den permalinks-optionen vgl.bar mit dem category-präfix. wer kann helfen?
und ja: es ist nur ein detail… aber mich nervts langsam – und mit jedem mal wo ich in der addressleiste /search/ lese nervts mich mehr… ehrlichgesagt ist wp2 ne ganz schöne enttäuschung…
erik sagt:
14.04.2006 von 02:48 (UTC 0 )
es gibt eine schnelle lösung, die zumindest die htaccess, wie sie wp in der 1.5er verwendete wieder herstellt (bzw. für eigene rewrite-regeln nutzbar) – ich zitiere:
>> Matt Read has provided an answer to the problem! Long live Matt! Edit classes.php inside the wp-includes directory and set set var $use_verbose_rules = false; to true, and update your permalink structure. Your .htaccess file should now contain all the several lines of code originally supposed to be there. Seuche WordPress” hergefunden)