Standardmäßig erscheint das Widget auf allen Seiten. Soll ein Widget z.B. nur auf der Startseite angezeigt werden, so kann man “show on selected” wählen und “frontpage” anklicken.

Alternativ zu den Checkboxen kann man auch den Link der Seite eintragen, auf der das Widget gezeigt werden soll. Am sichersten funktioniert es, wenn man absolute urls eingibt. Es ist darauf zu achten, dass am Ende des Links kein abschließender Slash / steht. Um ein Widget nur auf der Seite Impressum anzuzeigen, würde man z.B. eintragen http://meine-domain.de/impressum

In Drupal 7 ist der Headbereich des Templates in die Systemdatei html.tpl.php ausgelagert. Für die Bearbeitung der Datei html.tpl.php steht in Drupal 7 die API template_preprocess_html zur Verfügung. Folgende Funktion bindet Conditional Stylesheets in den Head Bereich des Themes ein

function themename_preprocess_html(&$variables) {

drupal_add_css(path_to_theme() . '/css/ie.css', array('group' => CSS_THEME,

'browsers' => array('IE' => 'lte IE 7', '!IE' => FALSE), 'preprocess' => FALSE));

drupal_add_css(path_to_theme() . '/css/ie6.css', array('group' => CSS_THEME,

'browsers' => array('IE' => 'IE 6', '!IE' => FALSE), 'preprocess' => FALSE));

}

Ausgabe der taxonomy terms als ungeordnete Liste

Im Gegensatz zu Drupal 6 gibt Drupal 7 die taxonomy terms nicht in einer ungeordneten Liste aus sondern in div-containern. Mit der folgenden Funktion, die dem theme bartik entnommen ist, kann man die Ausgabe in einer ungeordneten Liste erreichen. themename muss mit dem Namen des jeweiligen Themes ersetzt werden:

function themename_field__taxonomy_term_reference($variables) {

$output = '';

// Render the label, if it's not hidden.

if (!$variables['label_hidden']) {

$output .= '<h3>' . $variables['label'] . ': </h3>';

}

// Render the items.

$output .= ($variables['element']['#label_display'] == 'inline') ? '<ul>' : '<ul>';

foreach ($variables['items'] as $delta => $item) {

$output .= '<li' . $variables['item_attributes'][$delta] . '>' . drupal_render($item) . '</li>';

}

$output .= '</ul>';

// Render the top-level DIV.

$output = '<div>' . $output . '</div>';

return $output;

}

Ausgabe einer Breadcrumb Navigation

Für die Breadcrumb Navigation steht die API theme_breadcrumb zur Verfügung

<?php
function theme_breadcrumb($variables) {
  $breadcrumb = $variables['breadcrumb'];
  if (!empty($breadcrumb)) {
    // Provide a navigational heading to give context for breadcrumb links to
    // screen-reader users. Make the heading invisible with .element-invisible.
    $output = '<p>' . t('You are here') . '</p>';
    $output .= '<div>' . implode(' » ', $breadcrumb) . '</div>';
    return $output;
  }
}
?>

oder als ul-Liste:

<?php
function YOURTHEME_breadcrumb($variables) {
$breadcrumb = $variables['breadcrumb'];
if (!empty($breadcrumb)) {
$crumbs = '<ul>';
foreach($breadcrumb as $value) {
$crumbs .= '<li>'.$value.'</li>';
}
$crumbs .= '</ul>';
}
return $crumbs;
}
?>

Zeit also, sich die Neuerungen in Drupal 7 anzuschauen. Drupal Gründer Dries Buytaert hatte in seinem Artikel Starting to work on Drupal 7 die Ziele für Drupal 7 aufgelistet. Viele oder besser die meisten Punkte sind erfüllt worden.

Besserer Umgang mit Medien

