Aktueller Status 2016

Wir bekommen die letzten Monate über öfters die Frage gestellt, warum wir keine neuen Blogartikel veröffentlichen.

Derzeit sind wir bis in den Herbst hinein mit einem großen und langfristigen Projekt betreut. Das freut uns auf der einen Seite sehr, weil es eine reizvolle Herausforderung ist. Auf der anderen Seite müssen wir die meisten Anfragen potentieller Kunden leider abweisen. Ab Herbst 2016 wird das aber besser.

Intern passiert bei uns im Moment aber einiges:

Fixer Mitarbeiter

In unserem Umkreis bewegen sich zwar einige Freelancer und Partner, bis dato haben wir aber noch keinen fixen Mitarbeiter. Das ändert sich gerade und es schaut gut aus mit einem zukünftigen Kollegen. Wenns dann soweit ist, werden wir auch eine Blogartikelserie starten, die das Thema „Wie werde ich WordPress-Entwickler/Webentwickler“ behandelt.

GmbH

Wir sind gerade dabei unsere GesbR in eine GmbH umzugründen. Das ist ein logischer Schritt ab einer gewissen Größe, einem gewissen Umsatz und aufgrund der angedachten Zielen.
Für unsere Kunden ändert sich nix in der Geschäftsbeziehung. Wir haben dann einfach eine andere UID und eine Firmenbuchnummer.

Zukäufe/Übernahmen

Derzeit stehen wir in Verhandlungen, eine andere bekannte WordPress-Marke aus Österreich zu übernehmen. Wir werden diese Marke weiterführen und mit neuem Leben füllen. Dadurch wird ein Firmenbereich geschaffen, der nichts mit Agenturzusammenarbeit zu tun hat. Mehr dazu dann gegen Jahresende.

 

WordCamp Europe in Wien

Natürlich lassen wir uns das erste WordCamp Europe auf österreichischem Boden nicht entgehen! Wir werden mit drei Mann von 24. bis 26. Juni vor Ort sein und freuen uns auf andere interessante WordPress Geister.

https://2016.europe.wordcamp.org/

Pro bono

Wie jedes Jahr bieten wir zu Weihnachten ein Projekt im Wert von ca 1.000 € pro bono an. Da unser Zeitbudget heuer knapp wird bitten wir darum, eventuell uns schon jetzt die Ideen zukommen zu lassen. Wie gehabt setzen wir ein Projekt gratis um, wenn es einem guten Zweck dienen soll.

 

 

 

 

 

Wie werde ich Emojis los – soll ich überhaupt?

Kurzerklärung

Emojis sind ein moderner Weg der Kommunikation. Die Verwendung kostet aber Ladezeit und Geschwindigkeit. Emojis wird man mit dem Disable Emojis Plugin los.

https://wordpress.org/plugins/disable-emojis/
https://wordpress.org/plugins/disable-emojis/

Die Basics

Die Entwicklung von Emoji-Support begann rund um den Februar 2015.
Mit der Version 4.2 unterstützte WordPress Emojis dann im Core.

Emojis sind diese kleinen smileyähnlichen Bildchen wie das hier:

Emoji aus dem Noto Font
Urheber: Google

Damit kann man sprachunabhängig kommunizieren, wenn man will.
Emojis helfen zumindest recht einfach und schnell, seine Emotionen in größerem Umfang wiederzugeben.

Das Problem: Viele Smartphones unterstützen Emojis von Haus aus, daher steigt die Verwendung.
Aber nicht alle Geräte und (Desktop-) Browser können von sich aus Emojis anzeigen, deshalb wird in WordPress eine kleine JavaScript-Datei geladen die überprüft, ob Emojis korrekt angezeigt werden können.

Wenn das nicht passiert, könnte es so ausschauen wie im WordPress Codex:
Textstelle ohne Emojisupport
Daher werden Emojis dort durch Bilder ersetzt, wo der Browser keine Emojis anzeigen kann.

Damit hab ich nicht so unschöne Ergebnisse wie im WordPress Codex.

 

Probleme?

  • Verlängerung der Ladezeit und der Geschwindigkeit
  • Einbinden von Inhalten, die auf fremden Servern gehostet werden

 

Damit das jetzt reibungslos funktioniert, wird eben eine kleine JavaScript-Datei geladen. Diese ist ca 5Kb groß und verursacht einen eigenen Request.
Das Script checkt jetzt, ob Emoji Support da ist. Wenn dem nicht so ist, werden Emojis durch Bilder ersetzt, damit der Inhalt nicht verschandelt ausschaut.

