Beiträge von metawops

Zitat von Putzlowitsch

Also mit einer Fritz-Box sollte es kein Problem sein, da gibt es sogar einen FAQ-Artikel bei Strato:
Strato FAQ Frontend

Mein Draytek kann das leider nicht, da muß ich auf einen Windows-DynDns-Client ausweichen.

Wieso mußt Du dann alles lokal hosten? Du kannst bei Strato-DynDns auch nur eine Subdomain dynamisch gestalten und der Rest bleibt unverändert.

Gruß
Ingo

Gruß
Ingo

Ah ja, jetzt sehe ich es auch. Ich dachte, man könne nur für Domains, nicht für Subdomains das DynDNS Feature nutzen. Sehr schön.

Und die FritzBox hat in der Tat im DropDown Menü der DynDNS Anbieter auch einen Eintrag für Strato (und einen für benutzerdefinierte Eingaben).
Nur: leider kann ich nur EINEN DynDNS Dienst mit meiner neuen IP versorgen. Jetzt muss ich mich entscheiden, ob Strato oder dyndns.org, denn die dortigen Namen will ich ja auch behalten/nutzen/mit neuer IP versorgen.
Wird also darauf hinauslaufen, einen OS X Client auf dem Mac mini laufen zu lassen, der dann einen der beiden Anbieter versorgt (den anderen versorgt dann die FritzBox).

Aber das ist ja jetzt alles völlig off-topic. Daher: Schluss damit. Ich bastel da jetzt mal und wenn ich dann noch WordPress-Probleme mit der URL habe, melde ich mich hier wieder.

Dankeschön & Grüße,
Stefan.

Hi Ingo,

ja, das stimmt, bin bei Strato. Das ist ein prima Hinweis, den Du da gibts. Ich wusste das noch nicht, dass Strato ein eigenes DynDNS anbietet.

Werde das am Wochenende mal ausprobieren.

Hoffe, dass meine Fritzbox erlaubt, auch andere als die ganzen dyndns.org Server einzutragen, insb. den Strato'schen DynDNS Server.

Sonst müsste eine Mac OS X Applikation her, die das regelmäßige Update meiner IP bei Stratos DNS vornimmt. Da kenn ich noch keine, die beliebige DynDNS Servernamen erlaubt einzutragen... Liefe dann auf dem Mac mini mit, wo auch der apache läuft.

Allerdings müsste ich dann ALLES, was bisher unter *.wops.de erreichbar ist auch zuhause auf dem Mac mini hosten ... Müsste machbar sein.

Gut, wie gesagt: prima Tipp! Danke!! :-)

Viele Grüße,
Stefan.

ups! Das hat mir jetzt leider den kompletten Admin-Bereich zerschossen (kam nicht mehr rein) und ich musste via phpMyAdmin die beiden Werte wieder zurücksetzen. (Oder zumindest den einen, aber dann bliebe ja "Oops, kein Content ...".

sehr strange ... :-(

Ich habe das Admin SSL Plugin aktiv, werde mal probieren, ob das hier stört...

Hallo Ingo,

das ist total nett, dass du dich um mein Problem kümmerst! :)

Ich hab Dein Mini-Plugin ausprobiert und ja, jetzt gibts keine Endlos-Umleitungsschleife mehr. -- Allerdings bringt die Homepage jetzt anstelle meines Blog-Inhalts leider nur den Text "Oops - There's Nothing Here. It looks like the blog ownerhasn't written anything yet!".

Ich hatte den Wert des Parameters "Blog-Adresse" wieder auf "http://meta.wops.de" gesetzt und den Wert von "WordPress-Adresse" auf "http://wops.dnsalias.net/wp_meta" gelassen.

Die Links, die ich trotzdem in der Sidebar und im Menü oben sehe (z.B. Kategorien, Seiten) sind allerdings schon so wie sie sein sollen: http://meta.wops.de/kategoriename bzw. http://meta.wops.de/seitenname. :-)

WP Version ist übrigens 2.5.1, falls das hier Relevanz hat.

*kopfkratz*
Stefan.

Hallo Ingo! :)

