Die Farbe eines Buttons besteht in WordPress meist aus mindestens zwei Zuständen: dem normalen Zustand und dem Hover-Zustand, der erscheint, wenn der Mauszeiger über dem Button liegt. In GeneratePress und GenerateBlocks kann dieser Hover-Zustand direkt im Editor oder über globale Theme-Einstellungen gesteuert werden.
GenerateBlocks-Button direkt bearbeiten
Wenn der Button als GenerateBlocks-Element angelegt wurde, wähle ihn im Editor aus und öffne die Stil- beziehungsweise Farbeinstellungen in der rechten Seitenleiste.
Dort kannst du je nach Version zwischen Zuständen wie Normal und Hover wechseln und getrennte Werte für Hintergrund, Text und gegebenenfalls Rahmen vergeben.
Normal und Hover bewusst trennen
Ein häufiger Fehler ist, nur die normale Hintergrundfarbe zu ändern. Dann sieht der Button zunächst richtig aus, springt beim Überfahren aber auf eine alte oder unerwünschte Farbe zurück.
Kontrolliere daher immer beide Zustände:
- Hintergrund normal
- Text normal
- Rahmen normal
- Hintergrund Hover
- Text Hover
- Rahmen Hover
Kontrast beachten
Wenn die Hover-Hintergrundfarbe dunkler wird, muss möglicherweise auch die Textfarbe angepasst werden. Ein dunkler Text auf dunklem Hover-Hintergrund ist schlecht lesbar.
Die Hover-Farbe sollte eine Veränderung zeigen, aber der Kontrast muss erhalten bleiben.
Globale Farben statt Hex-Werte überall
Wenn dieselbe Markenfarbe auf vielen Buttons verwendet wird, ist eine globale Farbe sinnvoller als ein hart eingetragener Hex-Wert in jedem einzelnen Block.
Dann lässt sich die Farbe später zentral ändern, ohne dutzende Seiten einzeln zu bearbeiten.
GeneratePress Theme-Buttons
Bei Buttons, die über Theme- oder Standard-WordPress-Stile laufen, können die Farben auch aus den globalen GeneratePress-Einstellungen stammen. Je nach aktueller GeneratePress-Version und Setup findest du sie im Customizer beziehungsweise in den globalen Farb- und Style-Einstellungen.
Wenn ein GenerateBlocks-Button eigene Farben gesetzt hat, überschreibt er häufig die allgemeinen Theme-Werte.
Warum eine Änderung scheinbar nicht greift
Wenn du im Editor die Hover-Farbe änderst, auf der Website aber weiterhin die alte Farbe siehst, kommen mehrere Ursachen infrage:
- Browser-Cache
- Cache-Plugin
- minifizierte CSS-Datei
- globale Klasse mit höherer Priorität
- eigenes CSS mit
!important - anderer Button-Block als gedacht
Im Browser prüfen, welche CSS-Regel gewinnt
Mit den Entwicklertools des Browsers kannst du den Button untersuchen. Aktiviere dort den :hover-Zustand und schaue, welche CSS-Regel die Hintergrundfarbe tatsächlich setzt.
So erkennt man schnell, ob die Farbe aus GenerateBlocks, GeneratePress oder einem eigenen Stylesheet kommt.
Eigene CSS-Klasse nur wenn nötig
Wenn die integrierten Einstellungen nicht ausreichen, gib dem Button eine eindeutige CSS-Klasse, beispielsweise cta-button. Danach kann der Hover-Zustand gezielt definiert werden:
.cta-button:hover { background-color: #222; color: #fff; }Ein solcher Zusatz sollte erst eingesetzt werden, wenn die normalen Blockeinstellungen nicht genügen.
Focus-Zustand nicht vergessen
Buttons werden nicht nur mit der Maus bedient. Tastaturnutzer navigieren per Tab-Taste. Deshalb sollte auch der Fokuszustand gut sichtbar sein.
Eine Hover-Regel sollte niemals den Fokusrahmen so entfernen, dass Tastaturnutzer nicht mehr erkennen können, welcher Button aktiv ist.
Hover auf Touchgeräten
Auf Smartphones gibt es keinen klassischen dauerhaften Maus-Hover. Deshalb sollte die Grundfarbe des Buttons bereits ohne Hover gut funktionieren.
Ein Button darf nicht erst durch Hover lesbar oder verständlich werden.
Globale Button-Klasse für einheitliches Design
Wenn alle CTA-Buttons gleich aussehen sollen, ist eine zentrale Klasse oder ein globaler Stil sinnvoll. Damit werden:
- Farben
- Padding
- Border-Radius
- Schriftgewicht
- Hover-Zustand
konsistent gehalten.
Nur einen einzelnen Button abweichend gestalten
Für einen einzelnen Sonderbutton sollten die Einstellungen direkt am Block gesetzt werden. Sonst ändert eine globale Regel möglicherweise auch Buttons, die bewusst anders aussehen sollen.
Verlinkte Container versus Button-Block
Manche GenerateBlocks-Layouts verwenden keinen klassischen Button, sondern einen komplett verlinkten Container. Dann muss der Hover-Zustand am Container beziehungsweise an dessen Link-Stil definiert werden, nicht an einem Button-Block.
Textfarbe bleibt falsch
Wenn nur die Hintergrundfarbe wechselt, der Text aber nicht, kann ein Link-Stil oder :visited-Zustand die Textfarbe überschreiben. Im Browserinspektor lässt sich erkennen, welche Regel aktiv ist.
Visited-Zustand bei Buttons
Bei als Link ausgegebenen Buttons kann die globale a:visited-Farbe eingreifen. Gute Button-Stile definieren deshalb die benötigte Textfarbe für Normal-, Hover- und gegebenenfalls Visited-Zustände sauber.
Animation und Transition
Ein sanfter Übergang wirkt angenehmer als ein harter Farbwechsel. Mit CSS kann beispielsweise eine kurze Transition verwendet werden.
Viele Block-Styles bieten solche Übergänge bereits über die Oberfläche an. Wenn nicht, kann eine kleine zentrale CSS-Regel reichen.
Cache nach Änderungen leeren
Nach Style-Änderungen zuerst einen Hard Reload oder ein privates Browserfenster testen. Wenn ein Cache-Plugin oder CDN aktiv ist, auch dessen Cache leeren.
Responsive Verhalten kontrollieren
Hover-Farbe selbst ist nicht breakpointabhängig, aber Button-Größe, Breite und Padding können auf Mobilgeräten abweichen. Deshalb den fertigen Button in Desktop-, Tablet- und Mobilansicht prüfen.
Empfohlener Workflow
- Button auswählen.
- Normalzustand definieren.
- Hoverzustand definieren.
- Kontrast prüfen.
- Fokuszustand testen.
- Frontend öffnen und Hover kontrollieren.
- Bei Abweichungen Entwicklertools nutzen.
- Erst dann eigenes CSS ergänzen.
Fazit
Die Hover-Farbe eines Buttons lässt sich in GenerateBlocks normalerweise direkt am Block einstellen. Für globale Theme-Buttons stehen zusätzlich die GeneratePress-Farbeinstellungen zur Verfügung. Wichtig ist, Normal- und Hover-Zustand getrennt zu pflegen, globale Farben sinnvoll einzusetzen und bei scheinbar ignorierten Änderungen zunächst CSS-Priorität und Cache zu prüfen, statt immer weitere Regeln übereinanderzulegen.