SVG is a language for describing two-dimensional graphics in XML. SVG allows for three types of graphic objects: vector graphic shapes (e.g., paths consisting of straight lines and curves), images and text. Graphical objects can be grouped, styled, transformed and composited into previously rendered objects. The feature set includes nested transformations, clipping paths, alpha masks, filter effects and template objects.

– W3C: About SVG

SVGs sind eine feine Sache, wenn es um Grafiken geht, die „automatisch“ skalieren sollen, ohne dabei die Qualität des Bildes zu beeinflussen. In Zeiten von HighDPI Bildschirmen ein immer mehr populäres Hilfsmittel.

Wie sich schon rumgesprochen hat (ich berichtete), hat sich eine Gruppe von WordPress Contributor unter der Leitung von Matt als Ziel eine neues, moderneres Admin Design zu entwickeln gesetzt. Ein Schwerpunkt der Umgestaltung sind die Icons. Die neuen Icons sollen nicht im gewöhnlichen PNG Format gestaltet sein, sondern ebenfalls auf das SVG Format gesetzt werden.
Bis „MP6“ in den Core gelangt und wir in den Genuss der Grafiken kommen, dauert es noch ein Weilchen.

WordPress Logo

Das Plugin MP6 bringt eben aufgrund des neuen Formats auch das WordPress Logo als Vektorgrafik mit. Allerdings als Inline Image in Base64 kodiert.

.wp-badge {
	background-color: #0074a2;
	background-image: url(data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu……OTQsMjMuMjE1LDI4LjQzNHoiLz4NCgk8L2c+DQo8L2c+DQo8L3N2Zz4NCg==);
	background-position: center 30px;
	background-repeat: no-repeat;
	background-size: 110px 110px;
}

Ich habe den Base64 Code mal dekodiert und anschließend die SVG Datei angepasst, damit es unter dem Opera Browser zu keinen Darstellungsproblemem kommt. (Fixe Höhe und Breite waren definiert, was Opera anscheinend nicht mag.)
Um noch ein wenig an Bytes zu sparen, wurde die Datei einmal durch SVGO gejagt, wodurch nochmal 30% gespart werden konnten.

Das Ergebnis habe ich hier mal eingebunden. Zum Speichern entweder Rechtsklick -> Bild speichern oder den anschließenden Download nutzen. (Lizenz: Wie das Plugin und WordPress selbst: GPLv2 or later)

Zum Thema

• Plugin: MP6 (Das kommende Admin Design) — wordpress.org
• SVG-Bilder verlustfrei in der Größe reduzieren mit SVGO — playground.ebiene.de
• Plugin: SVG (Erlaubt das Uploaden von SVG Dateien) — gist.github.com

Ich konnte schon letzte Woche einen Blick auf das Theme werfen und habe im folgenden die Highlights festgehalten.

Header

Post Formate

Sidebar and Widgets

Comments

Image Attachments

Schrift

Als Schriftfamilie wird ‘Source Sans Pro’, Helvetica, sans-serif und ‘Bitter’, serif eingesetzt.

Icon Font

Mobiles Layout

Was sagt ihr dazu? Begrüßt ihr den Einsatz von Farbe oder sollte es doch wieder schlicht im nächsten Theme werden?

Zum Thema

• A first draft of the Twenty Thirteen theme — make.wordpress.org
• Demo von Twenty Thriteen — wordpress.com

Die Inhalte der vorhandenen Feeds können mit den richtigen Filtern angepasst werden. Doch wie kann ein eigener Feed angelegt werden?

Mit add_feed() einen eigenen Feed anlegen

Die seit WordPress 2.1.0 mitgelieferte Funktion add_feed() befindet sich in wp-includes/rewrite.php und ist, wie der Name schon verspricht, für das Anlegen neuer Feeds zuständig. Die Funktion ist folgendermaßen aufgebaut:

/**
 * Add a new feed type like /atom1/.
 *
 * @since 2.1.0
 *
 * @param string $feedname
 * @param callback $function Callback to run on feed display.
 * @return string Feed action name.
 */
function add_feed($feedname, $function) {
	global $wp_rewrite;
	if ( ! in_array($feedname, $wp_rewrite->feeds) ) //override the file if it is
		$wp_rewrite->feeds[] = $feedname;
	$hook = 'do_feed_' . $feedname;
	// Remove default function hook
	remove_action($hook, $hook, 10, 1);
	add_action($hook, $function, 10, 1);
	return $hook;
}

Zunächst erwartet die Funktion einen Slug für den Feed. Es ist der Name, unter welchem der Feed später aufrufbar sein wird. Er sollte deswegen nur aus den Zeichensatz [a-z0-9_-] bestehen. Die Feed URL wird bei aktivierten Permalinks im Format example.com/feed/{feed_slug} sein.
Der zweite Teil ist die Callback-Funktion. Diese Funktion sollte den Feed rendern und wird beim Aufruf des Feeds aufgegriffen.

Das feed-rss2.php Template

feed-rss2.php ist ein Template in WordPress und übernimmt die Darstellung für jegliche Art von Post Type im RSS2 Format.

Das Template ist somit die optimale Ausgangslage für die Darstellung des eigenen Feeds und kann deswegen in der Callback-Funktion geladen werden.

Anregung für PHP 5.3:

function ds_custom_feed() {
	add_feed( 'custom', function() {
		load_template( ABSPATH . WPINC . '/feed-rss2.php' );
	} );
}
add_action( 'init', 'ds_custom_feed' );

Feed mit eigenen Inhalt füllen

Was nun noch fehlt, ist der Inhalt des Feeds. Dazu als Beispiel folgende Klasse anschauen:

<?php
/**
 * Add a custom feed to WordPress.
 *
 * The feed will be rendered through the wp-includes/feed-rss2.php template
 * and avaiable under example.com/feed/{$feed_slug}.
 *
 * Note: Don't forget to flush the rewrite rules once.
 *
 * @author Dominik Schilling
 * @link   http://wpgrafie.de/897
 */
class DS_Custom_Feed {
	/**
	 * Sets the feed slug.
	 *
	 * @var string
	 */
	public static $feed_slug = 'custom';

	/**
	 * Registers the feed and the pre_get_posts action
	 */
	public static function init() {
		add_feed( self::$feed_slug, array( __CLASS__, 'feed_template' ) );

		add_action( 'pre_get_posts', array( __CLASS__, 'feed_content' ) );
	}

	/**
	 * Customizes the query.
	 * It will bail if $query is not an object, filters are suppressed and it's not
	 * our feed query.
	 *
	 * @param  WP_Query $query The current query
	 */
	public static function feed_content( $query ) {
		// Bail if $query is not an object or of incorrect class
		if ( ! $query instanceof WP_Query )
			return;

		// Bail if filters are suppressed on this query
		if ( $query->get( 'suppress_filters' ) )
			return;

		// Bail if it's not our feed
		if ( ! $query->is_feed( self::$feed_slug ) )
			return;

		// Change the feed content
		// Example: A feed for pages
		$query->set( 'post_type', array( 'page' ) );
	}

	/**
	 * Loads the feed template which is placed in wp-includes/feed-rss2.php.
	 */
	public static function feed_template() {
		load_template( ABSPATH . WPINC . '/feed-rss2.php' );
	}
}

/**
 * Hooks into `init`.
 *
 * Note: add_feed() needs access to the global $wp_rewrite
 */
add_action( 'init', array( 'DS_Custom_Feed', 'init' ) );

Es wird Gebrauch vom pre_get_posts Hook gemacht. Dieser erlaubt es die Query nach Bedarf anzupassen – hier wird z.B. der Post Type auf page gesetzt. Was alles angepasst werden kann, kann dem Eintrag im Codex entnommen werden.

