Beiträge von Putzlowitsch

Jetzt muß ich doch mal nachfragen. Kommt jetzt nur noch diese Warnung oder besteht der von Dir beschrieben Effekt mit der Anzeige in purem HTML auch noch?
Ich habe versucht, den Fehler bei mir zu simulieren. Bei mir zeigt sich das von Dir beschrieben Verhalten genau dann, wenn der Hostname, denn ich für 'siteurl' bzw 'home' zurückgebe, leer ist. Die Warnung traten dann bei mir allerdings auch nicht auf.
Es gibt schon einen wesentlichen Unterschied zur my-hacks.php-Version und da diese bei Dir ja funktioniert hat zeigt mir das zumindest, das Hostname die falsche "Baustelle" ist.

Vielleicht kannst Du mir noch ein paar Eckdaten Deiner Konfiguration mitteilen, also WP-/Apache-/PHP-Version und die wichtigsten PHP-Einstellungen (z.B: safe_mode).

Gruß
Ingo

Na ich würde sagen, da ist am Webserver irgendwas nicht richtig konfiguriert. Der ist schließlich dafür zuständig, was als content-type im Antwortheader eingetragen wird. Wenn ich den name "...vserver.de" richtig interpretiere, kann man da bestimmt selber an der Apache-Konfiguration rumfummeln. Allerdings bin ich diesbezüglich kein Experte, das muß sich mal jemand angucken, der was davon versteht.
Und das IE und Opera keine Probelme machen, dürfte daran liegen, das sie "fehlertolerant" den content-type einfach ignorieren und davon ausgehen, das eine *.css-Datei halt eine CSS-Datei ist, oder so :-)

EDIT:
Ich habe mal in die Konfiguration meines lokalen Apache-Testservers reingesehen, von Hause aus ist das in der Datei 'mime.types' korrekt eingestellt. Für die Dateierweiterung css wird text/css verwendet. Das wurde hier entweder dort geändert, warum auch immer, oder z.B. in der .htaccess überschrieben.

Gruß
Ingo

Es könnte daran liegen, das der Server für die CSS-Datei fälschlicherweise als content-typ 'text/html' und nicht 'text/css' zurückgibt. Firefox scheint sich nun streng an den Typ zu halten und versucht das ganze als HTML zu interpretieren. Naja, zumindest wird es nicht als CSS verarbeitet.

Gruß
Ingo

So, nun aber. War wohl gestern schon etwas spät. Da arbeiten die grauen Zellen manchmal nicht mehr so richtig :???:

Neue Version 0.12 ist an bekannter Adresse downloadbar.

Noch eine Frage, hattest Du die Urversion mit my-hacks.php auch schon getestet? Da hätte es auch nicht funktionieren dürfen (bei gleichen Bedingungen, sprich auf dem selben Server).

Gruß
Ingo

Besten Dank für Eure Hinweise.

Um nochmal den Hintergrund meiner Frage zu erläutern, ja, es geht mir um nicht-flüchtige Optionen.
Tja, und im Moment speichere ich schon zwei Stringlisten als Optionen persistent mittels der entsprechenden WP-Funktionen in der Options-Tabelle.
Nun kommt erstmal eine einfache Checkbox hinzu.

Da ich aber vermute, das später auch noch weitere Optionen dazukommen könnten, bin ich nun doch den Weg gegangen, die Optionen lokal in einem Array zu halten, und dann komplett in einer weiteren Option zu speichern.
Erfreulicherweise braucht man sich um das Zusammenfügen und Zerlegen des Arrays nicht selbst zu kümmern. 'update_option' nimmt ja klaglos ein array entgegen, und 'get_option' stellt es auch brav wieder im Ooriginalzustand her. Feine Sache das.

Gruß
Ingo

So, neue Version 0.11 liegt zum Download bereit:
http://putzlowitsch.de/123-multihost/

Anstelle der Variable 'HTTP_HOST' wird, falls diese nicht gesetzt ist, der Wert von 'SERVER_NAME' verwendet. Zudem ist es optional beim Dateiupload möglich, eine relative URL (=>GUID) zu erzeugen.

Gruß
Ingo

Ohoh, das sieht mir nach einem leeren Eintrag in der Zuordnungsliste aus. Das muß ich wohl nachbessern. Neue Version folgt in Kürze. Dann außerdem mit optionalem Erzeugen relativer Upload-URLs.

EDIT: Irrtum meinerseits. Es ligt wohl daran, das die Servervariable $_SERVER['HTTP_HOST'] nicht gesetzt ist.
Hmmm, man kann sich auch auf nix mehr verlassen ;-)

Gruß
Ingo

So, habe mal geschaut, was genau beim Einfügen von Uploads im Editor passiert. Die URL wird direkt aus der in der Datenbank gespeicherten 'guid' generiert, so das man an der Stelle nicht mit einem Filter eingreifen kann.
Aber man kann bereits beim eigentlichen Upload die URL manipulieren, aus der dann auch die die guid entnommen wird. Dafür gibt es ein Filter 'upload_dir', in das man sich reinhägen kann.

