Mit Hilfe des Services, der aktuell unter der URL https://api.wordpress.org/secret-key/1.1/salt/ zu erreichen ist, kann man sich 8 neue Schlüssel erstellen lassen und nutzt diese bzw. auch nur die letzten vier. Die neue Schlüssel sind vorrangig für die Multiuser-Funktionalität und werden klassisch wenig genutzt - ein Nachteil sind sie aber nicht und werden auch in der Funktion wp_salt() genutzt, die sich um die Sicherheit kümmert und diverse Hashes erstellt.

define('AUTH_KEY',         'q]ntdiiS9%&y%W&. M%JH+mUK=!j_CL|TZ ]0X$/cO]HrL6jMdc$0tx1|o+R.J#2');
define('SECURE_AUTH_KEY',  'Y}qq3FZH+~;,{H5w;jW=&gt;s$hB,P^kra#U?HtP]32w^5r*h|]|yTc~D?78M +z<HR>/qZ +FTi&gt;iKhudd');
define('LOGGED_IN_KEY',    '4i>/~Ox[JG0O|AK`vt@Vh5#D;r=E@Xsl-SR>XXgz0Np/&b;)|c(@t9yPtKaxj%N&');
define('NONCE_KEY',        ' j2H|0N[q%q||[mB1V;pj4v TO6I&amp;-NqEc=J&gt;G|!t#wZI |v+Q=d[@9@heM!I[d[');
// die neuen Schluessel
define('AUTH_SALT',        'yce=M 5@R^3q!`v_`o1[hh05kMY2l=k=|7Xdvg+zj`-bcw2qu;d*37?');
define('SECURE_AUTH_SALT', ';3^JS^3d-4JaX@{-~t*L');
define('LOGGED_IN_SALT',   'G#whJOmaws-PsnY/i8(G!gq)A?:elIE8cPTYL[0H]OX^&gt;-f.0#7+V82)J]&amp;] }b+');
define('NONCE_SALT',       '!yl]=f1]vrB mwtr|?#_-KvCIM}kBR&gt;rq:CV/MnTQb(!X/|;LB&gt;.3qhU:(Xni/{L');

• WordPress sicherer machen
• WordPress Templates sicherer machen

Die WordPress-Community ist sehr groß und es gibt viele gute Entwickler in diesen Bereich. Dementsprechend gibt es nun eine ganze Reihe an Plugins, die die Sicherheit auf verschiedene Art und Weise erhöhen. Im Beitrag "WordPress Plugins für mehr Sicherheit" sind diese Plugins nachzulesen. Sie sind zum Teil sehr nützlich und leicht einzusetzen, in jedem Fall einen Blick wert.

Egal ob die Verwendung eines freien, kommerziellen oder selbst erstellten Themes in deinem Weblog zur Verwendung kommt, man kann mittels PHP viele schöne und nützliche Funktionen einbauen. Aber durch diese Mächtigkeit kann man ebenso einfach und unbewusst Sicherheitslücken in das System holen.

Damit soll keine Angst vor dem Erstellen und Ändern von Themes und Templates geschürt werden, sondern Bewusstsein und Verantwortung für das Verwenden von Themes und Templates erzogen werden.

Daher in wenigen Punkten, einige Tipps und Tricks, die es gilt zu beachten bzw. zu prüfen.

1. echo $_SERVER prüfen

   Die direkte Ausgabe von Variablen, welche durch ungeprüfte Eingabe/ Übergabe gefüllt werden, is t nicht mit den PHP-Sicherheitsregeln in Einklang zu bringen.

   Eine ganze Reihe von Themes nutzen den folgenden Syntax:

   <?php echo $_SERVER['REQUEST_URI']; ?>
   

   Beispielsweise in der searchform.php

   
   <form method="get" id="searchform" action="<?php echo $_SERVER['REQUEST_URI']; ?>">
   

   Diese Ausgabe gehört da nicht hin, die Übergabe gehört gefiltert. Daher ist folgender Syntax zu nutzen.

   
   <form method="get" id="searchform" action="<?php bloginfo('url'); ?>/">
   

   Muss unbedingt mir $_SERVER gearbeitet werden, dann ist die Filterung der Daten anzuraten.

   
   <form method="get" id="searchform" action="<?php echo htmlspecialchars($_SERVER['REQUEST_URI']); ?>">
   

