WordPress 3.5: XML-RPC Schnittstelle wird standardmäßig für alle Seiten aktiviert

Die XML-RPC Schnittstelle in WordPress dient dazu, um WordPress mit externen Programmen verwalten zu können. Zum Beispiel um Artikel zu veröffentlichen oder Kommentare zu bearbeiten. Zu den Programmen gehören unter anderem die mobilen Anwendungen für iOS, Android und Co, aber auch der Windows Live Writer.

Schnittstellen sind immer mit Vorsicht zu genießen, denn bei schlechter Umsetzung können sie eine optimale Angriffsfläche für Angriffe mit bösen Absichten bieten.
Vor WordPress 3.5 gab es deshalb die Möglichkeit die Schnittstelle einfach nach Belieben zu aktivieren bzw. deaktivieren. Deaktiviert war sie aber standardmäßig.

Diese Einstellungen wird es in WordPress 3.5 nicht mehr geben.

In Laufe der Zeit wurde die XML-RPC Schnittstelle immer weiter ausgebaut und verbessert. Dies geschah hauptsächlich in WordPress 3.4.
Aus diesem Grund wird die XML-RPC Schnittstelle ab WordPress 3.5 standardmäßig aktiviert sein. Für neue Installationen sowie auch bestehende Seiten.
Gleichzeitig wurde die entsprechende Einstellung im User Interface entfernt.

XML-RPC Schnittstelle in WordPress 3.5 deaktivieren

Wie nun die Schnittstelle ohne UI deaktivieren? Per Filter.
Zum Deaktivieren wurde ein neuer Filter names xmlrpc_enabled angelegt. Daraus ergibt sich folgender Code:

