Beiträge von Webrocker

    Hallo,

    seit dem Update auf 2.0.7 aktualisiert sich mein Cache nicht mehr, wenn ein neuer Kommentar geschrieben wird - hat das jemand auch schon in seinem Blog beobachtet?
    Ich bin mir nicht sicher, ob es auch bei 2.0.6 nicht ging, bei 2.0.5 wurde aber definitiv die Seite neu gecachet nach einem neuen Kommentar.

    gruss + dank
    Tom

    Hallo Koto,

    die Permalinks funktionieren auch bei Strato, allerdings mit einer Einschränkung: Da bei Strato kein mod_rewrite benutzt werden kann, muss in den WP-Optionen die Permalinkstruktur so eingetragen werden, dass sie mit index.php beginnt. Dann ist hierfür kein mod_rewrite und auch keine weitere Änderung in der .htaccess notwendig.

    Ja. Aber Achtung, in der momentan aktuellen Wordpress-Version und den Vorgängern ist ein Bug, der Pingbacks nicht richtig bei den Beiträgen ankommen lässt, sich aber einfach beheben lässt. Siehe:

    http://forum.wordpress-deutschland.org/showthread.php?t=9089
    http://forum.wordpress-deutschland.org/showthread.php?t=12007

    gruss
    Tom

    hi,

    ich hatte mein blog bislang bei strato und musste wegen des fehlenden mod_rewrites auf die sog. "pathinfo" permalinks zurückgreifen:

    Code
    /index.php/%year%/%monthnum%/%day%/%postname%/

    jetzt bin ich bei einem anderen provider, und habe meine permalinks auf

    Code
    /%year%/%monthnum%/%day%/%postname%/

    umgestellt.
    Da mein Blog aber ziemlich gut bei google und so erfasst ist, möchte ich die "alten" Links trotzdem funktional haben.

    ich denke, das kann ich in der .htaccess machen, allein, ich bin zu doof dafür... die "wordpress" .htaccess sieht jetzt so aus:

    Apache Configuration
    RewriteEngine On
    RewriteBase /blog/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /blog/index.php [L]

    ich dachte, wenn ich den Request daruf überprüfe, ob er "/blog/index.php/.../" enthält, und ihn dann einfach als "/blog/.../" rewrite, müsste es gehen. Aber ich bekomme anscheinend die richtige Syntax dafür nicht hin.

    Apache Configuration
    RewriteEngine On
    RewriteBase /blog/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /blog/index.php [L]
    
    
    RewriteCond %{REQUEST_URI} ^/blog/index.php/(.*)?$
    RewriteRule ^blog/index.php/(.*)?$ /blog/$1 [L]

    funktioniert leider nicht.

    Hat jemand eine Idee?

    Vielen Dank + Gruss
    Tom

    http://asymptomatic.net/2006/02/09/225…of-destruction/

    Zitat

    In the current version of WordPress, the main post query uses a date in the WHERE clause to limit the posts it will return to only those posts that were published prior to the current time. That sounds fine, but it doesn’t allow caching tools for MySQL to do their jobs, since the query changes every time the time changes. If we knew in advance to eliminate an entire “type” of post from that query, the query would speed up significantly, potentially due to two things: Using a query cache would be more possible, and there would be no relative compare against a date, but a direct compare against a preset value.


    wenn ich das da richtig verstehe, dann ist Wordpress derzeit nicht in der Lage, Post mit Datum größer als dem aktuellen Datum zum Zeitpunkt der Query anzuzeigen.

    gruss
    Tom

    Edit:
    Habe gerade gesehen, dass Du schon in der entsprechenden where-clause rumgebastelt hast. evtl wird die anzeige des artikels nochmal woanders als in der classes.php gesteuert?

    ich hatte das problem auch schon einmal unter wp 2.0.3.
    da war die "schuld" die grösse der DB, die durch die logs-tabellen von bad-behaviour und vor allem wp-short-stats ziemlich aufgeblasen wurde.
    nach dem leeren der entsprechenden tabellen ging auch das cron-mail-versenden wieder.
    nach dem oben erwähnten update unter wp 2.0.4 von bad-behaviour ging das cron-gemaile exakt ein mal - seither ist wieder schluss mit backup.
    im backend zeigt er die cronjobs als ausgeführt, brav jede nacht, allerdings kommen keine mails. die db ist ziemlich schlank, da ich wp-short-stats nicht mehr einsetze und das logging von bad-behaviour nur noch die "denied" dinger logt, nicht mehr alle zugriffe.
    :???:
    Vielleicht liegt es garnicht am plugin, sondern an der umgebung?
    - mailfunktion, grösse der zu mailenden backup-datei, cronjobrechte auf dem server?
    meine wp installation läuft auf einem *räusper Strato Premium S Paket. php5, mysql 4.0.24. die gesamte db ist 1.6mb gross, dabei sind aber auch ein paar grössere tabellen, die nicht im backup gesichert werden sollen.

    Hallo,

    wenn Eure Pingbacks in anderen Blogs komisch angezeigt werden - also statt eines Auszugs des Textes Eures Beitrag irgendwelches anderen Inhalte Eurer Seite, meistens etwas aus dem Meta-Bereich des Beitrags oder aus der Beitrags-Navigation, dann schaut Euch mal Euer Beitrags-Template an.
    Wenn der Meta-Abschnitt (also das mit Kategorien des Beitrags und dem RSS Link und so) nicht in einem "P" Tag steht, sondern in einem "DIV" Tag, dann spinnen die Pingbacks.
    Ich hatte das vor ein paar Wochen in meinem Blog gefixt und es funktionierte bis heute. Gestern hatte ich die Ultimate-Tag-Warrior Funktion aktiviert, die verwandte Beiträge zum aktuellen Beitrag anzeigt - und aufeinmal war diese Auflistung in den Pingbacks zu sehen.
    Ich bin der Sache auf den Grund gegangen und habe, glaube ich, einen Fehler in der xmlrpc.php gefunden (das ist die Datei, die unter anderem für die Pingbacks sorgt). Ich will jetzt nicht in die Tiefe gehen, was da passiert, aber wenn man in Zeile 1192 eine kleine Änderung macht, funktioniert die Darstellung der Pingbacks in beiden Fällen:
    Statt

    PHP
    $linea = preg_replace( "/ <(h1|h2|h3|h4|h5|h6|p|th|td|li|dt|dd|pre|caption|input|textarea|button|body)[^>]*>/", "\n\n", $linea );

    muss

    PHP
    $linea = preg_replace( "/ <(h1|h2|h3|h4|h5|h6|p|th|td|li|dt|dd|pre|caption|input|textarea|button|body|div)[^>]*>/", "\n\n", $linea );

    stehen, dann klappt's. Dann gehen auch die Pingbacks mit Templates, die ein "DIV" im Meta-Bereich verwenden, und auch die verwandten Beiträge-Links stören nicht mehr.

    gruss
    Tom

    Nachtrag: Die xmlrpc.php steht direkt im wordpress-Verzeichnis, nicht in wp-includes oder so.

    hallo,
    seit dem update auf wp 2.0.4 funktioniert das cron-gesteuerte backup der database nicht mehr. manuell angestossen, geht das backup und der mail-versand, nicht aber zeitgesteuert. plugins deaktiviert, datenbank aufgeräumt, alles schon ausprobiert, geht immer noch nicht.
    hat jemand das gleiche problem?
    gruss
    Tom

    Hier mal die gesamte index.php, als Anregung:


    gruss
    Tom

    Hallo,
    es ist machbar, aber nicht unbedingt flexibel. Du musst dazu die eigentliche plugin-Datei im Code verändern, dh beim nächsten Update kannst Du die Arbeit nochmal machen.
    Damit sich das Ding in mein Design einfügt, habe ich in der Datei ../maillist/index.php diese Änderungen gemacht:

    Der Code für HtmlContentStart und HtmlContentEnd entspricht dem (html)Code in meiner single.php des Themes, halt nur aufgeteilt in "vor dem eigentlichen Content" (den ja das plugin liefert) und "nach dem eigentlichen Content". Die ganzen Wordpress template Tags und Loops sind rausgenommen.

    gruss
    Tom

    Hallo,

    ich habe ein komisches Problem mit der Darstellung meiner Pingbacks. Wenn ich einen anderen Blogeintrag pinge, dann erscheint dort nicht

    [...] Sinnvoller Auszug aus meinem Originalbeitrag [...]

    wie bei anderen Pingbacks von anderen Blogs, sondern

    [...] Text der in meinem Template bei den Metainfos steht (pages bzw rss und trackbacklinks [...]
    :shock:

    Woran könnte das liegen? Es hat irgendwas mit dem Theme bzw Template zu tun... Ich nutze wp 2.0.3 mit einem eigenen Theme. Wenn ich eines der Standardthemes benutze, dann einen Ping auslöse, dann werden die Zusammenfassungen richtig angezeigt.
    *help*

    gruss + danke
    Tom

    Zitat von Chris_

    Btw, wer auch immer den Bug gemeldet hat. Hast Du eine wp-includes/rewrite.php?
    Ich nicht, bei mir versteckt sich das ganze in wp-includes/functions.php in Zeile 217 - ich denke, bei Dir auch. ;-)
    Chris

    Ich habe die Beschreibung des Bugs mal erweitert und die ...key($rewrite)... Lösung vorgeschlagen. Mal schauen, was passiert. Dieser Bug ist momentan nicht auf der Liste für WP 2.0.4 oder 2.1.