2. echo $s prüfen

   Ähnlich verhält es sich mit der Ausgabe des Suchsyntax. Dabei handelt es sich um eine Übergabe von Nutzerwerten, die schnell zu einer XSS-Lücke werden. Daher gilt auch hier das Filtern der Eingabe.

   Vielfach in der searchform.php einiger Themes zu finden.

   
   <input type="text" value="<?php echo $s; ?>" name="s" id="s" />
   

   Die Lösung könnte, mit Sicherheitsmöglichkeiten von WordPress genutzt, wie folgt aussehen.

   
   <input type="text" value="<?php echo attribute_escape($s, 1); ?>" name="s" id="s" />
   

   Alternativ kann auch die Verwendung der Funktion the_search_query() genutzt werden.

   
   <?php the_search_query(); ?>
   

3. Konstanten nutzen

   Es empfiehlt sich die Nutzung von Konstanten und nicht die Übergabe einer Variable als Pfadangabe. WordPress stellt dafür im Standard eine ganze Reihe von Möglichkeiten zur Verfügung.

   • TEMPLATEPATH
     Ordner des aktiv genutzten Theme
   • STYLESHEETPATH
     Ordner des Stylesheets des aktiv genutzten Themes
   • ABSPATH
     Order der WP-Installation, dort, wo die wp-config.php liegt
   • WPINC
     Ordner wp-includes
   • PLUGINDIR
     Ordner wp-content/plugins

4. Prüfen

   Der WP-Scanner von BlogSecurity prüft die genannte Sicherheitslücke aus Punkt 1. Es empfiehlt sich diesen Scanner zu nutzen.

   Um das eigene Blog zu scannen, muss lediglich ein Kommentar in der header.php bzw. index.php, falls es keine header.php gibt, hinterlegt werden.
   <!-- wpscanner -->

Weitere Artikel und Referenzen

• BlogSecurity: Common WP Theme Vulnerabilities
• WordPress Installation und Betrieb sicherer machen
• WordPress Sicherheitsmöglichkeiten und PHP

Ein Thema, welches ich im Buch leider vernachlässigt habe, ist das Thema Sicherheit. Dieses Thema ist aber immer relevanter, gerade weil WordPress immer populärer wird und damit auch immer interessanter für Hacker und Andere, die sich unbefugt Zutritt zu einer Web-Applikationen geben wollen.

Nicht zuletzt ist der Artikel also eine Aufforderung vieler Leser, die mir per E-Mail oder Online-Rezension, einen Hinweis darauf hinterlassen habe und denen ich mit diesem Artikel ein wenig helfen möchte, ihre WordPress-Installation sicherer zu machen.

Kurz & Knapp - so werde ich also im folgenden einige Tipps für ein sicheres Weblog mit WordPress geben.

Sicherheit - einen Zustand, der frei von unvertretbaren Risiken der Beeinträchtigung ist oder als gefahrenfrei angesehen wird.

Wikipedia

Aber Achtung, damit will und kann ich nicht die Eigenverantwortung des jeweiligen Administrators herabsetzen oder abnehmen. Das Thema wird immer wieder präsent sein und die Sicherheitsregeln werden sich ändern. Nichtsdestotrotz kann man mit einigen wenigen Schritten die Installation recht sicher gestallten.

1. User-Name

   Nach jeder Installation ist der Standard-User-Name des Administrators admin. Diese Login-Name gehört als erstes geändert. Dieser Login-Name ist bekannt und sorgt dafür, dass eine unberechtigte Person nur noch an einem Wort tüfteln muss - dem Zugangspasswort. Mit einem eigenen Login-Namen erhöht man die Sicherheit des Systems.

   Ist der Blog schon eine weile im Betrieb, so hat das Login sicher einiges an Daten - Artikel, Kommentare. Aber keine Angst, WordPress erlaub beim Löschen eines Users die Übernahme aller Daten auf einen anderen User.

   1.1. User ID

   Wer sich nicht vor dem Zugriff und dem Ändern in der Datenbank scheut, dem sei das Ändern der ID zu empfehlen. Die Standard-IDs 1 und 2 werden am ehesten von Hackern genutzt.
   Achtung, dazu muss die user_id in den Tabellen _users und _usermeta gleich sein! Ebenso gilt es die Tabelle _posts, _links mit dem neuen ID zu versehen, Spalte post_author.
   UPDATE `wp_users` SET `ID` = “815″ WHERE `wp_users`.`ID` = 1;
