Beiträge von Putzlowitsch

Hier kommt z.B. mal wieder die my-hacks.php ins Spiel :-)

//--- BEGIN Template-Pfad verbiegen
function plw123_get_theme_root( $path ) {
    $path = WP_CONTENT_DIR;
    $path .= "/styles";
    return $path;
}
add_filter( 'theme_root', 'plw123_get_theme_root' );


function plw123_get_theme_root_uri( $path ) {
    $path = WP_CONTENT_URL;
    $path .= "/styles";
    return $path;
}
add_filter( 'theme_root_uri', 'plw123_get_theme_root_uri' );
//--- END Template-Pfad verbiegen

Gruß
Ingo

Bei der usermeta hängt die Anzahl davon ab, wieviele Nutzer es gibt.
Aber es ist schon richtig, daß da option_name und meta_key geändert werden müssen.

Gruß
Ingo

Ja eben, diese Keys sind halt neu dazugekommen oder ersetzen bereits vorhandene. Du solltest sie also in Deine wp-config.php einfügen.

Gruß
Ingo

Neee, das hatten wir schon:
http://forum.wordpress-deutschland.org/allgemeines/47…html#post230673
leider ohne Erfolg.

Gruß
Ingo

Wenn es mit Google geht, sollten die "Pings" zumindest prinzipiell funktionieren. Das Problem hängt dann dann mit den Diensten zusammen, wo die Warnung auftritt.
Denkbar wäre auch noch, das diese ihrerseits aus irgendeinem Grund den Zugriff sperren, weil das Sitemap-Ping zu oft aufgerufen wird, oder was weiß ich.

Mit Sitemaps an sich kenne ich mich gar nicht aus.

Gruß
Ingo

Nee, da kann man nichts machen.

Mal eine andere Frage, funktioniert denn die Benachrichtigung mit Google? Wenn ja, liegt es ja nicht an der Funktion fsockopen, sondern tatsächlich irgendwie an den Zielservern. Oder der Hoster hat den Remote-Zugriff auf bestimmte Seiten gesperrt.

Gruß
Ingo

Normal ist es sicher nicht. Die Funktionialität wird insofern eingeschränkt, daß die Dienste dann nicht über die Aktualisierung der Sitemap informiert werden. Eingelesen werden sollte sie dann aber beim nächsten, regulären Botlauf aber trotzdem.

Gruß
Ingo

Das hat aber weniger was mit der class-snoopy.php zu tun, als vielmehr damit, daß die Zielserver (submissions.ask.com und webmaster.live.com) den Zugriff verweigert haben.

Gruß
Ingo

Standardmäßig werden die Suchbegriffe bei Wordpess UND-verknüpft. Event 1985 findet also nur Artikel, die Event UND 1985 enthalten, aber eben nicht nur im Titel eines Beitrages, sondern auch im Inhalt. Also werden auch Artikel angezeigt, die z.B. Event im Titel und 1985 im Text enthalten. So ist es zumindest bei mir und ich habe keine Suchplugins installiert.

Gruß
Ingo

Das "normale" 123 No Rewrite Permalink" geht nicht, es gibt aber vom selben Entwickler auch eine spezielle Version für dem IIS:
Putzlowitscher Zeitung 123 IIS Permalink

Gruß
Ingo

Nein, es war nicht wirklich hilfreich. Der TE hat nur ein WebPack M, da geht mod_rewrite eben nicht. Mit mod_rewrite ab WebPack L ist natürlich alles keine Problem, das ist richtig.

Gruß
Ingo

Zitat von Riva

Das ist die Lösung für mein Problem. Ich hab' jetzt alle Methoden deaktiviert und der Blog läuft Wieselflink.

Wie oben schon angedeutet, könnte es auch reichen, alle Methoden außer 'fsockopen' zu deaktivieren. Dann bleibt die Funktionalität ohne Einschränkungen erhalten, WP 2.7.x verhält sich denn Remote-Connect-Technisch gesehen genau (zumindest fast) wie WP 2.6.x.