Welche Auswirkungen hat das auf die Seiten-Renderzeit?
Hier die Angaben aus dem entsprechenden Ticket:

Now the JS takes 1.6ms to run – 1.5ms for the JS, and 0.1ms for the style recalculation. About 0.01ms is added per emoji replaced. If we need to load Twemoji: Parsing twemoji.js: 0.8ms

Die JS Datei braucht also 1.6 ms für das Parsen. Das Behandel pro Emojis kostet 0.01ms. Wenn die Twemoji Datei geladen werden muss, kommen noch 0.8ms hinzu. (Twemoji bietet Unterstützung für Emojis, wenn der Browser/das Gerät keine Emojis versteht)

Der zweite Punkt ist, dass die Emojis von wordpress.org geladen werden, wenn diese in Bilder umgewandelt werden müssen:

?

Firebug Ansicht vom Emoji img src

Das kostet einerseits wieder einen Request und eine DNS Abfrage des wp.org Hosts und andererseits hat dann ein anderer Server als mein eigener, Zugriff auf Daten meiner Besucher.

Wie werde ich die Emoji-Unterstützung los?

Der einfachste und empfohlene Weg ist das Disable Emojis Plugin.

https://wordpress.org/plugins/disable-emojis/

Der Code hinter dem Plugin ist umfangreicher als gedacht:

function disable_emojis() {
	remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
	remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
	remove_action( 'wp_print_styles', 'print_emoji_styles' );
	remove_action( 'admin_print_styles', 'print_emoji_styles' );	
	remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
	remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );	
	remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
	add_filter( 'tiny_mce_plugins', 'disable_emojis_tinymce' );
}
add_action( 'init', 'disable_emojis' );

https://plugins.trac.wordpress.org/browser/disable-emojis/trunk/disable-emojis.php#L29

Aus der Sicht eines WordPress-Entwicklers ist das ziemlich umständlich.
Eigentlich hätte man den gleichen Weg wie beim Deaktivieren anderer JS erwartet.
Nämlich die Verwendung von wp_deregister_script.
jQuery deaktiviert man zb einfach so:

wp_deregister_script( 'jquery' );

 

Leider geht’s halt nicht so einfach. Daher entweder das Plugin installieren – was meist die besere Option ist. Alternativ kann man ja Teile des Plugin-Codes in ein (Child-)Theme übernehmen.

 

Soll ich den Emoji-Support deaktivieren?

Diese Frage muss jeder für sich selbst beantworten.

Es gibt genug Personen, die Emojis in ihren Inhalten verwenden. Wird der Support dafür deaktiviert, schauen die Text eventuell nicht mehr so gut aus.

Wird der Support deaktiviert, erspare ich mir weitere Requests und beschleunige die Ladezeit.

 

Lustiges Detail am Rande: Die Emoji-Unterstützung geht so weit, dass diese sogar in der Url erlaubt sind, siehe:


https://make.wordpress.org/core/2015/04/02/omg-emoji-%F0%9F%98%8E/

https://make.wordpress.org/core/2015/04/02/omg-emoji-%F0%9F%98%8E//

https://wordpress.org/plugins/disable-emojis/
https://wordpress.org/plugins/disable-emojis/

https://github.com/thierrypigot/mu-plugins/blob/master/deregister-emoji.php
https://github.com/thierrypigot/mu-plugins/blob/master/deregister-emoji.php

 

https://core.trac.wordpress.org/ticket/31701#comment:18
https://core.trac.wordpress.org/ticket/31701#comment:18

 

https://github.com/twitter/twemoji
https://github.com/twitter/twemoji

 

https://codex.wordpress.org/Emoji
https://codex.wordpress.org/Emoji

 

https://make.wordpress.org/core/tag/emoji/
https://make.wordpress.org/core/tag/emoji/

 

http://wordpress.stackexchange.com/a/185578
http://wordpress.stackexchange.com/a/185578

WordCamp Europe nächstes Jahr in Wien!

Tu felix Austria – wieder einmal.

Nachdem heuer das erste Mal überhaupt ein WordCamp in Österreich stattfand, setzt man noch eines drauf und macht Wien nächstes Jahr zum Veranstaltungsort des WordCamp Europe 2016.
Vom 24. bis zum 26. Juni wird es stattfinden:

https://twitter.com/WPVienna/status/614830584658063360

https://twitter.com/WPVienna/status/614830584658063360

 