UPDATE `wp_usermeta` SET `user_id` = '815' WHERE `wp_usermeta`.`user_id` = 1;
UPDATE `wp_posts` SET `post_author` = '815' WHERE `wp_posts`.`post_author` = 1;
UPDATE `wp_links` SET `link_owner` = '815' WHERE `wp_links`.`link_owner` = 1;

   Tipp

   Ich habe das Plugin Search & Replace erweitert und nun kann man mit einem Klick die User-Id und das User-Login einfach ändern, Kenntnisse im Bereich SQL sind nicht erforderlich.

2. Tabellen-Präfix

   Der Tabellen-Präfix von WordPress ist im Standard wp_. Dieser ist in der wp-config.php hinterlegt.

   Neuinstallation

   Bevor WordPress installiert wird, sollte dieser Präfix geändert werden, in einen beliebigen Präfix, der nicht einfach auch das System schließen lässt.
   In der Regel hat WordPress bei vielen Anwendern sicher eine eigene Datenbank und so muss der Präfix nicht auf das System schließen lassen.

   
   // Wenn du verschiedene Präfixe benutzt kannst du innerhalb einer Datenbank
   // verschiedene WordPress Installationen betreiben
   $table_prefix  = 'wp_';   // Nur Zahlen, Buchstaben und Unterstriche bitte!
   

   $table_prefix = '08xyz15_'; // Nur Zahlen, Buchstaben und Unterstriche bitte!

   Bestehende Installation

   Was nun aber, wenn das Blog schon aufgesetzt und in Betrieb ist. Auch dann empfiehlt sich die Änderung des Präfix in eine kryptische Variante.

   Natürlich muss auch dazu der Präfix in der wp-config.php geändert werden. Nun weis WordPress zwar, wie der neue Präfix lautet, aber die bestehenden Tabellen in der Datenbank haben diesen neuen Präfix noch nicht und das Blog kann somit nicht funktionieren.

   Mit Hilfe eines SQL-Kommandos ist aber auch dies recht schnell zu beheben. Dazu nutzt man am besten phpMyAdmin, welches bei vielen Webhostern vorinstalliert ist.
   Die folgende SQL-Anweisung benennt die Tabelle links um.
   RENAME TABLE wp_links to 08xyz15_links;

   Diese Anweisung führt man für jede bestehende Tabelle aus. Dabei hat WordPress, ab Version 2.3, im Standard 10 Tabellen: comments, links, options, postmeta, posts, terms, term_relationships, term_taxonomy, usermeta, users.

   
   RENAME TABLE wp_comments to 08xyz15_comments;
   RENAME TABLE wp_links to 08xyz15_links;
   RENAME TABLE wp_options to 08xyz15_options;
   RENAME TABLE wp_postmeta to 08xyz15_postmeta;
   RENAME TABLE wp_posts to 08xyz15_posts;
   RENAME TABLE wp_terms to 08xyz15_terms;
   RENAME TABLE wp_term_relationships to 08xyz15_term_relationships;
   RENAME TABLE wp_term_taxonomy to 08xyz15_term_taxonomy;
   RENAME TABLE wp_usermeta to 08xyz15_usermeta;
   RENAME TABLE wp_users to 08xyz15_users;
   

   Im Anschluss ist man nicht fertig! In den Tabellen options und usermeta müssen noch 4 Felder geändert werden. Dazu kann man folgenden Ql-Syntax nutzen.
   UPDATE 08xyz15_options SET option_name = REPLACE(option_name, 'wp_', '08xyz15_');
UPDATE 08xyz15_usermeta SET meta_key = REPLACE(meta_key, 'wp_', '08xyz15_');

   Sollte es aus irgendwelchen Gründen, z.B. ein Plugin, noch weitere Felder mit dem alten Präfix geben, dann kann man diese mit der folgenden Anweisung finden.
   SELECT * FROM 08xyz15_options WHERE option_name LIKE 'wp_%';
SELECT * FROM 08xyz15_usermeta WHERE meta_key LIKE 'wp_%';

   Handelt es sich um eine Installation kleiner WordPress Version 2.3, dann müssen folgenden 10 Tabellen berücksichtigt werden: categories, comments, link2cat, links, options, post2cat, postmeta, posts, usermeta, users.

   Natürlich gibt es auch für diese Arbeit ein Plugin, welches einem Anwender die Arbeit erleichtert und die Ändern schnell durchführt: WP Prefix Table Changer.

