WordPress als CMS: eigene Seiten-Typen definieren (Anleitung)

Wordpress als CMS: Seiten-Typen definieren

Wordpress als CMS: Seiten-Typen definieren - Foto / Illustration: T.Bortels/cpu20.de

WordPress ist ja nicht nur ein großartiges Werkzeug, um relativ unkompliziert eine Webseite, einen Blog oder eine News-Seite zu erstellen. Man kann WordPress inzwischen auch so weit anpassen, dass es sich durchaus als Content Management System (CMS) nutzen läßt. „WordPress als CMS“ ist ein großes Thema – aber was macht ein CMS aus?

Vorweg muß ich schnell anmerken, daß es mich ein wenig nervt, daß bei WordPress die Inhaltstypen ‚Post Types‘ genannt werden, und nicht ‚Content Types‘. Man gewöhnt sich zwar bekanntlich an fast alles, aber irgendwann sollte man diese Fehlbennung korrigieren. Warum? Der Begriff ‚Post Type‘ suggeriert, dass in WordPress eigentlich alles einer ‚Seiten-Matapher‚ folgen würde – was ich generell begrüßen würde. Allerdings gibt es bereits einen  Seitentypen (Post Type) „Seiten“ und das stiftet ein wenig Verwirrung. Denn sowohl „Seiten“ als auch „Beiträge“ sind bei WordPress Seiten-Typen. Dieser Umstand ist vermutlich der Geschichte von WordPress zu verdanken – als Blog-Tool ging es zunächst eben hauptsächlich um „Posts“. Seiten waren dann eine spezielle Art von eines „Posts“. Aber das führt jetzt vielleicht zu weit.

Was macht WordPress zu einem Content Management System?

Für mich ist die Möglichkeit, eigene Seitentypen definieren zu können vermutlich das wichtigste Kriterium, das WordPress zu einem CMS macht. Wenn man unterschiedliche Inhalts-Typen oder Daten-Typen verwalten möchte, kommt man nicht darum herum, diese Daten unterschiedlich zu behandeln. Jeder Inhalts-Typ hat seine ganz speziellen Eigenschaften. Eine Webseite für ein Plattenlabel hat beispielsweise Seiten zu Bands, Seiten zu Alben, Seiten zu einzelnen Songs – und vielleicht einen Konzert-Kalender. Hinzu kommen Seiten mit allgemein gehaltenen Informationen zum Label – also zum Beispiel ‚Info-Seiten‘ über die Label-Geschichte etc.

Wordpress CMS: eigene Seiten-Typen definieren

WordPress: Übersicht des Seiten-Typen „Info-Page“

Unterschiedliche Inhaltstypen sind in der Regel zunächst mal unterschiedliche Daten-Typen. Um diesen Daten Bedeutung geben zu können, sollten sie entsprechend unterschiedlich behandelt bzw. gehandhabt werden können. Und das ist nur dann möglich, wenn das CMS auch wirklich unterschiedliche Daten- bzw. Inhaltstypen unterschiedlich behandeln kann. Als Folge können dann Inhaltstypen jeweils eigene Eingabefelder, ein eigenes Template, ein eigenes Layout, eine eigene ‚Gestalt‘ haben.

Seiten-Typen mithilfe von Themes vs. Plugins definieren

Es gibt eine Fülle von WordPress Themes – sowohl kostenpflichtige ‚Premium‘ Themes, als als kostenlose Themes. Ein Premium Theme zeichnet sich häufig dadurch aus, dass es für einen besonderen Anwendungsfall konzipiert wurde. Es gibt Premium Themes für so ungefähr jeden Anwendungsfall: Ein Premium Theme für Fotografen ist vielleicht besonders stark in der Präsentation von Fotos und bringt einen Seitentypen „Portfolio“ mit – ein Premium Theme für Veranstaltungsorte wird vermutlich einen Content Typen „Termine“ mitbringen.