https://twitter.com/onthisearth/status/614827378506903552

https://twitter.com/onthisearth/status/614827378506903552

 

 

https://twitter.com/RubenSutiloFoto/status/614832840618983424

https://twitter.com/RubenSutiloFoto/status/614832840618983424

 

 

 

Update vom 29. Juni 2015:
Es gibt jetzt auch eine offizielle Stellungnahme, warum Wien das Rennen als Veranstaltungsort für das WordCamp 2016 gemacht hat:
Wien hat die perfekten Veranstaltungsräumlichkeiten und mit Paolo Belcastro hat man einen Organisator vor Ort, der auch schon in den letzten drei Jahren bei der Organisation des WordCamp Europe dabei war.
Hier der Originalartikel mit weiteren Details zur Auswahl des Veranstaltungsortes:

https://europe.wordcamp.org/2015/how-we-selected-vienna-the-wordcamp-europe-2016-host-city/
https://europe.wordcamp.org/2015/how-we-selected-vienna-the-wordcamp-europe-2016-host-city/

 

Vom 24. bis 26. Juni 2016 darf Wien also die WordPress-Gemeinde zum Stelldichein begrüßen.

Wir freuen uns darauf!

 

 

https://europe.wordcamp.org/2015/
https://europe.wordcamp.org/2015/

Quo vadis custom fields?

Im Jahr 2013 haben wir hier kurz darüber berichtet, dass man Custom Fields (Post Meta) besser nutzbar machen und umfangreiche Funktionalität dazu in den Core geben möchte. Es gab Bestrebungen, das Handling, Aussehen und die Funktionalität in „Richtung“ Advanced Custom Fields (ACF) zu treiben.

Mit etwas mehr als einer Million aktiven Installationen weltweit gehört ACF zu den beliebtesten Plugins und dürfte das führende Post Meta Plugin sein.
Warum?
Weil es die Metadaten aufwertet und sich unsagbar viele Dinge damit umsetzen lässt.

Das blieb dem Core-Entwicklerteam natürlich nicht verborgen und deswegen gab es auch schon im Jahr 2013 diesen Feature-as-a-Plugin-Ansatz, den wir in einem Blogpost kurz thematisiert haben.

Leider ist daraus nichts geworden – das Projekt ist eingeschlafen.

Helen Hou-Sandí, ein relativ neues Mitglied im Core-Entwicklerteam, hat sich dieser Sache nun angenommen und haucht der Idee neues Leben ein, Metadaten stärker in den Vordergrund zur rücken.

Durch den Erfolg der WP (JSON) API wird WordPress immer mehr zum Framework oder zur Grundlage für WebApps. Was auf der Hand liegt, weil man sich dadurch die Datenbankabstraktion, Benutzerverwaltung, Medienverwaltung usw usf spart.

Die JSON API ist eeextremst Gold wert – aber sie deckt nicht alles ab? Was nicht? GENAU! Custom Fields sind derzeit nicht zufriedenstellend implementiert.

 

Daten leben  nicht nur vom vordergründigen Inhalt alleine, sondern auch von den Metadaten und genau da hakt es ein wenig bei WordPress.

Zwei Eingabefelder alleine reichen im Jahr 2015 nicht mehr, um Metainformationen zu speichern.

Deswegen ist ACF ja so genial. Responsive Images, Slider, rudimentäre Webshopfunktionalität, globale Texte, Suchkriterien, Sortierkriterien, Front-End-Editing, Tag-, Category-, Termimages, zusätzliche Termoptions, rudimentäre Übersetzungen, flexible Inhalte usw usf.
Alles, was man sich an Funktionalität und verbundenen Daten wünscht und aufgrund der Tabellenstruktur der Post-Meta-Tabelle noch einigermaßen performant mit Custom Fields lösbar ist, lässt sich mit ACF leicht realisieren.

Was sich leicht realisieren lässt, wird auch von Entwicklern dankend angenommen und verwendet – dann soll so eine Funktionalität aber in den Core, um die Weiterentwicklung zu sichern. (Man sieht es beim Ausscheiden von Sergej Müller aus dem WordPress Universum, dass wir zu Abhängig von einzelnen Personen sind und diese dann auch noch zu wenig finanzieren.)