3. Plugin Verzeichnis schützen

   Das WordPress-Entwickler-Team empfiehlt die Sicherung durch einen einfachen Schutz, kopiere eine leere index.html in das Plugin-Verzeichnis /wp-content/plugins/. Damit ist man auf der sicheren Seite, falls der Apache das Anzeigen von leeren Verzeichnissen zulässt.

4. WordPress Version verschleiern

   WordPress hinterlegt in den Core-Daten die Version der Installation und der Datenbank. Bisher hat man in der Regel im Theme die Version eingepflegt. Diese dient lediglich statistischen Erhebungen, denn darüber konnte man ein wenig die jeweils aktuell verfügbaren Installationen recht einfach erkennen.

   Die Entwickler von WordPress empfehlen seit geraumer Zeit, dass man diesen Tag aus dem Theme entfernt um die Identifizierung zu erschweren. Dazu ist im Theme in der Regel die header.php zu ändern, in einigen Themes auch die index.php.

   <meta name="generator"
   content="WordPress <?php bloginfo('version'); ?>" />

   Die obige Zeile also entfernen.

   Allerdings sollte man nicht verschweigen, dass man trotzdem die Version von WordPress in der einen oder anderen Funktion benötigt und das man die Version beispielsweise im Feed auslesen kann. Einige Plugins beispielsweise greifen auf die Version zu und können so auf unterschiedliche Installationen reagieren. Die Version der WordPress-Installation und der Datenbank ist immer in /wp-includes/version.php zu finden. Wer also die Version komplett verschleiern will, der ändert den Eintrag in dieser Datei. Sollte es dann aber zu Problemen mit dem einen oder anderen Plugin oder Theme kommen, dann sollte man sich zumindest an diesen Eingriff erinnern.

   $wp_version = '2.2.3';
   
   $wp_db_version = 5183;
   

   Ebenso ist darauf zu achten, nach jedem Update der Installation ist diese Datei wieder hergestellt.

   Mit dem Löschen bzw. Ändern des Eintrags funktioniert außerdem der automatische Hinweis auf eine neue Version und der Hinweis auf neue Plugin-Versionen, der seit WordPress Version 2.3.1 vorhanden ist, nicht mehr zuverlässig bzw. gar nicht.

   Tipp

   Ich habe ein Plugin erstellt, was die Version von WordPress ersetzt, entweder mit einer Zufallszahl oder ab Version 2.4 wird der komplette Tag gelöscht. Damit werden keine Informationen nach außen getragen und man muss nach einem WP-Update nicht die Core-Dateien ändern.
   Weitere Information und Download des Plugins sind auf meinem Privaten Blog im Artikel WordPress Version verschleiern (Plugin) zu finden.

5. WordPress User-Logins reduzieren

   Im Normalfall hat das Backend nur so viele User, wie man auch wirklich Personen hat, die im System arbeiten. Test-User oder Überbleibsel gehören gelöscht.
   Ein Augenmerk gehört den Rechten. Es ist zu überprüfen, welche Rechte jeder User hat und ob diese wirklich notwendig sind. Es ist kein Zeichen von Angst oder Geiz, wenn die Rechte der User eingeschränkt sind, auf die jeweiligen Anforderungen und Bedürfnisse zugeschnitten.

   Ein Tipp

   Mit Hilfe des Plugins Role Manager Members lassen sich hervorragend Benutzerrechte erstellen. So lassen sich einfach und übersichtlich entsprechend zugeschnittene Rollen für die jeweiligen Nutzer-Aufgaben erstellen, falls die Rollen im Standard nicht ausreichen.

