Beiträge von Putzlowitsch

Na also, jetzt siehts doch gut aus :-)

Ich hab es grad mal bei mir mit "mceLink" gestestet, wenn ich da für
href = "" etwas eintrage, dann ist im Popup die URL damit vorbelegt. Allerdings, und das könnte den Unterschied ausmachen, habe ich den WYSIWYG-Editor aktiv. Beim "normalen" Editor geht es nicht, da müsste ich erst noch gucken, wo das ist.

Bei mir wird der PHP-Quelltext angezeigt, da scheint eher beim Webserver was nicht zu stimmen.

Also ich habe da was in der Datei tiny_mce.js gefunden.
Da gibt es zwei Stellen, wo vor dem Aufruf des Popups Variablen mit Leerstrings initialisiert werden:

case "mceLink":
...
var href = "", target = "", title = "", onclick = "", action = "insert", style_class = "";

und

case "mceImage":
            var src = "", alt = "", border = "", hspace = "", vspace = "", width = "", height = "", align = "";

wenn man diese Variablen wie gewünscht ensprechend vorbelegen würde, könnte es klappen.
Alle Angaben wie immer ohne Gewähr ;-)

Gruß
Ingo

Zitat von patrick0815

... Wie ich gesehen habe muss man sich erstmal alle möglichen Plugins runterladen um es Suchmaschinentauglich zu machen ...

Das verstehe ich nicht, wieso braucht man Plugins, um WP suchmaschinentauglich (was immer damit gemeint sein mag, man kläre mich auf) zu machen? Einfach bei Einstellungen->Permalinks "Basierend auf Datum und Name" auswählen, so hab ich das zumindest gleich von Anfang an gemacht, und gut ist.

So schnell, wie mit meinem ersten WP-Blog, wurde ich vorher noch nie in den Index aufgenommen, und Treffer bekomme ich auch zu (meist) relevanten Themen.
Nehmen wir als Beispiel nur meinen Artikel "Apple iPod Nano FX-G30". Am 22. Dezember geschrieben, am 23. bereits der erste Besucher über Yahoo, am 27. dann auch über Google, insgesamt waren das seitdem bisher mehr als 60 Zugriffe. Und hej, ich stehe bei Google auf Platz 1 :-)

Gruß
Ingo

Ähmm, ich bin zwar nicht gemeint (es ist ja nicht mein Blog), kann aber mit dem Firefox 2 keine Besonderheiten erkennen. Die Seite sieht bei mir genauso aus, wie z.B. mit dem IE 6. Was anderes hab ich grad nicht da, zum Testen.

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

Könnte es sein, das diejenigen mit dem schlechten Kontrast den IE verwenden? Mit dem hab ich auch hellgrauen Text auf dunkelgrauem Hintergrund, das ist wirklich schwer zu erkennen.
Im Firefox sieht aber eigentlich alles gut aus, da ist der Hintergrund auch (nahezu) weiß.

KLEINER NACHTRAG: Im IE kann man sich damit behelfen, mit der rechten Maustaste irgendwo an eine freie Stelle auf der Seite zu klicken und dann "Alles markieren" auswählen. Dann hat man zumindest lesbaren weißen Text auf blauem Hintergrund, egal was da nun auf der Seite eingestellt ist :-)

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