WordPress emoticons (of emoji) verwijderen

WordPress introduceerde emoticons (WP noemt ze emoji’s, vraag me niet waarom) in versie 4.2 van het populaire Content Management Systeem (CMS). Eerlijk gezegd snap ik niet waarom en vind ik het een vrij ondoordachte stap. WordPress is de afgelopen jaren uitgegroeid van een bloggersplatform tot een volwaardig en zeer uitgebreid CMS. Het standaard invoeren van emoticons lijkt op een stap terug: emoticons kunnen misschien een rol spelen op een interactief blog, maar toch niet op een serieuze bedrijfswebsite of webwinkel? Het is voor mij een raadsel waarom WordPress dit niet heeft ingevoerd als een optie: “Wilt u emoticons activeren? JA/NEE”.

Hoe dan ook, het de-activeren van deze emoji’s is niet zo moeilijk. Voeg de volgende code toe aan het bestand ‘functions.php’ in de folder van je thema (voorbeeld: /wp-content/themes/THEMANAAM/functions.php):


function disable_wp_emojicons() {
  // all actions related to emojis
  remove_action( 'admin_print_styles', 'print_emoji_styles' );
  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_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
  remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
  remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
  // filter to remove TinyMCE emojis
  add_filter( 'tiny_mce_plugins', 'disable_emojicons_tinymce' );
}
add_action( 'init', 'disable_wp_emojicons' );

function disable_emojicons_tinymce( $plugins ) {
  if ( is_array( $plugins ) ) {
    return array_diff( $plugins, array( 'wpemoji' ) );
  } else {
    return array();
  }
}
Geografische Targeting met Google Webmaster Tools

Geografische targeting met Google Webmaster Tools

We gaan ervan uit dat u al bekend met Google Webmaster Tools. U hebt waarschijnlijk al uw sitemaps toegevoegd en checkt regelmatig of die worden geïndexeerd en of Google problemen met die sitemaps en/of uw website rapporteert.

Wist u dat u (delen van) uw website kunt richten op specifieke landen? Dat is niet nodig als u al een top-level landendomein hebt, zoals .nl of .be. Google neemt dan al automatisch aan dat de website is gericht op Nederland respectievelijk België. Deze tip is alleen van toepassing voor zogeheten generieke top-level domeinen, zoals .com, .edu, of .org.

Als uw website meertalig is, kan het nuttig zijn de verschillende talen op specifieke landen te richten. Laten we zeggen dat uw standaardtaal Nederlands is, met daarnaast Noors, Zweeds en Deens. Deze drie extra talen zijn duidelijk voor een bepaald land.

Uw hoofdsite is al opgenomen in Webmaster Tools. De extra talen voegt u als aparte sites toe; met bovenstaande talen dus mijnwebsite.com/no/, mijnwebsite.com/se/ en mijnwebsite.com/dk/ (of, als u met subdomeinen werkt, no.mijnwebsite.com, se.mijnwebsite.com en dk.mijnwebsite.com).

Als dat is gebeurd, kunt u voor bijvoorbeeld mijnwebsite.com/no/ onder ‘Internationale targeting’ Noorwegen kiezen. Na enige tijd zal uw website in de Noorse taal in google.no beter scoren.

Let op: u moet wel voor elke taal apart zogenoemde xml sitemaps toevoegen. Hoe u dat kunt doen met WPML en WordPress SEO hebben we in een vorig bericht behandeld: Yoast WordPress SEO: Sitemap voor elke taal.

Maar wat nu als u als extra taal Duits hebt? Dat wordt tenslotte in drie landen gesproken: Duitsland, Zwitserland en Oostenrijk. Helaas, dan is geografische targeting niet mogelijk, want u kunt slechts één land kiezen, niet meerdere. Tenzij u zich vooral richt op klanten in Duitsland, dan kunt u wel overwegen de Duitstalige site op dat land te richten (en dus beter te scoren in google.de).

sitemap voor elke taal

Yoast WordPress SEO: Sitemap voor elke taal

