Beiträge von Putzlowitsch

    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:

    PHP
    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:
    Code
    # 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

    Eine Möglichkeit wäre noch, das WP-Anmelde-Cookie abzufragen:

    Apache Configuration
    # Bilder nur für angemeldete Benutzer
    RewriteCond    %{HTTP_COOKIE}    !wordpress_49745e19158d762ac2bed4e6c80d45d0
    RewriteRule ^wp-content/uploads/    -    [F,L]

    Zumindest hätten dann nur Nutzer Zugriff, bei denen das Cookie existiert, die also schon mal angemeldet waren oder noch sind.
    Oder jemand rekonstruiert den Namen und setzt sich so ein Dummy-Cookie, was natürlich möglich ist. Als Gegenmaßnahme könnte man aber einen eigenen Cookie-Namen in der wp-config.php definieren.

    Im Großen und Ganzen sollte es aber den normalen Nutzer fernhalten.

    Das da oben ist nur ein Beispiel, den Cookienamen und das zu schützende Verzeichnis muß man natürlich noch entsprechend anpassen :)

    Gruß
    Ingo

    Das Strato-Weblog-Basic ist eine von Strato modifizierte Wordpressversion, die nicht mit MySQL sondern mit SQLite funktioniert. Da wird Dir der Strato weiterhelfen müssen.

    Nachtrag: Wichtig ist, daß die Domain, für die das Weblog-Basic konfiguriert wurde, auch tatsächlich auf das Wurzelverzeichnis Deines Webspaces bei Strato zeigt, denn dort liegt das Verzeichnis '/cgi-data/weblog_basic/', in dem auch das Upload-Verzeichnis angelegt wird. Eventuell könnte man etwas Abweichendes in den WP-Einstellungen für das Uploadverzeichnis konfigurieren.

    Gruß
    Ingo

    Hilfreich ist es auch, den Bildern einen ordentlichen Titel zu geben (bei der WP-Medienverwaltung das Feld "Titel"), der dann im img-Tag als title-Attribut verwendet wird (<img src="..." title="...">). Der Dateiname selbst ist nicht ganz so wichtig. Wichtig ist aber der Text in der Umgebung des Bildes, da Google den Inhalt der Bilder nicht "sehen" kann, muß es den umgebenden Text (und den Titel) für die Suche verwenden.

    Gruß
    Ingo

    ...Bevor ich Seo benutzt habe hat Google wenigstens 2 Bilder aus dem Wordpress Uploadverzeichniss gelistet...


    Ich sag ja immer, SEO ist eher kontraproduktiv :)

    Wenn SafeSearch ausgeschaltet ist, werden immerhin 6 Bilder angezeigt:
    site:animesubs.kilu.de - Google Bilder

    Warum aber nur so wenige, weiß ich auch nicht. Allerdings muß man auch beachten, das Bilder deutlich länger als Texte brauchen, ehe sie in den Suchergebnissen erscheinen.

    Gruß
    Ingo

    Wie sieht denn Deine eingestellte Permalink-Struktur für Artikel aus, vielleicht ist das ja wichtig?
    Ich habe den Klassiker eingestellt, also

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

    Könnte sein, daß die Seiten in den Rewriterules landen, wenn man nur %postname% nimmt, oder so. Sonst können möglicherweise Artikel von Seiten nicht unterschieden werden.

    Nachtrag: Ich hab mal etwas mit der Permalink-Struktur rumgespielt, es liegt tatsächlich auch daran. Sobald man am Anfang irgendwas numerisches verwendet (Datum, Post-ID) werden die Seiten-Regeln nicht geschrieben. Hat man aber %postname%, %category% oder %author% ganz vorn, dann werden die vielen Regeln für die Seiten eingetragen.

    Gruß
    Ingo

    Qickedit und Quickpress bitte nicht verwechseln. Das eine ist die Möglichkeit, die Eigenschaften von Artikeln direkt in der Artikelübersicht zu bearbeiten, das andere dient zum schnellen Erstellen von Artikeln auf der Übersichtsseite. Letzteres (also Quick-Press) kann man mit den "Optionen einblenden" und "In der Übersicht anzeigen" ein- oder ausschalten.

    Eine Möglichkeit, das Quickedit in der der Artikelliste zu deaktivieren, suche ich auch noch.

    Gruß
    Ingo

    Genau, "Äpfel mit Birnen vergleichen", da liegt das Problem :)
    Es ist vielleicht falsch rübergekommen, meine Aussage mit den 3,5 Sekunden bezieht sich speziell auf Wordpress. Ich denke mal, daß Du bei Deiner normalen Homepage weder PHP noch eine Datenbank einsetzt. Und selbst wenn doch, es liegt zum großen Teil an dem "Codemonster" Wordpress, kleinere PHP-Sachen mit Datenbank sind auch bei Strato nicht ganz so langsam, wie WP.

    Ich bastle nun mittlerweile seit mehr als anderthalb Jahren mit Wordpress bei Strato rum, einzig was gebracht haben bisher Cache-Plugins, die quasi nur noch die "fertig gerenderte" HTML-Seite ausliefern und Wordpress selbst praktisch gar nicht mehr laden.

    Gruß
    Ingo