Automattic macht das eh ziemlich gut, und angelt sich die bekannteren Entwickler. (Ja! Es geht um die Entwickler! Die Plugins stehen alle unter der GPL und können von jedem geforkt werden.)
Durch den Schritt, WooCommerce zu kaufen, wandert ein weiteres, sehr stark verwendetes Plugin in „Richtung“ Core. WooCommerce wird voraussichtlich nicht direkt in den Core aufgenommen werden sondern wahrscheinlich das JetPack Plugin bereichern. Dennoch ist es für uns WordPress-Entwickler wichtig, dass WooCommerce unter der Obhut des Core-Entwicklerteams steht, die Weiterentwicklung gesichert ist und nicht die Gefahr besteht, eingestellt zu werden.

Uns als Entwickler kommen solche Schritte sehr entgegen, weil dadurch eine Planungssicherheit entsteht.

Daher ist es auch ziemlich unverständlich, warum man Elliot Condon, den Mann hinter ACF, nicht anstellt oder ACF kauft. Elliot wird vielleicht persönliche Gründe haben, davon Abstand zu nehmen.

Schade ist es aber, dass so ein Deal anscheinend nicht zustande kommt.

Dennoch geht hier etwas weiter. Das Core-Team ist dran, fängt aber bei Null an. ACF oder Elliot mit im Team zu haben wäre ein Raketenstart für die Verbesserung des Meta Handlings. Das spielt’s leider nicht, daher werden derzeit kleinere Brötchen gebacken.

Mehr Infos dazu gibt es hier:

https://make.wordpress.org/core/2015/05/27/metadata-api-project-reborn-the-new-fields-api-project/
https://make.wordpress.org/core/2015/05/27/metadata-api-project-reborn-the-new-fields-api-project/

 

https://make.wordpress.org/core/components/options-meta/
https://make.wordpress.org/core/components/options-meta/

 

Wir werden sehen, ob sich zwei Jahre später mehr tut und Erfolge erzielt werden, wenn es um Meta Handling im Core geht. Das Vorhaben ist ja schon einmal gescheitert – ich wünsche Helen daher mehr Erfolg bei diesem Versuch. Im Optimalfall können wir dann kompliziertere Daten- und Beziehungsstrukturen im Backend in Core-Mentalität abbilden und per JSON auslesen. Out of the box.

 

 

 

 

Sicherheitsrisiko durch fehlende Info im WordPress Codex (add_query_arg)

Seit Kurzem ist eine Sicherheitslücke bekannt, die dann auftritt, wenn man die Funktionen

add_query_arg()

und

remove_query_arg()

nicht richtig verwendet.

Problem

In der bisherigen Dokumentation wurde suggeriert, dass diese Funktionen die URLs escapen – also unsichere Zeichen aus der URL entfernen.

Dem war aber nicht so.

Daher beide Funktionen absichern, wenn diese mit Usereingaben verwendet, oder wenn damit potentiell unsichere URLs weiterverarbeitet werden.

Lösung:

Unbedingt folgende Funktonen zum Absichern verwenden:

esc_url() oder

esc_url_raw()

Wobei esc_url_raw() nur dort verwendet werden sollte, wo das „&“ Zeichen nicht ersetzt werden muss (speichern in die Datenbank, Redirect oder HTTP-Abfrage mit zB wp_remote_get()).

 

Weitere Infos:

https://wordpress.org/news/2015/04/wordpress-4-1-2/
https://wordpress.org/news/2015/04/wordpress-4-1-2/

https://make.wordpress.org/plugins/2015/04/20/fixing-add_query_arg-and-remove_query_arg-usage/
https://make.wordpress.org/plugins/2015/04/20/fixing-add_query_arg-and-remove_query_arg-usage/

https://www.golem.de/news/cross-site-scripting-zahlreiche-wordpress-plugins-verwenden-funktion-fehlerhaft-1504-113636.html

http://wptavern.com/xss-vulnerability-affects-more-than-a-dozen-popular-wordpress-plugins
http://wptavern.com/xss-vulnerability-affects-more-than-a-dozen-popular-wordpress-plugins

http://wptavern.com/xss-vulnerability-what-to-do-if-you-buy-or-sell-items-on-themeforest-and-codecanyon
http://wptavern.com/xss-vulnerability-what-to-do-if-you-buy-or-sell-items-on-themeforest-and-codecanyon

Vorsicht beim Setzen von Terms mit wp set object terms()

Um gleich mit der Tür in’s Haus zu fallen:

Warum?