Hier wurde im Vergleich zu Drupal 6 eine große Verbesserung erzielt. Beim Erstellen des Inhalts steht eine Funktion für den Bilderupload zur Verfügung. Gleichzeitig wird beim Bilder Upload ein Thumbnail und eine mittlere Größe des Bildes erstellt. Es lassen sich darüber hinaus auch Bildeffekte beim Upload anwenden (Desaturation, Rotieren, weitere Größenskalierungen und mehr). Insgesamt wurden vier Module integriert, die man in Drupal 6 noch extra installieren musste: Image Cache, Image Field, Image API und File Field.
Unter configuration -> image style lassen sich so eigene Regeln für den Bilder Upload definieren.

Benutzerdefinierte Inhaltstypen

Beim Erstellen eines neuen Inhaltstyps gibt es nun die Möglichkeit für jeden Inhaltstyp benutzerdefinierte Felder hinzufügen. In Drupal 6 musste man zu diesem Zweck noch das Modul CCK installieren, dessen Funktionen nun in Drupal 7 unter dem Namen field api integriert. Einstellungen zur Anzeige von Autor Namen und Datum können nun direkt beim Inhaltstyp eingestellt werden (vorher musste man diese Einstellung in der Theme Konfiguration vornehmen). Eine weitere Einstellungsmöglichkeit unter “menu settings’ ist, dass man bei Erstellung eines Inhaltstype einschränken kann, in welchem Menu ein Inhalt dieses Inhaltstyps angezeigt werden kann. Neu ist auch, dass man das body-field bearbeiten und sogar löschen kann. So kann lässt sich auch ein Inhaltstyp erstellen, der nur aus benutzerdefinierten Feldern besteht. Weiterhin läßt sich auch die Kommentardarstellung mit zusätzlichen Feldern versehen.

Bessere Organisation des Inhalts

Inhalte werden nun nach nur einem Klick auf ‘content’ angezeigt und lassen sich filtern. Wozu bei Drupal 6 noch mehrere Klicks notwendig waren, lässt sich nun mit einem Klick finden. Das neue Administrationsmenu und eine sinnvollere Umstrukturierung der einzelnen Funktionen im Backend machen die Strukturierung und das Bearbeiten von Inhalten benutzerfreundlicher. Mit ‘manage display’ lassen sich bei den einzelnen Inhaltstypen verschiedene Darstellungsweisen für Full Content, Teaser, RSS Feeds, Search Index und Suchergebnis Seiten einstellen. Sofern man die Berechtigung zum Bearbeiten des Inhalts hat, gibt es nun bei jedem Inhaltstyp ein kleines Kontext abhängiges Icon, das alle zur Verfügung stehenden Funktionen zum Bearbeiten auflistet und über das man schnell ins Backend gelangen kann.

Automatische Upgradefunktion

Themes oder Module über das Backend installieren oder aktualisieren. Bei der Installation kann man entweder einen Link oder eine Datei auf dem Computer als Installationsquelle angeben. Auch das Aktualisieren der Module kann, sofern die entsprechenden Schreibrechte auf dem Server gesetzt sind, über das Backend erfolgen. Anschließend muss wie bei Drupal 6 die update.php Datei aufgerufen werden.

Usability

Die Usability wurde in vielen Bereichen verbessert. Die einzelnen Menupunkte im Backend wurden sinnvoller strukturiert und das neuen Administrationsmenu sorgt für eine bessere Übersicht. Die Option Shortcuts erlaubt es, ein zusätzliches benutzerdefiniertes Menu mit häufig genutzte Funktionen zu erstellen. Das Backend ist mit einem eigenen Theme und einem Overlay deutlicher vom Frontend getrennt. Das Overlay ist ein standardmäßig aktiviertes Modul, das aber bei Nichtgefallen deaktiviert werden kann.

Benutzern kann nun auch die Rolle eines Administrators zugewiesen werden. Lediglich bei neu installierten Modulen müssen für weitere Administratoren die Berechtigungen neu vergeben werden.

Die Integration von Views und ein WYSIWYG Editor sind in Drupal 7 noch nicht berücksichtigt worden. Aber das wird dann sicherlich in Drupal 8 der Fall sein.