Für viele Nutzer sind solche mehr oder weniger fertig eingerichteten Themes einfach praktisch. Für die verschiedenen Anwendungsfälle bringt das Theme gleich die passenden Seiten-Typen mit – man muß die Webseite dann ’nur noch‘ den eigenen Wünschen entsprechend anpassen. Allerdings findet dadurch auch eine Vermischung von Gestaltung und Funktion statt – die Seiten-Typen sind im Theme integriert. Das kann sich als Nachteil herausstellen, wenn man eines Tages beispielsweise die Gestaltung der Webseite ändern möchte, die Seiten-Typen aber behalten möchte.

Das Probleme wird auch „Theme-Lock“ genannt. Das bedeutet, man läuft Gefahr, sich von diesem einen speziellen Theme abhängig zu machen. Am Anfang mag man diese Gefahr noch nebensächlich erscheinen. Hat man aber erstmal hunderte oder tausende Datensätze eingegeben ist ein Umzug auf ein anderes Theme nur unter Einsatz von viel Arbeit möglich – oder man hilft sich mit einem speziell angepassten Child-Theme.

Eigene Seiten-Typen-Templates in WordPress definieren

Neben Themes gibt es natürlich auch zahlreiche Plug-ins, die entweder neue Seitentypen ‚fertig‘ zur Verfügung stellen, oder einem beim Einrichten von neuen Seitentypen helfen. Aber letztendlich ist es vermutlich die eleganteste Vorgehensweise, wenn man genau den Seitentypen selbst definiert, den man gerade benötigt.

Grundsätzlich lassen sich in WordPress eigene Seitentypen auf zwei Arten definieren: entweder über die functions.php Datei des Themes, oder über ein eigenes Plugin. Und das gehlt leichter, als man vielleicht zunächst vermutet. Eigentlich sind nur zwei Schritte notwendig: über eine Funktion wird zunächst der neue Seitentyp definiert. Dann muß diese Funktion initialisiert werden, um WordPress den neuen Inhaltstypen zur Verfügung zu stellen. Anschliessend kann man damit beginnen, eigene Templates für den neuen Seitentypen anzulegen.

Einen neuen Inhaltstyp in einer Funktion beschreiben

Der folgende Code kann im Prinzip auch als eigenständiges Plugin eingebunden werden. Hier gehen wir aber erst mal davon aus, dass der Code der Theme-Datei functions.php hinzugefügt wird. Das ist zwar langfristig nicht ganz so flexibel, wie ein Plugin, da nun der Content-Typ mehr oder weniger mit dem Theme verknüpft ist – führt aber erst mal zu demselben Ziel:

function my_custom_content_type() {
$labels = array(
 'name'               => 'Info-Page',
 'singular_name'      => 'Info-Page',
 'menu_name'          => 'Info-Pages',
 'name_admin_bar'     => 'Info-Page'
};

$args = array(
 'labels'              => $labels,
 'public'              => true,
 'exclude_from_search' => false,
 'publicly_queryable'  => true,
 'show_ui'             => true,
 'show_in_nav_menus'   => true,
 'show_in_menu'        => true,
 'show_in_admin_bar'   => true,
 'menu_position'       => 5,
 'menu_icon'           => 'dashicons-admin-appearance',
 'capability_type'     => 'post',
 'hierarchical'        => false,
 'supports'            => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ),
 'has_archive'         => false,
 'rewrite'             => array( 'slug' => 'info-page' ),
 'query_var'           => true
 );

register_post_type( 'custom_content_type', $args );#
 // flush_rewrite_rules();
 }

add_action( 'init', 'my_custom_content_type', 0 );

Der oben gezeigt Code ist bereits vollkommen ausreichend, um den neuen Content-Typen „Info Page“ einzurichten. Anschliessend wird im Administrationsbereich ein neuer menupunkt „Info Pages“ zu sehen sein, über den sich Seiten anlegen und verwalten lassen.

Abschliessend können wir dem Theme nun auch noch eine neue Template-Datei für den eben definierten Inhaltstypen hinzufügen. Diese wird dann von WordPress automatisch erkannt und  geladen, um Inhalte dieses Typs anzuzeigen. Zunächst genügt es vollkommen, wenn die Datei „single.php“ als Kopie unter neuem Namen „single_custom_content_type.php“ abgespeichert und in das Theme-Verzeichnis des Servers geladen wird – in diesem Falle wäre das dann „single_info-pages.php“. Diese wird allerdings nur dann die passenden Inhalte laden können, wenn in dieser Datei folgende Zeile angepasst wird.

