Eigene Bildgrößen in der WordPress-Mediathek auswählbar machen

Dass man bei WordPress relativ leicht eigene Bildgrößen einstellen kann und in seinem Template einbinden kann ist meiner Meinung nach recht bekannt. Vor kurzem brauchte ich jedoch die Möglichkeit, dass der Anwender eben diese eigens angelegten Bildgrößen auch selber auswählen kann und sich nicht nur zwischen den vordefinierten Bildgrößen entscheiden muss:
WordPress-Mediathek Standard-Bildgrößen
Dazu bietet WordPress einen schönen Filter, welcher leicht zu implementieren ist. Vorerst jedoch muss man die Voraussetzung schaffen, um eigene Bildgrößen anlegen zu können. Der nachfolgende Code erklärt, wie man sowohl eigene Bildgrößen definiert und wie man diese in der Mediathek beim Bild einfügen – Dialog auswählbar macht. Er ist in die functions.php-Datei des Themes einzubauen:

/**
 * Enable support for Post Thumbnails 
 * (Support für eigene Bildgrößen einschalten)
 */
add_theme_support( 'post-thumbnails' );
 
/**
 * Add custom image sizes 
 * (Eigene Bildgrößen hinzufügen)
 */
add_action( 'after_setup_theme', 'af_add_custom_image_sizes' );
function af_add_custom_image_sizes() {
              //params: 'size-name', width, height, crop
    add_image_size( 'home-featured-image', 306, 152, false );
    add_image_size( 'imageslider-preview', 180, 240, false);
    add_image_size( 'imageslider-view', 99999, 600, false);
}
/**
 * Make custom image sizes available via media manager 
 * (Eigene Bildgrößen in der Mediathek verfügbar machen)
 */
add_filter( 'image_size_names_choose', 'custom_image_sizes_choose' );
function custom_image_sizes_choose( $sizes ) {
	$custom_sizes = array(
			'home-featured-image' => 'Startseitenbilder',
			'imageslider-preview' => 'Slider-Vorschau',
			'imageslider-view' => 'Slider-Bild'
	);
	return array_merge( $sizes, $custom_sizes );
}

Wichtig ist, dass man die Bezeichnung des ersten Parameters bei add_image_size gleich setzt zu den Keys im Array $custom_sizes. Am besten speichert man sich diese in einer eigenen Variable.
Im Template kann man dann über die Bezeichnungen die entsprechende Bildgröße einbinden:

/**
 * into the loop
 * (innerhalb des Loops)
 */
if(has_post_thumbnail()){
	the_post_thumbnail('home-featured-image');
}
/**
 * somewhere else i.e. outside the loop
 * woanders, z.B. außerhalb des Loops
 */
if(has_post_thumbnail($post->ID)){
	echo get_the_post_thumbnail($post->ID, 'home-featured-image');
}

Auch kann man die eigene Bildgröße in allen Bildfunktionen verwenden, die $size als Parameter empfangen können, beispielsweise wp_get_attachment_image(), wp_get_attachment_image_src() oder wp_get_attachment_link(). Die letzten 3 Funktionen benötigen jedoch eine Attachment-ID als Pflichtparameter (siehe Dokuverlinkungen).

Das Ergebnis in meinem Beispiel kann nun folgendermaßen aussehen:

Sieht man hinter den eigenen Bildgrößen keine Dateimaße und sind die Radio-Buttons ausgegraut und nicht anklickbar, so existiert diese Datei nicht in diesem Format. Gründe dafür können sein, dass sie zu klein ist für die eingestellte Bildgröße und somit nicht erstellt werden konnte oder dass die Datei hochgeladen wurde, bevor man die eigenen Bilddateigrößen festgelegt hat. Im Normalfall sollte jedoch folgende Ansicht danach vorhanden sein:
WordPress eigene Bilddateigrößen in der Mediathek auswählen

Viel Erfolg beim Umsetzen! Feedback und Verbesserungsvorschläge immer erwünscht! 🙂

Eigenen JavaScript-Code in das WordPress-Backend einbinden

Beim letzten Projekt benötigte ich JavaScript-Code, um das Backend ein wenig zu modifizieren. Hier will ich kurz anhand eines Beispiels festhalten, wie ich das realisiert habe.
Konkret ging es darum, dass ich im Backend ein Feld hatte, welches den Farbcode eines Elements im DOM bestimmen sollte. Der User sollte dazu aus einer vorgegebenen Liste mit Farbwerten einen auswählen und das DOM-Element sollte mittels Inline-CSS die entsprechende Hintergrundfarbe annehmen:

Normale Select-Option-HTML-Liste

Diese Liste wurde via Backend durch das (absolut empfehlenswerte!) Plugin Types eingepflegt und die Option-Values enthielten den CSS-kompatiblen Farbcode:

Da die Farbwerte jedoch teils recht nah beieinanderlagen, wollte ich die Select-Liste mit der entsprechenden Hintergrundfarbe unterlegen, so dass der User im Backend sieht, welchen Farbton er auswählt.
Das Plugin generiert folgenden HTML-Code für die Select-Liste:

<select id="wpcf-select-pagecolor-1178946369" name="wpcf[pagecolor]" class="wpcf-form-select form-select select">
	<option value="white" class="wpcf-form-option form-option option">Weiß</option>
	<option value="#cc3f14" class="wpcf-form-option form-option option">Rotorange</option>
	<option value="red" class="wpcf-form-option form-option option">Rot</option>
	<option value="#ffd900" class="wpcf-form-option form-option option">Dunkelgelb</option>
	<option value="#6f0" class="wpcf-form-option form-option option">Leuchtend Hellgrün</option>
	<option value="#24ff21" class="wpcf-form-option form-option option">Hellgrün</option>
	<option value="#0580ff" class="wpcf-form-option form-option option">Hellblau</option>
	<option value="#b2ffff" class="wpcf-form-option form-option option">Helltürkis</option>
	<option value="#ba87ff" class="wpcf-form-option form-option option">Hellviolett</option>
	<option value="#f200c2" class="wpcf-form-option form-option option">Pink</option>
</select>

 

Das Ergebnis sollte so aussehen:

Eingefärbte HTML-Select-Option-Liste

Dazu wollte ich mittels jQuery die value’s der option-Tags auslesen, also die Werte, die ich via Types CSS-kompatibel im Backend vorher eingepflegt hatte.

Folgender Code half hier aus:

<!--?php 
function custom_admin_js() {
	$script = '<script type="text/javascript"-->// &lt; ![CDATA['; 	$script .= ' 	jQuery(document).ready( function(){ 		var setBackground = function(){ 			jQuery("select[name=\"wpcf[pagecolor]\"]").css("background-color",  				jQuery("select[name=\"wpcf[pagecolor]\"]").find("option:selected").val() 			)}; 		setBackground(); 		jQuery("select[name=\"wpcf[pagecolor]\"]").find("option").each(function(){ 			jQuery(this).css("background-color", jQuery(this).val()); 		}); 		jQuery("select[name=\"wpcf[pagecolor]\"]").on("change",setBackground); 	}); 	'; 	$script .= ' // ]]&gt;';
	echo $script;
}
add_action('admin_head', 'custom_admin_js');
?&gt;

Wichtig hier ist der add_action – Aufruf, der als 2. Parameter den Namen der Funktion bekommt, die obenstehend deklariert ist und den JavaScript-Code enthält. Dort kann natürlich auch jeder andere Code stehen.

In meinem Fall benötigte ich den obenstehenden jQuery-Code, welcher hier nochmal genauer erläutert wird:

jQuery(document).ready( function(){
	//save background-color setting function for select-element into variable
	var setBackground = function(){
		jQuery("select[name=\"wpcf[pagecolor]\"]").css("background-color", 
			jQuery("select[name=\"wpcf[pagecolor]\"]").find("option:selected").val()
		)};
 
	//call the function to set the background color of the select-element
	setBackground();
 
	//set background-color for all option-tags
	jQuery("select[name=\"wpcf[pagecolor]\"]").find("option").each(function(){
		jQuery(this).css("background-color", jQuery(this).val());
	});
 
	//bind change-event to select-element
	jQuery("select[name=\"wpcf[pagecolor]\"]").on("change",setBackground);
});

Als jQuery-Selector konnte ich auf keine ID zugreifen, da die ID vom Types-Plugin generiert wurde und in jeder Installation anders wäre, daher nutzte ich folgenden Selektor:

select[name="wpcf[pagecolor]"]

Dieser war für meine Zwecke ausreichend, da er eindeutig war. In der Variable setBackground speichere ich mir eine Funktion, die das in der Select-Liste selektierte Option-Tag ausliest und den value-Wert als Hintergrundfarbe des Select-Elements setzt. Danach rufe ich die Funktion auch gleich auf, um den Wert zu setzen. Als rein anonyme Funktion kann ich sie jedoch nicht nutzen, da ich auch bei Farbwechsel den neu ausgewählten Wert setzen wollte. Dazu dient die letzte Zeile, in welcher der Event-Handler „onchange“ die Funktion „setBackground()“ bei Wechsel des Option-Elements aufruft. Wichtig hierbei ist, dass die Funktion ohne () übergeben wird, da hier nur die Referenz auf die Funktion notwendig ist. Würde man die Klammern mit übergeben, würde die Funktion direkt an dieser Stelle im Code ausgeführt werden und nicht erst bei Aufruf des Change-Events.

Das wars dann auch schon!
Anregungen, Kommentare und Verbesserungsvorschläge sind erwünscht! 🙂

Links in Posts von WordPress ersetzen in der Datenbank mit MySQL-Anweisung

Achtung! Dieser Beitrag ist ursprünglich vom Januar 2009 und damit schon sehr alt. Die hier veröffentlichten Informationen zum Umziehen berücksichtigen keine URLs, die serialisiert abgelegt werden. Bei serialisierten Daten können nicht einfach die URLs ersetzt werden, da hier die Zeichenlänge mit abgespeichert wird. Eine sicherere Variante gibt es hier: https://interconnectit.com/products/search-and-replace-for-wordpress-databases/ (in Englisch)

Der ursprüngliche Artikel:

Gerade ein akuter Fall bei mir gewesen: ich hatte zwecks Domainumzug (nicht bei mir, ich bleib hier! 🙂 ) das Problem, dass ich Artikel eines anderen Blogs in den neuen Blog importiert hatte, in denen Bilder verlinkt waren, welche jedoch noch zur alten Domain verlinkten. Via FTP hab ich das upload-Verzeichnis direkt in den neuen Blog übertragen können und somit alle hochgeladenen Bilder des alten Blogs bereits auf dem neuen Blog gehabt, jedoch nur physisch und nicht verlinkt. Nun wollte ich aber nicht die über 100 Artikel bearbeiten und die Bild-URLs aktualisieren, sondern suchte nach einer anderen Lösung. Ich wollte in der Datenbank in der Tabelle

wp_posts

in der Spalte

post_content

alle URLs mit der neuen Domain ersetzen. Auf der Suche nach einer Lösung suchte ich als erstes in der MySQL-Doku nach der

REPLACE()

-Funktion, diese jedoch liefert keine allzu guten Beispiele :-(. Glücklicherweise traf ich auf den Blog des Pfannenwenders, welcher in seinem Artikel „Suchen und Ersetzen in MySQL-Tabellen“ mir die Lösung auf dem Teller präsentierte.

 

Der entscheidende Befehl, welcher auf der MySQL-Datenbank auszuführen ist, lautet also:

 

UPDATE `wp_posts` SET `post_content` = REPLACE (
`post_content`,
'www.altedomain.de',
'www.neuedomain.de'
)

 

Dieser Befehl ersetzt alle vorkommenden www.altedomain.de mit www.neuedomain.de, beispielsweise: Im Artikel steht noch der alte Link:

<img src="http://www.altedomain.de/wp-content/uploads/bild.jpg" alt="" />

. Nach dem Ausführen des Update-Befehls steht dann statt dem alten Link dort:

<img src="http://www.neuedomain.de/wp-content/uploads/bild.jpg" alt="" />

. Und genauso wollte ich es haben! 🙂

Zu beachten sind die Backticks ( ` ) und die einfachen Anführungszeichen ( ). Die Tabelle und die Spalte der Tabelle müssen in Backticks geschrieben werden, die Suchstrings in einfachen Anführungszeichen. Falsch gesetzt wirft die Datenbank einen Fehler und führt den Update-Prozess nicht durch. Und, wie schon in Pfannenwenders Artikel: BACKUP der Datenbank vorher machen! Denn sonst ist alles schlimmstenfalls verpfuscht und nicht wiederherstellbar!

So, nun hoff ich mal, dass das jemandem hilft :-). Mir hats sehr geholfen und mindestens 600 Klicks erspart und ca. 2,5 Stunden Arbeit!

WordPress Stats Plugin zeigt keine Klicks für Posts und Seiten an – Gelöst!

Nach langem Suchen hab ich endlich die Lösung dafür gefunden. Wie schon früher berichtet gab es ja auf Clims Blog Probleme mit dem Plugin WordPress Stats. Nach einer Änderung am Theme hat das WordPress Stats Plugin immer 0 Views angezeigt, obwohl er Kommentare zu den Posts bekam. Nach diversen oben nachzulesenden Änderungen fehlten jedoch immernoch die Klicks auf die Artikel und Seiten. Da ich seit kurzem wieder intensiv an der Theme-Programmierung für WordPress arbeite, kam mir der Gedanke, dass ich ja im Forum von WordPress nochmal danach suchen kann. Siehe da, dort fand ich den Artikel, welcher besagt, dass das WP-Stats Plugin in der footer.php – Datei des Themes den Aufruf der wp_footer() – Funktion benötigt. Also flugs den Code oberhalb des schließenden -Tags in die footer.php gepackt und endlich geht alles wieder wie normal. Endlich werden die Klicks auf die Seiten und Posts wieder angezeigt! 🙂

Emailadressen in WordPress verschlüsseln mit PHPEnkoder

 

Ich mich mal wieder auf die Suche gemacht und nach einem Plugin gesucht, welches Emailadressen mittels JavaScript verschlüsselt, damit Spambots und Spammer die eMail nicht automatisiert herauslesen können. Endlich hab ich auch eine sehr einfache und effektive Methode gefunden. Im Beitrag von seovision.de fand ich nun das Plugin von weaselhat.com namens PHPEnkoder. Sinnvoll ist der Einsatz dieses Plugins, wenn man eMailadressen im Klartext in Beträgen oder Seite, beispielsweise dem Impressum,  verwenden will, so dass Leser mit Klick auf den mailto-Link direkt eMails von ihrem Client wie Thunderbird oder Outlook an den Betreiber senden können. Das Plugin verschlüsselt alle im Text gefundenen eMailadressen auch ohne mailto-Link mittels JavaScript. Kommt ein Nutzer ohne JavaScript, wird die eMailadresse nicht angezeigt. Für Webseitenbetreiber mit barrierefreiem Anspruch ist dieses Plugin leider nichts. Getestet hab ich das Plugin mit WordPress 2.6.2, funktioniert einwandfrei.