WPBakery: Externe Links öffnen nicht im neuen Tab – Lösung für Bridge & Qode

WPBakery Link öffnet nicht im neuen Tab? So behebst du den target="_blank"-Fehler bei Single Image, Bridge Theme und Qode mit einem PHP-Fix.

WPBakery: Externe Links öffnen nicht im neuen Tab – Lösung für Bridge & Qode


Kürzlich bemerkte ich auf einer unserer eigenen Websites, dass Bilder, die auf externe Websites verlinken, im WPBakery Page Builder plötzlich nicht mehr in einem neuen Tab geöffnet wurden. Die Einstellung „Open in new window“ beziehungsweise target="_blank" war im Backend korrekt gesetzt – im Frontend öffnete sich der Link trotzdem im gleichen Fenster. Bei der Fehlersuche zeigte sich, dass das Problem in unserem Fall erst bei der Ausgabe des WPBakery Single-Image-Elements im Zusammenspiel mit Bridge beziehungsweise Qode entstand.

WPBakery ignoriert target=“_blank“

Auf unserer Referenzseite verwenden wir mehrere WPBakery Single Image-Elemente. Die Bilder verlinken auf externe Kundenwebsites und sollen sich bewusst in einem neuen Browser-Tab öffnen.

Im WPBakery Page Builder war dafür korrekt eingestellt, dass der Link in einem neuen Fenster beziehungsweise Tab geöffnet werden soll.

Im Shortcode entspricht das:

img_link_target="_blank"

Trotzdem öffnete sich der externe Link beim Klick auf das Bild im gleichen Tab.

Zunächst lag der Verdacht bei WPBakery selbst, beim Browser oder bei einer Cache- beziehungsweise JavaScript-Optimierung. Ein Blick in den tatsächlich erzeugten HTML-Code brachte uns allerdings schnell weiter.

Was im HTML tatsächlich ausgegeben wurde

Im Frontend wurde der Link in unserem Fall so ausgegeben:

<a href="https://www.beispiel.de/" target="">

Der entscheidende Punkt ist:

target=""

Der für einen neuen Tab notwendige Wert _blank war bei der Ausgabe also verschwunden.

Korrekt müsste der HTML-Link beispielsweise so aussehen:

<a href="https://www.beispiel.de/" target="_blank">

Damit war klar:

Die Einstellung wurde im Backend gespeichert, ging aber bei der Verarbeitung beziehungsweise Ausgabe des Elements verloren.

Aus der Praxis

Bei solchen WPBakery-Problemen lohnt sich der Vergleich zwischen gespeicherter Einstellung und tatsächlich erzeugtem HTML. Steht im Backend ein neuer Tab fest, im Frontend aber nur target="", liegt der Fehler nicht bei der eingegebenen URL oder der Auswahl im Page Builder.

Die WPBakery-Einstellung war korrekt gespeichert

Der entscheidende Punkt bei der Fehlersuche war, dass die Einstellung für das Öffnen in einem neuen Browser-Tab im WPBakery Page Builder korrekt hinterlegt war.

Das Problem lag also nicht daran, dass _blank vergessen oder falsch eingestellt worden war.

Stattdessen ging der Wert erst bei der Ausgabe des Single-Image-Elements im Frontend verloren. Genau deshalb erschien im erzeugten HTML nur ein leeres target="", obwohl im Backend eigentlich ein neuer Tab vorgesehen war.

Damit verlagerte sich die Fehlersuche weg von der WPBakery-Einstellung selbst und hin zur Verarbeitung durch das Theme beziehungsweise die Qode-/Bridge-Erweiterung.

Bridge und Qode als Ursache

In unserem Setup verwenden die betroffenen Bilder zusätzlich die Qode-Hover-Funktion des Bridge Themes.

Genau an dieser Stelle wurde der von WPBakery gespeicherte Wert für das Linkziel offenbar nicht korrekt in das finale HTML übernommen.

Teilweise wurde sogar das interne WPBakery-Linkformat direkt als URL verarbeitet, anstatt daraus sauber die eigentliche Zieladresse und das Linkziel zu erzeugen.

In unserem Fall deutete deshalb alles auf ein Rendering- beziehungsweise Kompatibilitätsproblem zwischen WPBakery und der Bridge/Qode-Erweiterung des Single-Image-Elements hin.

Das ist auch der Grund, warum sich das Problem auf den ersten Blick so schwer einordnen ließ: Im Backend sah alles korrekt aus, erst die HTML-Ausgabe zeigte den eigentlichen Fehler.

Unsere Lösung über die functions.php

Da die Links im Backend bereits korrekt gepflegt waren, wollten wir nicht sämtliche Bilder und Zieladressen neu anlegen.

Stattdessen haben wir die fehlerhafte Ausgabe beim Rendern des WPBakery-Single-Image-Elements korrigiert.

Dafür verwenden wir auf dailyseven einen kleinen PHP-Filter in der functions.php des Child-Themes.