Schritt zwei: Initialisierung der Funktion / des Inhaltstypen

In der Datei  „single_custom_content_type.php“ anstelle von diesem Code-Schnippsel:

<?php get_template_part( 'content', get_post_format() ); ?>

…sollte mit folgendem Code-Schnippsel ersetzt werden:

<?php get_template_part( 'content', 'custom_content_type' ); ?>

…und fertig ist die Laube…

Vorteile von eigenen Seiten-Typen

Sogar ohne eigene Felder und ohne zusätzliche Style-Definitionen etc. ergeben sich umgehend folgende Vorteile:

  • Der Pager / die Blätterfunktion erkennt den neuen Inhaltstypen. Innerhalb eines Inhaltstypen läßt sich so direkt von Seite zu Seite blättern, ohne dass unterschiedliche Inhalte miteinander vermischt werden.
  • Die Navigationsleiste des Administrationsbereichs bekommt automatisch neue Funktionalitäten: mit einem Klick lassen sich alle Inhalte gleichen Typs übersichtlich auflisten und neue Seiten dieses Types hinzufügen (siehe Abbildung oben).
  • Seiten des neuen Inhaltstypen teilen sich alle dasselbe Stammverzeichnis, das im Code oben unter ’slug‘ bzw. unter  „rewrite“ angegeben wird. Dies gibt den Seiten Bedeuteung, sowohl für Nutzer, die die Seite aufrufen und die URL sehen, als auch für Suchmaschinen. Ausserdem können alle Seiten dieses Typs übersichtlich in einer  Web-Statistiken (z.B. PiWik) miteinander verglichen werden.

Das Definieren von speziellen Inhaltstypen ist natürlich nur ein erster Schritt. Aber immerhin. In den meisten Fällen möchte man nun vermutlich auch eigene Felder definieren – also eine spezielle EIngabemaske für diesen Content-Typen einrichten. Ob man nun diese Felder selbst per Code definiert oder ein PlugIn dafür nutzt muss natürlich jeder selbst für sich entscheiden. Wenn man bespielsweise vorwiegend Webseiten für Bands baut kann es sinnvoll sein. die Eingabemaske selbst zu programmieren und langfristig vielleicht ein eigenes Plugin zu entwickeln. Für die meisten Anwendungsfälle dürfte es aber ausreichen, ein entsprechendes Plug-In wie z.B. ACF oder Pods zu nutzen. Dazu mehr in einem anderen Artikel.

Inhaltstypen für bereits bestehende Seiten ändern

Häufig sieht die Situation ja so aus: man hat bereits eine WordPress-Installation mit einigen Einträgen und Seiten – unter Umständen hat man bereits viele Seiten. Dann kommt man irgendwann auf die Idee, dass es praktischer wäre, einige der Seiten einem neuen, eigenen Inhaltstypen zuzuordnen. Das ist dan des kleinen Plugins Post Type Switcher (wordpress.org/plugins/post-type-switcher/) relativ einfach machbar. Man muß das Plugin nur installieren und aktivieren und schon bekommt man für alle Seiten eine kleine Dropdown-Auswahl, über die sich der Seitentyp nachträglich ändern läßt. Und natürlich gibt es auch eine Möglichkeit, per Massen-Aktualisierung gleich meherere Seiten auf einemal einem neuen Inhaltstypen zuzuordnen. Und bei Fragen: einfach fragen!

WordPress: PiWik-Statistik – nur Besucher zählen

Die frei verfügbare quelloffene (Open SOurce) Statistik-Lösung PiWik wird immer beliebter –  Webseiten-Besucher mit PiWik zu zählen wird allmählich zu einem Standard. kein Wunder: PiWik läßt sich problemlos mit populären Content Management Lösungen wie Drupal und WordPress integrieren – und PiWik läßt sich vor allem verhältnismäßig einfach auf dem eigenen Webserver installieren. Damit bleiben die erfassten Daten beim Webseitenbetreiber – und nicht bei einem Dritten.