Als Beispiel kann ich auf meinen Feed für den WPD Planet hinweisen, welcher nur Beiträge mit einem bestimmten Custom Field anzeigt – Nachzulesen im GitHub Repo zum Theme.

Zum Thema

• Plugin API – Action Reference – pre_get_posts — codex.wordpress.org
• Feeds einer WordPress-Installation — perun.net

Wofür die Versionierung? Statische Dateien, die eine hohe Auslaufzeit (Expires-Header) haben, werden vom Browser nicht mehr vom Server geladen, sondern direkt aus dem Browsercache eingebunden. Wird die Resource aber auf dem Server geändert, bekommt der Browser dies nicht mit und lädt weiterhin die alte Version aus dem Browsercache. Abhilfe schafft die Versionierung.

WordPress hängt an die Resource eine Query String mit dem Parameter ver. Diese Art von Versionierung wird allerdings nicht empfohlen.
Google schreibt dazu:

Most proxies, most notably Squid up through version 3.0, do not cache resources with a “?” in their URL even if a Cache-control: public header is present in the response. To enable proxy caching for these resources, remove query strings from references to static resources, and instead encode the parameters into the file names themselves.

Die Version soll also mit in den Dateinamen gepackt werden.

Plugin: Dateinamen um die Version erweitern

Um die Dateien nicht physisch zu ändern hilft das mod_rewrite Modul und folgendes Plugin, welches sich in die WordPress Filter script_loader_src und style_loader_src einklinkt.

<?php
/**
 * Plugin Name: Filename-based cache busting 
 * Version: 0.2
 * Description: Filename-based cache busting for WordPress scripts/styles.
 * Author: Dominik Schilling
 * Author URI: http://wphelper.de/
 * Plugin URI: http://wpgrafie.de/880/
 *
 * License: GPLv2 or later
 * License URI: http://www.gnu.org/licenses/gpl-2.0.html
 *
 * 
 * Extend your .htaccess file with these lines:
 *
 *   <IfModule mod_rewrite.c>
 *     RewriteEngine On
 *     RewriteBase /
 *
 *     RewriteCond %{REQUEST_FILENAME} !-f
 *     RewriteCond %{REQUEST_FILENAME} !-d
 *     RewriteRule ^(.+)\.(.+)\.(js|css)$ $1.$3 [L]
 *   </IfModule>
 */
 
/**
 * Removes the `ver` query string of the source and places it into
 * the filename. Doesn't change admin scripts/styles and sources
 * with more than the `ver` arg.
 *
 * @param  string $src The original source 
 * @return string
 */
function ds_filename_based_cache_busting( $src ) {
	// Don't touch admin scripts
	if ( is_admin() )
		return $src;

	return preg_replace(
		'/\.(js|css)\?ver=(.+)$/',
		'.$2.$1',
		$src
	);
}
add_filter( 'script_loader_src', 'ds_filename_based_cache_busting' );
add_filter( 'style_loader_src', 'ds_filename_based_cache_busting' );

Wie im Plugin Header dokumentiert, muss die .htaccess ergänzt werden.
Wer auf nginx setzt kann folgende Zeilen nutzen, danke Sergej:

location ~ ^(.+)\.(.+)\.(js|css)$ {
    alias $1.$3;
}

Zum Thema

• Plugin auf GitHub — gist.github.com
• Web Performance Best Practices — developers.google.com
• RFC 2616 HTTP-1.1-Spezifikation — tools.ietf.org

Vor kurzem habe ich von GitLab gehört und wollte die Anwendung auf meinem Uberspace ausprobieren. Schaut man sich allerdings die Installationsanleitung an, so überschlägt sich diese nur so von sudo Aufrufen. Ein Hindernis für die Installation auf Uberspace.
Doch es geht auch ohne!

Die Anleitung bezieht sich auf eine GitLab Installation von Grund auf und umfasst 15 Schritte.
Als Grundlage habe ich die Anleitung vom Alexander (Danke!) aufgegriffen und entsprechend der jeweiligen neuen Versionen angepasst.