Weil nicht überprüft wird, ob die Taxonomy des Terms mit dem Objekt verknüpft ist.
Es wird zB nicht überprüft, ob eine Kategorie der eingebauten Taxonomy ‚category‘ mit dem Beitragposttype ‚Post‘ verbunden ist.
Ob es daher überhaupt erlaubt ist, zB einem Beitrag eine Kategorie zuzuweisen.

Trotzdem wird das Term zum Objekt gespeichert!!

Ok, das Beispiel ist recht sinnlos weil wir ja wissen, dass Beiträge ganz einfach in Kategorien eingereiht werden können. Das Beispiel dient nur der Veranschaulichung.

Viel interessanter wird es beim Zuweisen von Custom Taxonomy Terms, also den selbst erstellten „Tags“ und „Kategorien“.

wp_set_object_terms() überprüft nämlich nicht, ob der Beitrag den ich gerade „tagge“ auch wirklich mit der Custom Taxonomy verbunden ist.
Genau das wird problematisch, wenn man  Geschäftslogik mit eigenen Kategorien oder Tags löst.
Denn ich kann mit wp_set_object_terms() zB eine Seite ohne Probleme (und ohne Fehlermeldung) out-of-the-box einen Tag oder eine Kategorie zuweisen.

Lösung:

Vor dem Speichern mit wp set object terms() einfach überprüfen, ob der „Post“ (also das Objekt) eh mit der entsprechenden Custom Taxonomy verknüpft ist.

Wie finde ich das heraus?

Lösung mit der globalen wp_taxonomies Variable:

  global $wp_taxonomies;
  $alle_taxonomie_objekte   = $wp_taxonomies;
  $zugewiesenen_taxonomien  = $alle_taxonomie_objekte['category']->object_type;
  /*
  Array
  (
      [0] => post
      [1] => my_custom_post_type_wpent
  )
  */

Es gibt eine globale Variable, die alle Taxonomien mit den diversen Informationen bereithält. Wir sehen in diesem Beispiel, dass die normale WordPress Kategorie mit den Beiträgen (‚posts‘) und einem Custom Post Type (‚my_custom_post_type_wpent‘) verknüpft ist.
Aber eben nicht mit dem ‚Page‘ Post Type aka „Seiten“.

Lösung mit get_object_taxonomies()

Den oben beschriebenen Weg können wir abkürzen, wenn wir die Funktion get_object_taxonomies() verwenden. Damit wird genau das oben gezeigte Array geholt. Im WP Codex gibt es dafür ein schönes Beispiel:

   $taxonomy_names = get_object_taxonomies( 'post' );
   print_r( $taxonomy_names);

Gibt uns folgendes zurück:

Array
(
    [0] => category
    [1] => post_tag
    [2] => post_format
)

 

Alternativ mit wp_get_object_terms()

Man könnte auch direkt mit wp_get_object_terms() alle Terms abfragen, die zu einem Post gehören.

 wp_get_object_terms( 123, 'my_custom_taxonomy_wpent' );

Ist die Taxonomy (hier „my_custom_taxonomy_wpent“) nicht mit dem Post 123 verknüpft, wird ein wp_error zurückgegeben.
Als Fehlermeldung bekommt man den Hinweis  „invalid_taxonomy“ zurück und kann darauf reagieren.

 Wie kommt es dazu?

Die Funktion wp_set_object_terms() ist in der Datei „taxonomy.php“ enthalten.

Es wird überprüft ob der übergebene Term existiert:
https://github.com/WordPress/WordPress/blob/4.1-branch/wp-includes/taxonomy.php#L2991

