Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenDas hängt aber auch von den Einstellungen deines Blogs ab. Wenn du Permalinks benutzt, die die categorie mit in den Link einbauen oder sonstiges, Beispiel:
www.domain.tlc/category/my-first-pagedann wird das Bild von Browser in
www.domain.tlc/category/images/icon.jpggesucht. Falls der Image Ordner direkt im root liegt, dann versuch es doch man so
src='/images/icon.jpg'Da das Bild relativ zur aktuellen Seitenbasis angegeben ist [COLOR=#000000]
src='images/icon.jpg'müsste man wissen, wie diese lautet. Mit einem Link zum Blog wäre das deutlich einfacher zur erkennen und zu beheben.
[/COLOR]
Sollte jemand anders noch Probleme haben, hab jetzt ENDLICh das Problem bzw. die Lösung (alleine) gefunden.
Mag ich bezweifeln, denn die Hinweise auf den falschen Cookie Path wurden sehr wohl gegeben.
Hoffentlich werd ich keine anderen Probleme haben, da hier ja leider nicht sehr gut geholfen wird.
Auch das sehe ich anders. Wenn du eine Diagnose und Behandlung willst aber den Patienten nicht vorstellst (strikte Verweigerung des Links zu Seite), kann dir auch nur bis zu einem gewissen Punkt nur geholfen werden. Da du dich nicht an Punkt II der Forenregeln http://forum.wordpress-deutschland.org/allgemeines/44…t.html#post2065 gehalten hast, finde ich deine Aussage sehr unangebracht.
Das bastel doch mal ein Bild und schieb das so wie es sein soll, denn ich versteh nicht, was jetzt falsch sein soll.
Auch eine Reanimation nach 9 Monaten kann nur erfolgreich sein, wenn man den Patienten auch sehen kann. Also ohne Link zur Seite wird es wohl nix werden.
Wie bekomme ich die Leerzeile weg, die mir nach den Feed-Adressen eingeblendet werden?
Einfach das rote rauswerfen. Die Klasse "post" erzeugt Abstand nach unten und der kaputte p einen zusätzlichen Abstand nach oben und unten.
<div class="statistics">
<div [COLOR=Red][B]class="post"[/B][/COLOR]>
[B][COLOR=Red]<p>[/COLOR][/B]Ein Formular ist innerhalb eines <h2> Überschrift nicht erlaubt. Dein Suchfeld (Form) hast du jedoch in ein <h2> eingesperrt. Da solltest du einen <div> stattdessen nehmen.
Die Breite des Suchfelds ist prozentual angeben aber passt nicht zur Breite deiner Sidebar. Ändere das mal im Stylesheet (core.css.php (line 1056)) von 79% auf:
#s {
font-size:1.1em;
width:[COLOR=Red][I][B]68%[/B][/I][/COLOR];
}Also der Aufruf der Funktion mit der Post ID sieht dann so aus:
<a href="http://www.amazon.de/gp/search?ie=UTF8&keywords=<?php
global $post;
$tag = get_the_tags($post->post_ID);
if ($tag) {
$tag = $tag[0]; echo $tag->name;
}
?>&tag=neuemedien-21">www.amazon.de</a>
irgendwoher musst du ja die Post ID bekommen.
Also Neuanmeldungen können keine Leerzeichnen haben, oder du hackst WPMU. Wegen den Buchstaben: Überfragt. Wenn ich mich nicht täusche greift dort der Umlautedingsda von WP und äüö werden zu auo und deine Buchstaben dann auch. Aber stop: WordPress MU lässt nur A-Z zu (ohne Umlaute).
Gruß Dennis
Mal so aus der Hüfte heraus: Es geht doch eigentlich darum, Usernamen korrekt umzusetzen. Eine Mischung aus Leerzeichen zu Bindestrich und PunyCode (für Umlaut und Unicode Domain Namen) könnte da helfen:
материал -> xn--80aaomqb4ao
mühe-voll -> xn--mhe-voll-65aKönnte man doch in WMPU so integrieren und standardisieren ?
Nur so eine Idee.
Was man dazu braucht findest du hier: http://forum.wordpress-deutschland.org/konfiguration/…html#post172109
und hier: http://forum.wordpress-deutschland.org/konfiguration/…html#post172130
Hatten wir schon mal.
Na wenn du ganz viel Aufriss und genaue Breiten haben willst, benötigst du
Dann kann man die Breite ermitteln:
$coordinates = imagettfbbox ( 12, 0, "ARIAL.TTF", "Das ist ein Test");
$width = $coordinates[4] - $coordinates[6];wobei es meist essentiell ist, den vollen Pfad zur TTF Datei anzugeben!
iLaut der Anleitung sollte damit der erste Tag dargestellt werden aber geht leider nicht.
Nur warum?
In der Anleitung steht, dass es so nur in der Loop funktioniert. Wenn du das jedoch außerhalb der Loop verwenden willst, brauchst du die post ID und kannst das damit aufrufen:
function get_the_tags( $id = 0 )
denn die Funktion versteht ja nun auch eine post ID, nur steht das nicht im Codex, denn der ist noch nicht auf den neuesten Stand !
Ach ja, ist es trotzdem möglich die .mo Dateien zu benutzen ohne das / zu entfernen?
In diesem Plugin musst du das leider ändern. Es wäre auch gut, das dem Autor zu schreiben. Die WordPress Funktion zum Laden der Plugin Text Domains sieht intern so aus:
function load_plugin_textdomain($domain, $path = false) {
$locale = get_locale();
if ( empty($locale) )
$locale = 'en_US';
if ( false === $path )
$path = PLUGINDIR;
$mofile = ABSPATH . "$path/$domain-$locale.mo";
load_textdomain($domain, $mofile);
}Da bei Übergabe von $path immer ein Slash angefügt wird, würdest du, so wie es original ist, dann 2 nebeneinander bekommen, was dann dazu führt, das Unix Systeme die Datei nicht finden 
In XAMPP Systemen (Windows) funktioniert das aber so wie es dasteht.
Nur sollte es OS unabhängig auch klappen, deswegen den Slash am Ende entfernen.
Also eine mögliche Lösung hab ich hier schon angeboten: http://forum.wordpress-deutschland.org/installation/3…html#post173301
Es gibt aber vereinzelt Systeme, die das permanent haben (auch mit dem Patch), für diese ist eine Untersuchung noch in Arbeit.
Ist bei dir vor Kurzem erst auf PHP/5.2.6 umgestellt worden ?
Nein, leider habe ich sowas noch nicht gefunden!
Gibt es noch andere Möglichkeiten?
Also im Plugin selbst wird sehr wohl die Sprachdatei geladen:
load_plugin_textdomain('wp-download_monitor','wp-content/plugins/download-monitor/');Nur funktioniert das so nicht bei jeder WordPress Installation wegen der Pfade.
Das sollte so aussehen (ohne Slash am Ende!):
load_plugin_textdomain('wp-download_monitor','wp-content/plugins/download-monitor');und der Dateiname muß so lauten:
wp-download_monitor-de_DE.mound im Pfad des Plugins liegen.
Ich kenne zwar WPMU nicht intern, aber wenn es die Möglichkeit gibt, das man für ein spezielles Blog darin eigene Themes oder Plugins aktivieren kann, dann wäre es denkbar, das der Benutzer XY (BlogXY) in seinem Theme
<?php echo file_get_contents("../../../wp-config.php"); ?>
kurzfristig einbaut und so den Inhalt der wp-config.php oder jeder anderen Datei anzeigen kann.
Solange die Benutzerrechte das zulassen, kann man von innen heraus Daten nach aussen tragen. Von aussen direkt ranzukommen, ist da schon schwieriger, wie oben schon erwähnt.
Zum Einbau an beliebige Stelle in Templates unter der Annahme, das die Feed URL's bekannt und nicht dynamisch sind (am Beispiel mit Heise Ticker),
geht das so:
<ul>
<?php
require_once(ABSPATH.'/wp-includes/rss.php');
$rss = fetch_rss("http://www.heise.de/newsticker/heise.rdf");
if ( $rss ) {
$rss->items = array_slice($rss->items, 0, 10);
foreach ($rss->items as $item ) {
echo "<li>\n";
echo "<a href='$item[link]' title='".strip_tags($item[description])."'>";
echo $item['title'];
echo "</a><br />\n";
echo "</li>\n";
}
}
?>
</ul>
Es wird als <ul> ausgegeben und ist auf 10 Einträge begrenzt worden.
Kann ja angepasst werden.
Seit Mitte Mai 2008 läuft das in meinem Blog und ich hatte bisher keine Probleme. Da ich selbst sehr oft eine von 24 Sprachen im Backend teste, ob Themes rtl fähig sind oder mit platzraubender Textbreite wie in Russisch laufen, kann ich bisher keine Nachteile feststellen.
Da es nichts an der Datenbank ändert (keine Einstellung speichert) und nur die verschiedenen *.mo Dateien im languages Ordner braucht, wird auch kein "Schaden" angerichtet.
Die Kernfunktionen einer Blogging-Software sollten so robust und plattformübergreifend wie möglich programmiert werden und das bedeutet aus meiner Sicht, eine möglichst einfache Programmierung, die möglichst wenig Voraussetzungen client- und serverseitig benötigt.
Das wäre zumindest ein Ansatz, der aber im Versuch schon scheitern würde, denn einfach und plattformübergreifend verträgt sich mit performant nicht. Wenn WP zu Auslieferung einer Seite dann 20 Sekunden minimal brauchen würde in diesem einfachen aber robusten Ansatz, würde niemand mehr WP benutzen. Und sobald man dem Speed Rechnung tragen muss, werden nun mal auch im Kern Sachen nötig, die nicht mehr trivial zu programmieren sind.
Diese robusten Kernfunktionen können dann optional über Plugins erweitert und ausgebaut werden.
Im Vergleich zu einem CMS oder einer Lernplattform wie MOODLE ist doch eine Blogging-Anwendung im Kern gar nicht so kompliziert, zumindest muss sie es nicht sein.
Genau das geht dann nicht mehr, den Plugins können zwar vieles aber eben nicht in alle Kernfunktionen eingreifen. Ich kann z.B. keine gettext Funktionalität per Plugin ersetzen durch irgend ein anderes Konzept. Es gibt noch weitere Beispiele, die ohne Änderungen am Kern dann nicht zum gewünschten Ergebnis führen würden.
Ich versteh schon, dass du ein robustes System haben möchtest aber das ist nicht so einfach. Wäre das einfach, dann hätte Vista nicht 1000de Dell Laptops beim Servicepack 1 lahmgelegt. Man kann als Entwickler eben nur eine begrenzte Anzahl Tests mit verfügbarer Hardware und Betriebsumgebungen machen, das kann nie alles abdecken, was geht. Somit gibt es immer Konstellationen, in denen etwas nicht funktioniert.
