Beiträge von Ammaletu

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.

Was ist da denn nun genau durcheinander?! Dass das eine Posting doppelt erscheint? Dafür müsste man mal den Code sehen, der die Iteration macht.

Die statische Seite, welche per Plugin auf die Kategorie verweist, hat also Unterseiten, die in der Sidebar angezeigt werden sollten? Sind das auch Verweise auf Kategorien oder andere Inhalte?! Da das Plugin ja nur den Link entsprechend umbiegt, weiß WordPress beim Aufruf der Kategorienseite nichts mehr von den statischen Seiten und kann sie also auch nicht anzeigen. Wenn es um Unterkategorien geht, kann man da aber natürlich eine ähnliche Konstruktion in die Sidebar einbinden, welche für Kategorien die Unterkategorien anzeigt, analog zu den Seiten.

Leg Dir mal ein Tool wie Firebug oder die Web Developer Toolbar (beide für Firefox) zu, damit findet sich sowas ganz leicht.

Die Klasse, an der der graue Rahmen um die Beiträge hängt, heißt "post-alt". Probier es mal damit.

Gehen denn sonst Permalinks in dem privaten Blog? Probier mal den normalen Link stattdessen. Ähm... index.php?feed=rss oder so ähnlich. Der sollte immer gehen.

P.S.: Zur Ursache: Du sagst ja in der .htaccess des oberen Blogs, dass alle Anfragen, die nicht auf eine physisch existente Datei gehen, auf die index.php des oberen Blogs geleitete werden. Deshalb dürften Permalinks beim unteren Blog eigentlich nicht gehen, es sei denn, Du würdest dessen Permalink-Angaben in die .htaccess des oberen Blogs übernehmen (an den Anfang!). Oder eben beim privaten Blog ohne Permalinks arbeiten, dann sollte es auch gehen, da es dann ja immer auf die innere index.php geht.

Der FeedBurner-Feed enthält überhaupt kein Datum für die Einträge. Wie das passieren kann, weiß ich aber auch nicht. Du könntest ja mal das Plugin kurz abschalten und Dir den Original-Feed anschauen (der leitet im Moment immer weiter auf FeedBurner). Im Vergleich mit einem beliebigen funktionierenden RSS-Feed siehst Du, dass da einige Felder pro Item-Element fehlen (pubDate).

Das Theme verwendet mit Cufon offenbar eine JavaScript-basierte Methode, die Überschriften mit einer anderen Schriftart aufzuhübschen. Woran Dein Problem nun genau liegt, kann ich Dir nicht sagen. Es kann aber sein, dass beim Erstellen der Scripte der Themeautor einfach die entsprechenden Zeichen nicht mit ausgewählt hat. Siehe:
http://cufon.shoqolate.com/generate/

Eventuell könntest Du Dir damit eine neue Schriftdatei erstellen und die im Theme enthaltene ersetzen. Ich hab mir das aber nun auch nicht zu genau angeschaut, das müsstest Du mal ausknobeln. Laut Cufon-Webseite sollte es jedenfalls eigentlich funktionieren, wenn die Seite in UTF-8 ist.

Zitat

schau mal, nun habe ich eine statische "home" seite, und in der Unterseite Rallye Vltava Blog wird nun der Artikel angezeigt...jetzt würde ich nur gerne wissen wie ich den Begrüßungstext auf der Artikelseite wegbekomme und den eigentlichen wieder dort hin?

Ich bin nicht sicher, dass der jetzige Stand schon das ist, was Du möchtest. Du hast aktuell eine Startseite, die die letzten Postings anzeigt, so wie es die Standard-Startseite auch tut. So deute ich den Output jedenfalls mal. Was Du möchtest, ist den Begrüßungstext einfach auf die statische Seite schreiben und dann diese Seite in den Optionen wie beschrieben als Startseite auswählen (nicht als Artikelseite). Oder?!

Davon abgesehen hast Du noch ein Permalink-Problem. Offenbar ist in den Einstellungen eine andere Adresse eingetragen, so dass alle Links in der Sidebar dorthin führen und die Links zur Ansicht des Artikels nicht funktionieren.

Je mehr ich drüber nachdenke, desto weniger gefällt mir die ganze Idee. Überleg mal: Wenn Du die Einzelansicht der Beiträge im iFranme öffnest, musst Du das logischerweise ohne das ganze drumherum (Header, Footer, Sidebar) tun. Wenn nun jemand per Google auf der Seite landet, kommt er von da nirgends hin. Natürlich kannst Du das irgendwie per Parameter an der URL regeln, ob der ganze Seitenrahmen angezeigt wird oder nicht. Musst Du eigentlich sogar, denn unter den Beiträgen sind ja vermutlich die Kategorien und Tags verlinkt... Ist alles in allem natürlich machbar, aber Du musst schon so einiges bedenken. Und das alles für den zweifelhaften Effekt, Deine Besucher mit Musik zu beglücken?! Ich bin sicher nicht der einzige, der das als Belästigung empfindet.

Ich würde Dir raten, die Musik per PopUp einzubinden. Wer sie wirklich hören möchte (falls Du sagen wir mal die Website für eine Band gestaltest, die ihre Musik online stellen möchte), kann das anklicken, und alle anderen haben ihre Ruhe.

Andernfalls musst Du Dir genau überlegen, welche Seiten Du im iFrame öffnen möchtest und welche als neue Seite, was beim direkten Aufruf dieser Seiten passiert und an welchen Stellen Du alles Links modifizieren musst. Ein Beispiel zum Verändern des Outputs der Widgets per Filter kann ich Dir dann vermutlich aus meinem eigenen Theme raussuchen.

Tja, die nächsten Standard-Schritte wären eigentlich, Themes und Plugins zu prüfen. Also mal auf Default-Theme umschalten (Widget dann wohl in Sidebar statt Header packen) und schauen, ob es da geht. Wenn nicht, mal testweise alle Plugins deaktivieren (z.B. Plugin-Ordner per FTP kurz umbenennen, dann aber nicht die Backend-Pluginseite aufrufen währenddessen).

Habe den Feed übrigens gerade mal in meinem Testblog mit dem Default-Theme getestet, und da gehen die Umlaute.

Ja gut, dann wirst Du das so machen müssen. Hm... Also zum einen könntest Du per jQuery sehr simpel das target-Attribut an allen internen Links ergänzen. Das hilft dann allerdings den Besuchern ohne JavaScript nicht weiter. Also wirst Du wohl die Ausgaben der Widgets filtern müssen und das Attribut dort überall ergänzen. Ist machbar, aber je nach Anzahl der Widgets etwas aufwändiger. Kennst Du Dich grundlegend mit WP-Filtern aus?