0. Vorbereitungen

Dinge, die du nun brauchst:

• Etwas Geduld und Zeit
• Grundwissen über die Shell
• Einen Uberspace Account :-)

(Sofern nicht anders angeben, werden die folgenden Befehle im Home-Verzeichnis ausgeführt. <uberspacename> bitte mit Deinem Benutzernamen ersetzen, analog <uberspacehost> mit dem Servernamen.)

1. Git aktualisieren und konfigurieren

Wer möchte kann zunächst Git auf Version 1.8.0 aktualisieren. Dies kann mithilfe von toast erledigt werden. (Sollte kein gettext installiert sein, muss dies zuerst installiert werden.)

$ toast arm http://ftp.gnu.org/pub/gnu/gettext/gettext-0.18.1.1.tar.gz
$ toast arm http://git-core.googlecode.com/files/git-1.8.0.tar.gz

Wenn noch nicht geschehen, dann müssen Name und E-Mail-Adresse für Git festgelegt werden:

$ git config --global user.email "<mail@example.com>"
$ git config --global user.name "<Dein Name>"

2. Temporären Ordner anlegen

Da GitLab temporäre Dateien anlegt, sollte ein temporären Ordner im Home-Verzeichnis anlegt werden. Damit hast auch wirklich nur Du Zugriff auf dein GitLab.

$ mkdir ~/tmp

Damit der Ordner genutzt wird, muss die Shell-Konfiguration (.rc, .bashrc oder .zshrc) um Folgendes erweitert werden:

export TMPDIR=$HOME/tmp

3. SSH-Key generieren

Für gitolite wird ein eigener SSH-Key generiert:

$ ssh-keygen -t rsa -f admin -C "GitLab Key"

(Passwort-Eingabe überspringen.)

4. gitolite installieren und konfigurieren

gitolite dient für die Benutzerverwaltung der Git-Repositories. Die Jungs von Uberspace bieten dazu ein Setup-Skript an. Dies kann genutzt werden:

$ gl-setup admin.pub

Danach die eben angelegten Keys ins SSH Verzeichnis verschieben…

$ mv admin .ssh/id_rsa.gitlab
$ mv admin.pub .ssh/id_rsa.gitlab.pub

…, damit der Key genutzt wird, eine SSH-Config anlegen (wenn noch nicht vorhanden)…

$ touch .ssh/config
$ chmod 600 .ssh/config

…und schließlich die Key Datei verlinken:

$ echo -e "Host <uberspacehost>.uberspace.de localhost\n\tIdentityFile ~/.ssh/id_rsa.gitlab" >> .ssh/config

Zur Überprüfung einmal den Host per SSH aufrufen:

$ ssh <uberspacename>@<uberspacehost>.uberspace.de

Die Antwort sollte in etwa so aussehen:

The authenticity of host 'XXXXXXXX' can't be established.
RSA key fingerprint is XX:XX:XX:XX:XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'XXXXXXXX,XXXXXXXX' (RSA) to the list of known hosts.
hello admin, this is gitolite 2.3.1-1.el6 running on git 1.8
the gitolite config gives you the following access:
 R   W  gitolite-admin
 @R_ @W_    testing
Connection to XXXXXXXX closed.

Um später keine Problem mit der Authentifizierung in Git zu haben, sollte das Repo einmal geklont werden. Danach kann es wieder gelöscht werden:
(Die aufkommende Frage auch wieder mit yes beantworten.)

$ git clone <uberspacename>@localhost:gitolite-admin
$ rm -rf gitolite-admin

Zur Konfiguration die Datei .gitolite.rc aus dem Home-Verzeichnis öffnen und die folgenden Variablen abändern:

$GL_GITCONFIG_KEYS auf $GL_GITCONFIG_KEYS = ".*"; setzen und $REPO_UMASK auf $REPO_UMASK = 0007; setzen.

