Beiträge von Ammaletu

    Ähm, also so ganz sicher bin ich nicht, was Du da tust. Aber falls Du das Widgets-Plugin zu installieren versuchst, das ist in neueren WP-Versionen nicht mehr nötig, da schon integriert, und müsste beim Versuch der Aktivierung zu einem Fehler führen (weil die gleichen Funktionen im WP-Core ja schon da sind). Habe ich das jetzt richtig gedeutet?!

    Also, um Widgets nutzen zu können, muss Dein Theme Widgets unterstützen. Wenn es das nicht von sich aus tut, kannst Du es dazu bringen. Sag Bescheid, dann poste ich Details oder einen Link zur offiziellen Doku. Es sind nur einige Zeilen in der functions.php und der sidebar.php zu ergänzen. Welches Theme nutzt Du eigentlich?

    EDIT: Hab es noch schnell rausgesucht. Das ist die offizielle Doku, die eigentlich auch schon alles dazu aussagt: Widgetizing Themes « Automattic

    Ok, ich poste Dir mal eine Lösung, wie ich sie benutzt habe. Da werden innerhalb der list_pages-Funktion auch custom fields ausgegeben. Achtung: Das habe ich für WP 2.3.3 geschrieben. Falls sich die Methoden in neueren WP-Versionen geändert haben, müssten sie theoretisch an diese Änderungen angepasst werden.

    Also, folgendes in die functions.php Deines Themes:

    Das ist die überschriebene Funktion wp_list_pages. Geändert wurde nur der Klassenaufruf unten von Walker_Page zu My_Walker_Page. In der sidebar.php ersetzt Du dann natürlich wp_list_pages() durch my_list_pages(). Argumente bleiben gleich. Und dann natürlich die neue Klasse, welche die alte Klasse erweitert (einfach darunter in die functions.php):

    In diesem Beispiel wird zu jeder Seite ein Custom Field mit einer Bild-URL ausgelesen (falls vorhanden) und statt des Textes verlinkt. Das müsstest Du jetzt nur zu Deinem gewünschten Output anpassen. Und wie gesagt, keine Garantie, dass es mit WP 2.5 noch so funktioniert. ;-)

    Gerade das Update über größere Versionen ist auch nicht ganz ohne, weil sich dann teilweise doch einiges im Innenleben von WP geändert hat. Aber deswegen wird es mit der Zeit auch nicht leichter. Ein Update von einer 2.0er-Version auf 2.3.3 habe ich allerdings vor einigen Wochen relativ reibungslos über die Bühne gebracht. Es kann also auch alles glattgehen. Dabei wird viel wohl von den Plugins abhängen, die Du verwendest. Aber wie gesagt, mit Backups und einem lokalen Test kann man das relativ entspannt angehen. ;-)

    So oder so ist das besser als wenn Dein Blog am Ende gehackt wird und ohne Dein Wissen Spam und Viren verbreitet. Ich kann Dir aus dem Kopf nicht die genaue Version sagen, aber einige ältere WP-Versionen hatten Sicherheitslücken, die sowas ermöglichen und auch immer noch fleißig ausgenutzt werden. :-/

    Ansonsten zu Deinem Problem: Schau mal, ob die Datei search.php in Deinem Theme vorhanden ist. Wenn die da ist, könnte es auch sein, dass die .htaccess-Datei nicht stimmt und deswegen falsch umleitet. Das wären so zwei Sachen, die mir zu der nicht funktionierenden Suche einfallen würden.

    Zu Deinem Problem kann ich Dir nicht wirklich etwas sagen. Aber ich wollte Dir ein Update doch ans Herz legen, da ältere WP-Versionen teilweise Sicherheitslücken enthalten. Außerdem wird es schwieriger, je länger Du wartest und je mehr sich WP dabei verändert.

    Also, WP 2.5 oder 2.3.3 ziehen (noch werden beide Zweige gepflegt und sind - hoffentlich - frei von Sicherheitslücken). Und dann am besten lokal mit XAMPP eine Testinstallation aufsetzen. Das ist in wenigen Minuten gemacht und dann kannst Du das Update in aller Ruhe ausprobieren.

    Zitat

    Vielen Dank, habe ich nun mal eingefügt und auch UTF-8 ist eingetragen, doch leider keine Änderung.

    Würde ich so nicht sagen. Die Stellen, die mir vorher aufgefallen waren, werden jetzt korrekt angezeigt. Die Linkliste in der Sidebar zum Beispiel. Ich habe ein bisschen herumgeklickt, konnte aber keine kaputten Sonderzeichen mehr entdecken. Habe ich was übersehen? Ansonsten denke ich, hat das geholfen. Wenn Du bei Dir noch die alte Ansicht siehst, probiere es mal mit Strg + F5, um den Browsercache zu leeren.

    Ein Template kannst Du nicht zuweisen, aber Du kannst die Unterscheidung natürlich auf anderem Wege machen. Zum Beispiel könntest Du die Angaben bei Posts einer bestimmten Kategorie oder Tag nicht anzeigen. Wenn Du ein Tag dafür nimmst, ist es ja quasi relativ frei zuweisbar.

    Gut. Dann ist die Chance jetzt ziemlich groß, dass es an einem Plugin liegt, denke ich. Du kannst, bevor Du sie alle nach und nach abschaltest, auch mal in allen Plugindateien nach "get_attachment_link" suchen. Ich habe eben zufällig im Trac einen Eintrag gesehen, der diese veraltete Methode erwähnt. Wer weiß, vielleicht nutzt das ja eines Deiner Plugins noch.

    Ich habe jetzt doch noch mal den Thread auf der wp-hackers rausgesucht:
    [wp-hackers] Full size should mean full size

    Als Begründung hat Matt angeführt, damit Usern helfen zu wollen, die Bilder von ihrer Digicam unkonvertiert hochladen (das meinte ich mit DAU *g*). Was IMHO nicht sehr clever ist, da die Bilder dann ja trotzdem 2 MB oder so groß sind und nur vom Browser kleiner dargestellt werden. Und wenn ich heute ein Theme mit 500px Breite nutze und morgen auf ein Theme mit 800px umsteige, steht in älteren Posts die Weite von 500px fest drin. Nicht wirklich durchdacht also...

    Anyway, man kann seine eigene maximale Weite setzen, indem man in der functions.php seines Themes die Variable $content_width definiert (angeblich, ich habe es nicht probiert). So etwa z.B., einfach in die functions.php einfügen, außerhalb einer Funktion:

    PHP
    // set another maximum width for uploaded images
    $content_width = 800;



    Wenn man diesen Unfug nicht haben möchte, kann man da natürlich auch 5000 angeben oder so, dann sollten die Bilder bei Auswahl von "full size" auch immer mit der tatsächlichen Größe eingefügt werden.

    Das Ticket, mit dem das umgesetzt wurde, ist übrigens hier zu finden:
    #5777 (Constrain image size when adding to editor) - WordPress Trac - Trac

    Also ich denke, das wäre mit JavaScript eine Sache weniger Minuten. Genauer gesagt mit der jQuery-Bibliothek. So könnte ich mir das vorstellen:

    Du fügst nach den Feldern die Hinweise an die gewünschte Stelle ein und versiehst die div-Tags mit der Klasse "commentInfo".

    Du definierst im JavaScript-File Deines Themes (wenn Du keines hast, lege es an und binde es in den Header des Themes ein, ggf. auch nur für Einzelansichten) eine jQuery-Methode, die beim Start der Seite ausgeführt wird:

    Code
    /**
     * The following is jQuery functionality that will be executed as soon as the
     * DOM is ready (roughly equal to onload).
     */
    jQuery(function($) {
      // hide comment info on page load
      $(".commentInfo").hide();
      // add event handler on comment form fields
      toggleCommentInfo();
    });



    Das versteckt schon mal beim Laden der Seite die Hinweise. Wer kein JavaScript aktiviert hat, sieht sie gleich.

    Dann fehlen noch die Event Handler an den Formularfeldern. Hier gehe ich davon aus, dass das commentInfo-div mit im p-Tag steht. Ansonsten wäre das hier noch anzupassen.

    Code
    function toggleCommentInfo() {
      $("#comment_form .text_input").click(function() { 
        $(this).parent("p").find(".commentInfo").show("slow");
      });
    }



    Das ist noch nicht sehr ausgefeilt, aber mit der jQuery-Doku kriegst Du das sicher auch selber beendet:
    Main Page - jQuery JavaScript Library

    Der Befehl müsste auch außerhalb des Loops funktionieren, Du kannst dann aber natürlich nicht einfach $id benutzen wie im Loop. Willst Du aber ja auch gar nicht, sondern Du willst ja ein Feld der Unterseite ausgeben. Dessen ID musst Du natürlich kennen. ;-)

    Wie Du das in Deine Navigation integrierst, kann ich Dir jetzt so ohne Infos dazu schlecht sagen. Entweder suchst Du Dir selber die richtige Stelle heraus oder Du postest mal den Code der Navigation, dann kann ich ja mal schauen.

    Deine Seiten werden als UTF-8 ausgeliefert, die Metaangabe fehlt aber und die Umlaute scheinen teilweise als ISO-8859-1 codiert zu sein.

    Zuerst einmal solltest Du die Metaangabe ergänzen. Das hier bitte in der header.php Deines Themes am besten als erste Anweisung nach <head> einfügen:

    PHP
    <meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />



    Das wird möglicherweise das Problem aber noch nicht lösen. Die zweite Frage wäre, ob Du im Backend auch UTF-8 als Codierung eingestellt hast (Einstellungen > Lesen > Zeichensatz für Seiten und Feeds) und was in Deiner wp-config.php für DB_CHARSET und DB_COLLATE steht (falls da etwas steht, es muss auch nicht).

    Wenn das alles stimmt, müsste man im Theme mal schauen, wieso einige Dinge falsch herauskommen. Die Beitragstexte generell scheinen ja zu stimmen, während z.B. in der Linkliste und bei den Titeln statischer Seiten Fehler auftauchen. Wenn Du die entsprechenden Stellen weißt, kannst Du ja auch mal posten, welcher Code das ausgibt.

    Ja, das ist eines von den ganz tollen, neuen Features von WP 2.5. Wieder mal angepasst an den DAU. :-/

    Aber zum Glück kann man das umgehen -- ich kann Dir nur leider gerade nicht sagen wie. Es kann an mir liegen, aber ich finde einfach keine Informationen zu diesem Thema. Aber auf der WP-Hackers-Liste wurde das letztens erwähnt, dass man eine Konstante in seinem Theme setzen muss (glaube ich), welche die maximale Bilderweite enthält. Vielleicht weiß ja jemand anders hier weiter oder hat Zeit, im WP-Hackers-Archiv zu suchen?!

    Wenn ich mich richtig erinnere, werden übrigens nicht die Bilder selber kleiner gemacht, sondern es wird nur im HTML des Postings eine kleinere Weite eingegeben (korrigiert mich falls ich mich irre). In dem Fall müsstest Du alle bisher erstellten Beiträge bearbeiten und die falsche Weite dort ersetzen. Und die Höhe auch, da diese ja sicher ebenfalls verkleinert wurde!?

    Ich denke, dafür brauchst Du das Plugin gar nicht. Soweit ich weiß vereinfacht es ja auch nur den Zugriff auf die Custom-Fields ein wenig, aber man kann das auch mit WP-Bordmitteln ganz gut bewerkstelligen.

    In meinem Theme greife ich auf die Felder z.B. so zu:

    PHP
    echo get_post_meta($id, 'mein-gewaehlter-feldname', true);



    Die Variable $id ist dabei die ID des Postings, in Deinem Fall müsstest Du da die ID der Unterseite reinreichen. Dann halt den Feldnamen und true, wenn Du nur einen Wert erwartest (bei false kommt ein Array zurück).

    Da wirst Du uns ein paar Infos zur Homepage geben müssen, vor allem, wie sie umgesetzt ist. Nutzt Du ein CMS und wenn ja welches? In den meisten CMS müsste man den RSS-Feed Deines Blogs eigentlich einbinden können, so wie das ja auch in WordPress mit dem RSS-Widget möglich ist.