Beiträge von Putzlowitsch

Dann dürfte es sich wohl doch nicht um Trackback-Spam handeln, denn die wp-trackback.php ist da gnadenlos:

$pingstatus = $wpdb->get_var("SELECT ping_status FROM $wpdb->posts WHERE ID = $tb_id");


    if ( 'open' != $pingstatus )
        trackback_response(1, 'Sorry, trackbacks are closed for this item.');

Und weiter in der Funktion trackback_response($error ...):

if ($error) {
        echo '<?xml version="1.0" encoding="utf-8"?'.">\n";
        echo "<response>\n";
        echo "<error>1</error>\n";
        echo "<message>$error_message</message>\n";
        echo "</response>";
        die();
}

Da sollte eigentlich der Prozess definitiv beendet werden, ohne irgendwas weiter auszuführen.

Steht denn in der Datenbank tatsächlich bei allen Posts der ping_status auf nicht 'open'?

Gruß
Ingo

Zitat von Monika

...
schaltest Du autoping aus, informierst Du auch keine Newscenter von Deinen neuen Artikeln
...

Das kann man so nicht sagen
Wenn mit Newscentern die "Update Services" gemeint sind, die werden unabhängig von der oben genannten Option "Versuch jedes verlinkte Weblog vom Beitrag zu benachrichtigen" genau so, wie sie in der Liste bei "Einstellungen->Schreiben" aufgelistet sind, angepingt.
Funktioniert bei mir in der Praxis auch seit Monaten, ich werde bei neuen Artikeln oder Änderungen bei "frisch gebloggt" ganz normal angezeigt.

Gruß
Ingo

123 Multihost Version 0.15

Auf Grund eines mir erst jetzt aufgefallenen internen Fehlers (weiteres dazu hier) gibt es eine neu Version 0.15.

Zusätzlich kann über die neue Option “Hostname ermitteln” die “Strategie” zur Bestimmung des zu verwendenden Hostnamen festgelegt werden. Dies kann je nach Serverkonfiguration notwendig sein.

Nachtrag:
Die neue Version hatte ich gestern Abend leider falsch verlinkt. Jetzt stimmt es aber:
Putzlowitscher Zeitung » 123 Multihost

Gruß
Ingo

Och nee, da hab ich ja noch einen richtig dicken Klops in meinem Plugin, wie ich grad sehe. Deshalb wird es bei moneymakesmurder vermutlich auch nicht funktionieren.

Da schreibe ich noch so schön von 'HTTP_HOST' und verwende im Quelltext die überhaupt nicht existierende Variable 'HOST_NAME'.
Naja, Version 0.15 ist in Arbeit. Werde da gleich noch die Option reinnehmen, das der Nutzer bestimmen kann, was genommen wird.

Gruß
Ingo

Aha, na das mit dem HTTP_HOST stimmt so absolut, wie ich es dort geschrieben habe, nun auch wieder nicht.
Nach einigem hin und her im Ursprungsthread mit nepf, weil es dort nicht funktionierte, ist im Moment folgende Variante implementiert:

// Hostname,  der verwendet wird
// falls 'HOST_NAME' gesetzt ist, diesen nehmen, sonst 'SERVER_NAME'
if( $_SERVER['HOST_NAME'] != "" )
    $plw123mh_hostname = $_SERVER['HOST_NAME']; 
else
    $plw123mh_hostname = $_SERVER['SERVER_NAME'];

Man könnte das natürlich auch den User entscheiden lassen, was da genommen werden soll. Oder alternativ irgend was ganz anderes, was z.B. über ein Textfeld vorgegegeben wird. Kann ich ja mal noch einbauen.

Gruß
Ingo

moneymakesmurder
Freut mich natürlich, das Du das mir Arnos Hack hinbekommen hast. Andererseits würde mich schon interessieren, warum es mit dem 123-Multihost-Plugin nicht funktioniert hat. Schließlich will ich das ja auch weiter verbesserm und gegebenfalls den Wünschen der Nutzer anpassen.

arno
Apropos Userwünsche :-), wie meinst Du das mit den variablen Servervariablen? Hab ich nicht ganz verstanden.

Gruß
Ingo

Oh oh, ist mir das peinlich :oops:.

Da hatte ich mich doch im Übereifer beim Kampf gegen Spam und Bots selber, bzw. den armen, unschuldigen wp-cron ausgesperrt. Er wollte ja brav seinen Dienst verrichten, wurde aber von meiner .htaccess, respektive also von mir, mit einem 403er abgestraft.

Im Detail: Ich hatte vor ein paar Tagen in meiner .htaccess eine Regel eingefügt, die Zugriffe mit leerem [SIZE=-1]HTTP_USER_AGENT gnadenlos aussperrt, weil es mich genervt hatte, daß irgendwelche namenlosen Bots ständig alle Seiten durchklappern.
Der WP-Cron wird aber auch über einen normalen HTTP-Request aufgerufen und verzichtet sinnvollerweise auf jeglichen Schnickschnack wie Referer oder Useragent. Und schon wars passiert.