Ich werde das mal in meine nächste Pluginversion integrieren.
Aber wie gesagt, falls jemand "von außerhalb" auf den Inhalt per Feed zugreift, gibt es ein Problem. Man müßte dann wohl für diese relativen Links den Host wieder reinschreiben, per Filter-Plugin.

Gruß
Ingo

Wie im Titel schon angedeutet, wie macht Ihr das mit den Optionen oder gibt es sogar eine empfohlene Vorgehensweise?
Ich könnte je meine Optionen, also z.B. ja/nein- oder Auswahlwerte jeweils extra per add/get/update_option verwalten, was dann jeweils einen Datenbankeintrag pro Option ergeben würde.
Oder ich verwalte die die Werte selbst in einem array und lade und speichere alles in "einem Rutsch".
Was hätten die Methoden für Vor- oder Nachteile, die ich als Anfänger eventuell noch nicht überblicke?

Gruß
Ingo

Man müßte wohl ein Filter schreiben für 'attachment_link', und da dann den host-Part entfernen.
Ein kleiner Nachteil von diesen relativen Links ist mir aber im Zusammenhang mit meinem '123 Multihost'-Plugin schon aufgefallen. Im 'content'-Teil von RSS- oder Atom-Feeds bleiben sie dann relativ, und der geneigte Feed-User hat dann natürlich ein Problem. Man müßte sie also für die Feed-Ausgabe wieder "absolutieren" :-), damit es damit klappt. Auf der eigenen Seite sind relative Links natürlich keine Problem und für ein Funktionieren des '123 Multihost' auch unabdingbar.

Gruß
Ingo

EDIT: 'attachment_link' scheint die falsche Funktion zu sein, ich suche bei Gelegenheit mal weiter

Am besten die veraltete my-hacks.php-Datei wieder rausschmeißen und dafür mein neues Plugin verwenden :-)

http://putzlowitsch.de/123-multihost/

Gruß
Ingo

Inspiriert von 1 Blog - 2 URLs - 2 Themes hatte ich ja bereits als schnellen Hack eine Lösung für die my-hacks.php vorgestellt. Nachteil ist natürlich, das einerseits dieser Ansatz veraltet ist und nach Möglichkeit nicht mehr verwendet werden sollte. Andererseits mußt der Benutzer die Konfiguration händisch in den Quelltext eintragen.

So habe ich die Funktionialität nun doch in eine Plugin verpackt, inklusive einer über die Einstellungen erreichbaren Konfigurationsseite. Hier kann man bequem den Hosts eine bestimmtes Theme zuweisen. Denn das war ja auch der Ausgangspunkt, den unterschiedlichen URLs sollte auch ein eigenes Aussehen verpaßt werde.

Hier also das Plugin 123 Multihost Version 0.1

Gruß
Ingo

Sieh mir ein bißchen wie diese Problem aus:
http://forum.wordpress-deutschland.org/showthread.php?t=14924
Zusätzlich müßte man dann noch die Ausgaben hostabhängig filtern, da weiß ich aber nicht, wie das geht.

Gruß
Ingo

Sowas ähnliches hatten wir kürzlich hier:
http://forum.wordpress-deutschland.org/showthread.php?t=14757
Da war alles kursiv, auch die Links, Kategorien usw.
Da hilft wirklich nur in den Beiträgen suchen.

Gruß
Ingo

In der header.php ist schon richtig. Bei mir sieht die am Ende etwa so aus:

<div id="header">
    <div id="headerimg">
        <h1><a href="<?php echo get_settings('home'); ?>/"><?php bloginfo('name'); ?></a></h1>
        <div class="description"><?php bloginfo('description'); ?></div>
    </div>
[B]</div>[/B]
<hr />

Also muß da noch ein </div> vor dem <hr /> (scheint bei Dir zu fehlen), und nicht wie von mir oben vorgeschlagen, nach dem <hr /> eingefügt werden. Dann sollte es klappen.

Gruß
Ingo

Ja, es fehlt ein schließendes </div> für #header, würde ich sagen:

</a></h1></div>
<hr>
</div> <!-- das fehlende, schließende div -->
<a href="http://www.agys-gedankenwelt.de/">

Da könnte es hin, zumindest im generierten HTML-Quelltext. Die zu Grunde liegende PHP-Datei sieht man ja nicht.
Das boder: none; entfernen und den Rahmen in der CSS-Datei konfigurieren, aber nur beim oberen #page, nicht beim zweiten darunter. Oder zumindest nur an einer Stelle.

Gruß und gute Nacht
Ingo

Erstmal ist es schon ein Problem, das die in der CSS-Datei gemachten Einstellungen für #page border in Quelltext der Seite wieder außer Kraft gesetzt werden:

#page { background: url("http://www.agys-gedankenwelt.de/wp-content/themes/default/images/bg.jpg") repeat-y top;[B] border: none;[/B] }