6. WordPress aktualisieren

   WordPress Core

   Nicht zu letzt ist es wichtig, dass die Installation immer auf dem aktuellen Sicherheitsstand ist, das heißt: Spiele immer das aktuelle Release ein! Die aktuelle Release-Version sichert die Sicherheit von WordPress.
   Das heißt nicht, dass man immer die aktuellste Version von WordPress installiert haben muss. Aber das aktuellste Release der verwendeten Version sollte eingespielt sein.

   Um auf dem aktuellen Stand zu bleiben, bietet es sich an, den Feed von WordPress zu abonnieren bzw. immer mal den Tellerrand des eigenen Blogs zu lesen, denn dort wird der Feed-Inhalt dargestellt.
   Ab der Version WP 2.3.1 weist das System darauf hin, dass es eine neue Revision/ Version gibt. Wer den Zugriff nicht ermöglich will, der findet eine Reihe von Plugins im offiziellen Plugin-Verzeichnis, die diese Verbindung unterbrechen.

   WordPress Plugins

   Gleiches gilt für Plugins. Plugins stellen neue Funktionalitäten innerhalb des Systems und können damit neue Sicherheitslücken einbringen. Vertraue nicht jedem Plugin und versuche die Plugins immer auf dem aktuellen Stand zu halten, auch wenn meist neue Versionen neue Funktionalitäten einbringen.

   Im weiteren gehören nicht genutzte Plugins nicht in das laufende System. Werden sie nicht benötigt, dann gehören sie entfernt.

   WordPress Theme

   Auch Themes können Sicherheitsprobleme aufweisen! Themes mit ihren Templates nutzen PHP-Funktionen und können neue Funktionen im Bauch haben. Damit können Sicherheitslücken auftauchen. Es gilt also ebenfalls, auch Updates des Autors achten.

7. WP Plugins minimieren

   Wie schon im vorherigen Punkt erwähnt, Plugins können neue Sicherheitslücken in das System einbringen. Daher sollte immer die Überlegung gelten, muss es wirklich dieses Plugin sein. Bringt es Mehrwert und eventuell sollte man prüfen, wie gut ist das Plugin. Natürlich ist es schwer, vor allem wenn man keine PHP-Kenntnisse hat, den Code zu inspizieren und damit ein eventuell bestehendes Problem zu finden. Aber trotzdem kann man ein wenig die Seriosität des Plugin-Autors prüfen. Hat der Autor eine Anleitung zum Plugin, gibt es negative Schlagzeilen bzw. Blogeinträge und Kommentare und ist das Impressum des Autors gepflegt? Kleinigkeiten, die aber einiges über den Autor und das Plugin aussagen können.

   1. Die Grundregel lautet jedoch: Verwende so wenig wie nötig Plugins.
   2. Un die zweite Regel: Teste Plugins nicht im Live-System, ein Vorabtest in einer lokalen Installation kann viele Probleme verhindern.

Auch der zweite Punkt hat wichtige Relevanz. Immer wieder holen sich User Problem und unnötige Daten in ihr System. Viele Plugins benötigen Einstellungen, die in der Tabelle options abgelegt werden. Diese Daten bleiben bei den meisten Plugins auch nach dem deaktivieren des Plugins in der Tabelle bestehen!

8. Eingeschränkter Login auf wp-admin

   Ist der Zugriff auf das Backend nur von einem oder wenigen Rechnern gesichert, so kann man den Zugriff einschränken und damit die Sicherheit weiter steigern. Der Zugriff ist einfach per .htaccess zu beschränken. Information zu .htaccess gibt es viele im Internet. Die Zugriffssperre könnte zum Beispiel für zwei IPs wie folgt aussehen.

   AuthUserFile /dev/null
   AuthGroupFile /dev/null
   AuthName "Access Control"
   AuthType Basic
   Order deny,allow
   Deny from all
   # Whitelist IP Adresse
   Allow from 255.08.15.1
   Allow from 255.08.15.2
   

   Diese Syntax in eine leere Datei ablegen und die eigenen IPs hinterlegen und die Datei als .htaccess speichern. Die Datei im Anschluss im Ordner /wp-admin/ ablegen.

   Ob man den Zugriff einschränken muss und will, das muss jeder Anwender selbst entscheiden.

   Aber es damit ist natürlich die schöne Funktionalität einer Web-Applikation dahin, von überall auf das System zugreifen zu können.

   via Plugin

   Alternativ kann man dies auch per Plugin realisieren, was einfacher und schneller für den Laien zu bewerkstelligen ist. Als Plugin dient das Login Lockdown Plugin oder AskApache Password Protect.