Ja, ein direkter Aufruf mit dieser Art URL funktioniert -- funktionierte aber auch schon bevor ich die Subdomain-Umleitung änderte.

Das Ändern der Blog-Adresse führt leider zu dem Effekt einer endlosen Umleitungsschleife. Im Firefox sehe ich dann als URL http://meta.wops.de/wp_meta/wp_meta/wp_meta/... (und so weiter) und nach einigen Sekunden die Fehlermeldung "Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann." :-(

Das passiert übrigens auch, wenn ich als URL "http://wops.dnsalias.net/wp_meta" eingebe.

http://meta.wops.de/wp-admin funktioniert allerdings einwandfrei! Ist also "nur" ein Problem bei der Ausgabeseite, nicht bei der Admin-/Redaktionierungs-Oberfläche.

Ich ändere die Blog-Adresse jetzt wieder zurück ...

Danke fürs Mitdenken!! :)
Stefan.

Zitat von codestyling

Soll das ein Scherz sein ?

Schau mal in Wikipedia, findest du das hier:Willst du allen Ernstes deine Url "verschleiern" wollen, wie es Phisher/Spammer machen ?
Das Browser Um/Weiterleitungen anzeigen hat ja gerade den Sinn, dass selbst du sehen kannst, dass du nicht mehr auf deinem Online Banking Portal bist, wenn dich jemand umleitet beim Rechnung zahlen.

Kauf/Miet dir doch WebSpace für deine Domain, dann musst du das nicht mehr umleiten lassen und kannst das so per eigener Domain korrekt ausliefern lassen.

Auch Hallo, Namens- bzw. Identitätsverschleierer. ;-)

Als Informatiker kenne ich die HTTP Codes ganz gut, aber danke für den WikiPedia Hinweis.

Es geht hier überhaupt nicht um Verschleierung oder Phishing. Ich finde es ja auch nicht verschleiernd, wenn im WebBrowser der Domain-NAME stehen bleibt und nicht die IP-Adresse angezeigt wird.

Es ist doch ganz offensichtlich wesentlich übersichtlicher und ästhetisch schöner für den Besucher, wenn er eine kompakte, leicht zu merkende URL bzw. Domain im Browser sieht als eine blöde technische a la "meinaccount.dyndns.org/mein_wordpress_installations_verzeichnis", die inhaltlich nicht mehr sprechend ist. Hast Du mitbekommen, dass sprechende URLs von allen empfohlen werden?

Anyway. Zurück zum Thema. Das Internet ist ja v.a. dazu da, dass sich Leute inhaltlich zu Themen austauschen, dass man von anderen etwas lernen kann und nicht, dass man andere öffentlich angreift. Jedenfalls verstehe ich das so.

Ich habe mittlerweile herausgefunden, dass ich bei der Subdomain-Konfiguration bei meinem ISP ganz genau aufpassen muss, was ich dort eingebe. Ich hatte da bisher stehen, dass die subdomain meta.wops.de auf wops.dnsalias.net/wp_meta/index.php zeigen soll.
Dies führte dazu, dass nach der Eingabe von "meta.wops.de" im Browser sofort nach Auflösung dieser Subdomain "wops.dnsalias.net/wp_meta/index.php" in der Adresszeile des Browsers stand.
Jetzt habe ich die Subdomain stattdessen mal auf "wops.dnsalias.net/wp_meta" zeigen lassen, also ohne "/index.php" und auch ohne "/" am Ende. Das ergab schonmal einen Teilerfolg: gibt man jetzt "meta.wops.de" im Browser ein, bleibt dies auch dort stehen -- jedenfalls solange die Homepage angezeigt wird.
Alle Links beginnen aber leider wieder "wops.dnsalias.net/wp_meta/...", weswegen dies natürlich auch wieder im Browser oben steht.