Eine kleine Schwierigkeit war allerdings manchmal, dass man auch selbst gezählt wurde – und dass somit die Statistik nicht so richtig aussagekräftig war. Bei Verwendung von WordPress (oder Drupal) kann man diese Selbst-Zählung aber mit einem kleinen Trick umgehen. Man kann direkt feststellen, ob der aktuelle Besucher auch im CMS angemeldet ist, oder nicht. Nicht-angemeldete Besucher werden gezählt, angemeldete Besucher werden nicht gezählt.

Natürlich gibt es einige Plugins, mit denen sich diverse PiWik-Einstellungen bequem über das gewohnte WordPress-Interface bearbeiten lassen. Das ist auch schön und gut, aber ich bevorzuge es eigentlich, den PiWik-Code direkt ins Template einzubinden, ohne ein weiteres Plugin zu installieren. Dazu kopiere ich einfach den Tracking-Code direkt in die Datei footer.php des aktuell verwendeten WordPress-Themes.

Mithilfe einer WordPress-Funktion ‘is_user_logged_in()‘ läßt sich dann einfach prüfen, ob der aktuelle Besucher eingeloggt ist, oder nicht. Setzt man ein Ausrufezeichen „!“ vor den Funktionsnamen, wird der nachfolgende Code nur dann ausgeführt, wenn der aktuelle Besucher nicht angemeldet ist. AUfrufe von Administratoren und Redakteuren werden dann nicht gezählt.

Hier der Code-Schnippsel:

<?php wp_footer(); ?>
<?PHP if ( !is_user_logged_in() ) { ?>
<!-- Piwik -->
<script type="text/javascript">
...
<!-- End Piwik Code -->
<?PHP } ?>
</body>
</html>

Kostenlose VPN-Dienste und die Sicherheit vs freedome von F-Secure

Ich habe mich gerade mal wieder nach einem kostenlosen VPN-Dienst umgesehen. Mein bevorzugtes Setup im Prinzip ein kostenloses VPN-Plugin für den Browser, das ohne Registrierung oder Anmeldung funktionieren würde. Schließlich will ich eigentlich nur hin und wieder mal eine Webseite unter anderer ‚Länder-Herkunft‘ aufrufen.

Wofür brauche ich einen VPN-Dienst? Was macht ein VPN-Dienst?

Ich halte VPN-Dienste grundätzlich für eine großartige Erfindung – aber sie können ein wenig unheimlich werden, wenn man sich ansieht, wie ein VPN das ganze funktioniert. Und das gilt insbesondere dann, wenn man sich Gedanken über Sicherheit und Datenschutz macht. VPN steht für Virtual Private Network. Ein VPN-Dienst erlaubt es dem Nutzer, das Internet über sogn. Proxi-Server zu nutzen. Damit kann die eigentliche Herkunft des Nutzers verschleiert werden, und man hat eigentlich ein wenig zusätzliche Privatspäre gewonnen. Ich kann also mithilfe eines VPN-Dienstes aus Deutschland heraus Internetseiten aufrufen, ohne mein Herkunftsland ‚Deutschland‘ priszugeben. Stattdessen könnte ich mir den Stempel bzw. eine IP-Adresse mit dem Absender ‚Finnland‘ aufdrücken – und schon interpretieren die kontaktierten Webserver mein Herkunftsland als ‚Finnland‘.

Das ist aber nur dann der Fall, wenn der VPN-Dienst auch vertrauenswürdig mit den Daten umgeht. Immerhin vertraut man ihm seinen gesamten Datenverkehr an – und der VPN-Dienst kann damit im Prinzip tun und lassen was er möchte.

Ich habe also mal wieder eine 5-Minuten Recherche gemacht und fand den Dienst ‚Hola‘ zunächst ganz interessant. ALlerdings ist es immer eine gute Idee, auch nach eventuell bekannten Problemen zu googlen – und da sah ‚Hola‘ dann plötzlich gar nicht mehr so gut aus: massive Sicherheitsprobleme, von denen niemand sagen konnte, ob es sich dabei um Sicherheitslücken oder um absichtlich implementierte ‚Hintertüren‘ handelte:

Die Sicherheitslücken des Browser Plugins würden es einem Angreifer erlauben, den Internetverkehr des betroffenen Rechners zu kontrollieren. Damit ließe sich dann theoretisch auch ein Angriff gegen Dritte führen – tausende Nutzer könnten von einem Angreifer zu einem sogn. Botnet bzw. zu einer Botnet-Armee verbunden werden. Der Angreifer könnte dann ferngesteuert Angriffe gegen Webserver und Rechenzentruen, zum Beispiel sogn. DDoS-Attacken durchführen, ohne dass die betroffenenen, angreifenden Nutzer etwas davon mitbekämen. Nicht gut.

nicht kostenlos, aber vertrauenserweckend: Finnischer VPN-Dienst Freedome

Ich habe mich dann lieber noch mal nach Alternativen umgesehen. Mein aktueller Favourit ist freedome vom finnischen Sicherheits-Dienstleister f-secure. Der Dienst ist zwar nicht kostenlos – und man muss sich auch registrieren, um den Dienst nutzen zu können. Beides waren ursprünglich Ausschlusskriterien – aber letztendlich beisse ich lieber in diese zwei sauren Äpfel, als Teil einer Botnet-Armee zu werden.

Ich kenne F-Secure schon seit sehr langer Zeit. Ich fand es eigentlich immer gut, was die Finnische Firma in der Vergangenheit gemacht hat. Ich bin zuversichtlich, dass ich auch ihren VPN-Dienst Freedome mögen werde.

Vorteile eines VPN-Dienstes / Gründe für VPN

Eigentlich ist es ganz einfach: mithilfe eine VPN-Dienstes wird man einigermaßen ‚un-trackbar‘ – zumindest für die meisten Webserver und Webseiten. Und das kann einige Vorteile mit sich bringen:

  • Wie bereits erwähnt kann man sich ein abweichendes Landesfähnchen umhängen – also man kann vorgeben, aus einem anderen Land zu sein. Damit bekommt man unter Umstaänden Zugriffen auf Webseiten, die den Zugang auf bestimmte Herkunftsländer einschränken.
  • Als Web-Entwickler kann man mithilfe eines VPN-Dienstes eigene Geo-tracking-aktive Dienste und Funktionalitäten testen. Das wäre ohne VPN nur schwer möglich.
  • Einige Webseiten und Web-Dienste nutzen inzwischen sogenannte SUper-Cookies, um Nutzer über unterschiedliche Webseiten hinweg verfolgen (tracken) zu können. Solche Super-Cookies laufen bei VPN-Anwendern quasi ins Leere.
  • Die Nutzung von VPN-Diensten kann auch Sicherheitsvorteile bieten, da man nun nicht mehr direkt, sondern über den VPN-Proxi auf potentiell gefährliche Webseiten zugreift.

Ich werde jetzt mal die Testverion von Freedome installieren und mich dann zu gegebener Zeit mit einem Erfahrungsbericht melden.

 

Flash im Browser ausschalten [wg. Sicherheitslücke]

Update 10.Juli 2015: leider ist diese kleine Anleitung wieder bzw. immer noch aktuell. Wie vermutlich allgemein aus Funk und Fernsehen bekannt ist, wurde das sogn. „Hacking Team“ gehackt. Damit dürfte auch deren Werkzeugkasten in Umlauf sein – und darunter dürften sich auch Flash-Exploits befinden. Also – lieber erst mal ohne Flash. siehe auch: The Latest Flash 0-day is no Joke (A List Apart)

Nach dem letzten Alarm habe ich meinen Flash-Player bzw. mein Flash-PlugIn immerhin auf „immer fragen“ gestallt, so dass ich nur bewusst Flash-Filme geladen habe. Erst dachte ich, das wäre übertrieben – aber es war wohl doch richtig: denn jetzt ist wieder eine kritische Sicherheitslücke im Flash-Player bekannt geworden.

Heise News berichtet, dass der Exploit auf dem populären Video-Portal DailyMotion entdeckt wurde. Ausserdem sind je nach Player-Version wieder die drei Betriebssysteme Windows, Macintosh und Linux betroffen. Ein Patch soll diese Woche erscheinen.