Und dann ist da irgendwas in der Seitenstruktur ein bißchen durcheinander geraten, schließendes </div> an falscher Stelle oder so. Hier sollt die Seite an sich nochmal sorgfältig überarbeitet werden. Es sollte ausreichen, dem #page-Element einen Rahmen zu verpassen, aber irgendwie endet das schon unter dem Header, sollte wohl aber eigentlich die ganze Seite umfassen. Man kann sich sowas gut mit dem Firefox-DOM-Inspector ansehen.

Gruß
Ingo

Um vielleicht noch mal auf die Ausgangthese zurück zukommen "Was macht Dein Blog attraktiv?".

Viele der dort angeführten Punkte machen ein Blog für mich eher unattraktiv. Aber das liegt in der Natur der Sache, den ob etwas als attraktiv, also verlockend, begehrenswert, erstrebenswert oder anziehend empfunden wird, ist immer individuell und subjektiv.

Über Wetter, Erfolge, Katastrophen, Promis und Tierschicksale kann ich in richtigen Zeitungen genug lesen (ja, ich habe eine regionale, gedruckte Tageszeitung abonniert), das braucht in Blogs nicht noch 1000mal wiedergekäut zu werden. Aus meiner Sicht ist Blog eben nicht Zeitung. Auch die nochmal aufgebrühte Fernsehsendung vom Vorabend interessiert mich nicht sonderlich, aber das liegt eventuell auch daran, das mein Fernsehkonsum eher unterdurchschnittlich ist.

Was ich in Blogs lesenswert finde, sind die kleinen Alltagsgeschichten, Geschichten die das Leben schreibt. Das dürfen dann auch schon mal "Belanglosigkeiten in Überlänge" sein, wenn sie interessant geschrieben sind.

Und dann stellt sich noch die Frage, warum soll mein Blog überhaupt attraktiv sein, was oder wen will ich erreichen. Das muß natürlich jeder für sich selber beantworten. In meinem Fall war es eher eine kleine technische Herausforderung, mal was anderes auszuprobieren, etwa für mich neues. Ob das nun für andere besonders attraktiv daherkommt, ist mir egal. Obwohl ich mich schon darüber freue, wenn es Resonanz auf den einen oder anderen Beitrag gibt. Insgesamt ist es doch eher eine Art Selbstbestätigung (um jetzt nicht Selbstbefriedigung zu sagen ;-).

Wenn ich aber lese "...mehr Leser bringen...", "...Profitieren von..." und "...wird belohnt..." dann scheint mir die gewünschte Attraktivität eher ein geschäftliches Interesse zu verfolgen. Und auch wenn man "private Homepage" drüberschreibt, aber Werbung bis zum Abwinken auf der Seite hat und sogar eine Umsatzsteuer-Identifikationsnummer (da steckt der wirschaftliche Aspekt schon im Wort selber drin :-) angibt, würde ich das schon so ein bißchen als "gewerbsmäßig betriebenen Blog" ansehen.

Gruß
Ingo

Zitat von mastermind

Doch, mit der Option HostnameLookups = On macht der Apache genau das.

Mal davon abgesehen, das ich beim Shared-Server diese Einstellung nicht beeinflussen kann (ein Versuch in der .htaccess wurde mit einem Fehler 500 bestraft), habe ich ja zusätzlich noch einen großen Denkfehler drin.
Selbst wenn der Webserver ein Reverse-Lookup macht, ergibt das mitnichten meine schöne DynDNS-Adresse, sondern die vom meinem Zugangsprovider vorgesehen, also sowas wie 'p548C1334.dip0.t-ipconnect.de'.
DynDNS taugt nur für eine vorwärts gerichtete Host-zu-IP-Auflösungen.

Zitat von mastermind

... mit Kanonen auf Spatzen geschossen ...

Ja man sollte es wohl wirklich nicht übertreiben :)

Die Variante mit der Browserkennung und der IP-Adresse werde ich aber mal testen, wer weiß, wozu das noch nützlich sein kann.

Gruß
Ingo

Zitat von mastermind

... wobei die Variante mit der IP-Adresse wohl am schmerzlosesten wäre. So oft ändert sich die IP-Adresse ja nun auch nicht, die kann man ja einmal am Tag manuell aktualisieren.

Öhmmm, das bringt mich ja auf eine noch bessere Idee. Man muß ja nicht unbedingt die IP-Adresse nehmen. Mit der Abfrage nach 'REMOTE_HOST' und einer entsprechenden dynamischen Adresse bei dyndns.org oder ähnlichen Anbietern sollte man sich das manuelle Aktualisieren sparen können.

Hmmm, wenn ich jetzt so drüber nachdenke befürchte ich aber, daß nur kaum ein Webserver für jede Anfrage eine reverse DNS-Auflösung ausführen wird und somit der Parameter REMOTE_HOST gar nicht zu Verfügung steht. Naja, vergessen wir es wieder. Schade...

Gruß
Ingo