if ( !$term_info = term_exists($term, $taxonomy) ) {

 

Schauen wir uns die Funktion weiter näher an so sehen wir, dass zweimal die Funktion wp_get_object_terms() aufgerufen wird.
Diese Funktion liefert in unserem Fall ja einen Fehler zurück. Doch leider zu spät, da das Term schon gespeichert wurde. Außerdem wird gar nicht auf wp_error überprüft.

https://github.com/WordPress/WordPress/blob/4.1-branch/wp-includes/taxonomy.php#L2979

https://github.com/WordPress/WordPress/blob/4.1-branch/wp-includes/taxonomy.php#L3051

In beiden Fällen bekommt jetzt eine Variable ein wp_error Objekt zugewiesen. Keine der Variablen wird auf diesen Umstand hin überprüft.

 

Die Speicherung eines Terms, der eigentlich gar nicht mit einem Objekt (Post, Page, CPT) über die Taxonomy verknüpft ist, geht problemlos über die Bühne.

 

Informatives:

Check ob Term besteht
http://codex.wordpress.org/Function_Reference/term_exists

http://codex.wordpress.org/Function_Reference/term_exists

 

Check ob es die Taxonomy gibt
https://codex.wordpress.org/Function_Reference/taxonomy_exists
https://codex.wordpress.org/Function_Reference/taxonomy_exists

 

Holt alle Taxonomien eines Posts (Objektes)
http://codex.wordpress.org/Function_Reference/get_object_taxonomies
http://codex.wordpress.org/Function_Reference/get_object_taxonomies

 

wp_set_object_terms() auf Github
https://github.com/WordPress/WordPress/blob/4.1-branch/wp-includes/taxonomy.php#L2950
https://github.com/WordPress/WordPress/blob/4.1-branch/wp-includes/taxonomy.php#L2950

 

wp_get_object_terms() im Codex
http://codex.wordpress.org/Function_Reference/wp_get_object_terms
http://codex.wordpress.org/Function_Reference/wp_get_object_terms

 

wp_set_object_terms() im Codex
https://codex.wordpress.org/Function_Reference/wp_set_object_terms
https://codex.wordpress.org/Function_Reference/wp_set_object_terms

 

Check ob der Post einen gewissen Term hat
http://codex.wordpress.org/Function_Reference/has_term
http://codex.wordpress.org/Function_Reference/has_term

 

 

Wien hat sein Wordcamp – am 11. April ist es soweit

Wien hat sein Wordcamp!

Hamburg (seit 2008!), Paris,  Mailand, Birmingham, Barcelona, Jena, Cardiff, Bukarest, Utrecht, Griechenland, Kilkenny, Kopenhagen,  Berlin, Manchester, Sofia, Belgien, Stockholm, Lodz, Köln,  Oslo,  Edinburgh, Sevilla, Lissabon, Bologna, Bratislava, Lancaster, Leiden , Malaga, Sofia, London, Prag, Zürich, Timisoara, Mallorca, Warschau, durften u.a. schon Wordcamps auf europäischem Boden begrüßen.

http://central.wordcamp.org/schedule/past-wordcamps/
http://central.wordcamp.org/schedule/past-wordcamps/

In Österreich laufen die Uhren ein bisschen langsamer, aber nun ist es endlich soweit:

Am

11. April 2015

von 09.00 bis 18.00 Uhr

steigt das erste Wordcamp Wien/Österreich!

Veranstaltungsort ist die Uni Wien,Fakultät für Informatik, Währingerstrasse 29, 1090 Wien

http://vienna.wordcamp.org/2015/
http://vienna.wordcamp.org/2015/

Organisiert wird das Wordcamp anscheinend von den Machern des Wiener WP Meetups.

Das Wiener Meetup richtet sich eher international aus, daher ist die Vortragssprache meist Englisch. Was für das Publikum Sinn macht.
Was die Vernetzung aber nicht leichter macht.
Leider gibt es in Österreich sehr wenige Veranstaltungen, die sich dezidiert mit WP beschäftigen. Österreich ist da leider anders als zb Deutschland, Tschechien oder die Slowakei, wo die Community viel stärker vernetzt ist.

Daher ist es eine Wohltat endlich ein großes, offizielles Vernetzungstreffen in Wien erleben zu dürfen.

Wir sind natürlich Sponsor dieses Events und werden vor Ort sein.

Wer dabei sein will sollte hurtig handeln, denn von den 350 Tickets sind nur mehr noch gut 90 (Stand 18.02.2015) erhältlich.

http://vienna.wordcamp.org/2015/tickets/
http://vienna.wordcamp.org/2015/tickets/

 

https://twitter.com/wpvienna
https://twitter.com/wpvienna

 

http://wpvienna.com/
http://wpvienna.com/

 

Anzahl der (angezeigten/verwendeten ) Posts ändern – Ein Problem, viele Lösungsmöglichhkeiten

Egal ob es um das Anzeigen von Artikeln auf den diversen Seiten geht, oder darum,  mit zb der WP_Query Posts zu holen. Die Anzahl spielt oft eine Rolle.

Wie viele Posts auf der Seite aufscheinen oder ich mit einer Query bekommen möchte, lässt sich auf mehrere Arten lösen:

  1. Einstellen im Backend
  2. Mit  wp_query Parameter posts_per_page
  3. Mit  Action pre_get_posts
  4. Mit Filter parse_query
  5. Mit Action parse_request
  6. Mit Filter post_limits
  7. Mit Filter pre_option_posts_per_page
  8. Durch Ändern des wp_option Werts posts_per_page (!)
  9. Mit PHP

 

 1. Einstellen im Backend

Der einfachste Weg ist sicherlich, Im WordPress Backend unter Einstellungen -> Lesen die gewünschte Anzahl zu ändern.

Wobei die Anzahl separat für Einträge auf den Seiten und für den RSS Feed angepasst werden kann:

Veranschaulicht, wie man im Backend die Anzahl der Posts verändern kann
Veranschaulicht, wie man im Backend die Anzahl der Posts verändern kann

 

2. Mit  wp_query Parameter posts_per_page

Wenn eigene Loops oder Queries mit wp_query angestoßen werden, kann man ganz einfach den Parameter „posts_per_page“ verwenden:

$meine_neue_query = new WP_Query( 'posts_per_page=3' );


oder


$args_fuer_custom_posts = array(
    'posts_per_page'             => 3
);

$custom_posts = new WP_Query( $args_fuer_custom_posts );

 

Man kann für Archivseiten den Parameter posts_per_archive_page verwenden, der den vorhergehenden Parameter eben auf Archivseiten überschreibt.

 

3. Mit Action pre_get_posts

Die pre_get_posts Action ist mächtig und bietet viele Möglichkeiten, um das Query Ergebnis anzupassen. Eine davon verändert die Anzahl der zurückgegebenen Posts:

function aendere_post_anzahl_wpent( $query ) {
    if ( ! is_admin() && ! $query->is_main_query() )
        $query->set( 'posts_per_page', 3 );

}

add_action( 'pre_get_posts', 'aendere_post_anzahl_wpent' );

Bei pre_get_posts lassen sich einige (aber nicht alle) Conditional Tags verwenden.

4. Mit Filter parse_query

Der Filter parse_query funktioniert ähnlich wie die Action pre_get_posts

function aendere_post_anzahl_mit_pq_wpent( $query ) {
    if ( ! is_admin() && 'portfolio' == $query->query_vars['post_type'] ) {
        $query->set( 'posts_per_page', 1 );
    }
    
    return $query;
}    

add_filter( 'parse_query', 'aendere_post_anzahl_mit_pq_wpent' );

Wie bei pre_get_posts kann man auch bei parse_query Conditional Tags verwenden.

 

5. Mit Action parse_request

Die Action parse_request ist etwas kniffliger zu  handhaben, weil diese nur für die eigentliche Query gilt. Ich kann damit keine Custom Queries / Loops ändern, die ich mit wp_query o.ä. anstoße.

Parse_request macht aus der Url die Query und befüllt $wp->query_vars.

Das ist der Grund, warum ich hier keine wp_query Dinge ändern kann sondern nur die Standardquerie. Und das geht so:

add_action( 'parse_request', 'aendere_post_anzahl_mit_pr_wpent' );


function aendere_post_anzahl_mit_pr_wpent( $query ) {
    if (  'mein_cpt' == $query->query_vars['post_type'] ) {
        $query->query_vars[ 'posts_per_page' ] = 3;
    }
    
    return $query;
}

Zusätzliche Inspiration zu parse_request findet man hier:

https://wordpress.stackexchange.com/questions/27158/wordpress-multiple-category-search?answertab=active#tab-top
https://wordpress.stackexchange.com/questions/27158/wordpress-multiple-category-search?answertab=active#tab-top

 

6. Mit dem Filter post_limits

Mit post_limits kann man wiederum jede Query ändern und so die Anzahl der Posts einstellen:

add_filter( 'post_limits', 'andere_post_anzahl_durch_pl_wpent', 10, 2 );

function andere_post_anzahl_durch_pl_wpent( $limit, $query ) {

    if ( ! is_admin() && ! $query->is_main_query() && ! $query->is_search() ) {
        return 'LIMIT 0, 3';
    }

    return $limit;
}

 

7. Mit dem Filter pre_option_posts_per_page

Der Filter pre_option_posts_per_page gehört zum Filterbundle pre_option_(option_name). Dieser Filter ist besonders praktisch, wenn ich Werte aus der Options Tabelle verwende/brauche, ich diese aber nicht verändert in der Datenbank abspeichern will.

Wenn ich den Options Wert also nur kurz abwandeln und damit arbeiten will, ohne fix vorgegebene Werte zu verändern.

In unserem Fall ist ja der Wert, wie viele Posts angezeigt werden sollen, in der wp_options mit dem Eintrag „posts_per_page“ gespeichert. Dieser Options Eintrag hat standardmäßig den Wert 10 und kann vom User (siehe Screenshot oben) im Backend verändert werden.

Man könnte den Wert jetzt in den Options ändern (schlechte Idee, siehe unten) oder einfach einen temporären Wert verwenden, siehe:

add_filter( 'pre_option_posts_per_page', 'anzahl_aendern_mit_ppp_wpent' );

function anzahl_aendern_mit_ppp_wpent( $posts_per_page ) {

    global $wp_query;
    if ( 'mein_cpt' == $wp_query->query_vars['post_type'] )
        return 3;   
        
    return $posts_per_page;
}

Ein weiterer Options Eintrag besteht für die Anzahl der angezeigten Artikel im RSS Feed (siehe Screenshot oben). Das Gegenstück zu pre_option_posts_per_page ist dann pre_option_posts_per_rss. (Options Eintrag „posts_per_rss„)

 

8. Durch Ändern des wp_option Werts posts_per_page

Wenn im Backend der Punkt „Blogseiten zeigen maximal [  x  ] Werte“ geändert wird, wird der Wert in der Datenbank gespeichert. Genauer gesagt in der Tabelle wp_options.

Man kann daher hergehen und einfach diesen options Wert ändern, zb mit

update_option( 'posts_per_page', 3 );

Der Options-Eintrag lautet „posts_per_page“ (oder posts_per_rss für RSS Feeds) und kann per PHP Code angepasst werden.

Das ist aber meist eine schlechte Idee, weil dadurch Usereingaben verändert werden können. Der Benutzer bekommt von der Änderung nichts mit und sieht dann andere Ergebnisse, als er sich eigentlich erwartet hat.

 

9. Durch PHP eigene Funktionen oder mit JavaScript usw usf

Wenn die Daten von der Datenbank geholt wurden, habe ich immer noch die Möglichkeit mit stinknormalen PHP Funktionen die Anzahl zu ändern.

Oder aber auch auf der letzten Instanz, per JavaScript im Browser des Users, des Seitenbetrachters.

Dieser Punkt hat mit WordPress selbst nicht mehr viel zu tun, daher werden die Möglichkeiten hier nicht besprochen.

 

 

Alle hier gezeigten Funktionen/Hooks wurden getestet und funktionieren unter WordPress 4.1.

.concat() 2015

Am 7. März 2015 gibt es in Österreich eine recht interessante Web Development Veranstaltung mit dem Namen .concat().

Zu finden unter:

https://conc.at/

Interessant vor allem wegen der anwesenden Speaker wie

Douglas Crockford (dem „Erfinder“ von JSON),
Lena Reinhard von Hood.ie und natürlich
Vitaly Friedman (den man eher nicht näher beschreiben muss ).

Warum wir dafür Werbung machen?
Einerseits weil wir solche Vernetzungstreffen in einem kleinen Land wie Österreich verdammt gut finden.

Andererseits weil wir im Moment sehr beschäftigt sind, was sich in der Frequenz der neuen Blogartikel niederschlägt, aber dort vor Ort sein werden.

Wer immer also Lust und Laune hat uns kennenzulernen -> ab auf die .concat() 2015. Wir sind dort zwar keine Speaker aber wir freuen uns auf interessante Gespräche rund um Webentwcklung, WordPress Entwicklung und sonstigem PC/Internet Kram.

 

Wir haben übrigens die Order ID 23. Wenn das kein Zeichen ist!

 

 

 

Quick Tip: Slug nicht für Werte verwenden, mit denen man arbeiten will

Ich erlebe es in letzter Zeit häufiger, dass Entwickler wichtige Werte in Slugs von Kategorien oder Custom Taxonomies speichern.

Werte, mit denen später weitergearbeitet werden soll.
Die für Abfragen, Abhängigkeiten oder Verbindungen gebraucht werden.

Also zb den Wert von Steuersätzen (zb 20%, 19%, 10%, 0%) als Slug.
Mit diesen Steuersätzen sollen natürlich Berechnungen angestellt werden und daher wird darauf vertraut, dass der Slug den Steuersatz (noch dazu als STRING!) enthält.

Das ist eine ganz schlechte Idee, da Plugins oder andere Funktionalität in die Term/Tag Erstellung eingreifen und damit die Werte verfälschen kann.

Auch besteht die Möglichkeit, dass WordPress den Slug selbstständig ändert, wenn es ihn schon gibt.

Die bessere Variante ist, solche Werte in eigene Tabellen auszulagern.