Der Filter prüft beim Ausgeben eines vc_single_image-Elements, ob ein neuer Browser-Tab vorgesehen ist. Ist das der Fall, wird target="_blank" wieder korrekt in den Link geschrieben.

Zusätzlich wird ein eventuell noch vorhandenes internes WPBakery-Linkformat über vc_build_link() aufgelöst und wieder in eine normale URL umgewandelt.

Der verwendete Fix sieht bei uns so aus:

add_filter('do_shortcode_tag', function ($output, $tag, $attr) {

    if ($tag !== 'vc_single_image') {
        return $output;
    }

    $output = preg_replace_callback('/<a\b[^>]*>/i', function ($matches) use ($attr) {

        $anchor = $matches[0];

        if (!preg_match('/\bhref=(["\'])(.*?)\1/i', $anchor, $href_match)) {
            return $anchor;
        }

        $raw_href = html_entity_decode(
            $href_match[2],
            ENT_QUOTES,
            'UTF-8'
        );

        $target = '';

        if (strpos($raw_href, 'url:') === 0) {

            if (function_exists('vc_build_link')) {

                $link = vc_build_link($raw_href);

                if (!empty($link['url'])) {

                    $url = esc_url($link['url']);

                    $anchor = preg_replace(
                        '/\bhref=(["\'])(.*?)\1/i',
                        'href="' . $url . '"',
                        $anchor,
                        1
                    );
                }

                if (!empty($link['target'])) {
                    $target = $link['target'];
                }
            }
        }

        if (
            empty($target) &&
            !empty($attr['img_link_target'])
        ) {
            $target = $attr['img_link_target'];
        }

        if ($target === '_blank') {

            if (preg_match('/\btarget=(["\'])(.*?)\1/i', $anchor)) {

                $anchor = preg_replace(
                    '/\btarget=(["\'])(.*?)\1/i',
                    'target="_blank"',
                    $anchor,
                    1
                );

            } else {

                $anchor = preg_replace(
                    '/>$/',
                    ' target="_blank">',
                    $anchor
                );
            }

            if (!preg_match('/\brel=(["\'])(.*?)\1/i', $anchor)) {

                $anchor = preg_replace(
                    '/>$/',
                    ' rel="noopener noreferrer">',
                    $anchor
                );
            }
        }

        return $anchor;

    }, $output, 1);

    return $output;

}, 10, 3);

Nach dem Einbau des Filters und dem Leeren des WordPress- beziehungsweise WP-Rocket-Caches wurden die externen Bildlinks wieder korrekt in einem neuen Tab geöffnet.

Im HTML erscheint danach wieder die erwartete Ausgabe:

<a href="https://www.beispiel.de/"
   target="_blank"
   rel="noopener noreferrer">

Wichtig

Der Fix sollte möglichst in einem Child-Theme oder über ein geeignetes Code-Snippet-Plugin eingebaut werden. Änderungen direkt im Parent-Theme können bei einem Theme-Update überschrieben werden.

Fazit zum WPBakery-_blank-Problem

Was zunächst wie eine falsche Einstellung im WPBakery Page Builder aussah, hatte bei uns eine andere Ursache.

  • Die Einstellung für einen neuen Browser-Tab war in WPBakery korrekt gespeichert.
  • Bei der Ausgabe durch das Bridge/Qode-Setup ging der Wert verloren.
  • Im Frontend erschien deshalb nur target="".
  • Teilweise wurde das interne WPBakery-Linkformat nicht korrekt aufgelöst.
  • Ein PHP-Filter konnte die Ausgabe in unserem Setup korrigieren.

Wer also feststellt, dass ein WPBakery Link nicht im neuen Tab öffnet, obwohl „Open in new window“ ausgewählt wurde, sollte zuerst die tatsächlich erzeugte HTML-Ausgabe im Frontend prüfen.

Steht dort nur target="", obwohl in WPBakery ein neuer Tab eingestellt ist, lohnt sich insbesondere bei Bridge und Qode ein genauer Blick auf die Ausgabe des Single-Image-Elements.

Manchmal liegt der Fehler nicht dort, wo der Link angelegt wird – sondern erst einige Schritte später bei der Ausgabe im Frontend.

Über den Autor

Webdesign, WordPress & SEO – mit über 20 Jahren Erfahrung.

Hinter dailyseven steht Gino Koina. Als Webdesigner, WordPress-Spezialist und Programmierer entwickelt er Websites für Unternehmen, Selbstständige und Start-ups – mit Fokus auf klare Gestaltung, technische Qualität und nachhaltige Sichtbarkeit.

Wer eine Website erstellen lassen möchte, erhält bei dailyseven keine Standardlösung. Von der Konzeption, Webdesign über WordPress und individuelle Programmierung bis zur Suchmaschinenoptimierung werden Gestaltung, Technik und Sichtbarkeit gemeinsam gedacht.

Veröffentlicht am 3. September 2026 Zuletzt bearbeitet am 3. September 2026
Cookie Consent mit Real Cookie Banner