Beiträge von Putzlowitsch

Zitat von punctilio

Was is das?
Special vom letzten Jahr oder wie?

Ja genau, diese WebXmasSpecial-Tarife gab es Ende letzen Jahres mal für ein paar Wochen, immerhin auch in 3 Abstufungen L, XL, XXL. Mein XL kostet 12.95 im Monat, also genau der Bereich, wo jetzt gähnende Leere herrscht.

Gruß
Ingo

Ja, besonders die Tariflücke zwischen 7.95 und 24.95 find ich schon recht ungünstig. Der Sprung ist ganz schön groß, da hätte man noch gut was dazwischen positionieren können. Aber das muß der Anbieter halt selber wissen. Wahrscheinlich ist die Tarifstraffung Ergebnis einer sorgfältigen Marktbeobachtung oder so.
Da bin ich doch froh, mein gutes, altes WebXmasSpecial XL Paket zu haben

Achso, ich hatte gedacht, daß Du das oben von leviathan zitierte Script verwendest. Damit geht es so, wie ich es beschrieben habe. Beispielsweise unter http://ein.gabedaten.de/ zu sehen. Einen Nachteil dieser Methode will ich aber auch nicht verschweigen. Der Cache-Mechanismus des Browsers greift hier nicht, das heißt die Bilder werden bei jedem Aufruf immer komplett neu geladen.

Wenn Du es aber so machen willst, wie jetzt von Dir bschrieben, mußt Du wohl den von copernica ausführlich beschriebenen Weg gehen.
Das Problem liegt einfach darin, das die CSS-Datei (oder besser der Server) nichts von PHP an der Stelle weiß, also 'random.php' einfach unbehandelt läßt.

Gruß
Ingo

Ich habe mal die Stelle im Quelltext rausgesucht:

// Move the file to the uploads dir
    $new_file = $uploads['path'] . "/$filename";
    if ( false === @ move_uploaded_file($file['tmp_name'], $new_file) )
        die(printf(__('The uploaded file could not be moved to %s.'), $file['path']));

Der Pfad wiederum ergibt sich aus $uploads['path'], was vorher mittels

$uploads = wp_upload_dir()

gesetzt wird.
Diese Funktion setzt den Upload-Path wiederum aus den eingestellten Option zusammen, also z.B. Jahr und Monat, falls die Option aktiv ist.
Außerdem wird hier auch Filter 'upload_dir' aufgerufen, könnte also durchaus ein Plugin schuld sein, das es schief geht.

Wobei oben bei der Fehlermeldung anstelle von $file['path'] besser $uploads['path'] stehen sollte, dann könnte man auch sehen, wohin die Datei verschoben werden sollt.

Gruß
Ingo

ist vielleicht unter Einstellungen->Verschiedenes der Eintrag für "Uploads in folgendem Ordner speichern" leer.
Ich find die Meldung nämlich komisch, da soll bestimmt zwischen "..nach verschoben..." stehen, wohin sie verschoben werden sollten. Da steht aber nix, sehr verdächtig zumindest.

Gruß
Ingo

Zitat von mamphp

... wie kann ich selber eine site selbst für die anmeldung stellen? ...

Am einfachsten wäre es wohl, die wp-login.php (Original natürlich sichern!) zu nehmen, und den eigenen Wünschen anzupassen. Da sollte man aber schon ein wenig Ahnung von PHP, HTML und auch CSS haben. Ohne dem wird es wohl nichts werden.

Gruß
Ingo

Zitat von kdw

Leider zeigt mir der CSSviewer im Firefox immer das Background-image: random.php an, an statt das PHP zu expandieren.

Das ist schon richtig, des PHP-Script ändert ja nichts an der CSS-Datei selber, sonder gibt einfach das Bild dirket an den Browser zurück, wenn er es anfordert. Also steht dann beim Aufruf der CSS-Datei eben nicht ein zufällig generierter Bildname, wie 'Background-image: bild01.gif' oder so drin. Wenn man das will, müßte man die CSS-Date per Script "On The Fly" erzeugen.
Außerdem müßte es, wenn übehaupt,

background-image: url(random.php);

heißen.

Gruß
Ingo

Öhmm, das oben war natürlich Quark:
'<img src="<?php bloginfo('stylesheet_directory'); ?>/images/prev.jpg" />'
PHP im PHP, naja ist schon spät, ich gehe schlafen

Gruß
Ingo

Eine radikale Variante wäre, sich in die 'wp-blog-header.php' reinzuhängen. Hätte den Vorteil, das es immer funktioniert, egal welches Theme eingestellt ist. Nachteil ist wie immer ein unschöner, direkter Eingriff in Originaldateien und mögliche, unbekannte Risiken und Nebenwirkungen. Dennoch hier das Beispiel, ohne Gewähr und auf eigenes Risiko. Die Originale 'wp-blog-header.php' in jedem Fall vorher sichern!

<?php


