Sticky posts query, removed from loop

Sticky posts in WordPress are great to visually expose featured content in a theme. By default, WordPress shows posts marked as sticky at the top of the loop applying sticky as a special CSS class to post classes. Later on down the loop, they would show up again, in their natural position and without the extra class.
But we can, for fun and profit, also remove sticky post from the top of the main loop, wrap them into their own special query and print them in our theme templates using a (one) custom template tag.

Read on

Favicons, Touch-Icons, Tiles

Mit dem Real Favicon Generator kannst du Favicons, Touch und Tile Icons in allen erforderlichen Größen für Desktop-Browser, sowie Vorschau-Icons für iOS, Android und Windows in 3 einfachen Schritten generieren. HTML-Code und Bilddateien lassen sich über ein Mini-Plugin flexibel in WordPress einbinden, unabhängig vom verwendeten Theme.

Read on

WP Tavern, genauer gesagt Sarah Gooding, war so freundlich, meinem seit dem WordCamp Switzerland imminenten Vorschlag für eine Sprache-per-Post-API im WordPress-Core einen Beitrag zu widmen.

Beitrag von Sarah Gooding @ WP Tavern

Kurz gesagt, geht es um dieses Feature, dass es in WordPress (noch) nicht gibt:

Sprache für Beitrag wählen: in WordPress noch Zukunftsmusik

Ergänzung zum Tavern-Beitrag:

“As a user you’re pretty much locked in to the solution you choose, since not only are connections between original posts and translations gone when you switch plugins, but also the very marker of which language a post is written in simply vanishes or becomes ineffective,” Hübinger explained.

… hatte ich gesagt und eigentlich hinzugefügt, dass Multilingual Press eine Ausnahme bildet, da es die gesamte Sprachen-Struktur auf dem Multisite-Feature von WordPress aufbaut. Beim Deaktivieren des Plugins bleibt die sprachliche Zuordnung auf Site-Ebene daher vollständig erhalten, nur die Beziehungen der Sprachen zueinander werden nicht mehr vollständig abgebildet.

Dieses zwar nicht ganz unwichtige Detail hatte es, wahrscheinlich aus Platzgründen, nicht in den ansonsten hervorragenden Artikel der Tavern geschafft.

When Twitter Bootstrap first came out, I rewrote the compiled CSS to better reflect how I would author it by hand and to compare the file sizes. After minifying both files, the hand-crafted CSS was about 10% smaller than the pre-processor output. But when both files were also gzipped, the pre-processor output was about 5% smaller than the hand-crafted CSS.

This highlights how important it is to compare the size of files after HTTP compression, because minified file sizes do not tell the whole story.
It suggests that experienced CSS developers using pre-processors don’t need to be overly concerned about a certain degree of repetition in the compiled CSS because it can lend itself well to smaller file sizes after HTTP compression. The benefits of more maintainable “CSS” code via pre-processors should trump concerns about the aesthetics or size of the raw and minified output CSS.

Nicolas Gallagher