Mit wp-minify werden diese Dateien jeweils zu einer Datei mit Hilfe eines Caches gebündelt. Bei dem CMS Drupal ist diese Funktion bereits Core Funktion. Wp-minify schließt diese Lücke für WordPress

Für den kostenpflichtigen Zugang zu Inhalten steht PayPal als Bezahlmöglichkeit zur Verfügung. Es können sowohl Einmalzahlungen als auch sich regelmäßig in bestimmten Zeitabschnitten wiederholende Zahlungen (z.B. regelmäßige Monatsbeiträge) festgelegt werden.

Für jede Mitgliedsgruppe können die Zugangsberechtigungen separat gesetzt werden. Es können sowohl für Artikel, Seiten, Kategorien als auch Tags für jeden Mitglieds-Level Zugangsberechtigungen festgelegt werden. Im Backend können hier jedem Mitgliedslevel die entsprechenden Post- oder Seiten IDs zugeordnet werden, deren Zugang eine Mitgliedschaft des entsprechenden Mitglieds-Level erfordern. Ebenso kann der Zugang per Tags geregelt werden, z.B. alle Posts mit dem Tag “premium” erfordern die Premium Mitgliedschaft usw.

Die Tag-Berechtigungen haben eine höhere Priorität als Artikel-Berechtigungen und überschreiben andere Berechtigungen, die evtl. bereits dem entsprechenden Artikel per ID zugewiesen worden sind, sobald der Artikel diesen Tag aufweist.
Darüber hinaus kann man den verschiedenen Mitgliedsgruppen Kategorien zuweisen. Die Beschränkung des Zugangs zu einer Kategorie auf eine Mitgliedsgruppe überträgt sich automatisch auch auf Unterkategorien. Kategorieberechtigungen haben höhere Priorität als die Berechtigungen, die für einzelne Artikel gesetzt wurden.

Weiterhin gibt es noch die Möglichkeit, für den Aufruf einzelner Links mit der Zugehörigkeit zu einer Mitgliedsgruppe zur Voraussetzung zu machen.

Zu guter Letzt steht noch die Option “Specific Post/Page Access Restrictions” zur Verfügung. “Specific Post/Page Access Restrictions” erfordern keine Mitgliedschaft, sondern es wird nur der Zugang zu einer bestimmten Seite oder einem Artikel per “buy now” verkauft. Es ist kein Login erforderlich. Für den Zugang wird ein automatisch nach 72 Stunden auslaufender Link erzeugt. Diese Option eignet sich z.B. gut für Download-Produkte.

Mit einer zusätzliche Funktion “Unique IP Access Restrictions” kann man sich vor “Link-Sharing” schützen. Hier kann man angeben, wieviele unterschiedliche IP’s innerhalb eines bestimmten Zeitraums mit dem gleichen Benutzernamen eingeloggt sein bzw. auf einen bestimmten Link zugreifen dürfen. Wenn dieses Limit überschritten ist, wird der Benutzer automatisch mit einem temporären Bann belegt.

Es gibt auch noch fortgeschrittene Optionen, per Conditional Tags in php den Zugang einzuschränken. Um diese Funktion zu nutzen, muss man zusätzlich das Plugin exec-php installieren. Dieses ermöglicht es, im Texteingabefeld für einen Artikel oder eine Seite in der html-Ansicht auch php-Code zu verwenden.

So kann man auf einer Seite verschiedene Inhalte für verschiedene Mitgliedsgruppen anbieten.

Beispiel:

Beispiel #1: Vollen Zugang, für alle, die eingeloggt sind.

<?php if(is_user_logged_in()){ ?>
Inhalt für alle, die eingeloggt sind, unabhängig von der Mitgliedsgruppe
<?php } else { ?>
Öffentlicher Inhalt
<?php } ?>

Beispiel #2: Vollen Zugang für Mitglieder mit einem Level >= 1.

