Beiträge von Ammaletu

Hm, mit obigem Code überschreibst Du ja die Default-Query der Seite. Hast Du das vielleicht vorher schon mal gemacht, im Header oder so? Dann würde sich $post nicht mehr auf die aktuelle Seite beziehen sondern auf einen anderen Beitrag und es wird entsprechend nichts gefunden. Besser ist es in jedem Fall, die Original-Query und die $post-Variable nicht dauerhaft zu überschreiben.

Melde es bitte dem Themeautor, falls das keine Modifikation von Dir war. Dann müssen nicht andere Nutzer auch rätseln. ;-)

Interessant, die Autoreninfos werden offenbar als ISO-Zeichen im UTF-8-Text ausgegeben. Tja, wo setzt man da an? Zuerst mal schauen, dass die Datenbank aktuell auf jeden Fall UTF-8 ist und das auch so ausgelesen wird (wp-config.php). Dann vielleicht mal einen aktuellen Dump ziehen und die Zeichen darin reparieren? Zum Beispiel mal nach "Andreas M" suchen und schauen, was da für ein Zeichen statt des "ü" steht. Damit dann Suchen und Ersetzen im ganzen DB-Dump. Den Dump am Ende wieder in die DB einspielen. Und bei all dem natürlich Backups von allen Schritten aufheben bis das ganze behoben ist.

Also wenn ich mir das so von außen anschaue, sieht es doch alles korrekt aus. Die Seite wird als UTF-8 dargestellt und alle Umlaute stimmen. Was kaputt ist, sind die Anführungszeichen, allerdings sollten die nicht in der DB stehen sondern bei der Anzeige per Filter ergänzt werden. Im Editor im Backend müsste das also richtig als die normalen, geraden Anführungszeichen angezeigt werden. Hier müsstest Du vielleicht mal schauen, welche WP-Datei diese Ersetzung vornimmt (Funktion texturize?!) und ob diese Datei eventuell falsch abgespeichert ist (ISO statt UTF-8).

Alternativ könntest Du auch probieren, ob ein Plugin wie InTypo oder WP-Typography eine Verbesserung bringt.

Und generell wann immer möglich mit UTF-8 arbeiten statt ISO, das spart auf lange Sicht viel Ärger. Also auch nicht jetzt auf ISO zurückstellen, dann lieber das zugrundeliegende Problem lösen. ;-)

Das kann an allem möglichen liegen, aber zuerst mal würde ich sicherstellen, dass es kein Themeproblem ist. Zum einen kannst Du uns die relevanten Codestellen Deines Themes (welches?) posten, welche das Datum an den Kommentaren ausgeben. Du könntest auch mal kurz testweise aufs Default-Theme umschalten und schauen, ob der Fehler dort auch auftritt. Falls ja, liegt es wohl doch eher an einem Plugin, andernfalls wird es wohl Dein Theme sein.

Nutzt Du Avira? Dann ist das wohl ein Fehlalarm. Das wird aktuell gerade auf der wp-hackers-Liste diskutiert. Prüfe die Datei ggf. noch mit anderen Virencheckern (z.B. über http://www.virustotal.com/de/). Aber wenn Das AV-Programm die unverändert aus dem Download übernommene Datei anmeckert, ist es mit ziemlicher Sicherheit ein Fehlalarm, denn WP prüft die Downloads natürlich, ehe sie auf den Server kommen.

P.S.: Meine Güte, alle gleichzeitig. ;-) Wenn dazu konkrete Infos verfügbar sind, wäre das ggf. einen WPD-Blog-Eintrag wert?

Klappt denn das Auslesen des Kategorienamens? Gib doch mal $listCategory aus, ehe Du die Query startest.

Belies Dich erstmal, was ein Seitentemplate (<-- Klick) ist und wie Du das der statischen Seite zuweisen kannst. ;-)

Hm, ok, habe das Script noch etwas erweitert:

<?php global $notfound; ?>
            <?php /* Creates a menu for pages beneath the level of the current page */
            if (($notfound != '1') && (is_page() || is_category() || is_single())) {
              if (is_page()) {
                // static page
                $current_page = $post->ID;
              } else if (is_single()) {
                // single view
                $my_categories = get_the_category();
                if (!empty($my_categories)) {
                  $my_cat_title = $my_categories[0]->name;
                }
              } else {
                // category
                $my_cat_title = single_cat_title('', false);
              }
              if (!empty($my_cat_title)) {
                $page_query = $wpdb->get_row("SELECT ID, post_title, post_status, post_parent FROM $wpdb->posts WHERE post_title like '" . $wpdb->escape($my_cat_title) . "'");
                if (!empty($page_query)) {
                  $current_page = $page_query->ID;
                }
              }
              while ($current_page) {
                $page_query = $wpdb->get_row("SELECT ID, post_title, post_status, post_parent FROM $wpdb->posts WHERE ID = '" . $wpdb->escape($current_page) . "'");
                $current_page = $page_query->post_parent;
              }
              if (!empty($page_query)) {
                $parent_id = $page_query->ID;
                $parent_title = $page_query->post_title;
                if ($wpdb->get_results("SELECT * FROM $wpdb->posts WHERE post_parent = '" . $wpdb->escape($parent_id) . "' AND post_status != 'inherit'")) { ?>
            <ul class="nav">
              <?php wp_list_pages('sort_column=menu_order&title_li=&child_of='. $parent_id); ?>
            </ul>
        <?php   }
              }
            } ?>

Das funktioniert nur, wenn die gewünschte Kategorie die erste Kategorie ist, die an dem Beitrag hängt, wobei ich nicht sicher bin, in welcher Reihenfolge WordPress das zurückgibt. Im Zweifelsfall funktioniert es also nicht, wenn der Beitrag zwei Kategorien hat.

Hast Du eine statische Seite als Startseite und willst jetzt nur eine weitere Seite, wo die bekannte Ansicht aller Beiträge chronologisch sortiert sichtbar ist (also das, was per Default die Blog-Starteite ist)? Dann kannst Du das einfach im Backend einstellen: Leere statische Seite anlegen und unter Einstellungen > Lesen > Startseite > Artikelseite auswählen. Auf dieser werden dann die aktuellsten Beiträge angezeigt.

Wenn Du das selber machen willst, kannst Du aber auch einer statischen Seite ein Template geben und dort dann z.B. nur die letzten x Beiträge ausgeben ohne die Möglichkeit, weiter zurückzugehen. Dafür bräuchtest Du dann ein Seitentemplate und einen eigenen Loop. Anleitungen gibt es viele, z.B. hier: http://www.texto.de/weiterblaetter…er-sidebar-621/

Und hier mit Beiträgen einer Kategorie:
http://faq.wordpress-deutschland.org/artikel-der-ka…ite-y-anzeigen/

Hm, wie äußert sich Dein Problem denn? Ich gebe in meinem Theme den Suchbegriff einfach so aus:

echo '<p>Für die Suche nach &quot;'; the_search_query(); echo '&quot; wurden die folgenden ' . $wp_query->found_posts . ' Beiträge gefunden.</p>';

Weiter habe ich daran nichts überschrieben. Und wenn ich z.B. nach "<b>Hallo</b>" suche, wird das so auch wieder ausgegeben und nicht als fettes Hallo. Ist das als Testcase zu einfach? Poste mal ein Beispiel, was durchrutscht. Welche Version nutzt Du eigentlich? Obiges ist unter WP 2.8 getestet.

Zitat

Also liefert Wordpress offenbar immer im rss Format und nicht im rss2-Format.

Nein, wie Du selber geschrieben hast, ist es ja im RSS2-Feed korrekt. Du nutzt keine Permalinks, aber auch dann sollte RSS2 Standard sein, nicht RSS. So ist es oben rechts auf der Seite ja auch verlinkt. Ob das Datum im älteren RSS-Format vorgesehen war, weiß ich nicht genau, das ist aber eh nicht mehr aktuell.