5. Ruby installieren

GitLab basiert auf Ruby on Rails. Um Ruby zu installieren gibt es zwei Möglichkeiten.

Möglichkeit 1:

Uberspace bietet die Version 1.9.3 global an. Den Wiki-Eintrag bitte lesen; zusammengefasst:

$ cat <<'__EOF__' >> ~/.bash_profile
export PATH=/package/host/localhost/ruby-1.9.3/bin:$PATH
export PATH=$HOME/.gem/ruby/1.9.1/bin:$PATH
__EOF__
$ echo "gem: --user-install --no-rdoc --no-ri" > ~/.gemrc

Danach kann Bundler und CharlockHolmes installiert werden

$ gem install bundler charlock_holmes
$ bundle install --path ~/.gem

Nachteil: Man hat nicht die aktuelle Ruby Version zur Verfügung.

Möglichkeit 2:

Den Ruby Version Manager nach dieser Anleitung installieren.

Danach Ruby 1.9.3, Bundler, CharlockHolmes und sqlite3 (siehe Doku-Hinweis) installieren:

$ rvm install 1.9.3
$ rvm use 1.9.3
$ gem install --no-rdoc --no-ri bundler charlock_holmes
$ gem install sqlite3 -- \
  --with-sqlite3-include=/package/host/localhost/sqlite-3/include \
  --with-sqlite3-lib=/package/host/localhost/sqlite-3/lib

6. Redis installieren und konfigurieren

GitLab benötigt außerdem Redis. Dank toast wieder kein Problem:

$ toast arm http://redis.googlecode.com/files/redis-2.6.2.tar.gz

Zur Konfiguration den Ordner ~/.redis erstellen und in Diesem eine Datei names conf mit folgendem Inhalt anlegen:

unixsocket /home/<uberspacename>/.redis/sock
daemonize yes
logfile /home/<uberspacename>/.redis/log
port 0

7. GitLab installieren und konfigurieren

Nun ist GitLab selbst an der Reihe. Wir klonen uns das Repo und wechseln dann in den 3.0.3 Zweig:

$ git clone git@github.com:gitlabhq/gitlabhq.git gitlab
$ cd gitlab
$ git checkout v3.0.3 -q

Die Beispiel-Konfigurationsdateien kopieren…

$ cp config/database.yml.example config/database.yml
$ cp config/gitlab.yml.example config/gitlab.yml

…und die database.yml mit den richtigen Daten füllen. Achtung: Die Datenbanknamen müssen Deinen Benutzernamen mit Unterstrich als Präfix haben!

Danach gitlab.yml öffnen und folgendermaßen abändern:

web:
  host: <uberspacename>.<uberspacehost>.uberspace.de
  port: 80
  https: false

# Email used for notification
# about new issues, comments
email:
  from: noreply@<uberspacename>.<uberspacehost>.uberspace.de

# Git Hosting configuration
git_host:
  system: gitolite
  admin_uri: <uberspacename>@localhost:gitolite-admin
  base_path: /home/<uberspacename>/repositories/
  hooks_path: /home/<uberspacename>/.gitolite/hooks/
  gitolite_admin_key: gitlab 
  git_user: <uberspacename>
  upload_pack: true
  receive_pack: true
  host: <uberspacename>.<uberspacehost>.uberspace.de
  # port: 22

(Die Hosts können später, oder auch jetzt schon, mit einer beliebigen URL ersetzt werden.)

Wenn git über toast installiert wurde muss noch folgende Änderung gemacht werden:

# Git settings
# Use default values unless you understand it
git:
  path: /home/<uberspacename>/.toast/armed/bin/git

Danach die restlichen GitLab Abhängigkeiten installieren:

$ bundle install --without development test sqlite postgres  --deployment

Damit Redis und Resque miteinander harmonieren, müssen noch ein paar Änderungen vollzogen werden.
Öffne die Datei config/initializers/4_resque.rb und füge folgende Zeile am Anfang ein:

Resque.redis = Redis.new(:path => "/home/<uberspacename>/.redis/sock")

Öffne die Datei lib/hooks/post-receive und ersetze redis-cli mit /home/<uberspacename>/.toast/armed/bin/redis-cli -s /home/<uberspacename>/.redis/sock.

Jetzt die Hooks einrichten:

$ cp lib/hooks/post-receive ~/.gitolite/hooks/common/post-receive

Für das Deployment wird thin genutzt. Damit die Assets mit thin funktionieren muss in der Datei config/environments/production.rb die folgende Einstellung geändert werden:

config.serve_static_assets = true

8. Redis starten

Der Redis Server muss gestartet werden:

$ redis-server ~/.redis/conf

9. GitLab initialisieren

Jetzt kann die Datenbank und der Admin Account für GitLab angelegt werden. Das geht mit:

$ cd ~/gitlab
$ bundle exec rake db:setup RAILS_ENV=production
$ bundle exec rake db:seed_fu RAILS_ENV=production

10. GitLab Status Check

Um sicher zu gehen, dass bisher alles richtig gemacht wurde, sollte der Status der GitLab Installation geprüft werden:

$ cd ~/gitlab
$ bundle exec rake gitlab:app:status RAILS_ENV=production

Das Ergebnis sollte dem Screenshot ähnlich sein.

11. Resque starten

Wenn die Überprüfung erfolgreich war, kann Resque gestartet werden (könnte etwas dauern):

$ cd ~/gitlab
$ ./resque.sh

12. GitLab starten

Fast geschafft. Jetzt kann GitLab gestartet werden. Das geht über folgenden Aufruf (Wenn Ruby nicht über den RVM installiert wurde, && rvm use 1.9.3 weglassen):

$ cd ~/gitlab && rvm use 1.9.3 && bundle exec thin start --environment production --port <Port>

<Port> mit einem beliebigen, fünfstelligen, freien Port ersetzen.
Das Konsolenfenster noch nicht schließen! Es dient noch der späteren Überprüfung!

13. Apache-Rewrites anlegen

Damit GitLab im Web erreichbar ist, sollte im ~/html Verzeichnis eine .htaccess mit folgendem Inhalt angelegt werden:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule (.*) http://localhost:<Port>/$1 [P]
</IfModule>

<Port> mit dem selben Port wie beim thin Server ersetzen.

14. GitLab Installation finalisieren

Öffne GitLab im Browser, melde dich an (Name: admin@local.host, Passwort: 5iveL!fe, Passwort später unbedingt ändern!) und erstelle ein Beispiel-Projekt. Achte dabei auf das noch offene Konsolenfenster. Sollte dort keine Fehlermeldung erscheinen kann der thin-Server mit CTRL+C gestoppt werden.
Danach dann als Daemon wieder starten (Wenn Ruby nicht über den RVM installiert wurde, && rvm use 1.9.3 weglassen):

$ cd ~/gitlab && rvm use 1.9.3 && bundle exec thin start --environment production --port <Port> --daemonize

FERTIG!

Zum Thema

• GITLAB: Self Hosted Git Management Application — gitlabhq.com
• GitLab Demo — gitlabhq.com
• Uberspace Doku: Ruby — uberspace.de
• gitolite — github.com

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

WordPress Philosophy

Nachdem schon die Einstellung für die XML-RPC Schnittstelle entfernt wurde, hier nun ein paar Weitere.

oEmbed läuft nun komplett automatisch

oEmbed ist die Schnittstelle für das automatische Einbinden von zum Beispiel YouTube Videos oder, in WordPress 3.5 neu, Soundcloud und SlideShare Medien.

In den Einstellungen konnten dazu gewisse Anpassungen vorgenommen werden. Zum Beispiel die Höhe oder Breite festlegen, aber auch die automatische Einbindung komplett deaktivieren. In WordPress 3.5 wird dieser Abschnitt nicht mehr vorhanden sein.

