WordPress 3.4 - Theme Core Änderungen und weiße Seiten

codestyling | 20. Mai 2012 | 17:55

Ich hab nun eine Weile mit der kommenden Version von WordPress experimentiert. Dabei habe ich eine Vielzahl von verschiedenen Themes getestet und dabei wieder mal ein paar unschöne Feststellungen gemacht.

Der Theme Kern von WordPress wurde komplett neu geschrieben. An sich eine feine Sache, wenn da nur nicht eine Menge Probleme zum Vorschein kommen würden. Denn nun hat man bei den meisten Themes, die im Umlauf sind, deprecated Warnungen auf der Seite.

Theme Core - Funktionen als veraltet erklärt

Nach Durchsicht der bisherigen, verfügbaren Sourcen der kommenden WordPress Version 3.4 habe ich mal eine Zusammenstellung der Funktionen gemacht, die aktuell in Themes verwendet werden, aber nun als veraltet erklärt wurden:

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

function get_allowed_themes() {
   _deprecated_function( __FUNCTION__, '3.4', "wp_get_themes( array( 'allowed' => true ) )" );
 
function get_broken_themes() {
   _deprecated_function( __FUNCTION__, '3.4', "wp_get_themes( array( 'errors' => true )" );
 
function current_theme_info() {
   _deprecated_function( __FUNCTION__, '3.4', 'wp_get_theme()' );
 
function get_site_allowed_themes() {
   _deprecated_function( __FUNCTION__, '3.4', 'WP_Theme::get_allowed_on_network()' );
 
function wpmu_get_blog_allowedthemes( $blog_id = 0 ) {
   _deprecated_function( __FUNCTION__, '3.4', 'WP_Theme::get_allowed_on_site()' );
 
function get_themes() {
   _deprecated_function( __FUNCTION__, '3.4', 'wp_get_themes()' );
 
function get_theme( $theme ) {
   _deprecated_function( __FUNCTION__, '3.4', 'wp_get_theme( $stylesheet )' );
 
function get_current_theme() {
   _deprecated_function( __FUNCTION__, '3.4', 'wp_get_theme()' );
 
function add_custom_image_header( $wp_head_callback, $admin_head_callback, $admin_preview_callback = '' ) {
   _deprecated_function( __FUNCTION__, '3.4', 'add_theme_support( \'custom-header\', $args )' );
 
function remove_custom_image_header() {
   _deprecated_function( __FUNCTION__, '3.4', 'remove_theme_support( \'custom-header\' )' ); 
 
function add_custom_background( $wp_head_callback = '', $admin_head_callback = '', $admin_preview_callback = '' ) {
   _deprecated_function( __FUNCTION__, '3.4', 'add_theme_support( \'custom-background\', $args )' ); 
 
function remove_custom_background() {
   _deprecated_function( __FUNCTION__, '3.4', 'remove_theme_support( \'custom-background\' )' ); 
 
function get_theme_data( $theme_file ) {
   _deprecated_function( __FUNCTION__, 3.4, 'wp_get_theme()' );
timing: 0.040s

Dies äußert sich dann in der anzuzeigenden Seite mit einer oder sogar mehreren Warnungen dieser Art:

PHP
1

Notice: add_custom_background is deprecated since version 3.4! Use add_theme_support( 'custom-background', $args ) instead. in C:\xampp\__root_wordpress_34\wp-includes\functions.php on line 2705
timing: 0.027s

Es ist also notwendig, die eigenen (oder eingesetzten) Themes auf den aktuelle Stand zu bringen. Dies gestaltet sich allerdings ein wenig schwierig, wenn man Themes abwärtskompatibel halten will. Denn nicht jeder wird sofort auf WP 3.4 updaten und eine direkte Änderung der Themes auf 3.4 Niveau würde u.U. eine weiße Seite provozieren.

Deswegen hier ein Beispiel, wie man Rückwärtskompatibilität in das Theme bekommt. Exemplarisch habe ich eine Funktion ausgewählt, für alle anderen bekommt man das genauso hin, ist nur ein wenig Aufwand:

PHP
1
2
3
4
5
6
7
8
9

	// This theme allows users to set a custom background
	// ATTENTION: WordPress 3.4 deprecates some functions, thatswhy this test
	global $wp_version;
	if ( version_compare( $wp_version, '3.4a', '>=' ) ) {
		add_theme_support( 'custom-background', array() );
	}
	else {
		add_custom_background();
	}
timing: 0.033s

Weiße Seite beim Aufruf des Blogs

Würde man das komplett umstellen auf WordPress 3.4, dann muß man mit Funktionen arbeiten, die eine niedrigere WordPress Version nicht kennt. Als Beispiel nehmen wird mal: WP_Theme::get_allowed_on_network() als Ersatz an.

Wenn dann der Server auch noch in der php.ini so eingestellt ist:

PHP
1

display_errors = Off
timing: 0.035s

und diese neue Theme Core Funktion in der functions.php des Themes benutzt wird, dann ist sowohl das Frontend als auch das Backend nur noch eine weiße Seite bei WordPress Versionen < 3.4, Login unmöglich!
Man sollte also auch sicherstellen, dass in einem solchen Falle die php.ini auf dem Wert On steht, damit man zumindest sehen kann, was genau schief geht.

Man kann dies auch in seinem lokalen XAMPP testhalber so konfigurieren. Zu beachten ist nur, das der Apache bei php.ini Änderungen neu gestartet werden muß.

Zusammenfassung

Ich begrüße Core Überarbeitungen, um alten Code zu konsolidieren und zu verbessern. Das gewählte OOP Model im Vergleich mit der bisherigen funktionalen Herangehensweise gefällt mir auch gut. Allerdings sollte man so eine Menge an deprecated Funktionen auch im Vorfeld aktiver kommunizieren und nicht erst darauf warten, daß hunderte von Blogs nach einem Update dann in Panik repariert werden müssen.

Kategorien
Deutsch, WordPress (DE)
RSS Kommentare
RSS Kommentare

« Übersetzungen in WordPress - Google & Microsoft Translate API’s Änderungen der Sprachdateien für WordPress 3.4 Core »

12 Antworten    Schreib einen Kommentar

tom

tom

21.05.2012 | 07:02

Ehrlich, mir gehen die vielen grundlegenden Änderungen nach und nach so langsam auf den Geist. Ich habe einfach keine Lust bei allen Seiten nach (oder vor) jeden Update alles komplett zu überarbeiten. Zumal jedes Theme von einen Anbieter kommt und von mir individuell gestaltet ist.

Bevor ich den Berg Arbeit angehe werde ich mir einen wechsel zu einen anderen System überlegen

Antworten »

Viktor

Viktor

21.05.2012 | 11:12

Ich schließe mich da ganz meinem Vorredner an. Mein Theme stammt noch aus der Zeit von WP 2.2.
Nach den letzten Updates kämpfe ich immer noch mit einem Fehler den ich bisher nicht beheben konnte.

Ich weiß nicht ob ich den Fehler hier äußern darf oder ob es das Thema sprengt?
Auf jeden Fall hab herzlich dank für die Vorabwarnung.

Antworten »

codestyling

codestyling

21.05.2012 | 12:33

Schick mir einfach eine Mail mit der Problembeschreibung, ggf. mit dem Theme angehangen. Dann kann ich das mal durchsehen und ggf. einen Lösungsweg aufzeigen.

Antworten »

Mike

Mike

21.05.2012 | 14:34

Kotzt mich auch an. Sollen lieber mal an der Performance arbeiten, denn Wordpress ist nach wie vor nicht für seine Geschwindigkeit bekannt. Anstatt aber performanter zu werden, blähen sie es mit so einem Mist und zusätzlichen Funktionen noch mehr auf. Wer braucht die Einstellungen für das Theme? Wer nicht einmal dass kann, braucht auch keinen Blog.

Antworten »

Dominik

Dominik

21.05.2012 | 15:41

Wie kommst du darauf, dass die Änderungen Mist sind?
Hier wurde hauptsächlich an der Performance gearbeitet, welches manchmal das Entfernen von Altlasten unumgänglich macht.

> Wer braucht die Einstellungen für das Theme?
Die Frage ist wohl auch nicht wirklich ernst gemeint? Stichwort dynamische/individuell Contentgestaltung auf einer Basis.

Antworten »

Thomas Scholz

Thomas Scholz

21.05.2012 | 19:59

Bitte lies doch erst den neuen Code, ehe du ihn beurteilst. Performance war genau der Grund für die neue Theme-API …

Den Einstellungsdialog muß du nicht benutzen, er wird auch nur auf dieser einen Seite im Backend geladen und beeinflußt die Performance nicht.

Die Änderungen wurden dieses Mal gut im Vorhinein kommuniziert, und die Vorlaufzeit ist auch ordentlich lang. Das haben wir schon ganz anders erlebt – auch in dieser Hinischt also eine Verbesserung.

Antworten »

Nutzer

Nutzer

21.05.2012 | 22:26

Ich hoffe Ihr geht NICHT den Weg von Joomla, bei dem sich die Entwickler über ihre Nutzer gestellt haben und nur noch Versierte das System handhaben konnen. Der Rest ist bekannt. Joomla Entwicler können jetzt alles machen, was sie wollen, es interessiert kaum noch jemanden.

Das Kapital von Wordpress sind die einfachen Nutzer, macht ihr es zu schwer und damit laufende Projekte unbrauchbar, dann sind sie weg. Bitte Vorsicht!!

Antworten »

Wolfgang Wagner

Wolfgang Wagner

25.05.2012 | 09:42

Da läuft es im TYPO3-Team ein wenig besser. Hier werden als veraltet eingestufte Funktionen schon 2 Versionsnummer vorher genannt, sodaß jeder Extensionentwickler mehr als genug Zeit hat, seine Extensions daran anzupassen. Wenn also eine Funktion mit Version 4.7 wegfällt, weiss man schon seit Version 4.5 darüber Bescheid. Das verlangsamt vielleicht die Entwicklung ein klein wenig, ist aber auf jeden Fall sicherer.

Antworten »

Klaus Schaumberger

Klaus Schaumberger

19.06.2012 | 15:11

Leider komme ich nach der autmatischen Aktualisierung derzeit nichts ins Backend (weisse Seite)- gehe ich zurück wird mir allerdings angezeigt das ich eingeloggt bin. Habe mir bereits einige Beiträge angesehen, auch auf Wordpress, allerdings noch keine Lösung gefunden.

Aktualisierungen sind seit geraumer Zeit ein echter Schweisstreiber nach dem Motto - was funktioniert diesemal nicht. Kann mir jemand helfen oder hat die Lösung - würde mich sehr freuen.

Gruss Klaus

Antworten »

codestyling

codestyling

20.06.2012 | 06:34

Es gibt einige Plugins und Themes, die das in WP 3.4 verursachen. Welches Theme verwendest du?
Ich denke, das liegt am Theme weil es Kompatibilitätswarnungen auswirft, die dein Hoster dann als Anlass nimmt, die Scriptausführung abzubrechen: Ergebnis weisse Seite.
Zu Analysezwecken kannst du mir gern das Theme zur Verfügung stellen, dann kann ich prüfen, ob es daran liegt und wie man es beheben kann.

Antworten »

Vanderhellen

Vanderhellen

25.06.2012 | 01:45

Hallo,

nach einem Malware-Infekt auf einer Kundenseite habe ich das mittlerweile neue 3.4 drüberinstalliert. Die Datenbank-Aktualisierung hörte überhaupt nicht auf bzw. vermute ich, dass nur die Bestätigungsseite nicht aufgerufen wurde.

Aber nun sehe ich nur noch eine weisse Seite - ich komme nicht mehr in den Admin-Bereich oder sonstwas.
Das Theme ist von Elegantthemes, aber ich würde vorübergehend auch das Standard-Theme nehmen - wenn ich wüsste, wie ich das machen kann.

Ich bräuchte einen nachvollziehbaren Lösungsansatz, wie ich wenigstens wieder in den Adminbereich komme. Das wäre toll. Ich bin zwar nicht der begnadete Coder, aber ich kann logisch denken. :-)

Jede Hilfe ist willkommen. LG, Eddy

Antworten »

codestyling

codestyling

25.06.2012 | 13:53

Der Rücksprung zum default Theme geht in diesem Falle dadurch, dass du den Ordner des aktuellen Themes umbenennst und dann das Backend aufrufst. WordPress findet dann das aktuelle Theme nicht mehr und stellt automatisch auf das Standard Theme um.
Du solltest alledings das Standard Theme auch im Themes Ordner haben :-)
Mit dieser Maßnahme solltest du dann erstmal wieder Zugang zum Backend bekommen und auch das Frontend wird dann erstmal mit dem Standard Theme ausgeliefert.
Danach kannst du dich um Korrekturen deines Elegant basierten Themes kümmern.

Antworten »