Ich werde aber ist auf weiteres mein Flash-PlugIn nur dann starten, wenn es wirklich sein muss. Hier schnell ein Screenshot der vielleich für diejenigen hilfreich sein kann, die Ihren Firefox ebenfalls so einstellen wollen:

Mac OS Firefox: Flash ausschalten

Flash im Browser Firefox ausschalten – Screenshot: T.Bortels/cpu20.de

Flash auf Mac-Safari und Chrome deaktivieren

Weiterlesen

Links individuell per css stylen

Zeit für einen weiteren CSS-Notizbucheintrag: wie ist die korrekte CSS-Formatierung für Links? Das klingt jetzt erst mal vielleicht trivial, aber wenn es so trivial ist, dass man jedes mal die Suchmaschine anwirft, dann wird es eben Zeit für einen Notizbucheintrag…

Also – es geht um folgendes. Ich habe zwei unterschiedliche Links – und die sollen beide unterschiedlich gestaltet sein – unterschiedliche CSS-Anweisungen bekommen. Dazu fügt man dem Link-Tag jeweils eine eigene Klasse zu.

<a href=“#“ class=“class1″>Linktitel1</a>
<a href=“#“ class=“class2″>Linktitel2</a>

Im Prinzip ginge das natürlich auch über eine individuell vergebeme ID – aber in diesem konkreten Fall ging es eigentlich um mehrere Links, die jeweils der einen oder anderen Style-Gruppe zuzuordnen waren. Daher machen wir das also dementsprechend über die class.

Der CSS-Code für die verschiedenen Link-Zustände sieht dann so aus:

<style>
<!--
/* class1 */
 a.class1:link {
  }
 a.class1:visited {
  }
 a.class1:hover {
  }
/* class2 */
 a.class2:link {
  }
 a.class2:visited {
  }
 a.class2:hover {
  }

 //-->
</style>

Da sind jetzt natürlich noch keine Style-Anweisungen eingetragen – aber ich hoffe doch, dass das Prinzip klar ist. Der entscheidende Punkt war für mich auch lediglich festzuhalten, wie denn nun die Style-Anweisungen genau formatiert sein müssen, um auch angezeigt zu werden. Also: wenn man dem Link direkt eine Klasse zuweist kommt die Klasse im CSS direkt an das a – ohne Leerzeichen – gefolgt von den Pseudoklassen für die Zustände hover und active – wieder ohne Leerzeichen.

Das kann zum Beispiel dann praktisch sein, wenn man in einer Navigation einen Link besonders hervorheben möchte. So lassen sich beispielsweise die Links für „Aktuelles“ oder für einen Sprachwechsler „English“ von der übrigen Navigation ganz einfach unterscheiden.

memory_limit per htaccess manuell einstellen

Manche Server-Prozesse brauchen mehr Rechenpower, als die Standardeinstellungen des Servers hergeben. Zum Beispiel verlangt die Zusammenstellung der Jahresansicht im Statistik-Tool Piwik nach deutlich mehr Memory, als  beispielsweise bei all-inkl voreingestellt ist.

Wenn man seine Webseite auf einem sogn. Shared-Server laufen hat, sind die Möglichkeiten häufig begrenzt. Man kann zwar beim Support nachfragen, ob die das Memory-Limit nicht vielleicht ein wenig hochschrauben können, aber meistens stößt man damit auf taube Ohren. Verständlich: schließlich teilen sich duzende, manchmal hunderte Kunden bzw. Webseiten die Rechenleisung eines Shared-Servers.

Anders bei sogn. Managed-Servern. Das man bei diesem Hosting-Modell der einzige Kunde ist, kann man fröhlich das Memory-Limit hochschrauben. Das kann man für jeden Webspace, für jede Domain oder auch für jedes Verzeichnis einzeln definieren. Dafür genügt es, einen kleinen Eintrag in der htaccess-Datein hinzuzufügen, mit dem man das  memory_limit manuell einstellen kann. Hier exemplarisch die Einstellung für ein memory_limit von 265MByte:

php_value memory_limit 256M

Damit riskiert man zwar, dass andere Prozesse bzw. der ganze Server vorübergehend etwas langsamer läuft – aber wenn es sich nur um die monatliche Zusammenfassung der Zugriffsstatistik handelt kann man das schon mal machen.