Die Breite wird weiterhin durch die global Variable content_width ermittelt. Wenn die Variable nicht definiert wurde, wird die Breite auf 500px festgelegt. Die Höhe des Mediums ist dann das 1,5-fache der Breite. Siehe dazu die Funktion wp_embed_defaults().
Mit Hilfe des bekannten Shortcodes [embed] ist weiterhin möglich, die Breite bzw. Höhe individuell anzupassen.

oEmbed deaktivieren

Das automatische Einbinden lässt sich ab WordPress 3.5 nur noch über einen Filter deaktivieren. Dazu folgende Zeile:

/**
 * Deaktiviert oEmbed ab WordPress 3.5.
 */
remove_filter( 'the_content', array( $GLOBALS['wp_embed'], 'autoembed' ), 8 );

Editorhöhe setzt auf Cookies

Die Höhe des Editors (der Textbox) ließ sich in den Einstellungen › Schreiben festlegen. Standardmäßig waren hier 20 Zeilen definiert.

In WordPress 3.5 wird die Höhe in ein Cookie gespeichert. Dadurch kann die Höhe inviduell für den jeweiligen Artikel optimal angepasst werden.

Zusammen mit meinem Plugin Preserve Editor Scroll Position wird das Schreiben direkt viel angenehmer.

Privatsphäre als eigenständige Seite entfernt

Zur Privatsphäre gehörte die Einstellung zur Sichtbarkeit der Seite. Diese Einstellung ist aber nicht komplett von der Oberfläche verschwunden.

Die Index-Einstellung ist in WordPress 3.5 nun unter Einstellungen › Lesen einsortiert.
Anstelle einer Ja-Nein Auswahl gibt es auch nur noch eine Checkbox.

Upload Verzeichnis ändern

Neben dem Verschieben des wp-content-Verzeichnis, Plugin- oder Theme-Verzeichnis ist es auch möglich, ein benutzerdefiniertes Verzeichnis für die Dateiuploads zu definieren. Der Pfad konnte unter Einstellungen › Mediathek eingestellt werden.
Allerdings war weiterhin ein Zugriff auf das Dateisystem nötig, sodass gerade Anfänger hier viel kaputt machen konnten.
Dies ist auch der Hauptgrund dafür, dass die Einstellung in WordPress 3.5 nicht mehr vorhanden ist. Sie wird nur noch angezeigt, wenn die Einstellung schon vor 3.5 geändert wurde.
Ansonsten lässt sich ein benutzerdefiniertes Verzeichnis weiterhin über Konstanten oder Filter (wp_upload_dir()) definieren.

Zum Thema

• Remove autoembed_urls, embed_size_w, embed_size_h — core.trac.wordpress.org
• WordPress Plugin: Auto-embeds Disabler — gist.github.com
• Remove default_post_edit_rows — core.trac.wordpress.org
• Settings -> Privacy “block search engines” option is not accurate — core.trac.wordpress.org
• Hide upload_path and upload_url_path from the UI for new installs — core.trac.wordpress.org

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.

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

• Enable XML-RPC by default and remove the option — core.trac.wordpress.org
• Mobile Apps — wordpress.org
• XML-RPC WordPress API — codex.wordpress.org
• WordPress Plugin: XML-RPC Disabler — gist.github.com

Titelbild von Matt.

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

• Bump memory limit from 32MB — core.trac.wordpress.org
• php.ini Direktiven: memory_limit — php.net
• »Fatal error: Allowed memory size of *** bytes exhausted…« ? — faq.wpde.org
• WordPress: Print some debug infos into backend footer — gist.github.com

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

Seit geraumer Zeit besitzen WebKit Browser, siehe Chrome und Safari, einen XSS Filter, der überprüft, ob ein Skript, welches auf einer Webseite ausgeführt werden soll, sich auch schon in der POST Anfrage befand. Ist dem so, kann dies ein Indiz für eine XSS-Attacke sein und wird geblockt.