Kurz und gut, seitdem ich die lokale Zugriffe von meinem Filter ausnehme, ist wieder alles bestens.

Ungeachtet dessen funktioniert mein weiter oben beschriebener Hack ganz ordentlich und setzt den WP-Cron außer Gefecht. Allerdings auch mit den beschriebenen Nebenwirkungen.

Gruß
Ingo

[/SIZE]

Na dann, gute Besserung!

Gruß
Ingo

Ja, hab ich so gemacht, aber auch erst vorhin. Zunächst war mir vor ein paar Tagen nur aufgefallen, das die Trackbacks nicht mehr versandt wurden. Dann bin ich dem Weg der Trackbacks im Programm nachgegangen und auf diese Pseudo-Cron-Geschichte gestoßen.
Das ich dann gestern auch über 600 Aufrufe der wp-cron.php hatte, habe ich erst heute beim Blick in das Server-Logfile gesehen. Leider hab ich da erst mir einem Tag verzögerung Zugriff.

Im übrigen kann man sehen, was alles zum "Cronen" ansteht, wenn man sich in der Tabelle wp-options den Inhalt der Option 'cron' ansieht. Sollte man eventuell auch einfach mal löschen, ich habe das zumidnest gemacht. Es hat je eh nicht funktioniert.

Allerdings wird mit meinem hack, so er denn funktioniert, die gesamte Cron-Funktionalität außer Kraft gesetzt. Ich weiß nicht, was außer Ping und Trackback sonst noch eventuell darüber abgewickelt wird.
Wie immer also alles auf eigene Gefahr und ohne Gew(ä|e)hr

Gruß
Ingo

Es mach schon was aus, wenn die wp-cron.php nicht vorhanden ist. Zum Beispiel werden keine Pings und Trackbacks mehr versandt. Das eigentliche Problem dürfte aber darin liegen, daß dieses auch schon mit der wp-cron.php nicht richtig funktioniert hat. Denn so wird bei jedem Seitanaufruf versucht, die anstehenden "Cronjobs" auszuführen. Wenn das klappt, ist alles gut und die wp-cron.php wird bis zum nächsten neuenArtikel oder einer Änderung nicht mehr aufgerufen. Schlägt das Ausführen aber fehl, wird es immer und immer wieder versucht, was dann zu den unzähligen wp-cron-Aufrufen führt.

Ich habe das auch seit etwa zwei, drei Tagen.
Besser als das Umbennen wäre ein deaktivieren der Cron-Funktion. Könnte z.B. in der 'my-hacks.php' gemacht werden:

<?php
  remove_action( 'init', 'wp_cron' );
?>

Bei den Einstellungen muß unter Verschiedenes noch
[x] Die veraltete my-hacks.php-Datei unterstützen.
aktiviert werden.

Gruß
Ingo

Ja genau, Auto-Ping ausschalten.
Wie gesagt, beim Ping wird der Inhalt aus der Umgebung des eigentlichen Links genommen, im Falle einer Linkliste am Ende eines Artikels halt nicht besonders sinnvoll.
Beim Trackback hingegegn werden die ersten 250 Zeichen vom Artikelanfang, oder so vorhanden, die Kurzfassung verwendet. Da sollt dann hoffentlich brauchbarer Text stehen

Gruß
Ingo

Deshalb habe ich auch schon seit längerem die automatischen Pings für Artikel abgeschaltet, und nutze nur noch das Trackback-Feld bei Posten. Da muß man dann zwar die Trackbackadressen explizit eintragen, das Ergebnis ist aber einfach besser.
Beim Ping wird der Text 100 Zeichen vor und nach dem Link verwendet, beim Trackback hingegegn die ersten 250 Zeichen vom Artikelanfang, oder so vorhanden, die Kurzfassung.

Die Trackbackdaten (z.B. Titel) werden außerdem direkt aus der Datenbank erstellt, beim Ping hingegen wird die Artikelseite, also das was nachher auch der Betrachter sieht, geparst.

Gruß
Ingo

Ja, um diese Anpassungen in der Datenbank wird man wohl nicht drunrum kommen. Aber das ist mit ein paar SQL-Zeilen erledigt:

--
-- hostname in den Posts anpassen
--
UPDATE `wp_posts`
SET `post_content`=REPLACE(`post_content`,'http://alteurl.de','http://neueeurl.de')
WHERE `post_content` LIKE '%http://alteurl.de%';


--
-- hostname in GUID anpassen
--
UPDATE `wp_posts`
SET `guid`=REPLACE(`guid`,'http://alteurl.de','http://neueeurl.de')
WHERE `guid` LIKE '%http://alteurl.de%';

Etwas komplizierter ist es da schon, die Metadaten der Uploads zu ändern. Hier ist jeweils der absolute Pfad der Datei auf dem Server hinterlegt. Falls dieser nicht stimmt, werden die Thumbnails für Bilder von der Uploadverwaltung nicht gefunden.
Das ist aber leider nicht so einfach mit einem SQL-Befehl zu erschlagen.
Hier die Erklärung, warum das so ist:
http://forum.wordpress-deutschland.org/82856-post10.html