/**
 * Deaktiviert die XML-RPC Schnittstelle ab WordPress 3.5.
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Am Rande: Atom Publishing Protocol

Neben dem XML-RPC Protokoll gab es in WordPress noch das Atom Publishing Protocol. Diese Schnittstelle wurde in WordPress 3.5 entfernt und in ein Plugin ausgelagert.

Zum Thema

Titelbild von Matt.

WordPress 3.5: Speicherlimit auf 40 MB erhöht

Im Zusammenspiel mit vielen Plugins, älteren PHP Versionen und anderen Faktoren kann WordPress recht schnell das festgelegte Speicherlimit überschreiten. Dies endet dann in der PHP typischen Fehlermeldung à la Fatal error: Allowed memory size of 999999 bytes exhausted.

In der aktuellen Version versucht WordPress das Speicherlimit auf 32 MB festzulegen. „Versucht“ deswegen, weil nicht jeder Webhoster den Zugriff über ini_set() zulässt.

In WordPress 3.5 wird das Speicherlimit nun auf 40 MB erhöht. Das liegt allerdings nicht daran, dass die zukünftige Version 8 MB mehr Speicher benötigt, sondern viel mehr daran, um die schon oben genannte Fehlermeldung zu unterdrücken bzw. mehr Spielraum zu bieten.

Persönliche Meinung: Ich hab die Erhöhung erstmal nicht befürwortet, da es meiner Meinung nach der falsche Weg ist. In der PHP Doku findet man folgende Aussage:

[memory_limit] Setzt den Maximalwert des Speichers in Byte, den ein Skript verbrauchen darf. Damit können schlecht geschriebene Skripte daran gehindert werden, den gesamten verfügbaren Speicher eines Servers „aufzufressen“.

Heißt im Umkehrschluss: Schlechte Skripte aka Plugins bekommen mehr „zu fressen“.

Allerdings muss es nicht immer ein schlechtes Plugin sein. Benutzer erwarten heutzutage leider immer mehr die eierlegende Wollmilchsau. Und natürlich spielt die Anzahl von Plugins auch eine wesentliche Rolle. — Nein, 50 aktive Plugins zu haben ist nicht normal.

Wie sieht dein Speicherverbrauch aus?

Der Speicherverbrauch meines Dashboards beläuft sich aktuell auf 19,6 MB bei 9 Datenbankabfragen, 7 aktivierten Plugins und deutscher Sprachdatei. Ein guter Wert, wie ich finde.
Diese Informationen lass ich mir übrigens bei jeder Seite durch ein kleines Plugin ausgeben. Das Plugin habe ich mal auf Github veröffentlicht.

Mich würde nun mal brennend interessieren, wie den dein aktueller Speicherverbrauch ausfällt und wie viele Plugins aktiviert sind? Würdet ihr von einer Speichererhöhung profitieren?

Zum Thema

Titelbild von jjackowski, CC BY-NC-SA 2.0.

WordPress 3.5: Willkommen Backbone.js und Underscore.js; Adios Prototype und script.aculo.us

Während des gestrigen Entwickler Chats waren die JavaScript Bibliotheken in WordPress großes Thema.

Zum einem wurde jQuery 1.8, welches mittlerweile 3 Wochen auf dem Markt ist, für den Core abgesegnet. Zudem wurde auch jQuery UI auf die stabile Version 1.8.23 aktualisiert.

Backbone.js und Underscore.js

Backbone.js ist ein Model-View-Controller (MVC) Framework für JavaScript. Die Bibliotheken bieten eine solide Basis für objektorientierte Programmierung und simulieren etliche Hilfsfunktionen und eine erweiterbare Klassenhierarchie.
Dieser Vorteil ermöglicht das organisieren der Daten und die saubere Trennung zwischen Daten und Logik.
Mit der integrierten Template-Engine kann das HTML-Markup und die Logik sauber voneinander getrennt werden.

With Backbone, you represent your data as Models, which can be created, validated, destroyed, and saved to the server. Whenever a UI action causes an attribute of a model to change, the model triggers a “change” event; all the Views that display the model’s state can be notified of the change, so that they are able to respond accordingly, re-rendering themselves with the new information. In a finished Backbone app, you don’t have to write the glue code that looks into the DOM to find an element with a specific id, and update the HTML manually — when the model changes, the views simply update themselves.

Backbone.js: Introduction

Underscore.js verspricht hingegen die Unterstützung von funktionalen Programmierkonstrukten für den Umgang mit Arrays, Collections und Objekten, wie zum Beispiel each, map, find, filter oder toArray.

Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming support that you would expect in Prototype.js (or Ruby), but without extending any of the built-in JavaScript objects. It’s the tie to go along with jQuery’s tux, and Backbone.js’s suspenders.

Underscore provides 60-odd functions that support both the usual functional suspects as well as more specialized helpers. It delegates to built-in functions, if present, so modern browsers will use the native implementations.

Underscore.js: Introduction

Was will WordPress mit Backbone.js und Underscore.js?

Beide Projekte sind eine optimale Grundlage für sogenannte Single-Page Webanwendungen.
Eine solche Anwendungen findet man auch jetzt schon im WordPress Core.

WordPress Theme Customizer

Es ist der Theme Customizer (Live-Vorschau des Themes), der mit WordPress 3.4 eingeführt wurde.

In WordPress 3.5 wird es weitere Projekte geben, die auf diese Art umgesetzt werden sollen.
Dazu zählt der neue Media-Workflow samt den Dialogfenster, sowie die Umsetzung von Aktionen und Filtern für JavaScript, quasi add_action() bzw. add_filter() für JavaScript.

Den Grafiken folgen Prototype und script.aculo.us

Wie schon berichtet, hat WordPress sich von ungenutzten Grafiken befreit. Jetzt hat es auch die beiden JavaScript Bibliotheken/Frameworks Prototype und script.aculo.us getroffen. Kein großer Verlust, denn sie wurden schon länger nicht mehr genutzt.

Fallback für Plugins/Themes: Falls doch noch ein Plugin/Theme existiert, welches von den beiden Bibliotheken abhängig ist, werden die benötigten Skripte automatisch von der Google API eingebunden. Guter Schachzug meiner Meinung nach.

Ausschnitt aus der Funktion wp_default_scripts():

<?php
	// WordPress no longer uses or bundles Prototype or script.aculo.us. These are now pulled from an external source.
	$scripts->add( 'prototype', '//ajax.googleapis.com/ajax/libs/prototype/1.7.1.0/prototype.js', array(), '1.7.1');
	$scripts->add( 'scriptaculous-root', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/scriptaculous.js', array('prototype'), '1.9.0');
	$scripts->add( 'scriptaculous-builder', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/builder.js', array('scriptaculous-root'), '1.9.0');
	$scripts->add( 'scriptaculous-dragdrop', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/dragdrop.js', array('scriptaculous-builder', 'scriptaculous-effects'), '1.9.0');
	$scripts->add( 'scriptaculous-effects', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/effects.js', array('scriptaculous-root'), '1.9.0');
	$scripts->add( 'scriptaculous-slider', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/slider.js', array('scriptaculous-effects'), '1.9.0');
	$scripts->add( 'scriptaculous-sound', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/sound.js', array( 'scriptaculous-root' ), '1.9.0' );
	$scripts->add( 'scriptaculous-controls', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/controls.js', array('scriptaculous-root'), '1.9.0');
	$scripts->add( 'scriptaculous', false, array('scriptaculous-dragdrop', 'scriptaculous-slider', 'scriptaculous-controls') );

Nebenbei: min.css/min.js für komprimierte Stylesheets/Skripte

Bisher wurden die unkomprimierte Stylesheets mit der Endung .dev.css kenntlich gemacht, analog bei den Skripten .dev.js.
WordPress 3.5 geht nun die typische .min Konvention ein, das heißt: Komprimierte Dateien bekommen die Endung .min.css/.min.js und die Unkomprimierten haben keinen Suffix mehr.

Vor WordPress 3.4:
Entwicklerversion: dateiname.dev.css
Komprimierte Version: dateiname.css

Mit WordPress 3.5:
Entwicklerversion: dateiname.css
Komprimierte Version: dateiname.min.css

Zum Thema

WordPress 3.5: Ungenutzte Grafiken entfernt, mehr CSS3 Farbverläufe

Zusammen mit Helen, Scott und Andrew haben wir die letzten Tage an einen Punkt für WordPress 3.5 gearbeitet: Ungenutzte Grafiken, die seit Versionen mit geschleppt werden, entfernen und die vermehrte Verwendung von CSS3 Farbverläufen (Gradients). Dieser Punkt ist nun abgehakt.

Warum dieser Schritt? Der Punkt der ungenutzten Grafiken sollte klar sein. Warum mehr einpacken, als man braucht? Das WordPress Paket ist damit um ein paar Bytes geschrumpft.

Die Liste der entfernen Grafiken ist lang. Plugin Autoren sollten deswegen auch mal kurz draufschauen, ob sie nicht eine der Grafiken derzeit nutzen.
Wenn doch sollte gegebenenfalls eine Kopie das Plugin eingebunden werden. Die Liste:

  • wp-admin/images/archive-link.png
  • wp-admin/images/blue-grad.png
  • wp-admin/images/button-grad-active.png
  • wp-admin/images/button-grad.png
  • wp-admin/images/ed-bg-vs.gif
  • wp-admin/images/ed-bg.gif
  • wp-admin/images/fade-butt.png
  • wp-admin/images/fav-arrow-rtl.gif
  • wp-admin/images/fav-arrow.gif
  • wp-admin/images/fav-vs.png
  • wp-admin/images/fav.png
  • wp-admin/images/gray-grad.png
  • wp-admin/images/loading-publish.gif
  • wp-admin/images/logo-ghost.png
  • wp-admin/images/logo.gif
  • wp-admin/images/menu-arrow-frame-rtl.png
  • wp-admin/images/menu-arrow-frame.png
  • wp-admin/images/menu-arrows.gif
  • wp-admin/images/menu-bits-rtl-vs.gif
  • wp-admin/images/menu-bits-rtl.gif
  • wp-admin/images/menu-bits-vs.gif
  • wp-admin/images/menu-bits.gif
  • wp-admin/images/menu-dark-rtl-vs.gif
  • wp-admin/images/menu-dark-rtl.gif
  • wp-admin/images/menu-dark-vs.gif
  • wp-admin/images/menu-dark.gif
  • wp-admin/images/required.gif
  • wp-admin/images/screen-options-toggle-vs.gif
  • wp-admin/images/screen-options-toggle.gif
  • wp-admin/images/toggle-arrow-rtl.gif
  • wp-admin/images/toggle-arrow.gif
  • wp-admin/images/upload-classic.png
  • wp-admin/images/upload-fresh.png
  • wp-admin/images/white-grad-active.png
  • wp-admin/images/white-grad.png
  • wp-admin/images/widgets-arrow-vs.gif
  • wp-admin/images/widgets-arrow.gif
  • wp-includes/images/upload.png

CSS3 Gradients

Die CSS3 Farbverläufe sind meiner Meinung nach eine positive Neuerung in CSS3.
Es erspart die lästige Erstellung von zusätzlichen Grafiken, schont die Bandbreite und reduziert die Anzahl der HTTP-Anfragen.

Und genau diese Performance-Steigerung ist der Grund dafür, dass WordPress 3.5 nun vermehrt CSS3 Farbverläufe nutzt.

Um die Umsetzung einheitlich zu gestalten, haben wir uns dafür noch eine kleine Syntax überlegt. Vielleicht kann der Eine oder Andere diese für sein nächstes Projekt gut gebrauchen.

.grad-to-top {	
	background: #fff;
	background-image: -webkit-gradient(linear, left top, left bottom, from(#fff), to(#000));
	background-image: -webkit-linear-gradient(top, #fff, #000);
	background-image:    -moz-linear-gradient(top, #fff, #000);
	background-image:      -o-linear-gradient(top, #fff, #000);
	background-image: linear-gradient(to bottom, #fff, #000);
}

.grad-to-bottom {	
	background: #fff;
	background-image: -webkit-gradient(linear, left bottom, left top, from(#fff), to(#000));
	background-image: -webkit-linear-gradient(bottom, #fff, #000);
	background-image:    -moz-linear-gradient(bottom, #fff, #000);
	background-image:      -o-linear-gradient(bottom, #fff, #000);
	background-image: linear-gradient(to top, #fff, #000);
}

.grad-to-bottom-with-color-stops {	
	background: #fff;
	background-image: -webkit-gradient(linear, left bottom, left top, color-stop(0, #fff), color-stop(1, #000));
	background-image: -webkit-linear-gradient(bottom, #fff 0%, #000 100%);
	background-image:    -moz-linear-gradient(bottom, #fff 0%, #000 100%);
	background-image:      -o-linear-gradient(bottom, #fff 0%, #000 100%);
	background-image: linear-gradient(to top, #fff 0%, #000 100%);
}

Unterstützt werden mit der Methode die Browser Firefox, Opera, Safari, Chrome und Internet Explorer 10.
(Link zur jsFiddle Demo.)

Zum Thema

WordPress 3.3: Abschied von RSS 0.92 und RDF

Mit der kommenden Version von WordPress wird man sich von den zwei Feed-Arten RSS 0.92 und RDF (RSS 1.0) verabschieden.

WordPress Default Feed
Änderung bei der Funktion get_default_feed()

RSS 0.92 hatte unter anderem den Nachteil, dass der Feed nur ein Kurzfassung des Artikels darstellen konnte, egal welche Einstellung getätigt war.

Beide Arten sind mittlerweile von RSS 2.0 bzw dem Atom Feed überholt worden.
Dementsprechend werden in WordPress 3.3 die alten Feeds zum RSS 2.0 Feed weitergeleitet.

Die Umsetzung hat 4 Jahre gedauert und kann in diesem Ticket nachgelesen werden.

Nachtrag: Auf Wunsch von Matt wurde der RDF Feed noch nicht deaktiviert. Er kann somit weitergenutzt werden.