Seit WordPress 3 ist es möglich, Excerpts auch für Seiten zu aktivieren; dazu muss die functions.php um folgende Zeile erweitert werden:

add_post_type_support( 'page', 'excerpt' );

Das Erstellen von Auto-Excerpts funktioniert damit jedoch nicht, die Texte müssen also jeweils von Hand eingetragen werden.

Im Theme kann jetzt die Ausgabe eingebaut werden (dabei wird die Größe des Post-Thumbnails mit 100×100 Pixel angegeben):


$pages = get_pages('child_of=ID-DER-ELTERN-SEITE&sort_column=post_title&sort_order=asc');
$count = 0;
foreach($pages as $page)
{
$excerpt = $page->post_excerpt;
if(!$excerpt)
continue;
$excerpt = apply_filters('the_excerpt', $excerpt);
echo $page->post_title;
echo get_the_post_thumbnail($page->ID, array(100,100));
echo $excerpt
}


• archive-[Custom Content Type Name].php
• taxonomy-[Custom Content Type Taxonomy Name].php
• …

Auch auf diesen Seiten greift jedoch die in den Einstellungen festgelegte Anzahl der Beiträge pro Seite. Dies kann auf folgende Weise angepasst werden:

archive-[Custom Content Type Name].php
Einfügen vor dem Loop setzt die Anzahl der gelisteten Beiträge auf 1000 (dabei ist zu beachten, dass der Name des Custom Post Types eingetragen werden muss):
<?php global $wp_query;
$wp_query = new WP_Query("post_type=[Custom Content Type Taxonomy Name]&post_status=publish&posts_per_page=1000"); ?>

taxonomy-[Custom Content Type Taxonomy Name].php
Einfügen vor dem Loop setzt die Anzahl der gelisteten Beiträge auf 1000:
<?php $current_query = $wp_query->query_vars;
query_posts( array( $current_query['taxonomy'] => $current_query['term'], 'showposts' => 1000 ) ); ?>

//Conditional Tags für Custom Taxonomy
function taxonomy_map($tax, $term, $_post = NULL) {
if ( !$tax || !$term ) { return FALSE; }
if ( $_post ) {
$_post = get_post( $_post );
} else {
$_post =& $GLOBALS['post'];
}
if ( !$_post ) { return FALSE; }
$return = is_object_in_term( $_post->ID, $tax, $term );
if ( is_wp_error( $return ) ) { return FALSE; }
return $return;
}

Im Theme wird die Abfrage so eingebaut:

<?php
if (taxonomy_map('ort', 'ortsname-1')) {
echo "Anfahrt Ortsname 1";
}
elseif (taxonomy_map('ort', 'ortsname-2')) {
echo "Anfahrt Ortsname 2";
}
else {
}
?>

In diesem Fall wurde innherhalb der Taxonomy “Ort” überprüft ob der Post Ortsname-1 oder Ortsname-2 zugeordnet wurde; hier im Beispiel wird dann lediglich Text ausgegeben, in der Umsetzung wird je eine Datei mit der entsprechenden Wegbeschreibung inkludiert.

Genau diese Lösung wurde aber benötigt, um eine sich selbst aktualisierende Liste von Beiträgen auf einer Seite darzustellen; etwas Recherche brachte mich zu einem interessanten Lösungsansatz: hier wird eine Liste von Tags erstellt und gleichzeitig mit den aktuellsten Artikeln die mit dem jeweiligen Schlagwort versehen wurden ausgegeben (das Ganze MUSS außerhalb des Loops im Template platziert werden):

<?php
$noOfTags = 10;
$noOfPosts = 4;
$cloudRight = get_tags("orderby=count&order=DESC&number=$noOfTags");
foreach((array)$cloudRight as $tagRight) : ?>
<?php
$postsRight = new WP_Query();
$postsRight->query("tag={$tagRight->slug}&showposts=$noOfPosts"); ?>
<?php if ( $postsRight->have_posts() ) :?>
<dl>
<dt><?php echo $tagRight->name ?></dt>
<?php while ( $postsRight->have_posts() ) : $postsRight->the_post(); ?>
<dd><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title_attribute(); ?>"><?php the_title(); ?></a></dd>
<?php endwhile;?>
</dl>
<?php endif; ?>
<?php unset($postsRight); endforeach; ?>