Mit folgenden Beispiel kann der XSS Filter selbst getestet werden:

<?php
if( ! $_POST ) :
?>
<form method="post">
	<input name="xss" value="<iframe src='http://example.com'></iframe>" />
	<input type="submit" />
</form>
<?php
else :
	echo $_POST['xss'];
endif;

Was hat das nun mit der Artikelvorschau in WordPress zu tun?

Ganz einfach: Starte Chrome oder Safari, erstelle einen Artikel mit einem YouTube Video und klicke auf den Button Vorschau.

Das Ergebnis:

Man sucht vergeblich das YouTube Video, die Konsole wirft ein „Refused to execute a JavaScript script. Source code of script found within request.“ aus und nach einem Reload des Fensters ist das YouTube Video wieder da.

Warum? Der XSS-Filter hat zugeschlagen.

Beim Klick auf den Vorschau Button wird eine POST Abfrage an /wp-admin/post.php gestartet und intern als post.php?action=preview aufgenommen.

Dadurch wird erreicht, dass eventuelle Änderungen in einem Entwurf oder einer Revision (Autosave) gespeichert werden. Genaueres kann man der Funktion post_preview() entnehmen.

Das Wichtige an der Funktion ist die Rückgabe. Er enthält die Weiterleitung zur eigentlichen Vorschau.

Wie bekannt ist, zeigt die Vorschau eine 1:1 Kopie des Artikels samt Änderungen. Dazu zählt auch in unserem Fall der vorher per POST gesendete Artikelinhalt mit dem YouTube Video.
Wir erinnern uns zurück: Der XSS-Filter schlägt zu, wenn ein Skript in einer POST Abfrage gefunden wird und gleichzeitig vom Browser gerendert werden soll.
Trotz dem Umweges ist dies nun bei WordPress genau der Fall.

Und jetzt?

Den WebKit XSS Filter umgehen

Mit Hilfe eines nicht-standardisierten HTTP-Headerfeldes X-XSS-Protection kann dem Browser mitteilt werden, dass schon auf der Client-Seite für die nötige Sicherheit gesorgt wurde. Der Wert des Feldes sollte dann mit 0 belegt werden.

Folgende Zeilen setzen das Vorhaben für unsere Artikelvorschau um und sollte in einem Plugin Platz finden.

/**
 * Add a X-XSS-Protection = 0 header for post previews to allow
 * Webkit browsers to render iframe and flash objects.
 * @see: http://core.trac.wordpress.org/ticket/20148
 *
 * @param $headers array  Already added header items.
 * @param $object  WP     The query variables.
 *
 * @return array
 */
function send_no_xss_protection_header( $headers, $object ) {
	if (
		! empty( $object->query_vars['preview'] ) &&
		! empty( $object->query_vars['p'] ) &&
		wp_get_referer() &&
		wp_get_referer() == sprintf( admin_url( 'post.php?post=%d&action=edit' ), $object->query_vars['p'] )
	)
		$headers['X-XSS-Protection'] = 0;


	return $headers;
}
add_filter( 'wp_headers', 'send_no_xss_protection_header', 10, 2 );

Führt man das obige Szenarion nun erneut aus, so sollte das YouTube Video direkt angezeigt werden.

Zum Thema

• Preview post in Webkit browser doesn’t render Flash objects — core.trac.wordpress.org
• Security in Depth: New Security Features — blog.chromium.org
• Controlling the XSS Filter — blogs.msdn.com
• HTTP access control (CORS) — developer.mozilla.org

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.

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

• Move unused JavaScript libraries to external sources — core.trac.wordpress.org
• JavaScript actions and filters — core.trac.wordpress.org
• Switch to min.js convention — core.trac.wordpress.org
• Add Underscore.js and Backbone.js to core — core.trac.wordpress.org