Wenn Ihre Avada-Seite plötzlich fehlerhaft aussieht (gestapelte Spalten, absurd große Ränder, überlaufender Slider), liegt das Problem selten an Avada selbst. Meiner Erfahrung nach handelt es sich fast immer um einen Ressourcenkonflikt (CSS/JS), einen zu aggressiven Cache oder globales CSS, das dem Child-Theme vorschnell hinzugefügt wurde.
das Problem
Layoutkonflikte in Avada (Fusion Builder) treten oft ohne eindeutige Fehlermeldung auf. Sie werden im Frontend angezeigt, manchmal nur auf Mobilgeräten, manchmal nur im eingeloggten Zustand.
Wenn eine Fehlermeldung erscheint, finde ich oft JavaScript-Fehler in der Browserkonsole oder PHP-Fehler in den Protokollen. Reale Beispiele:
Uncaught TypeError: Cannot read properties of undefined (reading 'init')
at fusionBuilderApp.init (fusion-builder.min.js:1)
Uncaught ReferenceError: jQuery is not defined
at fusion-something.min.js:1
PHP Fatal error: Uncaught Error: Call to undefined function fusion_library() in /wp-content/themes/Avada-child/functions.php:42
Wann und wo es erscheint:
- Front-End : Spalten, die 100 % einnehmen, Container, die ihre Breite verlieren, Elemente, die sich überlappen.
- Administrator Der Avada Builder Editor lädt nicht mehr, der Ladekreis dreht sich endlos, die Schaltflächen sind inaktiv.
- Nach einem Update Avada/Avada Core/Avada Builder wurde aktualisiert, anschließend erfolgte eine Cache-/Optimierungsoperation, bei der jedoch noch alte Dateien verwendet werden.
- Nach der Aktivierung eines Plugins : Optimierung (Minifizierung/Kombination), Sicherheit (Deaktivierung von REST), globales CSS/JS-Plugin, „Performance“-Plugin, das sich von jQuery unterscheidet.
Für wen ist es geeignet: wenn Sie Anfänger sind auf WordPress 6.9.4 (April 2026) und Sie Avada/Fusion Builder verwenden, werden Sie es am Ende erfahren:
- Ermitteln Sie, ob das Problem durch CSS, JS, den Cache oder einen Plugin-Konflikt verursacht wird.
- Wenden Sie 3 gängige Korrekturen an, wobei sicherer Code (PHP 8.1+) an der richtigen Stelle platziert wird.
- Führen Sie ordnungsgemäße Tests durch (Konsole, Abfragemonitor, Integritätsprüfung), ohne Ihre Produktionsumgebung zu beeinträchtigen.
Kurze Zusammenfassung
- Beginnen Sie damit, alle Caches zu leeren. (Plugin, Server/CDN, Browser): Dies ist die häufigste Ursache nach einem Avada-Update.
- CSS/JS-Optimierung vorübergehend deaktivieren (combine/delay/defer): Avada Builder reagiert empfindlich auf die Ladefolge.
- Globales CSS aufspüren hinzugefügt in „Benutzerdefiniertes CSS“, dem Child-Theme oder einem Plugin: ein einfaches
.container{width:100%}reicht aus, um das Avada-Gitter zu zerstören. - Überprüfen Sie die Browserkonsole. : a
jQuery is not definedDas erklärt oft, warum ein Builder nicht mehr reagiert. - Diagnose ohne Risiko mit Health Check (Fehlerbehebungsmodus) + Query Monitor, auf WordPress 6.9.4.
Symptome
Hier sind die Symptome, die ich am häufigsten bei Avada (Fusion Builder / Avada Builder) beobachte. Mehrere können gleichzeitig auftreten.
- Gestapelte Spalten Eine Zeile 1/2 + 1/2 ergibt auch auf einem Desktop-Computer 100% + 100%.
- Gebrochene „volle Seitenbreite“ : Container in voller Breite werden „eingerahmt“ oder im Gegenteil horizontal überlaufen (Scrollen X).
- Inkohärente Räume : verdoppelte Ränder/Abstände, „zusammengequetschte“ Abschnitte, eingefügte Titel.
- Fehlende Schriftarten/Symbole Unsichtbare Font Awesome-Icons, Titel in Ausweichschrift.
- Der Builder lässt sich nicht laden Im Admin-Modus: weißer Bildschirm, Ladekreis, Schaltflächen reagieren nicht.
- Im Text angezeigte Kurzcodes Sie sehen
[fusion_text]anstelle des ausgelieferten Inhalts. - 404-Fehler bei CSS/JS : Dateien in
/wp-content/uploads/fusion-styles/ou/wp-content/cache/Nicht gefunden. - Unterschiede zwischen verbundenen und getrennten : typisch für einen Seitencache oder eine JS-„Verzögerung“, die nur für Besucher gilt.
Kurzdiagnosetabelle (nützlich, wenn man nicht weiß, wo man anfangen soll):
| Symptom | Mögliche Ursache | Überprüfung | Lösung |
|---|---|---|---|
| Nach dem Update sind die Spalten defekt. | Zwischengespeicherte und veraltete zusammengeführte CSS-Dateien | Test im privaten Browsermodus + Plugin-/CDN-Cache leeren | Lösung 1 (Kombinieren/Verzögern deaktivieren, Bereinigen, Regenerieren) |
| Horizontales Scrollen (Überlauf) | Globales CSS aktiviert html, body / .container / img |
Inspektor (Chrome-Entwicklertools) → Element, das über den Bereich hinausragt | Lösung 2 (corriger (globales CSS, Avada-Wrapper) |
| Der Builder-Administrator reagiert nicht mehr. | JavaScript-Fehler (jQuery, defer, Plugin-Konflikt) | Konsole → rote Fehler + Netzwerk-Registerkarte | Lösung 1 + Lösung 3 |
| Angezeigte Kurzcodes | Avada Builder/Core-Plugin deaktiviert, Inhaltsfilter, Roh-HTML-Block | Aktive Avada Core/Builder-Erweiterungen? | Lösung 3 (Hook-Reihenfolge, Inhalt, Sicherheit) |
| CSS/JS 404 | Berechtigungen, Cache, Umschreiben, CDN, generierte Dateien gelöscht | Netzwerk → 404-Status + genauer Pfad | Bereinigen + neu generieren + Berechtigungen/Umschreibungen prüfen |
Warum passiert das
Einfache Version (für Anfänger): Avada erstellt Ihre Layouts mit einer Kombination aus CSS (für Raster, Abstände, Reaktionsfähigkeit) und JavaScript (Bei interaktiven Modulen, dem Builder und bestimmten Effekten). Wenn ein Plugin die Ladefolge ändert, eine Datei löscht oder eine zwischengespeicherte Version ausliefert, gerät das Layout durcheinander.
Hier ein Einblick in die technischen Details hinter den Kulissen:
- Avada und seine Plugins (Avada Core / Avada Builder) Assets speichern und laden über die WordPress-API (
wp_enqueue_scriptsVorderseiteadmin_enqueue_scripts(Admin-Seite). Referenz: wp_enqueue_script (). - Optimierungs-Plugins verändern den endgültigen HTML-Code: Sie kombinieren, minimieren und verzögern Skripte. Ein Avada-Skript, das nach jQuery oder einem anderen Modul ausgeführt werden soll, könnte dadurch zu früh ausgeführt werden.
- Globales CSS (Child-Theme, „Benutzerdefiniertes CSS“, Plugin) kann sehr generische Selektoren überschreiben. Ich habe oft gesehen, dass
*{box-sizing:border-box}oder ein aggressiver Reset führt zu Fehlern bei den Breitenberechnungen. - Der Cache (Plugin + CDN + Browser) liefert möglicherweise eine veraltete Datei aus. Nach einem Avada-Update verweist das HTML auf eine neue Version, das CDN liefert jedoch die alte, oder umgekehrt.
Mögliche Ursachen, von der häufigsten zur seltensten:
- Caching/Optimierung : kombiniert CSS/JS, verzögertes JS, „unbenutztes CSS entfernen“, Seitencache.
- CSS global zu breit (Child-Theme, benutzerdefiniertes CSS, Plugin), das sich auswirkt
.container,.row,img,iframe,body. - JavaScript-Konflikt : Verzögerter jQuery-Aufruf, doppeltes Skript, JS-Fehler durch ein Drittanbieter-Plugin.
- Avada Core / Avada Builder nicht synchron : Inkompatible Versionen oder eines der Plugins ist deaktiviert.
- Rewrite-Regeln / Berechtigungen : Generierte Dateien nicht zugänglich, 403/404 bei Assets.
- Serverprobleme HTTP/2 Push falsch konfiguriert, Brotli/CDN-Umschreibung, WAF blockiert REST/AJAX.
Voraussetzungen vor Beginn
Speichern Sie Ihre Arbeit, bevor Sie Änderungen vornehmen. Verändern Sie niemals den WordPress-Kern oder die Dateien des Avada-Elternthemes: Arbeiten Sie in einer sauberen, unveränderten Umgebung. Kind Thema oder benutzerdefinierte Plugins.
- WordPress : 6.9.4 (oder neuer).
- PHP Mindestens 8.1 empfohlen (8.2/8.3 oft komfortabler). Referenz: PHP: Unterstützte Versionen.
- Werkzeuge :
- Abfrage-Monitor (kostenlos) PHP-Fehler, Hooks, Abfragen und geladene Skripte/Styles anzeigen: wordpress.org/plugins/query-monitor.
- Health Check & Fehlerbehebung Um Plugins/Themes nur für Sie zu deaktivieren (Fehlerbehebungsmodus): wordpress.org/plugins/health-check.
- Protokollierung aktivieren (vorübergehend) über
wp-config.phpUm Fehler zu erfassen, laut Dokumentation: Debuggen in WordPress.
Beispielhafte Debug-Konfiguration (zu übermitteln an false (sobald die Diagnose abgeschlossen ist):
/**
* Active le debug WordPress (à désactiver après dépannage).
* À placer dans wp-config.php, avant "That's all, stop editing!".
*/
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Lösung 1: CSS/JS werden in falscher Reihenfolge geladen (Prioritäten, Optimierung, Cache)
Typische Symptome: fehlerhaftes Layout nach dem Update, inaktive Avada-Module, nicht reagierender Builder, Konsolenfehler jQuery is not defined ou Cannot read properties of undefined.
Das Problem rührt oft von einem Performance-Plugin her, das:
- CSS/JS kombinieren,
- Skripte unterscheiden sich (verzögern) oder verzögern (verzögern),
- Verschieben Sie jQuery in die Fußzeile.
- oder löscht Dateien, die als „unnötig“ erachtet werden.
Schritt 1 (ohne Code): Schnelltest im Fehlerbehebungsmodus
Aktivieren Sie mit Health Check die Fehlerbehebungsmodus (nur du kannst es sehen), dann:
- Deaktivieren Sie das Optimierungs-Plugin (Autoptimize, WP Rocket, LiteSpeed ​​Cache usw.).
- Leeren Sie zuerst den Avada-Cache (unter Avada > Leistung / Cache, je nach Ihrer Version), dann den Plugin-Cache und anschließend den CDN-Cache.
- Laden Sie die Seite im privaten Browsermodus neu.
Wenn alles wieder normal funktioniert: Sie haben einen Asset-Konflikt bestätigt. Fahren Sie mit Schritt 2 fort.
Schritt 2 (mit Code): Verhindern einer Verzögerung bei Avada-Skripten
Einige Plugins gelten defer über den WordPress-Filter script_loader_tag. ein Filter ist eine Funktion, die einen Wert empfängt und diesen zurückgeben muss (im Gegensatz zu einer Funktion). Aktion (das Code ausführt, ohne einen Wert zurückzugeben).
Wo soll der Code eingefügt werden? idealerweise in einem Mu-Plugin (Plugin muss verwendet werden), damit es auch beim Wechsel des Designs aktiv bleibt.
Weg : /wp-content/mu-plugins/avada-assets-fix.php (Ordner erstellen) mu-plugins (falls es nicht existiert).
Vor dem Ändern speichern. Fehlende Klammern verursachen einen 500-Fehler.
VORHER (Beispiel für „fehlerhaften“ Code, der häufig in functions.php hinzugefügt wird):
<?php
/**
* Exemple de snippet problématique : ajoute defer à (presque) tous les scripts.
* Je l'ai vu copié depuis des tutoriels anciens.
*/
add_filter( 'script_loader_tag', function( $tag, $handle ) {
// ERREUR : on defer aussi les scripts qui doivent s'exécuter immédiatement (Avada, jQuery, etc.)
return str_replace( ' src', ' defer src', $tag );
}, 10, 2 );
NACHHER (ohne Avada + jQuery + einige gängige Handles):
<?php
/**
* Plugin MU : exclusions defer/delay pour Avada (WordPress 6.9.4+, PHP 8.1+).
* Fichier : wp-content/mu-plugins/avada-assets-fix.php
*/
defined( 'ABSPATH' ) || exit;
/**
* Retire "defer" (ou empêche son ajout) sur des scripts critiques.
*
* Pourquoi :
* - Avada Builder et certains modules attendent un ordre précis (dépendances JS).
* - Si un script est defer alors que son dépendant ne l'est pas, on obtient des erreurs JS.
*/
add_filter( 'script_loader_tag', function( $tag, $handle ) {
// Liste à adapter : utilisez Query Monitor > Scripts pour voir les handles réels.
$critical_handles = array(
'jquery',
'jquery-core',
'jquery-migrate',
// Avada / Fusion (handles fréquents, selon versions)
'fusion-builder-app',
'fusion-scripts',
'avada-scripts',
);
if ( in_array( $handle, $critical_handles, true ) ) {
// On retire defer si un autre plugin l'a injecté.
$tag = preg_replace( '/sdefer(=(['"]).*?2)?/i', '', $tag );
$tag = preg_replace( '/sdata-no-defer(=(['"]).*?2)?/i', '', $tag );
return $tag;
}
return $tag;
}, 100, 2 );
Warum korrigiert es?
Avada ist von JavaScript-Abhängigkeiten und der Ausführungszeit abhängig. Wenn ein Plugin zu stark „optimiert“, führt das zu folgenden Ergebnissen:
- ein Avada-Skript, das vor jQuery ausgeführt wird
- oder Module, die initialisiert wurden, bevor das DOM bereit war,
- oder nicht zugeordnete Ereignisse (inaktive Schaltflächen im Builder).
Durch das Ausschließen kritischer Handles ermöglichen Sie dem Optimierungs-Plugin, den Rest zu bearbeiten, ohne Avada zu beeinträchtigen.
Muss noch überprüft werden (genaue Diagnose)
- Browserkonsole: der Fehler
jQuery is not definedmuss verschwinden. - Netzwerk-Registerkarte: Avada-Skripte sollten mit einem 200-Statuscode antworten (nicht 404/403).
- Abfragemonitor > Skripte: Überprüfen Sie die Reihenfolge und das Vorhandensein der Dateien.
Lösung 2: Defekte Abschnitte in voller Breite (Container, Child-Theme, globales CSS)
Typische Symptome: Container in voller Breite, die nicht mehr die volle Breite haben, Spalten, die überlaufen, horizontales Scrollen, Abschnitte, die am Rand "kleben bleiben", oder im Gegenteil, alles ist in einer festen Breite eingeschlossen.
Der klassische Auslöser: ein globales CSS, das hinzugefügt wurde zu:
- Avada > Optionen > Benutzerdefiniertes CSS
- Darstellung > Anpassen > Zusätzliches CSS
- das Child-Theme (style.css),
- ein CSS-Snippet-Plugin,
- oder ein Page-Builder-Plugin eines Drittanbieters.
Ein häufiger Fehler: Überlastung von .container/.row
VORHER (das "fehlerhafte" CSS, das ich regelmäßig sehe):
/* Exemple problématique : trop générique */
.container {
width: 100%;
max-width: 100%;
}
.row {
margin-left: 0;
margin-right: 0;
}
Warum das gefährlich ist: Avada verwendet eigene Wrapper und ein eigenes Raster. Wenn Sie es erzwingen .container ou .rowSie verstoßen gegen die Berechnung von Rändern und Abständen sowie gegen das Responsive Design.
Diagnose: Die richtige CSS finden
- Öffne die defekte Seite.
- Rechtsklick > Untersuchen (Chrome/Firefox).
- Wählen Sie ein Element aus, das überläuft (oft ein Container).
- Schauen Sie sich den Reiter „Stile“ an: Dort sehen Sie die genaue Regel und die Datei wer es anwendet.
Wenn die Regel aus Ihrem Child-Theme oder zusätzlichem CSS stammt, korrigieren Sie sie, indem Sie sie auf den richtigen Kontext beschränken.
Korrektur: Definieren Sie den Gültigkeitsbereich Ihres CSS, anstatt generische Klassen zu ändern.
NACHHER (korrigiertes, zielgerichtetes CSS):
/* Exemple corrigé : on cible uniquement une zone spécifique */
.page-id-123 .banniere-custom .container {
max-width: 1200px;
margin-left: auto;
margin-right: auto;
}
/* Et si vous voulez du full width, ciblez votre wrapper, pas .container global */
.page-id-123 .banniere-custom {
width: 100%;
max-width: 100%;
}
Wo soll dieses CSS eingefügt werden?
- Am saubersten: Kind Thema >
style.css. - Okay, los geht's: Zusätzliche CSS (Personifizieren).
- Vermeiden Sie es, die Orte zu multiplizieren (ansonsten wissen Sie nicht mehr, woher die Regel stammt).
Häufiger Avada-Fall: overflow-x versteckt, um einen Überlauf zu maskieren
Ich habe oft gesehen, dass Benutzer dies hinzufügen, um das horizontale Scrollen zu entfernen:
html, body { overflow-x: hidden; }
Dadurch wird nur das Symptom, nicht die Ursache, verschleiert. Wenn ein Modul tatsächlich überlaufen muss (z. B. Schieberegler, Animation), wird es abgeschnitten. Suchen Sie stattdessen das fehlerhafte Element (Entwicklertools) und korrigieren Sie dessen Breite/Rand.
Erweiterte Option (mit Code): Korrigierendes CSS nur auf bestimmten Seiten laden
Wenn Sie das globale CSS nicht ändern möchten, laden Sie eine Patch-Datei seitenweise über einen Hook. Haken ist ein Hook in WordPress: eine Aktion oder ein Filter. Hier verwenden wir die Aktion wp_enqueue_scripts.
Wo soll der Code eingefügt werden? : functions.php du Kind Thema (oder ein benutzerdefiniertes Plugin).
Vor dem Bearbeiten speichern. Ein vergessenes Komma kann die Website beschädigen.
VORHER (schlechte Vorgehensweise: riesige Inline-CSS-Mengen auf der gesamten Website):
<?php
add_action( 'wp_head', function() {
// ERREUR : CSS injecté partout, difficile à maintenir, impact perf
echo '<style>.container{max-width:100%!important;}</style>';
} );
NACHHER (Warteschlange bereinigen + Targeting):
<?php
/**
* Thème enfant : charge un CSS correctif seulement sur une page.
* Fichier : wp-content/themes/Avada-child/functions.php
*/
add_action( 'wp_enqueue_scripts', function() {
// Exemple : ne charger que sur la page ID 123.
if ( ! is_page( 123 ) ) {
return;
}
wp_enqueue_style(
'avada-child-layout-fix',
get_stylesheet_directory_uri() . '/assets/css/layout-fix.css',
array(), // Dépendances (si besoin, ajoutez le handle du style Avada)
'2026-04-05'
);
}, 20 );
Warum es besser ist: WordPress kümmert sich um das Laden, das Browser-Caching und Sie vermeiden, dass alle Seiten mit Inhalten überladen werden.
Lösung 3: Fusion-Shortcodes werden nicht gerendert und JS Builder funktioniert nicht (Hooks, REST/AJAX, Sicherheit)
Typische Symptome:
- Sie sehen Avada-Shortcodes im Klartext (z. B.:
[fusion_text]). - Der Builder lädt nur teilweise und friert dann ein.
- Netzwerkaufrufe schlagen fehl (403/401) am
/wp-json/ouadmin-ajax.php.
Häufige Ursache: Avada Builder/Core deaktiviert oder inkonsistente Versionen.
Avada benötigt Begleit-Plugins. Siehe Erweiterungen:
- Avada Core : aktiv
- Avada-Generator : aktiv
Wenn ein Shortcode inaktiv ist, werden einige Shortcodes nicht mehr gespeichert, sodass WordPress sie als Text anzeigt.
Eine häufige Ursache: ein Filter, der den Inhalt "bereinigt" und dadurch Shortcodes nicht mehr funktionieren.
Ich bin schon oft auf diesen Ausschnitt gestoßen (aus alten Quellen kopiert). Artikel) wodurch Shortcodes aus dem Inhalt entfernt werden:
VORHER (defekt):
<?php
/**
* Exemple problématique : supprime les shortcodes du contenu.
* Résultat : Avada ne peut plus rendre ses éléments.
*/
add_filter( 'the_content', function( $content ) {
// ERREUR : retire tout ce qui ressemble à un shortcode
$content = preg_replace( '/[[^]]+]/', '', $content );
return $content;
}, 5 );
NACHHER (wir vermeiden es, den Inhalt zu verändern, oder beschränken ihn auf einen bestimmten Fall):
<?php
/**
* Correction : ne supprimez pas les shortcodes globalement.
* Si vous devez nettoyer un contenu, faites-le sur un champ spécifique,
* ou sur un type de contenu précis, et jamais via une regex globale.
*/
add_filter( 'the_content', function( $content ) {
// Exemple : ne rien faire sur les pages Avada (le plus sûr pour débuter).
if ( is_singular() ) {
return $content;
}
return $content;
}, 5 );
Warum dies das Problem behebt: Avada verwendet Shortcodes (oder interne Blöcke/Strukturen, abhängig von der Konfiguration). Das Entfernen dieser Shortcodes auf der entsprechenden Ebene… the_content läuft darauf hinaus, das Layout „Rezept“ zu entfernen.
Häufige Ursache: Die REST-API ist aus Sicherheitsgründen blockiert, und der Builder ist von API-Aufrufen abhängig.
Manche Sicherheits-Plugins oder Code-Snippets blockieren die REST-API. Der moderne WordPress-Editor und einige WordPress-Builder basieren jedoch darauf. /wp-json/ (auch wenn Avada über eigene Mechanismen verfügt).
VORHER (gefährlicher Ausschnitt, zu aggressiv):
<?php
/**
* Exemple courant : bloque TOUTE la REST API.
* Effets : éditeurs et builders cassés, intégrations KO.
*/
add_filter( 'rest_authentication_errors', function( $result ) {
if ( ! is_user_logged_in() ) {
return new WP_Error( 'rest_forbidden', 'REST API désactivée.', array( 'status' => 403 ) );
}
return $result;
} );
NACHHER (wir begrenzen die Blockade und lassen zumindest die notwendigen Wege offen):
<?php
/**
* Version plus prudente : ne bloquez pas la REST API globalement.
* Si vous devez restreindre, faites-le par route et avec une logique claire.
*
* OÙ : plugin custom ou mu-plugin (évitez functions.php si vous testez souvent).
*
* Risque sécurité : mal configurer ce filtre peut exposer des données.
* Testez en staging.
*/
add_filter( 'rest_authentication_errors', function( $result ) {
// Si une autre auth a déjà échoué, on respecte.
if ( is_wp_error( $result ) ) {
return $result;
}
$request_uri = isset( $_SERVER['REQUEST_URI'] ) ? (string) $_SERVER['REQUEST_URI'] : '';
// Exemple : autoriser tout /wp/v2/ et laisser WordPress gérer les permissions.
// Adaptez à votre politique réelle.
if ( str_contains( $request_uri, '/wp-json/wp/v2/' ) ) {
return $result;
}
// Bloquer uniquement certaines routes custom (exemple).
if ( str_contains( $request_uri, '/wp-json/mon-plugin-prive/' ) && ! is_user_logged_in() ) {
return new WP_Error(
'rest_forbidden',
'Accès REST restreint.',
array( 'status' => 403 )
);
}
return $result;
} );
Offizielle Referenz zur REST-API: developer.wordpress.org/rest-api.
Häufige Ursache: Blockierter Admin-AJAX (Nonce/Berechtigungen) oder WAF
Wenn der Bauherr Anrufe tätigt admin-ajax.php Und falls Sie 403/401 sehen, überprüfen Sie Folgendes:
- Sicherheits-Plugin/WAF (Wordfence, Cloudflare WAF, ModSecurity), das eine Anfrage blockiert.
- Ein Cache, der eine AJAX-Antwort zwischenspeichert (schlechte Konfiguration).
- Nuntius verstorben: eins Nuntius Es handelt sich um ein Anti-CSRF-Token. Ist es ungültig, lehnt WordPress die Aktion ab.
Hinweis zu Nuntien: Nonces (WordPress-Sicherheit).
Nachkorrekturprüfungen
Führen Sie nach jeder Lösung die Tests in dieser Reihenfolge durch (andernfalls riskieren Sie, aufgrund des Caches ein falsch positives Ergebnis zu "bestätigen"):
- Säuberung : Avada-Cache, Plugin-Cache, Server-Cache, CDN-Cache.
- Navigator : Neuladen erzwingen (Strg+F5) + Test im privaten Browsermodus.
- Console : Keine roten Fehlermeldungen mehr im Zusammenhang mit Avada/jQuery.
- Mobil : Responsive Testing (Entwicklertool) + wenn möglich ein echtes Smartphone.
- Verbunden/Getrennt : Öffnen Sie ein privates Fenster, um einen Besucher zu simulieren.
Wenn Sie Fusion Builder/Fusion Slider verwenden: Testen Sie eine einfache Seite (1 Container, 2 Spalten, 1 Schaltfläche). So können Sie schnell überprüfen, ob das Raster wieder angezeigt wird.
Wenn das immer noch nicht funktioniert
Wenn ich auf Widerstand stoße, gehe ich immer methodisch vor, sonst drehen wir uns nur im Kreis.
1) Auf Fehler prüfen (Protokolle + Abfragemonitor)
- geöffnet
wp-content/debug.log(falls WP_DEBUG_LOG aktiviert ist). - Installieren Sie Query Monitor und beobachten Sie Folgendes:
- PHP-Fehler
- Skripte/Stile geladen
- HTTP-Anfragen
2) Gesundheitscheck: Theme/Plugins isolieren, ohne die öffentliche Website zu beeinträchtigen
- Aktivieren Sie den Fehlerbehebungsmodus.
- Verlassen Sie Avada + Avada Core + Avada Builder.
- Deaktivieren Sie alles andere.
- Reaktivieren Sie sie nacheinander, bis der Fehler reproduzierbar ist.
Wenn Sie das fehlerhafte Plugin gefunden haben: Suchen Sie nach einer „Ausschluss“-Option (Avada-Skripte von der Verzögerung/Kombination ausschließen), bevor Sie es löschen.
3) Überprüfen Sie die Assets (Netzwerk) auf 404/403-Fehler.
In DevTools > Netzwerk:
- Filtern Sie nach „CSS“ und dann nach „JS“.
- Identifizieren Sie die Statuscodes 404/403.
- Öffnen Sie die URL in einem neuen Tab: Wenn ein 404-Fehler zurückgegeben wird, liegt das nicht am Browser, sondern am Server/Rewrite/Berechtigungen/CDN.
4) Permalinks / Umschreiben
Ein nützlicher Tipp: Gehen Sie zu Einstellungen > Permalinks und klicken Sie auf „Speichern“ (ohne etwas zu ändern). Dadurch werden die Rewrite-Regeln neu generiert.
Reference: spülen_umschreiben_regeln() (Bitte nicht auf jeder Seite erwähnen, sondern nur gelegentlich).
5) PHP-Speicher prüfen
Avada kann ressourcenintensiv sein, insbesondere bei vielen Modulen und Optionen. Unzureichender Speicher kann zu ungewöhnlichem Verhalten führen (und nicht immer zu einem eindeutigen Fehler).
Reference: Erhöhung des für PHP reservierten Speichers.
6) Letzter Schritt: Alle serverseitigen Caches vorübergehend deaktivieren
- Nginx/FastCGI Cache
- Varnish
- CDN (Entwicklungsmodus)
Ich habe erlebt, dass ein CDN eine mehrere Tage alte Avada-CSS-Datei auslieferte, obwohl das Plugin diese angeblich erfolgreich gelöscht hatte. Der ultimative Test: Umgehen Sie das CDN (wenn möglich über den Host oder die direkte Ursprungs-URL), um dies zu bestätigen.
Häufige Fallstricke und Fehler
| Symptom | Mögliche Ursache | Empfohlene Lösung |
|---|---|---|
| Fehler 500 nach dem Hinzufügen eines Code-Snippets | Der Code wurde an der falschen Stelle eingefügt, ein Semikolon fehlt. | Entfernen Sie den Codeausschnitt per FTP, verwenden Sie ein MU-Plugin und überprüfen Sie die Syntax. |
| Builder eingefroren, Konsole: jQuery ist nicht definiert | Ein Performance-Plugin, das sich von jQuery unterscheidet | Lösung 1 (kritische Handles ausschließen, Verzögerung/Aufschub für Avada deaktivieren) |
| Überall gestapelte Säulen | Globales CSS für .container/.row | Lösung 2 (CSS einschränken, generische Regeln entfernen) |
| Alles funktioniert, solange die Verbindung besteht, aber es funktioniert nicht mehr, sobald die Verbindung getrennt wird. | Seitencache und JS-Verzögerung unterscheiden sich für Besucher | Seitencache im Pages Builder deaktivieren, bereinigen, Ausnahmen festlegen |
| Angezeigte Kurzcodes | Avada Builder/Core ist inaktiv oder der the_content-Filter ist destruktiv. | Avada-Plugins aktivieren, Regex-Bereinigung entfernen, Lösung 3 |
| Die Korrektur wurde angewendet, aber es hat sich nichts geändert. | Browser-/CDN-Cache nicht geleert | Privater Browsermodus + CDN-Bereinigung + CSS-Versionierung (Abfragezeichenfolge) |
| Der Code-Schnipsel „defer“ funktioniert nicht. | Falscher Hook, falsche Priorität | Verwenden Sie script_loader_tag mit hoher Priorität (100), überprüfen Sie die Handles. |
| CSS/JS 404 | Dateiberechtigungen, Uploads/Cache-Ordner gelöscht | Berechtigungen reparieren, Assets neu generieren, Server-Sicherheitsregeln überprüfen |
Fehler, die ich häufig bei Anfängern beobachte (und die Zeit kosten):
- Kopieren Sie den Code nach das übergeordnete Thema anstelle des Kinderthemas.
- Testen Sie direkt in der Produktionsumgebung, ohne zu speichern oder eine Zwischenspeicherung durchzuführen.
- Vergessen, den Cache des Plugins UND des CDN zu leeren (und glauben, dass es dann nicht funktioniert).
- Verwendung eines 5 Jahre alten Optimierungs-Tutorials, das „alles aufschiebt“ (inkompatibel mit modernen Build-Systemen).
- Verwirrende Aktion und Filter: Ein Filter muss Rückkehr der Wert.
Variante / Alternative
No-Code-Methode: Ausschlüsse in Ihrem Optimierungs-Plugin
Die meisten Performance-Plugins ermöglichen es Ihnen, Folgendes auszuschließen:
- Skripte per URL oder per Schlüsselwort (
fusion,avada), - Seiten (Editor, Seitengenerator),
- oder um „delay JS“ nur auf bestimmten Seiten zu deaktivieren.
Für Anfänger ist dies oft der beste Kompromiss: weniger Risiko als ein schlecht eingefügter PHP-Codeausschnitt.
Fortgeschrittenere Methode: präzise Profilierung der Vermögenswerte
Für technische Profile können Sie:
- Verwenden Sie Query Monitor, um Skripte/Stile und deren Abhängigkeiten aufzulisten.
- Vergleichen Sie den gerenderten HTML-Code (Quelltext anzeigen) im Normalmodus und im Fehlerbehebungsmodus.
- Falls Sie WP-CLI verwenden, überprüfen Sie die Konfiguration und führen Sie gezielte Bereinigungen durch (abhängig von Ihrem Stack).
WP-CLI-Referenz (offiziell): WP-CLI-Befehle.
Vermeiden Sie dieses Problem in Zukunft
- Führen Sie die Aktualisierungen der Reihe nach durch. WordPress 6.9.4+ → Avada (Theme) → Avada Core/Builder → Plugins. Anschließend den Cache vollständig leeren.
- Vermeiden Sie Code-Schnipsel mit dem Begriff „magische Optimierung“. wer sich bewirbt
defer/asyncÜberall. Moderne Bauunternehmen brauchen einen stabilen Auftragsablauf. - Zentralisieren Sie Ihr CSS : ein einziger Veranstaltungsort (Kinderthema) anstelle von 4 Veranstaltungsorten. Dort finden Sie die Regeln.
- Beschränken Sie Ihren CSS-Code bevorzugen
.page-id-123 .mon-blocstatt.containerglobal. - Behalte eine Bühne Selbst eine „billige“ Testumgebung schützt Sie davor, Ihre öffentliche Website zu beschädigen.
- Überwachen Sie die Konsole. Nach jeder Plugin-Hinzufügung kann ein einziger JS-Fehler die gesamte Benutzeroberfläche lahmlegen.
Wenn Sie einen Code-Schnipsel hinzufügen müssen, verwenden Sie ein MU-Plugin und versionieren Sie Ihre Änderungen. Dadurch lässt er sich im Notfall leichter per FTP deaktivieren.
Ressourcen
- Debugging in WordPress (WP_DEBUG)
- wp_enqueue_script() (Lade JS)
- script_loader_tag-Filter
- REST-API-Handbuch
- Nonces (WordPress-Sicherheit)
- Abfragemonitor (Plugin)
- Gesundheitscheck & Fehlerbehebung (Plugin)
- Unterstützte PHP-Versionen
- WordPress Core auf GitHub (Code-Referenz)
Häufig gestellte Fragen
Sollte ich Avada Builder deaktivieren, wenn ich meine Seiten nicht mehr bearbeite?
Nein, nicht wenn Ihre bestehenden Seiten davon abhängen. Wenn der Inhalt mit Avada-Elementen erstellt wurde, kann die Deaktivierung von Avada Builder/Core dazu führen, dass Shortcodes als Klartext angezeigt werden oder die Darstellung fehlerhaft ist.
Warum tritt das Problem nur auf Mobilgeräten auf?
Häufig liegt dies daran, dass die globale CSS- oder „kritische CSS“-Optimierung die Breakpoints nicht abdeckt oder dass ein responsives Skript verzögert wird. Testen Sie dies, indem Sie vorübergehend „Unbenutztes CSS entfernen“ und „JS verzögern“ deaktivieren.
Ich habe das CSS korrigiert, aber ich sehe keine Änderung.
Es ist fast immer zwischengespeichert. Leeren Sie den Plugin-Cache und den CDN-Cache und testen Sie es dann im privaten Browsermodus. Wenn Sie eine CSS-Datei laden, ändern Sie deren Versionsnummer (z. B. 2026-04-05) um den Browser zu zwingen.
Wo ist der beste Ort, um einen PHP-Codeausschnitt einzufügen?
Für die Avada-Fehlerbehebung bevorzuge ich ein Mu-Plugin (In /wp-content/mu-plugins/): Es bleibt aktiv und kann im Fehlerfall schnell per FTP entfernt werden.
Worin besteht der Unterschied zwischen einer Aktion und einem Filter?
Einen halben Tag Aktion führt Code zu einem bestimmten Zeitpunkt aus (z.B. wp_enqueue_scripts). A Filter erhält einen Wert und muss Rückkehr verändert oder unverändert (z.B.: script_loader_tag).
Kann ein Caching-Plugin Avada beschädigen?
Ja, insbesondere wenn JavaScript kombiniert/verzögert wird oder Seiten zwischengespeichert werden, die nicht zwischengespeichert werden sollten (Bearbeitungsseiten, Seiten mit dynamischem Inhalt). Seiten- und Skriptausschlüsse lösen das Problem in der Regel.
Warum sehe ich im Builder einen weißen Bildschirm, aber nicht auf der öffentlichen Website?
Da die Administrationsoberfläche unterschiedliche Skripte lädt, kann ein JavaScript-Fehler in der Administrationsoberfläche (oder eine Einschränkung von REST/AJAX) den Builder beeinträchtigen, ohne dass dies Auswirkungen auf das Frontend hat.
Kann ein einfacher "CSS-Reset" ausreichen, um das Layout zu zerstören?
Ja. Übermäßig aggressive Resets bei img, iframe, .container, .row oder globale Regeln box-sizing Sie können das Raster durcheinanderbringen. Beschränken Sie Ihre Regeln auf Ihren Block.
Ich erhalte 404-Fehler bei den generierten CSS-Dateien: Was soll ich tun?
Beginnen Sie mit dem Löschen und Regenerieren des Avada- und Plugin-Caches. Überprüfen Sie anschließend die Berechtigungen/Rechte für wp-content/uploadsFalls ein CDN aktiv ist, sollte auch die CDN-Seite bereinigt werden.