WordPress-Themes und die GPL

Das Content Management System WordPress ist unter der GPL lizenziert und damit stellt sich die Frage, ob Themes unter WordPress ebenfalls unter der GPL lizenziert sind? Die kurze Antwort: Themes müssen unter der GPL lizenziert werden. Im Detail können bei der Frage allerdings Abstufungen vorgenommen werden. Die GPL definiert eine Reihe von Freiheiten:

Die Freiheit, das Programm auszuführen wie man möchte, für jeden Zweck (Freiheit 0).

Die Freiheit, die Funktionsweise des Programms zu untersuchen und eigenen Datenverarbeitungbedürfnissen anzupassen (Freiheit 1). Der Zugang zum Quellcode ist dafür Voraussetzung.

Die Freiheit, das Programm zu redistribuieren und damit Mitmenschen zu helfen (Freiheit 2).

Die Freiheit, das Programm zu verbessern und diese Verbesserungen der Öffentlichkeit freizugeben, damit die gesamte Gesellschaft davon profitiert (Freiheit 3). Der Zugang zum Quellcode ist dafür Voraussetzung.

Da die PHP-Dateien eines Themes die unter der GPL lizenzierten Schnittstellen von WordPress nutzen, muss das Theme ebenfalls unter der GPL lizenziert werden. Das Theme läuft niemals für sich alleine, sondern benötigt zwingend die entsprechenden WordPress-Schnittstellen. Sobald ein Theme distribuiert wird, muss es unter der GPL lizenziert werden.

Mit Themes lässt sich das Aussehen der Webseite anpassen

Mark Jaquith, einer der Entwickler von WordPress drückte das Ganze wie folgt aus:

Theme code necessarily derives from WordPress and thus must be licensed under the GPL if it is distributed.

Der Einwand, welcher ab und an vorgebracht wird, das mit einem GPL-Theme kein Geld verdient ist dabei haltlos. Die GPL verbietet es nicht mit GPL-Software Geld zu verdienen. So kann ein Ersteller eines Themes die Themes verkaufen. Natürlich könnte nun ein Käufer das Theme anderweitig bereitstellen, allerdings kann der Nutzer bei vielen Erstellern Updates der Themes und Support dazu kaufen. Dies stellt einen Mehrwert gegenüber eine Theme da, welches eventuell schon veraltet ist.

Theoretisch können WordPress-Themes unter unterschiedlichen Lizenzen angeboten werden. Dies war beim Theme Thesis der Fall. Hier sind sämtliche PHP-Dateien unter der GPL lizenziert, während CSS- und JavaScript-Dateien proprietär sind. Interessant wird es bei Lizenzbedingungen, des Theme-Erstellers, welche gegen die GPL verstoßen. Technisch betrachtet dürften solche Themen nicht mit WordPress genutzt werden.

WordPress ist nicht das einzige System, bei welchem sie die Rechtslage so darstellt, so erklärt die FAQ des Content Management Systems Drupal:

Drupal modules and themes are a derivative work of Drupal. If you distribute them, you must do so under the terms of the GPL version 2 or later. You are not required to distribute them at all, however. (See question 8 below.)

Wie sieht, es in dem Fall aus das ein Theme erstellt wurde und dieses Theme auf der eigenen Webseite genutzt wird? Muss dieses Theme nun unter GPL bereitgestellt werden? Die Antwort darauf ist nein. Der Grund hierfür ist das, wenn ich ein unter GPL lizenziertes Produkt ausliefere, ich den Quelltext dazu veröffentlichen muss. Allerdings liefert WordPress keine Themes, sondern Webseiten aus. Deshalb muss der Quelltext des Themes nicht bereitgestellt werden. Wäre dies der Fall wären z.B. alle Dokumente welche mit LibreOffice erstellt werden auch unter der GPL lizenziert werden. Dazu noch einmal Mark Jaquith:

No. The GPL is triggered by distribution. Work-for-hire for a client is not distribution. In this case, they would have the copyright on the code. Distributing it would be up to them. As long as they didn’t distribute it, the GPL wouldn’t kick in. Your clients needn’t worry.

WordPress-Suchwidget auf bestimmte Post Types beschränken

Für eine WordPress-Installation war ich auf der Suche nach einer Möglichkeit die Suche bzw. im Speziellen das Suchwidget so zu beschränken das nur die Post Types page und post durchsucht und angezeigt werden. Möglich ist dies, indem ein Filter für pre_get_posts in die functions.php des Themens hinzugefügt wird:

function search_only_in_specific_post_types( $query ) {
	
  // Modify query (but only in frontend)
  if ( $query->is_search && is_admin() == false ) {
    $query->set( 'post_type', array( 'page','post') );
  }
	
  return $query;
}

add_filter( 'pre_get_posts', 'search_only_in_specific_post_types' );

Der Filter passt die Query an, wenn die Query für eine Suche genutzt wird und diese Nutzung aus dem Frontend heraus geschieht. Die Begrenzung auf des Frontend ist notwendig um keine Suchqueries im Backend zu stören. Damit würde die modifizierte Suche nur noch Dokumente mit dem Post Type page und post finden.

Theme und Plugins einer WordPress-Installation ermitteln

WordPress ist einer der meistgenutzten Content-Management-Systeme unserer Zeit. Wenn WordPress für die eigenen Webseiten und Projekte genutzt wird, kann es manchmal von Interesse sein herauszufinden, welche Themes und Plugins andere WordPress-Seiten nutzen. Mit Hilfe des WP-ThemeDetector ist genau so etwas möglich.

Neben dem Theme können auch genutzte Plugins ermittelt werden