Das "riecht" jetzt für mich so, als wäre der Weg nicht mehr weit, dass auch alle (Perma-)links geradegezogen werden könnten und mit "meta.wops.de/..." anfangen. Nur leider reichen da meine WP-Kenntnisse noch nicht aus, das hinzubekommen.
Diese Anleitung scheint meinen Fall ja nicht abzudecken, oder?

Ich stelle mir das so vor, dass jetzt alle Links der Art "meta.wops.de/2008/06/blog-artikel-titel" nach "wops.dnsalias.net/wp_meta/2008/06/blog-artikel-titel" aufgelöst werden. Das wäre ja auch genau die Subdomain Namensersetzung, die da passt. Leider kriege ich das aber alleine mit den beiden Parametern "WordPress-Adresse" und "Blog-Adresse" in den WP-Einstellungen nicht hin. :-(

Vielleicht hat ja jemand einen konstruktiven Tipp, das wäre nett.

Vielen Dank auf jeden Fall allen (natürlich auch "codestyling") fürs Lesen und Mitdenken!! :-)

Stefan.

Zitat von Ammaletu

Der Grund, warum der Besucher Deine 'interne' Adresse zu sehen kriegt, ist dieser hier:

Ein 301er-Redirect wird vom Browser nicht nur gecacht, sondern dem Besucher auch angezeigt. Damit der Besucher die interne Adresse nicht zu sehen kriegt, müsstest Du die Subdomain direkt auf die dnsalias-Adresse schalten (ohne Redirect), und selbst da bin ich mir nicht sicher, ob das klappt.

Hm. Also dass es ein 301er ist, kann ich nicht ändern, das ist halt eine Vorgabe meines ISPs.
Und was meinst Du mit "direkt" umleiten?

Ist es denn richtig, dass ich bei beiden Einstellungen die dnsalias-Adresse drin habe?

Gibt es nicht irgendwelche meta tags, die dafür sorgen, dass die ursprüngliche URL in der Browser-Adresszeile stehenbleibt?

Hallo zusammen,

mein WP-Blog ist unter MetaWops’ Home. erreichbar. Gehostet ist es bei mir zuhause auf einem Mac mini. Die Subdomain META.wops.de wird per 301er redirect auf die tatsächliche URL bei mir zuhause weitergeleitet. Damit mein Mac mini permanent aus dem Internet erreichbar ist, habe ich natürlich einen kostenlosen Eintrag beim Dienstleister dyndns.org -- und das sieht der Besucher leider auch in der URL-Zeile des Browsers: statt meta.wops.de steht da dann wops.dnsalias.net/wp_meta/2008/...

Wie und wo kann ich einstellen, dass in der Browser-URL-Eingabezeile aber "meta.wops.de/2008/..." stehen bleibt?

Bei den beiden Einstellungen "WordPress-Adresse (URL)" und "Blog-Adresse (URL)" habe ich auch MetaWops’ Home. eingetragen -- weil nämlich jede andere Kombination von dieser Adresse und MetaWops’ Home. leider dazu führte, dass mein Blog nicht mehr erreichbar war, auch via Admin-Oberfläche nicht mehr. So musste ich dann immer direkt in der DB wieder auf MetaWops’ Home. zurückpatchen.

Danke für eure Hilfe schonmal im Voraus,
Stefan.

Hi Andy16,

eine für mich sehr positive Nachricht -- für Dich jetzt wahrscheinlich eher nicht: bei mir gehts wieder!!
Leider kann ich nicht sagen, woran es lag, denn was ich machte, war einfach, den Mac mini (WebServer, DB-Server) komplett neu zu booten. Frei nach der alten Informatiker Weisheit "Reboot tut gut".
Hätte ich mal früher machen sollen!

Ich weiß nicht, wie Du hostest, falls auf einem eigenen Rechner zuhause könnte ja auch bei Dir ein Reboot helfen. Falls Du natürlich bei einem ISP bist, geht das wohl nicht. Dann muss das Problem wo anders liegen.

