Beiträge von Putzlowitsch

Ja genau, falls Links verwendet wurden und ein Update installiert wurde, bleiben diese erhalten und können weiterhin genutzt werden. Bei Neuinstallationen gibt es die Link hingegen nicht mehr.

Gruß
Ingo

Zitat von Putzlowitsch

... Die "Freischaltung" der geschützten Artikel wird in einem Cookie vermerkt, welches nur für die originale Wordpress-Domain gültig ist. ...

Hab ich doch gleich in der ersten Antwort geschrieben, wie das mit den geschützten Artikeln bei Wordpress funktioniert. Aber wenn es sowieso keiner liest, kann ich mir die technischen Erklärungen demnächst auch sparen. :-)

Gruß
Ingo

Hab ich doch oben geschrieben.

Da Wordpress für Domain A installiert ist, setzt Wordpress nur Cookies für Domain A (die Cookiedomain). Wenn Du über die Domain B zugreifst und das Passwort eingibst, setzt Wordpress auch ein Cookie für Domain A. Der Browser liefert das aber beim Aufruf über Domain B nicht mit aus, so daß es so aussieht, als sei kein Cookie gesetzt worden und WP will wieder das Passwort haben.

Eine einfache Lösung gibt es dafür nicht. Mir fällt dazu nur ein, die Cookie-Domain in der wp-config.php dynamisch zu setzen:
http://codex.wordpress.org/Editing_wp-con…t_Cookie_Domain

Also etwa so:

define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

Habe ich aber nicht geteste und ich kann nicht sagen, ob es da unerwünschte Nebenwirkungen gibt.

Gruß
Ingo

Was genau meinst Du mit "umgeleiteter URL"?

Falls es sich um eine andere Domain handelt, kann es Probleme wegen der Cookies geben. Die "Freischaltung" der geschützten Artikel wird in einem Cookie vermerkt, welches nur für die originale Wordpress-Domain gültig ist.

Gruß
Ingo

So mach ich das für Bilder:

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www.)?schnurpsel.de/.*$ [NC]
RewriteRule \.(gif|jpe?g|png)$ - [F,L]

Wo stehen den die Regeln in der .htaccess und wie testest Du, ob es funktioniert?

Wenn es um Bots geht, wird das aber auch nichts nützen, denn die senden in der Regel keinen Referrer mit. Da Du Zugriffe mit leeren Referrer erlaubst, bringt das also nichts.

Gruß
Ingo

Zitat von Melewo

...Wenn Dein Blog bei wordpress.org liegt, ist dies ohnehin die richtige Adresse für diese und weitere Fragen. ...

Bei wordpress.org liegen gar keine Blogs, wenn dann bei wordpress.com als Bloghoster. Aber das nur nebenbei. :-)

Gruß
Ingo

Irgendwie fehlt da noch die abschließende RewriteRule. Nur RewriteConditions bewirken gar nichts.

Gruß
Ingo

Ist vermutlich eh nur Linkbuilding bzw. Spam.

Wenn ich mir die komischerweise nicht verlinkte Blogseite des TE ansehe, dann ist das nicht gerade ein Aushängeschild für den Webhoster. Die Seite lädt bei mir ziemlich langsam. Wenn ich ein traceroute mache, lande ich bei space.net und nicht bei keyweb.de. Naja, egal, er hat seinen Link untergebracht. :-)

Gruß
Ingo

Wie viele News-Artikel schreibst Du denn so am Tag?
Du könntest ja einfach die Nummer selbst beim Slug hinten dran hängen.

Gruß
Ingo

Offensichtlich befinden wir uns hier sowieso auf dem Holzweg, denn wenn ich das richtig sehe, ist blogg.de ein Bloghoster ähnlich wie wordpress.com. Da wird man selbst an der Konfiguration gar nichts ändern können, weder im Wurzelverzeichnis noch sonst wo. Die Vorschläge kamen ja nicht von mir, ich habe nur richtig gestellt, was prinzipiell daran falsch ist.

Du mußt Dich an den Betreiber von blogg.de wenden, wenn es Probleme gibt.

Gruß
Ingo

Ja dann mach doch einfach Schluß für heute, wird ja nicht besser. :-)

Gruß
Ingo

Im übrigen hat so eine lokale, minimale php.ini-Datei möglicherweise auch Nachteile. Falls der Webhoster in der zentralen php.ini-Datei Werte geändert, insbesondere erhöht hat, gehen diese dann verloren. Die lokale php.ini-Datei wird nämlich, wenn vorhanden, anstelle der zentralen Datei geladen.
Aber das nur nebenbei.

Gruß
Ingo

Es geht hier aber nicht um das memory_limit für den Blog allgemein, wie in Deinem Link, sondern um die Größe von Upload-Dateien. Die Uploads erfolgen im wp-admin-Bereich und da bewirkt eine php.ini im Wurzelverzeichnis der Domain rein gar nichts.

Frage nebenbei, welche Server bei welchem Hoster? Das würde mich jetzt mal echt interessieren.

Gruß Ingo

Es geht hier aber nicht um das memory_limit für den Blog allgemein, wie in Deinem Link, sondern um die Größe von Upload-Dateien. Die Uploads erfolgen im wp-admin-Bereich und da bewirkt eine php.ini im Wurzelverzeichnis der Domain rein gar nichts.

Gruß Ingo

Ich weiß nicht wie es Euch geht, aber ich finde den neuen Media-Uploader, den es seit Wordpress 3.5 gibt, nicht wirklich gut.

Deshalb habe ich kurz entschlossen ein Mini-Plugin geschrieben, welches den alten Datei-Uploader wieder hervorzaubert:
http://schnurpsel.de/wordpress-plugins/123-old-uploader/

Gruß
Ingo

php.ini im Root nützt übrigens auch nichts, da sie nicht wie die .htaccess ihre Einstellungen auf untergeordnete Verzeichnisse vererbt. Wenn eine php.ini, dann im wp-admin-Verzeichnis.

Also nicht wild drauflos posten, sondern vorher auch mal drüber nachdenken. :-)

Gruß
Ingo

Ja, dann schalte doch mal einen Gang zurück, oder willst Du einen neuen Rekord mit Forums-Antworten pro Minute brechen. :-)

php.ini im Root nützt übrigens auch nichts, da sie nicht wie die .htaccess ihre Einstellungen auf untergeordnete Verzeichnisse vererbt. Wenn eine php.ini, dann im wp-admin-Verzeichnis.

Gruß
Ingo

Mit Doppelkreuz davor bewirkt das gar nichts, weil so Kommentare in der .htaccess beginnen.
Und sofern der Webhoster diese Art der PHP-Configuration nicht unterstützt, produziert man so nur 500er Fehler.

Gruß
Ingo

Naja, das Doppelkreuz vor den Einträgen in der .htaccess kommentiert diese aus, so daß sie gar nichts bewirken können.

Aber mal davon abgesehen ist es keine gute Idee, einfach irgendwas in die .htaccess einzutragen ohne zu wissen, ob das überhaupt vom Webhoster unterstützt wird. Bestenfalls provoziert man damit einen Fehler 500 für die gesamte Website.

Letztendlich sollte man beim Webhoster nachfragen oder in den FAQ nachsehen, was es da für Möglichkeiten gibt.

Gruß
Ingo

Und ein nslookup auf die IP-Adresse liefert das: h1862897.stratoserver.net

Falls das auch noch ein V-Server im unteren Leistungsbereich ist, braucht man sich über die schlechte Performance nicht wundern. Da wäre die Seite in einem normalen Webhostingpaket wohl besser aufgehoben.

Gruß
Ingo