<?php if (is_user_logged_in() && current_user_can("access_s2member_level1")){ ?>
Inhalt für eingeloggte Mitglieder mit einem s2Member Level >= 1.
<?php } else { ?>
Öffentlicher Inhalt
<?php } ?>

Beispiel #3: Verschiedene Inhalte für verschiedene Mitglieds-Level

<?php if (is_user_logged_in() && current_user_can("access_s2member_level4")){ ?>
Some premium content for Level 4 Members.
<?php } else if (is_user_logged_in() && current_user_can("access_s2member_level3")){ ?>
Premium Inhalt für Level 3 Mitglieder.
<?php } else if (is_user_logged_in() && current_user_can("access_s2member_level2")){ ?>
Premium Inhalt für Level 2 Mitglieder.
<?php } else if (is_user_logged_in() && current_user_can("access_s2member_level1")){ ?>
Premium Inhalt für Level 1 Mitglieder.
<?php } else if (is_user_logged_in() && current_user_can("access_s2member_level0")){ ?>
Inhalt für kostenlose Mitgliedschaft
<?php } else { ?>
Öffentlicher Inhalt
<?php } ?>

Example #4: s2Member API Konstante statt Funktionen.

<?php if (S2MEMBER_CURRENT_USER_IS_LOGGED_IN_AS_MEMBER){ ?>
Inhalt für Mitglieder mit einem s2Member Level >= 1.
<?php } else if(S2MEMBER_CURRENT_USER_IS_LOGGED_IN) { ?>
Inahlt für kostenlose Mitgliedschaft
<?php } else { ?>
Öffentlicher Inhalt
<?php } ?>

Example #5: s2Member API Konstante statt Funktionen.

<?php if (S2MEMBER_CURRENT_USER_ACCESS_LEVEL >= 4){ ?>
Inhalt für Mitglieder mit einem s2Member Level >= 4.
<?php } else if (S2MEMBER_CURRENT_USER_ACCESS_LEVEL >= 3){ ?>
Inhalt für Mitglieder mit einem s2Member Level >= 3.
<?php } else if (S2MEMBER_CURRENT_USER_ACCESS_LEVEL >= 2){ ?>
Inhalt für Mitglieder mit einem s2Member Level >= 2.
<?php } else if (S2MEMBER_CURRENT_USER_ACCESS_LEVEL >= 1){ ?>
Inhalt für Mitglieder mit einem s2Member Level >= 1.
<?php } else if(S2MEMBER_CURRENT_USER_ACCESS_LEVEL === 0){ ?>
Some content for Free Subscribers.
<?php } else if(S2MEMBER_CURRENT_USER_ACCESS_LEVEL === -1){ ?>
Öffentlicher Inhalt
<?php } ?>

Das Plugin s2member kann auch auf BuddyPress Seiten eingesetzt werden.

Für eine Multisite Installation sollten die WordPress Dateien und Ordner im Rootverzeichnis liegen, nicht in einem Unterordner. Voraussetzung ist, dass bei der WordPress Installation die Multisitefunktion aktiviert ist.
Hierzu fügt man in die Datei wp-config.php eine zusätzliche Zeile
define('WP_ALLOW_MULTISITE', true);
oberhalb der Zeile
/* That's all, stop editing! Happy blogging. */
ein.
Danach steht unter Werkzeuge der zusätzliche Menupunkt “Blog-Netzwerk” zur Verfügung.

Bei Aktivierung des Netzwerkes kann man wählen, ob die Unterseiten jeweils als Subdomain oder als Unterordner angelegt werden sollen. Um die Unterseiten als Subdomains anlegen zu können, muss der Server Wildcard DNS unterstützen. Dies ist bei den meisten Shared Hosting Angeboten nicht der Fall, so dass hier die Einstellung Unterordner gewählt werden sollte.

Nach Aktivierung des Netzwerkes müssen nun manuell noch einige kleine Änderungen vorgenommen werden:

1. Im Verzeichnis wp-content muss ein zusätzlicher Ordner blogs.dir angelegt werden, der volle Schreibrechte für den Server besitzen muss.
2. Die Datei wp-config.php muss ergänzt werden. Der Code hierfür wird angezeigt.
3. Die Datei .htaccess muss ergänzt werden. Der Code hierfür wird ebenfalls angezeigt.

Nun lassen sich im Adminbereich unter dem neuen Menupunkt “Blog-Netzwerk” neue WordPress Seiten hinzufügen und verwalten.

Um diesen neuen Seiten einen eigenen Domainnamen zuweisen zu können, benötigt man das Plugin WordPress MU Domain Mapping Plugin. Dieses Plugin darf nicht über die automatische Funktion “Plugins installieren” installiert werden, sondern muss manuell heruntergeladen, entpackt und anschließend müssen die Dateien in separate Ordner hochgeladen werden.

Im wp-content Ordner muss ein zusätzlicher Ordner mu-plugins angelegt werden. In diesen Ordner kommt die Datei domain_mapping.php, das Bestandteil des heruntergeladenen MU Domain Mapping Plugins ist.

Nun wird die Datei sunrise.php, die ebenfalls im MU Domain Mapping Plugin enthalten ist, direkt in den wp-content Ordner hochgeladen.

Nun muss abermals die Datei wp-config.php bearbeitet werden und mit dem Zusatz
define( 'SUNRISE', 'on' );
wird das Laden der Datei sunrise.php aktiviert.

Nun sind die technischen Voraussetzungen für das Domainmapping gegeben und es müssen nur noch unter “Blog-Netzwerk” → Domain Mapping das Domain Mapping Plugin konfiguriert werden. Hier muss entweder unter IP die IP-Adresse der Multisite Installation oder der Domainname eingegeben werden.

Die IP Adresse lässt sich z.B. über das Online-Tool Reverse IP Check herausfinden.

Bei den Domain Optionen am besten die beiden mittleren Optionen ankreuzen, wie auf einem Tutorial von ottopress unter step 3 sehr schön erklärt ist.

Nun wird unter Blog-Netzwerk eine neue Seite angelegt. Um eine andere Domain auf diese Seite zu mappen, muss man sich zunächst als Administrator dieser Seite einloggen. Es ist wichtig, im Backend der Unterseite zu sein, nicht im Backend der Hauptseite. Hier gibt es nun unter dem Menupunkt Werkzeuge einen neuen Link “Domain-Mapping”. Hier trägt man nun unter “add new Domain”, den neuen Domainnamen ein, der dann als “primary Domain” aktiviert werden muss.

Zu guter Letzt müssen nun noch bei diesem Domainnamen Einstellungen vorgenommen werden, damit dieser auf die WordPress Multisite Installation verweist. Hierzu muss man den sogenannten A-Record bei den DNS Einstellungen dahingehend ändern, dass er auf die IP Adresse der Multisite Installation verweist. Der Screenshot links zeigt ein Beispiel der DNS Einstellungsmöglichkeiten bei godaddy. Dies ist von Hoster zu Hoster unterschiedlich.

Wenn man keine eigene IP Adresse hat (was bei den meisten Shared Hosting Paketen der Fall ist) und die Domain auf einem anderen Server geparkt ist, erhält man beim Aufruf der gemappten Domain erst einmal ein “Forbidden 403″ Fehlermeldung. Dem Shared Server muss nun erst einmal mitgeteilt werden, wohin die Domainanfrage geschickt werden soll.

Wie diese Eingabe aussieht, ist von Hoster zu Hoster verschieden. Bei meinem Hoster all-inkl muss man dazu im kasserver die Domain neu anlegen und als Ziel die Multisite Installation (also das Rootverzeichnis) eingeben. Befindet sich die Domain auf dem gleichen Server wie die Multisite Installation, dann muss auch hier die Multisite Installation als Zielordner für diese Domain eingestellt werden.

Es kann noch etwas Zeit in Anspruch nehmen, bis die neuen DNS Einstellungen wirksam sind, aber meist lässt sich die Seite dann schon nach kurzer Zeit unter der gemappten Domain aufrufen.