if (! isset($wp_did_header)):
if ( !file_exists( dirname(__FILE__) . '/wp-config.php') ) {
    if ( strstr( $_SERVER['PHP_SELF'], 'wp-admin') ) $path = '';
    else $path = 'wp-admin/';
    die("Es scheint keine <code>wp-config.php</code> Datei zu existieren. Ich brauche sie aber, bevor wir anfangen k&ouml;nnen. Brauchst Du weitere Hilfe? <a href='http://codex.wordpress.org/Installing_WordPress'>Hier findest Du sie. (engl.)</a>.  Bei WordPress Deutschland findest du <a href='http://wordpress.de/installation'>eine deutschsprachige Anleitung</a>. Du kannst die <a href='{$path}setup-config.php'>wp-config.php hier online erstellen</a>, dass funktioniert leider nicht mit allen Servern. Die sicherste Methode ist es, die Datei manuell herzustellen.");
}


$wp_did_header = true;


require_once( dirname(__FILE__) . '/wp-config.php');


wp();
gzip_compression();


if (is_user_logged_in()) {
    require_once(ABSPATH . WPINC . '/template-loader.php');
} else {
    require_once(dirname(__FILE__) . '/wp-login.php');
} 




endif;


?>

Gruß
Ingo

Die Frage wäre erstmal, wo diese Bilder abgelegt sind. Sind sie in einem 'images'-Verzeichnis im Theme-Ordner, klappt das so nicht, weil sich in der von Dir verwendeten Weise das 'images' immer auf den aktuellen Kontext bezieht. Als bei der Startseite bspw. auf das WP-Basisverzeichnis.
Du könntest aber folgendes Schreiben:

<?php
posts_nav_link(' ',
'<img src="<?php bloginfo('stylesheet_directory'); ?>/images/prev.jpg" />',
'<img src="<?php bloginfo('stylesheet_directory'); ?>/images/next.jpg" />');
?>

Oder Du legst die Bilder in ein festes Unterverzeichnis '/images' in die Wurzel und sprichst sie dann mit

<img src="/images/prev.jpg" />

an.

Gruß
Ingo

Es trägt zwar jetzt nicht direkt zur Problemlösung bei, aber es erhellt vielleicht etwas den technischen Hintergrund.
Da ich befürchtete, IE und Opera eventuell vorschnell mit meiner Bemerkung weiter oben, ob der Interpretation des Types anhand der Dateierweiterung, "verurteil" zu haben, bin ich der Sache nachgegangen.
Doch es zeigt sich wieder mal, das sich der Firefox korrekt an die RFCs hält, auch wenn es aufgrund z.B. einer fehlerhaften Serverkonfiguration zu Problemen führt, die man dann schnell mal bei oberflächlicher Betrachtung dem Firefox anlastet.

Im entsprechenden RFC 2616 zum HTTP 1.1 steht unter Punkt 7.2.1, das der Server eine content-type im Antwortheader senden sollte und nur wenn dieser fehlt, dann kann der Browser selbst versuche herauszubekommen, was das denn nun für Daten sein könnten.
Wobei es im Fall der eingebundenen CSS-Datei ja sogar noch eine Hilfestellung im Link selber gibt, dann da steht der Typ normalerweise mit drin:

<link rel="stylesheet" href=".../style.css" type="text/css" media="screen" />

Wenn der Server aber einen content-type sendet, hat das den Browser dennoch nicht zu interessieren. Und wenn der Server was falsches sendet, kommt halt korrekterweise das raus, was oben als Problem geschildert wurde.

Gruß
Ingo

Na supi, ich hatte schon langsam arge Zweifel ob meiner Programmierfähigkeiten bekommen

Man muß nun aber auch das Multihosting und die Themezuordnung explizit einschalten, damit sich überhaupt was tut. Vielleicht sollte ich das als Voreinstellung doch auf 'ein' setzen, nicht das sich nun jemand wundert, das dat aktivierte Plugin gar nix mach.

Gruß
Ingo

Ich habe mittlerweile herausgefunden, daß hier eher zwei Probleme vorliegen.

Das mit der Warnung bezüglich eines "Empty delimiter" (mal davon abgesehen, das die Funktion strpos keinen Parameter "Delimiter" hat) tritt dann auf, wenn die Zuordnungliste (Host zu Theme) leer ist. Die Warnung kommt bei mir natürlich auch, nur habe ich sie nicht gesehen, sie steht aber im PHP-Logfile. Ich prüfe nun also, ob der Wert nicht leer ist und nur dann wird das Theme aus der Liste zurückgeliefert. Sonst kommt das in der normalen Konfiguration eingestellte Theme zurück.

Das hat aber alle nichts mit dem Problem der puren HTML-Darstellung zu tun, denn für die Darstellung des Backends wird auf das eingestellte Theme nicht zurückgegriffen. Hier scheint doch, warum auch immer, irgendwas mit den Hostnamen schief zu laufen. Denn wie oben schon beschrieben, kann ich dieses Verhalten dadurch provozieren, daß ich in meiner Pluginfunktion nur 'http://' ohne Hostname zurückgebe.

Ich habe zusätzlich noch zwei Optionen eingefügt, mit denen man das "Multihosting" selber und auch die Verwendung der Themezuordnung ein- oder ausschalten. Beide Option stehen per Voreinstellung auf aus.
Außerdem zeige ich auf der Einstellungsseite nach der Version noch den aktuellen Host an, auf dem man gerade im Backend angemeldet ist. Falls dort nichts steht, ist was oberfaul.

Neue Version 0.13 kann an der bekannten Adresse runtergeladen werden.

Gruß
Ingo

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