Um nur die aktuellesten Artikel eines spezifischen Tags zu listen muss diese Lösung etwas umgeschrieben werden:

<?php
$postsRight = new WP_Query();
$postsRight->query("tag=tag-slug&showposts=5");
?>
<?php if ( $postsRight->have_posts() ) :?>
<ul>
<?php while ( $postsRight->have_posts() ) : $postsRight->the_post(); ?>
<li><a title="<?php the_title(); ?>" href="<?php the_permalink() ?>"><?php the_title(); ?></a></li>
<?php endwhile;?>
</ul>
<?php endif; ?>
<?php unset($postsRight);
?>

Durch das Anpassen des Tag-Slugs werden die aktuellsten 5 Beiträge, die mit diesem Schlagwort versehen wurden, im Template aufgerufen.

PS: Das gleiche Ergebnis lässt sich auch mit der Einbettung des RSS-Feeds des jeweiligen Schlagworts erreichen.

Komfortabler ist es, Änderungen direkt über das Backend durchführen zu können, wobei auch diese Lösung vor einem Theme-Update nicht sicher ist; aber immerhin hat der Kunde jetzt auf bequeme Weide die volle Kontrolle über den Text. Umgesetzt wird das Ganze folgendermassen:

Zuerst wird im Backend eine Seite mit dem gewünschten Inhalt angelegt und publiziert, die ID der Seite wird im nächsten Schritt benötigt; ggf. kann die Seite noch aus der XML-Sitemap ausgeschlossen werden.

Der Aufruf des Inhalts der Seite auf der Startseite wird über das Einfügen dieses Codes an der gewünschten Stelle in der home.php des Themes erreicht: <?php echo getPageContent(ID-der-Seite); ?>

Um das Ganze zum Laufen zu bringen muss jetzt lediglich noch die functions.php des Themes um diese Funktion erweitert werden:

<?php

function getPageContent($pageId)
{
if(!is_numeric($pageId))
{
return;
}
global $wpdb;
$sql_query = 'SELECT DISTINCT * FROM ' . $wpdb->posts .
' WHERE ' . $wpdb->posts . '.ID=' . $pageId;
$posts = $wpdb->get_results($sql_query);
if(!empty($posts))
{
foreach($posts as $post)
{
return nl2br($post->post_content);
}
}
}

?>

Der einfachste Weg um herauszufinden ob die Auto-Update Funktion unterstützt wird ist sicherlich die Try’n'Error-Methode: einfach schauen was passiert. Normalerweise erscheint bei Nichtunterstützung der Funktion einfach eine Fehlermeldung und damit heisst es dann dass alle Updates wie gehabt von Hand durchgeführt werden müssen.

In seltenen Fällen allerdings kann die komplette Site ausgeknockt werden: im Frontend steht permant die (holperig übersetzte) Meldung “Für kurze Zeit nicht verfügbar um eine regelmäßige Instandhaltung durchzuführen. Prüfe in einer Minute nochmals”, ein Zugriff auf das Backend ist fatalerweise nicht mehr möglich… stellt man das zum ersten Mal fest ist der Herzinfarkt in Reichweite. Glücklicherweise kann das Problem aber behoben werden indem man via FTP-Programm die Datei .maintenance vom Server löscht.

Eventuell sind für einen FTP-Benutzer trotz aktivierter Option “Auflistung versteckter Dateien erzwingen” (FileZilla) eben diese versteckten Datein trotzdem nicht sichtbar, in diesem Fall muss die Datei via FTP-Befehl gelöscht werden (FileZilla: Server -> Benutzerdefinierten Befehl eingeben): del .maintenance

Was bleibt ist die geringfügig störende Meldung “Ein automatisches Update konnte nicht beendet werden – Bitte starte das Update jetzt erneut.” die im Backend ständig sichtbar ist und von der ich hoffe dass sie mit dem nächsten Systemupdate (manuell durchgeführt) verschwinden wird…

function fb_disable_feed() { wp_die( __('Kein Feed erreichbar, besuchen Sie die <a href="'. get_bloginfo('url') .'">Startseite</a>!') ); }