Hast Du schon mal im englischen Support-Forum (WordPress › Support) nach "Failed to write file to disk" (die engl. Bezeichnung dieses Fehlers) gesucht? Da gibt es viele Treffen mit jeweils vielen Tipps. Vielleicht hilft ja einer davon!?

Ansonsten wüsst ich auch nix -- das belegt ja mein langer Thread hier... :-(

Viel Erfolg! Ich drück die Daumen!

Stefan.

Also, erstmal freut es mich, dass es bei Dir geholfen hat. Schön, dass die Dokumentation meines "Martyriums" ;-) hier wenigstens einem/einer geholfen hat! :-)

Tja, leider bin ich schon seit Beginn dieses Threads auf 2.5.1 und habe immer noch dieses Problem. :-(

Ich hatte von 2.5 auf 2.5.1 mit dem kleinen "Delta-Paket" geupdatet, also nur die Dateien, die sich geändert hatten eingespielt.

ABER: in einem Beitrag hier im Thread schrieb ich ja auch, dass selbst eine komplette Neu-Installation eines blanken WP 2.5.1 inkl. einer komplett neuen leeren Datenbank dazu das Problem auch zeigt. (Was ein Problem in der Server-Konfiguration nahelegt -- was wiederum auch nicht sein kann, da es mit 2.5(.0) ganz am Anfang ja mal ging -- und an der Serverkonfiguration habe ich nichts geändert; immer noch die selbe Apache, PHP, mySQL, OS X Version...)

Außerdem, so schrieb ich, brachte auch das komplette "überbügeln" der Verzeichnisse wp-admin und wp-includes meiner WP 2.5.1 Installation nichts.

Klar: das manuelle "Hochladen" von Bildern auf den Webserver (bei mir ein einfaches Kopieren im LAN) geht natürlich. Aber das Einbauen in einem Beitrag ist dann schon blöd/mühsam. Insbesondere, wenn ein Bild dann mal rechtsbündig/linksbündig sein soll oder so. Ich kenne ja die CSS Klassen/IDs nicht, die ich dafür manuell im HTML Code angeben müsste. Alles andere als schön.
:-(

Schade, dass sich keiner erbarmt ... habe das Problem immer noch.
Es gibt jede Menge Tipps im wordpress.org Forum, aber keiner hat bisher geholfen.
Zuletzt habe ich in meiner php.ini die Variable upload_tmp_dir auf den wert "/tmp" gesetzt. (War vorher nicht gesetzt worden im php.ini.)
Dann apache gestoppt und neu gestartet.
Was soll ich sagen, ihr ahnt es schon: auch das half nicht.

der apache (prozessname "httpd") läuft hier auf dem mac mini als user "nobody" (ist der vom xampp paket).

alle dateien und ordner von WP gehörten aber dem user "stefan". habe kurzerhand den owner aller dateien und ordner auf "nobody" geändert.

=> half auch nichts. :-(

hm. interessant: das importieren der wordpress-export-datei aus meinem ursprünglichen WP klappte mit der selben fehlermeldung nicht: "Konnte die Datei nicht auf die Festplatte kopieren." kommt da anstelle eines erfolgreichen import-vorgangs ...

so langsam glaube ich wieder an ein filesystem-rechte-problem, aber zumindest das wp-content verzeichnis ist 777. und auch das darin befindliche uploads verzeichnis ist 777.

*kopfkratz*

so ein ärger!

ich habe jetzt eine komplett neue wordpress 2.5.1 installation gemacht, inkl. komplett neuer datenbank.

als allererstes, bevor ich irgendwas geändert oder hinzugefügt habe, bin ich auf "Schreiben" gegangen und habe dann im Editor das Icon für Bild-Upload geklickt. Ein Bild von der lokalen Platte gewählt und --bumms!-- auch hier genau die selbe Fehlermeldung!

jetzt bin ich völlig verzweifelt und hab keine ahnung mehr, woran es liegen kann.

frust pur! :-(

Ohje. Jetzt hat mich genau dieses Problem bzw. diese Fehlermeldung erwischt -- mit WP 2.5.1 allerdings!
Habe das hier dokumentiert -- vielleicht hat ja jemand einen Tipp? Das nervt leider sehr und macht WP quasi unbrauchbar ... :-(

... und in meiner php.ini ist open_basedir nicht gesetzt (mit Semikolon auskommentiert).
... und safe_mode ist Off.

... falls das eine Rolle spielt. Kam hierdurch (vorletztes Posting) drauf, aber da ging es ja um eine viel ältere WP Version.

... werde weiter tapfer googlen.

Und nochwas: alle Plugins deaktivieren hilft übrigens auch nicht. Immer die selbe, stupide Fehlermeldung "Konnte die Datei nicht auf die Festplatte kopieren." in roter Fettschrift. :-(

Und es ist egal, ob ich Safari 3.1 oder FireFox 3.0b5 verwende...

Junge, Junge. Das scheint ne harte Nuss zu sein. Ich habe jetzt
- via phpMyAdmin in der Datenbank alle Vorkommen der alten URL manuell in die neue URL gepatcht. => Kein Erfolg.
- alle bisher hochgeladenen Bilder (aus der Zeit als es noch ging) mittels WordPress Admin Oberfläche gelöscht. => Kein Erfolg.
- das Plugin "flexible upload" probiert. => Kein Erfolg. Geht genausowenig, kommt der selbe Fehler.
- sowohl das error_log als auch das access_log beobachtet, während ich ein Bild-Upload versuche. Keine Auffälligkeiten. Das error_log produziert gar keinen neuen Eintrag, im access_log finden sich diese beiden Zeilen zu der versuchten Aktion:
91.55.xxx.xxx - - [29/Apr/2008:20:04:49 +0200] "GET /wp_meta/wp-admin/media-upload.php?post_id=-1209492210&type=image& HTTP/1.1" 200 8986
91.55.xxx.xxx - - [29/Apr/2008:20:04:58 +0200] "POST /wp_meta/wp-admin/async-upload.php HTTP/1.1" 200 86

Beide haben den Status 200, also völlig okay.

Ich weiß jetzt wirklich nicht mehr weiter. Habe auch das wp-includes und das wp-admin Verzeichnis komplett gelöscht und vom wordpress-2.5.1-de.zip Archiv neu kopiert. Brachte ebenfalls nichts.

Sonst funktioniert alles einwandfrei...

Ganz schön frustrierend... :-( *soifz*

Gibts denn GAR keine Möglichkeit, genauere Details zum Grund der Fehlermeldung "Konnte die Datei nicht auf die Festplatte kopieren." herauszufinden? Kann man irgendwo einen log-level hochsetzen?

(Die Datei, die ich hier immer als Test-Bild nehme, ist übrigens gerade mal 8KB groß -- irgendwelche PHP Memory-Beschränkungen sollten daher auch nicht das Problem sein...)

Übrigens hat auch keiner der Tipps hier geholfen. :-(

Bin ganz schön ratlos und will doch, ja MUSS bloggen! Sonst ist die Aktualität futsch! :-( :-( :-(

Hallo maksi,

danke für den Tipp -- aber auch das hilft leider hier nicht. (Hätte mich auch gewundert, weil es mit dem Bilder hochladen ja klappt, wenn ich nur diese beiden URLs in den Einstellungen ändere -- die von Dir genannte Datei ist dann ja immer noch da.)

Ich habe mittlerweile herausgefunden, dass die bisher hochgeladenen Bilder in der Tabelle wp_posts stecken -- zumindest gibt es dort Suchtreffer, wenn ich nach meiner früheren URL suche (via phpMyAdmin), die in den Einstellungen eingetragen war.
Ich frage mich nur, was jetzt helfen würde? Manuell in der DB die Vorkommnisse dieser alten URL in die neue URL patchen?

Hmmm...