9. Eingeschränkter Zugriff auf wp-content und wp-includes

   Mit Hilfe einer .htaccess kann man ein ganze Reihe von Daten schützen. Mit Hilfe dieser Methode empfiehlt es sich den Zugriff nur auf bestimmte Datei-Formate, wie Bilder, Stylesheets und JavaScript zu beschränken.

   Order deny,allow
   Deny from all
   <Files ~ ".(xml|css|jpe?g|png|gif|js)$">
   Allow from all
   </Files>

   Der obige Syntax wird wieder in einer .htaccess gespeichert und die Ordner /wp-content/ und /wp-includes/ kopiert. Die Datei-Endungen im Syntax müssen natürlich angepasst werden, je nach dem, auf was für Dateien man zugreifen muss.

   Aufpassen, das eine oder andere Plugin benötigt den Zugriff auf php-Dateien. Daher den Syntax in dem Fall um php erweitern. Zumindest für die .htacces in /wp-content/ empfiehlt sich die Aufnahme von php. Ähnlich verhält es sich, wenn man den Cache von WordPress aktiv hat, dann muss man den Zugriff auf lock erlauben.

   # Allow only css,jpe*g,png,gif,js
   Order deny,allow
   Deny from all
   <Files ~ ".(php|lock|xml|css|jpe?g|png|gif|js)$">
   Allow from all
   </Files>
   

   Im weiteren ist darauf zu achten, dass man nur eine .htaccess-Datei im Ordner hat. Sollte man also ebenfalls den Zugriff per .htaccess aus Punkt 8 nutzen, so muss der Syntax in einer Datei untergebracht werden.

10. Schütze die wp-config.php

    Ein weiterer Schutz ist der Zugriff auf die wp-config.php, in der alle Daten zum einloggen in die Datenbank hinterlegt sind. Im Grunde gibt es diesen Zugriff nicht, aber mit dieser kleinen Erweiterung in der .htaccess im root-Verzeichnis der Installation, geht man auf Nummer sicher.

    # protect wp-config.php
    <files wp-config.php>
    Order deny,allow
    Deny from all
    </files>
    

    Viele weitere Informationen dazu mit einigen Beispielen und Diskussionen findet man im zugehörigen Artikel auf meinem privaten Blog.

11. Sicherheit prüfen

    Das Team von BlogSecurity bietet die Online-Version des WP-Scanners schon eine geraume Zeit an und aktualisiert diesen auch immer wieder.

    Nicht immer liegt es an den Dateien von WordPress, auch das Theme kann Sicherheitslücken enthalten.

    Um das eigene Blog zu scannen, muss lediglich ein Kommentar in der header.php bzw. index.php, falls es keine header.php gibt, hinterlegt werden.
    <!-- wpscanner -->

    Der Scan ist kritisch zu sehen aber er hilft und erleichtert die Arbeit.

Soll die Ausgabe von einigen Inhalten auf dem Blog nur Personen zugänglich sein, die entsprechende Rechte in Ihrem Weblog haben, so kann man innerhalb des Templates eine Abfrage hinterlegen.

Mit folgendem Code wird geprüft, ob der User eingeloggt ist und ob er die entsprechende Berechtigung hat, dabei stehen die User_Level 0-10 zur Verfügung.

Wie sich die einzelnen Berechtigungen auswirken ist im Codex ausführlich nachzulesen.

<?php if (intval($userdata->user_level) >= 9 ) {
function();
. . .
?>

Update:
Tobias weist mich darauf hin, Danke. Ich bringe gleich mal ein Update, denn WordPress gibt den Nutzer dafür seit geraumer Zeit eine Funktion in die Hand.

<?php if( current_user_can('level_10') ) {
function();
. . .
?>

In einem Template könnte man es dann wie folgt nutzen.

<?php if( current_user_can('level_10') ) { echo 'Level 10'; } else { echo '< LEVEL 10'; } ?>

Das obige Beispiel gibt Level 10 aus, wenn der angemeldete User über Adminrechte verfügt, alternativ wird < LEVEL 10 ausgegeben.

Benötigt man zusätzlich das User-ID, dann ist es wie folgt zu lösen. Die obige Version sollte aber in den meisten Fällen ausreichen.

<?php global $user_ID; if( $user_ID ) : ?>

<?php if( current_user_can('level_10') ) : ?>

<p>Inhalt, nur fuer den Admin (Level 10)</p>

<?php else : ?>

<?php endif; ?>

<?php endif; ?>

Folgende Tabelle stellt eine Übersicht der Berechtigungen in WordPress dar.