Gruß
Ingo

Das ist aber irgendwie unlogisch. Auch bei WP 2.6.x werden Remote-Connections verwendet, sei es zum Überprüfen der WP-Version, Plugin-Updates und natürlich für Pings und Trackbacks. Der Unterschied zu 2.7.x ist nur die Einführung einer neuen Klasse wp-http, welche nun die Remote-Connections über unterschiedliche Methoden ausführt.
Wenn mit 2.6.x alles funktioniert sollte es reichen, mit dem Plugin alle Methoden außer 'fsockopen' auszuschalten. Vor Version 2.7.x wurden alle Remote-Connections per fsockopen abgewickelt. Es liegt alse vermutlich daran, das bestimmte Methoden vom Hoster nicht unterstützt werden.

Gruß
Ingo

Vielleicht ist ja mod_speling schuld. Das versucht vermeintlich falsch eingegeben URLs zu verbessern.
Ausschalten kann man das in der .htaccess mit:
CheckSpelling off

Gruß
Ingo

Vielleicht bringt ja das Plugin etwas:
Schnurpsel 123 HTTP Transport
Einfach alle Methoden deaktivieren.

Zwingend notwendig sind Remote-Connections meiner Meinung nach nicht, wenn man auf die ganzen automatischen Updates sowie Pings und Trackbacks verzichten kann.
Probleme könnte dann aber auch der WP-Pseudo-Cron machen, der z.B. für die zu einem späteren Zeitpunkt veröffentlichten Artikel zuständig ist.

Gruß
Ingo

Auch das "123 No Rewrite Permalink"-Plugin benötigt die .htaccess, um eine benutzerdefinierte Fehlerseite zu konfigurieren. Was halt nicht benötigt wird, ist mod_rewrite.

Gruß
Ingo

Naja, also direkt per SQL würde ich das nicht machen, da ja seit WP 2.3 die Kategorien in den Taxonomies aufgegangen sind. Man mußt da immer zwei oder drei Tabellen aktualisieren, slug bestimmen usw.

Ich würde das schon Wordpress selbst überlassen. In wp-admin/includes gibt es die taxonomy.php. Diese enthält eine Funktion wp_create_categories die als Parameter einfach ein Array mit den Namen der neu anzulegenden Kategorien erwartet. Denn Rest erledigt dann WP.

Gruß
Ingo

Du mußt dann für die internen Links auch die Artikel-/Seiten-ID verwenden. Das ist ja eigentlich auch der große Vorteil des Plugins, denn egal was Du bei den Permalinks einstellst oder wenn Du sie später mal änderst, die internen Links passen sich automatisch an und stimmen immer. Die ID des Artikels ändert sich ja nicht.

Gruß
Ingo

WP fragt die E-Mail gar nicht ab, wenn Du das nicht veranlaßt. Guck mal hier, da ist alles wichtige zum Bloggen per E-Mail geschrieben:
Schnurpsel Mit Wordpress per E-Mail bloggen

Gruß
Ingo

Zitat von AngiWaters

...
Ich bin dabei eine Seite mit WP zu erstellen, die nur registrierten Usern zugänglich ist...

Ich verweise mal auf das Ausgangsproblem.

Also muß sich der Benutzer sowieso vorher registrieren und anmelden. Wenn er das getan hat, wird ja der Cookie gesetzt. Nicht angemeldete Benutzer sollen eh weder Artikel noch Bilder sehen können.

Was heißt, der Cookie muß personalisiert sein? Der Cookie hat immer bei allen Nutzern den gleichen Namen, der Inhalt interessiert gar nicht. Genau die Existenz des Authentication-Cookies wird in meinem Beispiel geprüft, mehr nicht. Das funktioniert übrigens ganz wunderbar, ich habe es bei mir natürlich getestet, bevor ich das hier reingeschrieben habe :-)

Gruß
Ingo