• [shortcode]
• [shortcode attribut="wert" /]
• [shortcode]Inhalt[/shortcode]

Interessant wird es nun aber, wenn man – so wie ich – einen Shortcode geschrieben hat, der sowohl in der “self-contained” (Variante 1 und 2) als auch als “enclosing” (Variante 3) Form vorkommen können soll. Verwendet man nämlich beides in dem gleichen Artikel, dann führt das zu unerwarteten Ergebnissen¹.

Das Problem

In meinem Fall der Shortcode [link], mit dessen Hilfe ich auf Artikel oder Seiten linken kann. Dabei habe ich – faul wie ich nunmal bin – die Möglichkeit eingebaut, entweder nur [link to=”post_slug|ID”] zu schreiben oder [link to=”post_slug|ID”]Irgendein text, der statt dem Artikel- oder Seitentitel angezeigt werden soll, wobei ein %s mit dem Titel ersetzt wird [/link].

Das klappte auch alles soweit ganz gut, bis ich in einem Test-Artikel beide Varianten mischte²:

\{link to="erdbeer-tiramisu"]

\{link to="stroppy-me-in-concert"]Auftritt\{/link]

Das Resultat war ähnlich dem Folgenden:

\{link to="stroppy-me-in-concert"]Auftritt

wobei der Text zum Artikel “Erdbeer-Tiramisu” verlinkt war.

Nach stundenlanger Suche fand ich die Ursache im regulären Ausdruck, der die Shortcodes herausfiltert. Und da Ursachen finden immer der erste Schritt zur Lösung eines Problems ist, war nach ein bißchen ausprobieren und Dokumentation lesen die Lösung auch schon gefunden.

Die Lösung

Wie bei vielen Problemen, so ist auch hier die Lösung – so die Ursache erst einmal gefunden ist – verblüffend einfach.

In der Datei wp-includes/shortcodes.php einfach den regulären Ausdruck von

178

return '(.?)\[('.$tagregexp.')\b(.*?)(?:(\/))?\](?:(.+?)\[\/\2\])?(.?)';

ändern in

178

return '(.?)\[('.$tagregexp.')\b(.*?)(?:(\/))?\](?:((?:.(?!\[\2))+?)\[\/\2\])?(.?)';

und schon kann man beide Varianten der Shortcodes für einen Tag in einem Artikel mischen und es funktioniert wie erwartet.

Dazu brauchte es nur einen negativen Lookahead, der auschließt, daß das Suchmuster passt, wenn im Inhalt des Shortcodes derselbe Shortcode noch einmal geöffnet wird³.

Einen Nachteil hat diese Lösung jedoch: Man ändert eine Kern-Datei von Wordpress, d.h. man muss beim nächsten Aktualisieren die Änderung wieder einfügen. Ich habe (noch) keine Ahnung, wo oder wie man dem Wordpress-Team Bugs melden kann, und bis ich das herausgefunden habe, werde ich diese Änderung wohl nach jeder Aktualisierung vergessen – und diesen Artikel wieder lesen :)

Ähnliche Artikel

• Meine neue Seite ist endlich online

(cc-by-nc-nd) 2009 Mathias Gelhausen