Vorbei mit my-hacks.php?

Anzeige

Noch diesen Monat soll die neue Version 2.8 von WordPress erscheinen; in der Blogosphäre wird schon lange kein so großer Wind mehr darum gemacht, wie es noch in den Jahren um Version 2.0 war. Aber der Linkmangel etc. wird ja auch in anderen Themen bemängelt.

Die neue Version bringt viele neue Sachen, fixt eine große Anzahl von Problemen und WordPress gestaltet sich aus meiner Sicht noch offener als in den Versionen zu vor. Eine der Punkte, die Benutzer beachten sollten, ist die Tatsache, dass man die Option für die Unterstützung der my-hacks.php entfernt. 2003 wurde diese Datei noch als Feature angekündigt, geht sie nun wieder still und leise. WordPress hat ein ausgefeiltes Schnittstellen-System; man kann an diversen Punkten ansetzen und neue Funktionalitäten einbringen, so dass man sich dazu entschieden hat, die Lösung nicht mehr zu unterstützen. Alternativen und Möglichkeiten des weiteren Nutzen will hier kurz aufzeigen.

my-hacks.php weiter nutzen

Die Datei mit eigenen Erweiterungen kann auch in 2.8 weiter genutzt werden, sie wird nur nicht mehr per Option aus dem Backend aktiviert. Will man dies tun, so muss man den Eintrag hack_file in der Tabelle options auf 1 setzen.
Dies geschieht entweder direkt in der Datenbank, beispielsweise über phpMyAdmin oder via Code:

update_option( 'hack_file', 1 );

Alternativ kann man die Option via Plugin wieder in das Backend holen, siehe Beitrag und Plugin-Download bei Schurpsel.

Die Abfrage der Datei ist weiterhin im Core und soll auch so bleiben, auch die Abfrage des Felder in der Datenbank soll bleiben.

// Check for hacks file if the option is enabled
if ( get_option('hack_file') ) {
	if ( file_exists(ABSPATH . 'my-hacks.php') )
		require(ABSPATH . 'my-hacks.php');
}

Damit bleibt alles beim alten, wer das möchte. Die Datei weiterhin im Root (ABSPATH) der Installation ablegen und sie wird gezogen.

Die Überlegung die Datei nicht mehr zu unterstützen ist natürlich mit Überlegungen verbunden und da WordPress ausgezeichnete Schnittstellen bietet, ist die Unterstützung nicht mehr als relevant angesehen. Außerdem wird die Datei recht früh gezogen und lässt sich damit nicht immer so sauber steuern, wie man das von anderen Schnittstellen kennt. Eine Prüfung auf Intoleranzen und Probleme ist garnicht vorhanden und die Datei kann auch das System bremsen.

via Plugin

Eine der Schnittstellen ist die Plugin-Schnittstelle und daher bietet es sich an, dass man sich ein Plugin anlegt, in dem man die kleinen Hacks ablegt. Entweder man lernt wie das geht, zum Beispiel in meinem kleinen Tutorial zum Plugin schreiben oder hier die Vorlage.

Einfach eine PHP-Datei anlegen und folgenden Syntax rein, dann die eigenen Hacks dort ablegen und die Datei in das Plugin-Verzeichnis kopieren. Im Backend muss es dann nur noch aktiviert werden.

<?php
/*
Plugin Name: my-hacks.php
Plugin URI: http://
Description: my-hacks.php - Ersatz seit WordPress 2.8
Author: DU
Version: 0.1
Author URI: http://
*/

/**
 * hier die Hacks ablegen
 */

?>

Theme-Funktionen

Das aktive Theme kann immer eigene Funktionen hinzubringen, dazu wird die Datei functions.php genutzt und die kann jedem Theme hinzugefügt werden. Gedacht ist sie, um explizit für das jeweilige Theme, neue Funktionen einzubringen. Daher kann man auch die Hacks dort ablegen, also einfach in die functions.php des Themes schreiben, hochladen in den Theme-Ordner und fertig.

Alternative Sprachordner

Ein dritte Möglichkeit um eigene Funktionen einzubringen ist der Sprachordner, im Standard ist das /wp-content/languages/; wp-content kann seit Version 2.5 verschoben und umbenannt werden. Wenn ein Sprachschlüssel in der wp-config.php gesetzt ist, zum Beispiel de_DE, dann wird durch WordPress in dem Ordner nach einer Sprachdatei .mo- und einer .php-Datei gesucht und wenn vorhanden, gezogen.

define ('WPLANG', 'de_DE');

/**
 * The locale of the blog
 * @since 1.5.0
 */
$locale = get_locale();
$locale_file = WP_LANG_DIR . "/$locale.php";
if ( is_readable($locale_file) )
	require_once($locale_file);

/**
 * Loads the theme's translated strings.
 *
 * If the current locale exists as a .mo file in the theme's root directory, it
 * will be included in the translated strings by the $domain.
 *
 * The .mo files must be named based on the locale exactly.
 *
 * @since 1.5.0
 *
 * @param string $domain Unique identifier for retrieving translated strings
 */
function load_theme_textdomain($domain, $path = false) {
	$locale = get_locale();

	$path = ( empty( $path ) ) ? get_template_directory() : $path;

	$mofile = "$path/$locale.mo";
	load_textdomain($domain, $mofile);
}

Dies sollte natürlich nur für Hacks und Funktionen genutzt werden, die mit der Sprache des Blog zu tun haben und nicht missbraucht werden. Im Grunde kann man aber auch dort Funktionen ablegen. Diese Möglichkeit ist vor allem sehr gut geeignet und sprachtypische Funktionen abzulegen, wie zum Beispiel das die URL bei Permalinks sauber übergeben wird (ue statt u bei ü etc.).