Wieso FeedBurner damit nun Probleme hat, weiß ich nicht so genau. Kann sein, dass es sich einfach nach der Angabe des älteren Feedformats den Feed doch noch gemerkt hat. Hast Du nach der Umstellung auf RSS2 oder Atom im FeedBurner-Backend mal versuchsweise einen neuen Beitrag geschrieben? Das sollte FeedBurner ja auf jeden Fall dazu bewegen, den Feed neu einzulesen.

Innerhalb von WordPress sollte das eigentlich alles richtig behandelt werden. Bleibt die Ausgabe des Suchbegriffs im Theme, das muss im Theme korrekt gemacht werden. Im neuen Twentyten sieht das so aus (kann aber sein dass es die Funktion erst ab WP 3.0 gibt):

<?php the_search_query(); ?>

Und im älteren Default-Theme wird z.B. das Suchformular über get_search_form() eingebunden, welches den Suchbegriff so ausgibt:

<?php print esc_attr(apply_filters('the_search_query', get_search_query())); ?>

Hilft Dir das weiter?!

Würde es Dir ansonsten helfen, einfach alle Kategorien (ggf. mit einigen ausgeschlossenen) ans Ende der Liste der statischen Seite auszugeben? Das habe ich für eines meiner Blogs mal geschrieben. Lässt sich mit ein paar Zeilen in der functions.php machen und ist für den Nutzer von außen ja nicht direkt ersichtlich, ob es sich um eine Seite oder eine Kategorie handelt. Nur bunt zusammensortieren geht damit nicht, die Kategorien wären dann sortiert, z.B. alphabetisch nach Name.

Du meinst vermutlich nicht Seite sondern Seiten-Template, nehme ich an. Seiten selber kannst Du ja im Backend unkompliziert anlegen. Welche Theme-Dateien Dir zur Verfügung stehen (falls in Deinem Theme nicht vorhanden einfach als Kopie der in der Hierarchie als nächstes kommenden Datei anlegen), kannst Du hier sehen:
http://codex.wordpress.org/images/1/18/Template_Hierarchy.png

Und dann kannst Du natürlich einzelnen statischen Seiten Seiten-Templates zuweisen. Dazu sollte sich per Google, Forensuche oder im Codex genug finden lassen.

Bambaataa hat "sichern" im Sinne von "absichern" interpretiert. Für Dein aktuelles Problem kannst Du das also erst mal ignorieren, auch wenn die Hinweise generell natürlich richtig sind.

WP merkt, dass es installiert ist, wenn es die Datenbank mit den entsprechenden Inhalten findet. Da das bei Dir offenbar nicht klappt, solltest Du zuerst mal prüfen, dass die DB am Ziel tatsächlich korrekt importiert wurde und dass die Daten in der wp-config.php stimmen.

Hat sich bei dem Umzug ansonsten die Domain oder der Pfad auf dem Server verändert? Und wenn ja, hast Du das vor dem Import im DB-Dump korrigiert?

Ok, also iFrame. Ich will Dir das ja auch nicht ausreden, automatisch startende Musik ist für mich persönlich allerdings die sicherste Methode mich binnen Sekunden zum Verlassen einer Webseite zu bewegen. ;-) Beispiele anderer Musiker, an die ich mich so erinnern kann, waren entweder als PopUp gemacht oder eben nur auf einer Seite eingebunden, dann konnte man eben nicht rumsurfen beim Musik hören. PopUp hat ja auch den Vorteil, dass man das einfach offen lassen kann im eigenen Fenster während man woanders hinsurft. PopUp-Blocker sollten PopUps, die sich auf ausdrücklichen Klick des Nutzers öffnen, ja eigentlich auch in Ruhe lassen.

Ähm... Ok, also modifizieren der Links in der Sidebar:

/**
 * Customize the output of functions like wp_list_pages by adding a target
 * attribute to all links.
 * 
 * @param output The HTML code for a link list.
 * @return The modified output.
 */
function my_add_target_to links($output) {
  return str_replace('<a ', '<a target="_blank" ', $output);
}


// add the target attribute to all links
add_filter('wp_list_pages', 'my_add_target_to links');

Ist doch einfacher als ich es im Gedächtnis hatte, habe es allerdings jetzt nicht laufen lassen. "_blank" musst Du natürlich durch den Namen des iFrames ersetzen. Und dann den Filter für alle Methoden aufrufen, die von Widgets in der Sidebar verwendet werden. Die Lösung ist relativ simpel und setzt voraus, dass die Links noch kein Target-Attribut enthalten; sollten sie normalerweise aber auch nicht.

Der nächste Schritt wäre dann, alle Theme-Dateien so zu modifizieren, dass der Seitenrahmen nicht angezeigt wird, wenn ein bestimmter Parameter mitgegeben wird. Der dann natürlich erst mal mitgegeben werden muss...

Sorry, hatte Deine Antwort nicht gesehen. Wir haben das wohl halbwegs gleichzeitig getippt. post-alt ist die Klasse, die mir die Web-Developer-Toolbar beim Drüberhalten ausspuckte, deswegen dachte ich, da passt es am besten hin. Habe es jetzt aber nicht mit Firebug ausprobiert. Kann ja auch an beiden Stellen gehen. ;-)

Ich hab Dir mal was zusammengehackt. Ich habe es mal schnell in meinem Testblog eingebunden und da lief es. Wer hätte es gedacht, heute auch mal ohne zu viele Flüchtigkeitsfehler. ;-)

Ok, also:

<?php global $notfound; ?>
            <?php /* Creates a menu for pages beneath the level of the current page */
            if ((is_page() or is_category()) and ($notfound != '1')) {
              if (is_page()) {
                $current_page = $post->ID;
              } else {
                $my_cat_title = single_cat_title('', false);
                $page_query = $wpdb->get_row("SELECT ID, post_title, post_status, post_parent FROM $wpdb->posts WHERE post_title like '" . $wpdb->escape($my_cat_title) . "'");
                if (!empty($page_query)) {
                  $current_page = $page_query->ID;
                }
              }
              while ($current_page) {
                $page_query = $wpdb->get_row("SELECT ID, post_title, post_status, post_parent FROM $wpdb->posts WHERE ID = '" . $wpdb->escape($current_page) . "'");
                $current_page = $page_query->post_parent;
              }
              if (!empty($page_query)) {
                $parent_id = $page_query->ID;
                $parent_title = $page_query->post_title;
                if ($wpdb->get_results("SELECT * FROM $wpdb->posts WHERE post_parent = '" . $wpdb->escape($parent_id) . "' AND post_status != 'inherit'")) { ?>
            <ul class="nav">
              <?php wp_list_pages('sort_column=menu_order&title_li=&child_of='. $parent_id); ?>
            </ul>
        <?php   }
              }
            } ?>

Für Kategorien wird hier nach einer Seite mit dem gleichen Namen gesucht. Die statische Seite muss also genau gleich wie die Kategorie heißen und der Seitentitel muss eindeutig sein. Ich hoffe, das reicht Dir; wenn nicht,müsste man das noch etwas schlauer machen und schauen, wie genau das Plugin die Verlink8ung herstellt.

Und ja, ich hoffe, dass sowas mit dem neuen Menüsystem, das ab WP 3.0 kommt, dann mal endlich einfacher wird... ;-)

Zwei Sachen fallen mir beim Draufschauen noch auf. Zum einen der Tippfehler:

the_cateory()

Und zum anderen: Muss das nicht jeweils get_the_* heißen? the_category gibt die Kategorie aus, get_the_category gibt sie zurück, so dass Du sie einer Variablen zuweisen kannst. Keine Ahnung, ob das nun schon die Ursache ist, aber behebe das ruhig erstmal.