add_action('do_feed', 'fb_disable_feed', 1);
add_action('do_feed_rdf', 'fb_disable_feed', 1);
add_action('do_feed_rss', 'fb_disable_feed', 1);
add_action('do_feed_rss2', 'fb_disable_feed', 1);
add_action('do_feed_atom', 'fb_disable_feed', 1);

Allerdings musste ich schnell feststellen, dass es hier keine Möglichkeit gibt die angezeigten Artikel nach Kategorie oder Vorhandensein auf der Startseite zu filtern, so dass prinzipiell alle Artikel gelistet werden.

Im zweiten Anlauf versuchte ich die Option zu nutzen, den Artikel-Output auf einen bestimmten Autor zu beschränken. Also einen neuen Benutzer angelegt und diesem die Newsbeiträge zugeordnet. Hatte ich jetzt jedoch erwartet in der Auswahlliste den Benutzer auswählen zu können wurde ich enttäuscht: “Nicht von mir erstellt oder geändert” heisst etwas schwammig die Option, aber letztendlich sollte das ja aufs Gleiche hinauslaufen. Dumm nur dass die Filterung schlicht und einfach nicht funktioniert.

Ich habe noch die Möglichkeit die “Zuletzt erstellten zuerst” oder die “Zuletzt bearbeiteten zuerst” anzeigen zu lassen, allerdings läuft es mir angesichts der damit einhergehenden Verpflichtung bei einer sich im Betrieb befindenden Website permanent mit den Änderungsdaten jonglieren zu müssen einfach nur kalt den Rücken hinunter.

Das “Neueste Nachrichten” Modul war damit aus dem Rennen, die Recherche nach externen Erweiterungen brachte auf die Schnelle auch nichts Vielversprechendes ans Tageslicht, so dass mir letztendlich nichts anderes übrig blieb als das System zu überlisten:

Das Modul “Feed-Anzeige” ermöglicht das Einbetten externer RSS-Feeds in die eigene Website, und natürlich kann damit auch der Feed der eigenen Startseite aufgerufen werden…
Das hat zwar funktioniert, jedoch war ich überrascht eine meiner Meinung nach Basis-Funktion eines CMS auf diese relativ umständliche Art herbeiführen zu müssen.

INSERT INTO jos_users VALUES (1, 'Administrator', 'admin', 'email@domain.net', '21232f297a57a5a743894a0e4a801fc3', 'Super Administrator', 0, 1, 25, '2009-10-29 00:00:00', '2009-10-29 00:00:00', '', '');

INSERT INTO jos_core_acl_aro VALUES (1, 'users', '1', 0, 'Administrator', 0);

INSERT INTO jos_core_acl_groups_aro_map VALUES (25, '', 1);

Dadurch wird ein Benutzer mit dem Namen admin und einem gleich lautenden Passwort angelegt, diese Einstellung können nach erfolgreichem Login im Backend problemlos geändert werden.

Genauere Informationen zum Einfügen der Einträge in die Datenbank hat Stefan Kloss verfasst:
www.stefankloss.com/web-20/joomla-kein-login-moeglich-da-kein-benutzer-admin-nach-installation-vorhanden/

[ nggallery id=1 template=carousel images=4 ]

id bezeichnet die Galerie-ID, template=carousel legt die Art der Präsentation fest und images definiert die Zahl der Thumbnails.

So weit, so – relativ – gut, allerdings setzt das Plugin-Stylesheet die in den Optionen angelegten Kantenmaße für Vorschaubilder außer Kraft und skaliert die großen Bilder prinzipiell auf eine Breite von 100%, was zumindest bei hochformatigen Bildern zu ungewünschten XXL-Ergebnissen führt.

Immerhin bietet das Plugin die Möglichkeit die Ausgabe mittels eigener Theme-Dateien zu beeinflussen, diese werden im Theme-Ordner in einen Ordner namens nggallery gepackt ( (…)/wp-content/themes/mein-theme/nggallery ) und sind somit auch nach Plugin-Updates noch gültig.
Informationen zu den verwendbaren Dateien gibt es hier im WordPress Forum, in diesem Fall war jedoch lediglich nötig, das nggallery.css Stylesheet zu bearbeiten.
Inkonsequenterweise gehören Stylesheets nicht zu den vom Plugin erkannten Theme-Dateien, so dass die Änderungen im Stylesheet des WordPress Themes untergebracht werden mussten.