Nach der Eingabe der gewünschten Ziel-URL, versucht der WP-ThemeDetector zu ermitteln, welches Theme und welche Plugins auf der Seite verwendet werden. Für das Theme werden die Informationen aus der style.css-Datei des Themes extrahiert. Bei Plugins werden deren Spuren im Quelltext ausgewertet. Dies führt bei den Plugins dazu das nicht alle Plugins ermittelt werden können, da manche Plugins nur im Backend wirken oder keine größeren Spuren im Quelltext der Seite hinterlassen. Der WP-ThemeDetector ist unter wpthemedetector.com zu finden.

Footer zu Beiträgen unter WordPress hinzufügen

Nachdem ein WordPress-Beitrag geschrieben und veröffentlicht wurde, wird er im Normalfall nicht mehr modifiziert. In meinem Fall wollte ich bestehende Beiträge um einen Footer ergänzen, konkret um auf die Möglichkeit hinzuweisen mich auf Steady zu unterstützen. Dazu existieren einige Plugins, welche allerdings in den meisten Fällen veraltet sind, wie z.B. Bottom of every post.

Bottom of every post
Preis: Kostenlos

Wesentlich aktueller ist das weiter gefasste Plugin Head, Footer and Post Injections, welches neben dem Beitragsfooter auch die Seitenheader und Footer anpassen kann.

Mit diesem Plugin kann für alle Beiträge ein Footer definiert werden. Dazu müssen die Einstellungen im Backend mit dem Punkt Header and Footer geöffnet werden und dort der Tab Posts ausgewählt werden. Wenn kein zusätzliches Plugin installiert werden soll, kann stattdessen das Theme angepasst werden. Dafür muss in der Theme-Datei functions.php eine Funktion angelegt werden:

function addPostFooter($content) {
  if(is_single()) {
    $content .= '<hr/>';
    $content .= 'Ich bin ein Testfooter';
  }

  return $content;
}

add_filter('the_content', 'addPostFooter');

Diese Funktion wird anschließend mittels add_filter zu den Filtern hinzugefügt und sorgt dafür dass der Footer an jedem Beitrag zu finden ist.

Waipoua-Theme für den Podlove Publisher anpassen

Seit meinem letzten Wechsel des Designs auf seeseekey.net nutze ich eine stark modifizierte Version des Elmastudio-Themes Waipoua. Neben Anpassungen am Design wurden unter anderem die externen Einbindungen der Google Fonts deaktiviert. In den aktuellen Themes von Elmastudio werden diese leider immer noch extern eingebunden; was wohl auch auf absehbare Zeit so bleibt.

Leider hat das Waipoua-Theme einige Probleme mit dem Plugin Podlove Publisher. Der Podlove Publisher ist ein Plugin, welches einen Workflow für Podcasts, vom Anbieten bis zum Abonnieren bereitstellt.

Podlove Podcast Publisher
Preis: Kostenlos

Das erste Problem mit dem Podlove Publisher im Zusammenhang mit dem Waipoua-Theme ist die Anzeige der von Beiträgen mit dem Post Type podcast auf der Startseite. In den Experteneinstellungen des Podlove Publishers ist dies die Einstellung Blog und Podcast kombinieren. Damit dies mit dem Waipoua-Theme funktioniert muss die Datei index.php des Themes angepasst werden. Dort findet sich folgende Quelltextblock:

<?php /* Start the Loop */ ?>
<?php global $query_string;
query_posts( $query_string . '&ignore_sticky_posts=1' ); ?>

  <?php while ( have_posts() ) : the_post(); ?>

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

  <?php endwhile; // end of the loop. ?>

<?php wp_reset_query(); // reset the query ?>

An dieser Stelle werden sämtliche Manipulationen der Abfrage entfernt. Anschließend sollte der Code so aussehen:

<?php /* Start the Loop */ ?>

  <?php while ( have_posts() ) : the_post(); ?>

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

  <?php endwhile; // end of the loop. ?>

Nach dieser Modifikation tauchen die Beiträge mit dem Post Type podcast in der Beitragsliste im Startmenü auf. Das nächste Problem betrifft die Darstellung der Beiträge mit dem Post Type podcast, sobald diese einzeln angezeigt werden. Hierbei wird das Design zerschossen, da der Beitrag in voller Breite angezeigt wird. Eine Sidebar würde in diesem Szenario nach unten rutschen.

Nach dem Fix funktionieren die Einzelseiten mit dem Post Type podcast

Um dies zu verhindern muss die Datei header.php angepasst werden. Dort findet sich nach dem schließenden head-Tag die Zeile:

<body <?php body_class(); ?>>

Diese Zeile wird entfernt und stattdessen durch folgenden Quellcode ersetzt:

// Fix problem with single posts (post type: podcast)
$body_class = get_body_class();

// single-podcast exists in body class, replace
if (in_array("single-podcast", $body_class)) {

  echo "<body class=\"";

  foreach($body_class as $body_class_value) {
    if ($body_class_value == "single-podcast") {
      $body_class_value = "single-post";
    }

    echo $body_class_value . " ";
  }
  
  echo "\" >";
}
else {
?>
  <body <?php body_class(); ?>>
<?php
}
?>

Der Quellcode sorgt dafür das die Klasse single-podcast in single-post umbenannt wird. Damit greift das CSS für gewöhnliche Beiträge und die Darstellung der Podcast-Seiten funktioniert ohne Probleme. Als letzten Schritt habe ich die archive.php angepasst. In der Datei wurde der komplette header-Block entfernt. Diese Anpassung ist im Gegensatz zu den anderen Anpassungen Geschmackssache. Sie sorgt dafür das keinerlei Archivtexte mehr auftauchen.