Gruß
Ingo

Da bin ich jetzt ehrlich gesagt etwas ratlos. Der workaround hat bei mir so wie beschrieben funktioniert.
Und zur eigentlichen Fehlerbehebung muß wohl jemand von WP was sagen, da hab ich erstmal auch keine Idee.

Gruß
Ingo

Ja, allerdings ist das nur ein workaround, das eigentliche Problem behebt es nicht. Achtung, die Funktion kommt nicht in die functions.php im wp-include Verzeichnis, sondern in die im aktuellen Theme-Ordner!
Falls noch keine solche existiert, eine neue functions.php anlegen und folgendes hineinschreiben:

<?php
  do_all_pings();
?>

Falls schon eine existiert, einfach die Zeile do_all_pings(); direkt am Anfang unter dem öffnenden <?php einfügen.
Wenn man nun einmal die Blog-Seite aufruft, werden alle noch austehenden Pings und Trackbacks abgearbeitet. Man kann die Funktion anschließend wieder auskommentieren. Sie wird sonst bei jedem Seitenaufruf ausgeführt.

Was die eigentliche Ursache ist, weiß ich nicht. Es hängt zumindest mit der seit 2.1.x eingeführten Cron-Geschichte zusammen. Wenn man in der wp-options-Tabelle bei der Option 'cron' nachsieht, stehen die Pings zwar drin, werde aber, warum auch immer, nicht ausgeführt.
Es könnte was mit der Sommerzeit zu tun haben, denn seit der Zeitumstellung trat das Problem bei mir erstmalig auf, und besteht auch weiterhin.

Gruß
Ingo

Hatte ich kürzlich auch. Das liegt daran, das da irgendwas mit den Cron-Funktionen nicht hinhaut.
Man kann das Versenden der Trackbacks aber auch mit der Funktion do_all_pings() auslösen.
Ich hatte mir dann so beholfen, das ich diese Funktion in meinem aktuellen Theme in die functions.php eingetragen hatte. Dann wird beim nächsten Aufruf der Seit der Trackback-Versand ausgeführt. Anschließen habe ich es aber wieder rausgenommen.

Gruß
Ingo

Dann wäre vielleicht das hier ein Ansatz:
http://forum.wordpress-deutschland.org/design/18513-s…ress-holen.html

Gruß

Ingo

Ich z.B. habe immer noch nicht verstanden, worum es geht.

Dein WP liegt also z.B. auf 'unausprechlichername.de'. Wo kommt jetzt hier eine Subdomain ins Spiel? Etwa als 'wp.unausprechlichername.de'? Nur was bringt das?

Völlig unklar sind mir im Zusammenhang mit WP auch die Begriffe Mainframe und Content. Bei WP gibt es keine Frames, die anzuzeigende Seit wird immer komplett geladen.

Am besten wäre es, das ganze deinerseits am lebenden Beispiel zu illustrieren, sonst ist das Ganze nur ein Stochern im Nebel.

Ich vermute mal, daß es den anderen ähnlich geht, deswegen gab es auch bisher noch keine Antworten.

Gruß
Ingo

Zitat von Putzlowitsch

Naja, meine halböffentlichen Testblogs hat es noch nicht erwischt. Könnte aber an der Karenzzeit von etwa 3 Monaten liegen, so lange sind die noch nicht am Start. Beim ersten wäre das Mitte März der Fall, mal sehen...

Ist schon erstaunlich, meine Prognose wurde doch tatsächlich voll bestätigt. Am 12. März sind bei oben erwähntem Testblog die ersten Spamversuche eingegangen. Gleich zweimal kurz hintereinander, wahrscheinlich nur zum Testen mit unverfänglichem Inhalt:

Zitat

Google is the best search engine…

Und entsprechendem Link auf google.com.

Hab ich aber erst heute bemerkt, weil ich da nicht so oft reinschaue. Hmmmm, aber wieso habe ich keine Moderations-E-Mails bekommen, obwohl das in den Einstellungen angehakt ist.

Gruß
Ingo

Das mit den Uploads ist ein anderes Problem. Die werden im Dateisystem des Servers abgelegt. Da müssen noch Schreibrechte auf das Verzeichnis '/wp-content/uploads/' gesetzt werden. Dazu steht z.B. hier etwas:
http://forum.wordpress-deutschland.org/konfiguration/…erzeichnis.html

Das mit den eigentlichen Beiträgen ist aber ein anderes Problem. Die werden ja in der Datenbank gespeichert. Ist allerding schwierig, das jetzt näher einzukreisen. Leider hat sich auch Chet nicht wieder gemeldet. Das kann heißen, er hat das Problem bisher nicht gelöst oder er hat uns hier einfach vergessen :-|

Gibt es denn eine Fehlermeldung bei den Beiträgen die zu groß sind? Stehen die denn in der Datenbank?

Gruß
Ingo