Die Installation ist einfach: Das Plugin bei WordPress herunterladen, entpacken und per ftp in den wp-content/plugins Ordner hochladen oder aber gleich direkt über das Backend installieren.

Nun muss noch im Ordner wp-content ein Unterordner “header-images” (/wp-content/header-images/) erstellt werden. Dieser Ordner muss die vollen Schreibrechte chmod 777 erhalten.

Im Backend steht nun in der Navigationsleiste ein neuer Menupunkt “Headers” zur Verfügung. Hier können unter “add new images” die Headerbilder hochgeladen werden (alternativ kann der Upload auch per ftp in den neu erstellten header-images Ordner erfolgen).

Beim Erstellen eines neuen Artikels oder einer neuen Seite steht nun ein neues Feld am unteren Ende der Seite zur Verfügung. Es trägt den Titel “Nicasio Dynamic Header”

Hier werden in einem Dropdownmenu alle hochgeladenen Headerbilder aufgelistet und man kann für den betreffenden Artikel oder die betreffende Seite ein Headerbild auswählen, das dann bei Aufruf dieses Artikels oder dieser Seite im Header erscheint.

Damit das Headerbild im Template aufgerufen werden kann, ist noch eine kleine Modifikation des Templates notwendig.

Dort, wo das Headerbild erscheinen soll, muss der folgende Code eingefügt werden:

<?php if(function_exists('show_media_header')){ show_media_header(); } ?>

Die Größe der Headerbilder muss dem für das Headerbild im Template zur Verfügung stehenden Bereich angepasst werden.

Unter “Headers” -> Settings kann im Backend auch noch ein Headerbild bestimmt werden, das standardmäßig als Headerbild erscheint, wenn für einen Artikel kein eigenes Headerbild definiert wurde.

Für weitere conditional tags, die zur Verfügung stehen, findet sich auf wordpress.org eine Übersicht:
http://codex.wordpress.org/Conditional_Tags

Die Installation ist einfach. Das Plugin herunterladen und in den Ordner wp-content/plugins hochladen und anschließend im Backend aktivieren.
Es stehen nun für jede Spalte sogenannte Shorttags zur Verfügung, mit Hilfe derer man den Inhalt in Spalten aufteilen kann. Eine Spalte beginnt mit einem öffnenden [column width="47%" padding="6%"] Tag, dem noch Parameter für die Weite width=”x%” und den Innenabstand padding=”x%” mitgegeben werden. Anschließend folgt der Inhalt für die erste Spalte, die dann mit einem schließendem [/column] Tag wieder geschlossen wird.

Beispiel für ein 2-Spalten Layout:
[column width="47%" padding="6%"]
Inhalt der ersten Spalte
[/column]
[column width="47%" padding="0"]
Inhalt der zweiten Spalte
[/column][end_columns]

Beispiel für ein 3-Spalten Layout:

[column width="30%" padding="5%"]
Inhalt der ersten Spalte
[/column]
[column width="30%" padding="5%"]
Inhalt der zweiten Spalte
[/column]
[column width="30%" padding="0"]
Inhalt der dritten Spalte
[/column][end_columns]

Beispiel für ein 4-Spalten Layout:

[column width="22%" padding="4%"]
Inhalt der ersten Spalte
[/column]
[column width="22%" padding="4%"]
Inhalt der zweiten Spalte
[/column]
[column width="22%" padding="4%"]
Inhalt der dritten Spalte
[/column]
[column width="22%" padding="0"]
Inhalt der vierten Spalte
[/column][end_columns]

Statt prozentualer Angaben können natürlich auch feste Werte in Pixeln eingesetzt werden.

define('WP_TEMP_DIR', ini_get('upload_tmp_dir'));

Um herauszufinden, welches der Ordner für temporäre Dateien ist, einfach folgenden php-Befehl in eine php-Datei schreiben (kann danach wieder gelöscht werden):

Es wird dann der Pfad zum temporären Ordner ausgegeben.