Beiträge von Ammaletu

    In dem Fall führen viele Wege nach Rom. Sorry wenn ich da schon gleich wieder zu kompliziert gedacht habe. ;-)

    Seitentemplate geht natürlich genauso und dann da oben eine Variable setzen und die in der header.php auswerten statt des benutzerdefinierten Feldes. Oder wie alchymyth vorschlägt einfach immer Klassen passend zum Slug vergeben und die in den Stylesheets ansprechen. Kommt immer etwas auf den Einsatzzweck an, aber letzteres ist vielleicht mit die schönste Lösung. Mit IDs würde ich eher nicht rumhantieren. Macht sich schlecht wenn man parallel ein Testsystem hat, dann muss man da die IDs immer noch synchron halten.

    Zitat

    Ich habe jetzt allen Seiten, die A als Header benutzen sollen ein Benutzerdefiniertes Feld zugewiesen. Ab da wird es etwas undurchsichtig für mich. Könntest du da etwas ausfürhlicher werden.

    Gerne. Hatte gestern nicht so die Zeit, das ausführlicher aufzuschreiben.

    Ok, also folgendes kommt oben in die header.php des Themes, in einen PHP-Block. Hm... Was hast Du denn als Feldwert gesetzt? Wenn es ein Feld ist, das nur per true/false anzeigt, dass die Seite den anderen Header kriegen soll, dann müsste das so aussehen (korrekten Feldnamen ersetzen und CSS-Klassenname!):

    PHP
    $my_header_class = '';
    if (is_page()) {
      $my_has_custom_header = get_post_meta($id, 'FELDNAME', true);
      $my_header_class = ($my_has_custom_header == 'true') ? 'CSS-KLASSENNAME' : '';
    }

    Wenn Du da direkt den Klassennamen reingeschrieben hast (um z.B. auch verschiedene Header zu ermöglichen), dann so (ebenfalls Feldname ersetzen!):

    PHP
    $my_header_class = '';
    if (is_page()) {
      $my_header_class = get_post_meta($id, 'FELDNAME', true);
    }

    Was Du mit dem Klassennamen jetzt anstellst, kommt drauf an, wie genau der aktuelle Header aufgebaut ist. Im Default-Theme könnte man das z.B. so einbauen:

    PHP
    <div id="header" class="<?php print $my_header_class; ?>">
        <div id="headerimg">
            <h1><a rel="nofollow" href="<?php echo get_option('home'); ?>/"><?php bloginfo('name'); ?></a></h1>
            <div class="description"><?php bloginfo('description'); ?></div>
        </div>
    </div>

    Und dann muss das in der style.css natürlich noch eingetragen werden. Auch das kommt drauf an, wie es aktuell umgesetzt ist, sollte sich aber finden lassen. Wenn z.B. aktuell eine Angabe für "#header ..." im Stylesheet steht, schreibst Du einfach darunter "#header.CSS-KLASSENNAME ..." und kannst darin dann ändern, ergänzen und überschreiben was Du magst (ohne die Anführungsstriche natürlich und mit dem oben vergebenen Klassennamen).

    Wenn es nur eine Kategorie pro Nutzer sein soll, da gab es auf jeden Fall ein Plugin dafür. Das nimmt dem Autor quasi die Kategoieauswahl weg, man kann dem Nutzer dann eine Kategorie fest zuweisen. Wenn Du es gefunden hast, müsstest Du mit dem Pluginnamen hier im Forum mal nach einem Fix schauen, da es so wie es im Repository steht mit neueren WPs nicht mehr lief. (Sorry, bin gerade in Eile und komme nicht auf den Namen. Sag Bescheid, falls Du es nicht findest, dann schaue ich noch mal.)

    Das kannst Du mit einer kleinen Modifikation am Theme recht leicht umsetzen. Kennst Du Dich denn ein wenig mit PHP aus?

    Grundsätzlich würde ich sagen gibst Du den Seiten, die Header A kriegen sollen, ein benutzerdefiniertes Feld, meinetwegen "headerA=true" oder so. In der header.php prüfst Du dann auf is_page und wenn ja, dann prüfst Du, ob das Feld gesetzt ist. Falls ja, kriegt die Seite eine andere Header-Klasse, welche dann per CSS ein anderes Bild oder sonstiges Aussehen kriegt. Für die Startseite kann das fest im Theme umgesetzt werden: In der header.php prüfen auf is_home (hm, es gab verschiedene, mindestens is_home und is_start_page, Du müsstest mal im Codex nachschlagen welches davon für Dich die richtige Abfrage ist).

    Probier mal wie folgt. Wenn es das noch nicht war, bräuchte ich einen Link zur Seite, dann klärt sich das ohne Raten viel schneller. ;-)

    Im Moment rate ich mal, dass die äußere Liste die Widgets enthält und dass .page-item an den Links direkt dran hängt. Der Code muss am besten ans Ende des Stylesheets. Farbnamen natürlich ersetzen durch den gewünschten Farbcode, aber so sollte man es erst mal sehen.

    Ich hab mir jetzt nur mal die Online-Demo angeschaut. Mögliche Fehlerquellen, die mir auffallen:

    - Liegen die JS-Dateien im richtigen Ordner (absolute Angabe des Ordners ist besser als nur Unterordner "scripts")? Zeigt der Browser JS-Fehler an?
    - Hat das textarea einen Style overflow: auto? Siehe Beschreibung des Plugins: "jScrollPane is a jquery plugin which allows you to replace the browsers default vertical scrollbars on any block level element with an overflow:auto style."

    ...

    Ok, ich war neugierig und hab mir die Datei doch mal angeschaut. Wie es aussieht scheint das Plugin nicht für Formularelemente geeignet zu sein. Ich hab Dein Beispiel mal berichtigt (eindeutige ID vergeben) und es auch mit obverflow: auto probiert, aber dann konnte man in dem Textarea gar nicht mehr scrollen.

    Andererseits: Im Textarea kannst Du doch sowieso schon scrollen. Geht es Dir nur um die Gestaltung? Ich glaube, an der kannst Du nicht wirklich etwas ändern, es sei denn, Du verwendest IE-spezifische CSS-Befehle. Die versteht dann aber kein anderer Browser, und ich bin auch nicht sicher, ob es das in IE8 noch gibt.

    Dazu brauchst Du am Plugin nichts ändern, es sollte eine Anpassung im Stylesheet reichen. Finde erst mal raus, wo denn die Linkfarbe im Moment definiert ist in Deinem Stylesheet. Tools wie die Web Developer Toolbar oder Firebug helfen da sehr. Danach musst Du das eigentlich nur noch für die jeweils darunterliegenden Ebenen definieren.

    Allgemeines Beispiel: Wenn das Menü im Moment mit #nav li a definiert ist, kannst Du mit #nav li > ul > li a die zweite Ebene und mit #nav li > ul > li > ul > li a die dritte Ebene ansprechen.

    Liegt das daran, dass nur bei manchen Seiten der Browser eine Scrollleiste einblendet? Dann einafch im Stylesheet angeben:

    Code
    body {
      width: 101%;
    }

    Dann sollte die Scrollleiste immer zu sehen sein und entsprechend der Inhalt nicht mehr hin- und herspringen.

    Du kannst Widgets einsetzen, wo Du möchtest. Es heißt zwar meistens "Sidebar", aber treffender wäre "Widget-Bereich". Binde also einfach einen Widget-Bereich im Footer ein. Ich habe den Code gerade nicht zur Hand, aber wie sich benannte Widgetbereiche in der functions.php definieren lassen, sollte sich ergoogeln lassen. Genauso wie Du den Bereich in der footer.php aufrufst.

    Zur Positionierung: Du kannst den Widgets z.B. eine feste Weite geben und sie dann links floaten (float: left; width: 123px;). Oder Du setzt sie auf 25% Weite, wenn Dein Theme eine flexible Weite hat. Das alles gehört mit der ID oder Klasse des neuen Widgetbereichs versehen ins Stylesheet.

    Tja, das kann ja vermutlich auch von anderen Zeichen ausgelöst werden. Die Frage ist einfach, ob hier tatsächlich ein XML-Parser zum Parsen eines HTML-Textes benutzt wird, was so nicht korrekt wäre. Hast Du mal geschaut, was da genau passiert und ob andere Nutzer des Plugins ähnliche Probleme haben? Ohne einen Blick in den Quelltext des Plugins zu werfen, kann ich da sonst nicht viel mehr zu sagen, fürchte ich.

    Zitat

    The following code runs when the document is ready and finds any element with a class of "scroll-pane" and then calls jScrollPane on them.

    Hast Du denn dann nicht nur dem Textarea die Klasse gegeben, sondern den erwähnten Code auch irgendwo im Header oder in einer eigenen JS-Datei eingebunden?

    Die Sprache stellst Du in der wp-config.phop ein, da wo jetzt "de_DE" definiert ist. Das müsste dann vermutlich "es_ES" lauten. Dazu brauchst Du natürlich die spanischen Sprachdateien, die per FTP auf dem Server in den richtigen Ordner gehören. Fürs Frontend muss dann noch das entsprechende Theme ebenfalls eine spanische Sprachdatei bekommen oder direkt in Spanisch beschriftet sein.

    Rufst Du das über eine Stand-Alone-Installation auf oder über das MultipleIE-Tool? Bei letzterem kann es sein, dass die Conditional Comments nicht gehen. Ich erinnere mich dunkel, dass da was war.

    Davon abgesehen: Lohnt sich das noch? Sind IE6-Benutzer als Zielgruppe für Deine Seite wichtig? Oder reicht es vielleicht, das Script von http://browserupdate.org/ einzubinden?

    Zitat

    Vermutlich wurde die Datei mit ANSi Textformat, anstelle von utf-8 abgespeichert, doch ob so etwas auch Auswirkung auf die Funktionalität haben kann, vermag ich leider auch nicht so zu beantworten.

    Ja, hätte es, wenn die DB-Daten ein Nicht-ASCII-Zeichen enthalten würden, also z.B. einen Umlaut im Passwort oder so.

    Du kannst ansonsten natürlich mal den technischen Support Deines Hosters fragen. Es ist aber fast sicher, dass irgendetwas an den DB-Daten nicht stimmt. Einzige andere Idee, die mir noch einfällt: Es handelt sich aber um eine aktuelle MySQL-Version, oder? Nicht dass das eine uralte MySQL-Version ist, die WP nicht mehr unterstützt.

    Über Fragen dieser Art sollten ansonsten die hoffentlich schon vorhandenen Release Notes Aufschluss geben. In jedem Fall vorher ein Backup machen (Dateien und vor allem Datenbank) und ggf. das ganze mal lieber zuerst an einem lokalen Testsystem ausprobieren.