De WordPress SEO plugin van Yoast is zeer populair (actief op meer dan 1 miljoen websites). Deze plugin kan ook XML Sitemaps aan je website toevoegen. Maar als je een meertalige website hebt, is niet erg duidelijk hoe je voor elke taal apart sitemaps kunt maken. Met WPML is dat alleen mogelijk als je verschillende subdomeinen hebt (bijv. nl.mywebsite.com en en.mywebsite.com) en in de taal-instellingen van WPML ‘een apart domein voor elke taal’ aanvinkt.

Maar wat als je geen subdomeinen hebt, maar voor elke taal een aparte submap (bijv. mijnwebsite.com/nl/ en mijnwebsite.com/en/)?

De oplossing is niet zo moeilijk. Voeg de volgende code toe aan het bestand functions.php in je themafolder:


if (isset($sitepress)) add_filter('wpseo_posts_join', 'sitemap_per_language', 10, 2);
function sitemap_per_language($join, $type) {
    global $wpdb, $sitepress;
    $lang = $sitepress->get_current_language();
    return " JOIN " . $wpdb->prefix . "icl_translations ON element_id = ID AND element_type = 'post_$type' AND language_code = '$lang'";
}

De XML sitemap voor je standaardtaal is nog steeds te vinden via de link mijnwebsite.com/sitemap_index.xml. De andere talen hebben geen ‘index.xml’, maar aparte sitemaps, zoals ‘mijnwebsite.com/en/post-sitemap.xml‘ en ‘mywebsite.com/en/page-sitemap.xml‘ (en mogelijk nog meerdere, afhankelijk van hoeveel verschillende post types je hebt, bijvoorbeeld producten).

Als je nu je sitemaps wil toevoegen bij Google Webmaster Tools kun je voor de standaardtaal gewoon één link gebruiken: ‘sitemap_index.xml’, maar voor je andere talen moet je meerdere XML sitemaps toevoegen, zoals hierboven beschreven.

Bovenstaande stappen zijn noodzakelijk als je een algemeen hoofddomein (.com, .org) hebt en een deel van je site op een bepaald land wilt richten (bijv. Nederland). Dit heet Geografische target.

Beperk datumkeuze in Gravity Forms

Gravity Forms Datepicker: beperk datumkeuze

Wat zou het toch handig zijn als Gravity Forms het makkelijk maakte om de datumkeuze in de datepicker te beperken. Behalve als het om bijv. een geboortedatum gaat, heeft het vaak geen zin om 100 jaar terug in de tijd te kunnen. Sommige plugins beloven dat je in de administratie van het formulier makkelijk de datum kunt beperken, maar met deze plugin kun je alleen maar vaste data invoeren. Onbruikbaar als je de datum wil beperken tot bijvoorbeeld vandaag en 1 jaar vooruit.

Je kunt een simpele jQuery code toevoegen aan de pagina, zoals deze:

jQuery(document).ready(function($) {
    $(".datepicker").datepicker({ minDate: 0 });
});

Oops, maar je bent nu wel de kalender-icon kwijt! Die moet je dus nog eens extra weer toevoegen, bijvoorbeeld met onderstaande code (controleer of het pad naar dat icon correct is!):

jQuery(document).ready(function($) {
		$( "#input_6_3-0" ).datepicker({  buttonImage: 'images/calendar.gif', minDate: '+1d' });
  });

Maar zelfs met bovenstaande code gebeurt het dat het kalender-icon niet verschijnt. Ik heb niet kunnen uitvinden waardoor dat komt. Het enige wat er dan nog op zit is een core file van Gravity Forms aan te passen: wp-content/plugins/gravityforms/js/datepicker.js

Dat klinkt ingrijpender dan het is. Sterker, het is doodeenvoudig, verander dit (op regel 9 en 10):

yearRange: '-100:+20',
showOn: 'focus',

naar dit:

yearRange: '0:+1',
minDate: '+1w',
maxDate: '+1y',
showOn: 'focus',

De code spreekt voor zichzelf: een gebruiker kan alleen het huidige of volgende jaar selecteren en alleen een datum die minstens 1 week en maximaal 1 jaar in de toekomst ligt.

Er zit natuurlijk een nadeel aan deze werkwijze, want het bestand wordt overschreven zodra je Gravity Forms update. Maar ik vind dit een zo makkelijk oplossing voor dit probleem, dat ik gewoon een notitie maak om bij een update dit kleine klusje (minder dan 1 minuut werk) opnieuw te doen.