Beiträge von threadi

Ein Child-Theme erstellt man nicht aus einem Theme sondern zusätzlich zu einem Theme. Die englische Dokumentation dazu ist hier: https://developer.wordpress.org/themes/advance…s/child-themes/ - eine deutsche z.B. hier: https://www.deinwp.de/einstieg-in-wordpress-child-themes/

Du brauchst einfach nur TwentyTwen anstelle des Child-Themes unter Design aktivieren um zu wechseln. Dann hast du vermutlich das PHP-Kompatiblitätsproblem sofort gelöst.

Wenn du dennoch ein Child-Theme mit individuellen Anpassungen nutzen willst, hast du 2 Chancen:

a) Das bestehende anpassen, so dass es kompatibel ist.
b) Ein komplett neues erstellen, wo du deine gewünschten Anpassungen hinterlegt.

Aus meiner Sicht wäre a) völlig ausreichend, da es nicht viel Aufwand sein sollte. Ich kenne das Theme wie gesagt zwar nicht, aber das kann nicht so viel sein.

Das von dir genutzte Theme ist schon auf dem aktuellen Stand. Dein Problem ergibt sich vermutlich eher aus dem von dir genutzten Child-Theme, welches jemand (du?) für deine Website programmiert hat. Dieses muss ggfs. für die aktuelle PHP-Version angepasst werden.

Wenn du das Child-Theme nicht selbst programmiert hast, dann wende dich an denjenigen, der das für dich gemacht hat. Wenn du denn nicht finden kannst, du das aber selbst nicht hinbekommst, kannst du dir hier jemanden suchen, der sich das für dich anschaut: Jobs & Aufträge

Nochmal zum Hintergrund:
Ein Theme zu aktualisieren heißt, dessen ausstehende Updates einzuspielen. TwentyTen ist ein ehemaliges Standard-Theme von WordPress, welches auch nach 15 Jahren noch von der WordPress-Community aktiv gepflegt wird. Für dieses Theme gibt es daher weiterhin Updates, das letzte am 19. August diesen Jahres, welches auch bei dir bereits eingespielt ist.
Ein Child-Theme nutzt man, um Anpassungen am Eltern-Theme vorzunehmen. Das sind entweder individuelle Styles, angepasste Templates oder Funktionen. Ein solches wird immer individuell pro Projekt erstellt, weshalb niemand von uns hier auch weiß was bei dir dort angepasst wurde und auf welchem technischen Stand dein Child-Theme ist. Aus dem Grund musst du bei Bedenken bzgl. der PHP-Kompatibilität, dieses Child-Theme prüfen oder prüfen lassen.

Alternativ zur Anpassung des Child-Themes gäbe es übrigens für dich auch die Möglichkeit einfach das Haupt-Theme TwentyTen zu aktivieren. Das kannst du jederzeit im Backend unter Design machen. Die Folge ist, dass in deinem Child-Theme befindliche Anpassungen nicht mehr aktiv sind. Möglicherweise hast du dann kein PHP8.3-Problem mehr, gleichzeitig aber eben auch möglicherweise andere Ansichten im Frontend - je nachdem was im Child-Theme gemacht wurde.

Einen Theme-Wechsel finde ich übrigens überhaupt nicht notwendig. Wie gesagt ist TwentyTen aktuell und auch mit modernen PHP-Versionen kompatibel. Ein Wechsel wäre erst notwendig, wenn das nicht so wäre, was aus heutiger Sicht nicht absehbar ist. Möglicherweise wirst du das Theme noch viele weitere Jahre verwenden können.

Manchmal möchte man zusätzliche Sprachpakete aus WordPress-Projekten entfernen, da sie nicht mehr benötigt werden. Z.B. hat man aus versehen mal Finnisch installiert, bekommt ständig neue Updates auch für diese Sprache und wird sie einfach nicht los. Doch WordPress hat dafür (derzeit) keine Oberfläche. Wie man sie dennoch entfernen kann, möchte ich hier kurz zeigen.

Vorbemerkungen

In diesem Beitrag geht es um die Sprachdateien, die WordPress für Übersetzungen der Texte im eigenen Backend verwendet, aber auch um diejenigen von Plugins und Themes, die ihre eigenen Sprachdateien mitbringen. Es geht nicht um Mehrsprachen-Plugins - diese handhaben ihre Sprachen jeweils anders.

WordPress selbst arbeitet standardmäßig mit "Englisch (EN_US)". Diese Sprache kann man nicht entfernen, da deren Texte Bestandteil der WordPress-Core-Dateien sind. Sie sind in keiner Sprachdatei zu finden.

Jeder WordPress-Nutzer kann die Sprache für sein Profil auch selbst festlegen. Sollte dein Nutzer die dann entferne Sprache verwenden, schaltet WordPress ihn automatisch auf „Englisch (EN_US)“ um.

Vorgehen

Ausgangsstand

Ich habe ein WordPress-Projekt, in dem Suomi (Finnisch) zusätzlich installiert ist. Die Sprachauswahl, wo das zu sehen ist, finde ich in WordPress unter Einstellungen > Allgemein.

Sprachen werden in WordPress mit international nach ISO-639 standardisierten Sprach-Kürzeln verwendet. Für einzelne Sprachen sind diese jedoch leicht angepasst, um mit Ober- und Unterkategorien zu Arbeiten (ISO 3166-1). Das Kürzel für „Deutsch“ ist z.B. de_DE, es gibt aber auch „de_CH“ für „Deutsch (Schweiz)“. Für Finnisch ist es jedoch einfach nur „fi“.

Zu diesem Projekt habe ich einen FTP-Zugang, über den ich auf die Dateien der WordPress-Installation Zugriff habe. Solltest du diesen Zugang derzeit nicht zur Hand haben, wende dich an den Support deines Hosters um ihn zu erhalten.

Vorbereitung

Stelle zunächst sicher, dass du nicht, wie oben im Screenshot zu sehen, die zu entfernende Sprache als aktuelle Sprache verwendest. Wenn doch, wechsle auf „Englisch (EN_US“).

Greife per FTP auf die Datei wp-config.php zu und kontrolliere, ob du dort eine Konstante namens WP_LANG_DIR siehst. Das könnte z.B. so aussehen:

define( 'WP_LANG_DIR', '/ein/pfad/' );

Wenn nicht, ist alles in Ordnung. Wenn sie doch vorhanden ist, merke dir den an ihr hinterlegten Pfad gut, denn du brauchst ihn später.

Ich würde zudem empfehlen vor den folgenden Arbeiten ein Backup vom Hosting zu erstellen. Beachte, dass nicht jedes Backup-Plugin auch die Sprachdateien umfasst. Du kannst auch einfach per FTP das gesamte Verzeichnis mit den Sprachdateien zu dir runterladen.

Vorgehen

Melde dich nun per FTP an deinem Hosting an. Rufe dort entweder den oben gemerkten Pfad oder diesen auf: /wp-content/languages/. Bei mir sieht das z.B. so aus:

Um die Sprache Finnisch (Sprachkürzel „fi“) zu entfernen, lösche hier die Dateien aus dem Hauptverzeichnis „languages“ nach folgendem Schema:

• Sprachkürzel.mo
• admin-Sprachkürzel.mo
• admin-network-Sprachkürzel.mo
• continents-cities-Sprachkürzel.mo
• admin-Sprachkürzel.l10n.php
• admin-network-Sprachkürzel.l10n.php
• continents-cities-Sprachkürzel.l10n.php
• Sprachkürzel.l10n.php

Für Finnisch (Kürzel „fi“) also:

• fi.mo
• fi.l10n.php
• admin-fi.mo
• admin-fi.l10n.php
• admin-network-fi.mo
• admin-network-fi.l10n.php
• continents-cities-fi.mo
• continents-cities-fi.l10n.php

Hinweise

Die PHP-Dateien der Sprachdateien existieren erst seit WordPress 6.7. Bei Installationen vor 6.7 gibt es sie nicht.

Die ebenfalls vorhandenen .po-Dateien kannst, musst du aber nicht löschen. WordPress beachtet nur .mo und die dazugehörigen PHP-Dateien zur Erkennung der Sprachen. Natürlich macht es aber schon Sinn sie mit zu löschen, da sie nicht mehr benötigt werden.

Vermutlich wirst du auch sehr viele JSON-Dateien sehen, die mit dem von dir gesuchten Sprachkürzel beginnen. Z.B.:

Diese kannst, musst du aber ebenfalls nicht löschen – auch wenn es im Sinne des Aufräumens durchaus Vorteile hat.

Plugins und Themes

Von dir genutzte Plugins oder Themes, könnten die von dir zu löschende Sprache ggfs. ebenfalls unterstützen. Auch diese haben die Sprachdateien dann in ihren jeweiligen Unterverzeichnissen vom Sprach-Datei-Verzeichnis abgelegt. Sie sind nach diesem Schema angelegt:

• plugin-slug-Sprachkürzel.i10n.php
• plugin-slug-Sprachkürzel.mo

Beispiel für Finnisch von Activitypub:

Auch diese kannst du einfach löschen.

Nachkontrolle

Nachdem du die Dateien gelöscht hast, kannst du wieder im Backend unter Einstellungen > Allgemein nachschauen. Du wirst die von dir gelöschte Sprache dort nun nicht mehr finden. Sie werden auch nie wieder geladen werden, es sei denn du wählst die Sprache explizit nochmal aus.

Alternativen

Es gibt auch hier, wie in WordPress fast immer, ein Plugin als mögliche Lösung: Simple Translation Remover. Nach Installation und Aktivierung gehst du auf Werkzeuge > Simple Translation Remover und hakst in der Liste die Sprache an, die du entfernen willst. Danach wählst du unten den Modus aus nach dem du vorgehen willst. „Löschen“ löscht die Dateien der Sprache. Ergebnis ist das gleiche wie auf oben beschriebenem Weg.

Woher weißt du das?

Ein Blick in den Code vom WordPress Core hilft: https://github.com/WordPress/Word…/l10n.php#L1473

Dieser Beitrag wurde ursprünglich hier veröffentlicht: https://www.thomaszwirner.de/sprachen-in-wordpress-entfernen/

Bei WordPress trifft man ab und zu mal auf die Situation, dass man in der Ausgabe im Frontend seiner Website einen HTML-Code hat, der nicht die eigenen Anforderungen erfüllt, der sich aber ebenso nicht anpassen lässt. Er stammt entweder vom WordPress Core selbst oder von einem Plugin, welches den Code weder über ein Template noch über einen verwendbaren Hook ausgibt. In dem Fall muss man - wie ich sie gerne nenne – die Holzhammer-Methode verwenden, die ich nun hier kurz beschreiben werde.

Worum geht es?

Ein praktisches Beispiel: der WordPress Core liefert den robots-Tag im HTML-Code in der Form aus:

<meta name='robots' content='max-image-preview:large' />

Der Code stammt von dieser Stelle hier: https://github.com/WordPress/Word…emplate.php#L49

Wie man sieht, ist er dort nicht anpassbar. Er steht genau so im Code vom WordPress Core. Man möchte nun aber statt der einfachen die doppelten Anführungszeichen am HTML-Attribut „robots“ haben.

PHP Buffer verwenden

Um das zu ermöglichen, muss man die Ausgabe des HTML-Codes im Frontend anpassen. Eine Lösung dafür könnte folgender Code unter Verwendung von PHP Buffer mit ob_start() sein:

function custom_replace_quotes( $buffer ) {
    // Here you can change the HTML content
    return str_replace( "'robots'", '"robots"', $buffer );
}

add_action( 'template_redirect', function() {
    ob_start();
    ob_start( 'custom_replace_quotes' );
});

Hier passiert folgendes:

• Im template_redirect-Hook wird zunächst der PHP Buffer aktiviert. Also in dem Moment, wo WordPress das anzuzeigende Template ermittelt, folglich vor jeder Ausgabe.
• Bei deinem zweiten Aufruf wird eine Callback-Funktion als Parameter übergeben, die wiederum nach Ende der Ausgabe automatisch aufgerufen werden soll.
• Und diese Callback-Funktion führt dann die Ersetzung der einfachen zu den doppelten Anführungszeichen durch.

Möglichkeiten

Das oben beschriebene Vorgehen ermöglicht zahlreiche Optionen, die man in scheinbar unlösbaren Fällen hat. Man kann damit jeglichen HTML-Code im Frontend anpassen. Optimal wäre natürlich, wenn man hierbei mit regulären Ausdrücken arbeitet, um die anzupassenden Code-Stellen auch wirklich zu treffen.

Fallstricke

Man muss jedoch auch gleichzeitig aufpassen bei diesem Lösungsweg. Es gibt 2 Fallstricke:

• Der PHP Buffer selbst könnte ggfs. einen Fehler werfen und so die Ausgabe der gesamten Website stören. Ob das passiert hängt vom HTML-Code selbst, aber auch von serverseitigen Einstellungen im Hosting ab. Es könnten hierbei auch Grenzwerte erreicht werden.
• Andere Plugins könnten das ebenso machen. Caching-Plugins sind sehr bekannt dafür Buffer-Methoden für die Ausgabe zu verwenden. Dadurch könnte es dazu kommen, dass 2 oder mehr Codes die gleiche Funktion ausführen wollen – was ebenso in einer nicht erreichbaren Website enden könnte.

Fazit

Auch wenn es diese Möglichkeit gibt, die bessere Lösung für solche Fälle ist weiterhin die Anpassung an der Quelle des HTML-Codes selbst. Nur sollte man eben weder die WordPress Core Dateien noch Plugin- oder Theme-Dateien anpassen. Eventuell wäre es empfehlenswerte sich in den Fällen an den Support der verantwortlichen Komponenten zu wenden.

Dieser Beitrag wurde ursprünglich hier veröffentlicht: https://www.thomaszwirner.de/die-holzhammer-methode/

War wiedermal ein schönes Meetup in Zoom mit vielen bekannten, aber auch neuen Gesichtern. Benjamin berichtet von seiner Aufgabe als Release Lead für WordPress 7.1 und zeigte eine Menge der Neuerungen der letzten beiden Major-Releases.

Nächster Termin ist der 18. November, auch wenn a) der noch nicht in der Liste steht https://www.meetup.com/de-de/wordpres…up-dach/events/ und b) noch kein Thema dazu bekannt ist.

Interessant mal den Namen Immich zu lesen. Bin kein Anwender, wollte es aber an mein Plugin Externe Dateien für die Mediathek anbinden. Leider habe ich es bis heute nicht hinbekommen ein lauffähiges Immich zu installieren. Die Anleitung führte mich irgendwie in Sackgassen und ich hab ehrlich gesagt mich auch nicht tagelang damit beschäftigen wollen. Kenne auch niemanden der es nutzt - aber es scheint sie ja doch zu geben? Vlt. interessiert sich doch mal jemand für eine enge Anbindung an WordPress

Heute in einer Woche um 19 Uhr ist das nächste DACH Meetup via Zoom. Thema: Neuerungen in WordPress 7.0 und 7.1: https://www.meetup.com/wordpress-onli…ents/315696707/

Ein enorm wichtiges Thema. Und eigentlich ist aus meiner Sicht der Grundsatz: wer seine Website barrierefrei macht, hat mehr davon. Denn viele Aspekte der Barrierefreiheit decken sich mit den Anforderungen die Google seit Jahrzehnten an Websites stellt. Gut lesbare Texte, Alternativtexte für Bilder, klar strukturierte und navigierbare Inhalte. Wer sich daran hält, bietet auch seinen Besuchern mehr.

Und ja, man muss deswegen nicht gleich die Anforderungen des BFSG erfüllen. Aber man sollte die Möglichkeiten auch nicht aus den Augen verlieren. Nur weil man nicht dazu verpflichtet ist, muss man nicht darauf verzichten. Nach meinen Erfahrungen reichen schon oft kleinere Anpassungen, um Hürden zu vermeiden.

Dennoch: die Anforderungen des BFSG komplett umzusetzen ist nicht ohne. Ich habe das bei ein paar Projekten bereits machen dürfen. Die benötigte Zeit war enorm, u.a. auch da echt Betroffene die Websites auch testen mussten bevor sie live geht (ich bin unsicher, ob das wirklich eine Anforderung ist aber sie zeigt einem echte Fehler auf).

Wie ein Behinderter Websites erlebt, habe ich dieses Jahr erneut beim WordCamp Leipzig erleben dürfen. Manuela scheiterte an einem Consent Dialog. Schaut euch das hier mal an: https://wordpress.tv/2026/05/09/cau…phone-erkunden/ (ab Minute 15 glaube ich, Rest ist aber auch interessant).

Bzgl. Abmahnungen: nach meinen Informationen vom Juni 2026, ist die Abteilung, die Beschwerden zur Barrierefreiheit in Deutschland bearbeiten soll, weiterhin im Aufbau (Quelle: jemand die direkten Kontakt zu denen hat). Wenn ich das nicht mit dem Cyber Resiliance Act verwechsle, stellen die immer noch Leute ein und organisieren sich. Von automatischen Scans war übrigens nie die Rede. Sie nehmen sich gemeldete Fälle vor und schauen sie sich an. Ob und welche Technik dabei zum Einsatz kommt, ist auch mir unbekannt. Aber "automatische Scans" von beliebigen Websites ohne Anhalt werden dort nicht gemacht. Abmahnungen zur Barrierefreiheit kommen eher von übereifrigen Anwälten als von einer Behörde.

Nicht getestet bisher, du?

Übermorgen ist wieder Meetup-Time in Leipzig. Diesmal haben wir "Werkstatt" als Thema - d.h. jeder kann kommen mit einem Problem in seinem WordPress und wir lösen es gemeinsam. Kostenfrei, aber mit Mehrwert für dich.

Details: https://www.meetup.com/de-de/leipzig-…ents/312268628/

Derzeit gibt es eine Bot-Welle, die es offenbar auf das Passwort-vergessen-Formular abgesehen hat. Ich habe diese Woche dutzende solcher E-Mails von verschiedensten Projekten bekommen.

Bisher habe ich kein Sicherheitsplugin gefunden was diesbezüglich hilft. Das einzige was derzeit hilft ist WP Armour: https://de.wordpress.org/plugins/honeypot/

Wenn es dir um o.g. .htaccess-Schutz geht, müsste dieser nicht nur /wp-admin/ schützen sondern auch /wp-login.php. Es ist durchaus das effektivste, aber man muss bei der Konfiguration schon sehr aufpassen nichts am Web kaputt zu machen.

Das heißt in einem deutschsprachigen WordPress nicht "Slug" sondern "Titelform". Das ist bei dir bereits angehakt. Du müsstest unterhalb irgendwo eine Box sehen die "Titelform" heißt und ein Eingabefeld hat. Genau das ist der Slug den du ändern kannst.

Mmh, dachte Abonnenten können das nicht. Es gibt aber Plugins, die deinen Wunsch ermöglichen:

Ich habe sowas früher auch mal mit diesem Plugin gelöst: https://de.wordpress.org/plugins/peters-login-redirect/

Was die Plugins leisten, kann man auch mit eigenem PHP Code lösen. Hier ein Ansatz dazu: https://wordpress.stackexchange.com/questions/5275…non-admin-users

Das hängt erstmal von der Rolle ab, die der bekommt. "Abonnenten" haben z.B. keinerlei Zugriff aufs Dashboard. Andere Rollen haben es, aber je nach Status mehr oder weniger.

Jetzt kommt es also darauf an was für "Benutzer" du meinst. Welche Rolle haben sie?

Ja, da sieht wesentlich besser aus

Hab ich volles Verständnis für. Musste die Woche auch bei einigen von mir betreuten Shops Länder als Zielländer in WooCommerce entfernen

Die Updates kostet nie etwas. Ich hab allerdings auch immer eine gültige Lizenz, weiß nicht wie es ist wenn man die nicht hat. Da das ein kommerzielles Produkt ist, kann man das hier nur schwer selbst mal eben reproduzieren. Da lohnt sich eher eine Frage bei deren Support um solche Details zu klären.

Das URL Thema ist gelöst, ja - das passt. Allerdings sehe ich nun auch, dass Google Fonts und Google Tag Manager geladen werden bevor der Besucher dem zugestimmt hat. Das müsstest du ändern da du sonst Abmahnungen bekommen könntest. Wie das änderst hängt davon ab wie du beides eingebunden hast. Google Fonts würde ich empfehlen lokal im Hosting abzulegen. Viele Plugins, über die man sie einbindet, haben dafür Optionen. Für den Tag Manager brauchst du in jedem Fall ein Cookie Consent Tool.

Nein, das liegt nicht daran, dass es nicht im WordPress Repository ist sondern, weil die Entwickler von Avada das schlicht noch nicht (sinnvoll) eingebaut haben. Denn eigentlich sind auch Autoupdates für derartige Themes/Plugins möglich, auch ohne irgendwelche Hilfsmittel.

Meine Quelle: jahrelange Erfahrung mit Avada sowie die Entwicklung eigener kommerzieller Plugins, die sich per Autoupdate aktualisieren lassen. Auch ich habe in den letzten Wochen bei allen betroffenen Projekten die 2 Avada-Sicherheitslücken durch manuell ausgeführte Updates fixen müssen.

Das o.g. Theme Forest Plugin funktioniert nur, wenn man seine Lizenz über ThemeForest bucht. Wir nutzen eine Agenturlizenz von Avada selbst, wo das nicht möglich ist. Dieses Plugin haben wir daher nur bei einzelnen Kunden im Einsatz, die die Lizenz selbst gebucht haben, wo aber auch dort das Autoupdate nicht funktioniert hat. Auch hier ist meine Quelle wieder meine eigene Erfahrung damit in den letzten Wochen.

Meine Empehlung: den Avada Changelogs folgen und bei Sicherheitsupdates zeitnah manuell diese installieren. Hilfreich können auch Sicherheitsplugins sein, die über solche Lücken z.B. per Mail informieren auf die man dann auch schnell reagieren sollte.

Alternative: auf Avada verzichten. Das erfordert jedoch eine komplette Neueinrichtung des Projektes, was mit entsprechendem Aufwand verbunden sein mag.

Zitat

Ich habe zuerst bei wordpress angefangen, das ist richtig. Wie kann sich das jetzt auswirken?

Diese alte URL ist noch irgendwo im Projekt hinterlegt und wird auch bei der Ausgabe im Frontend verwendet. Die Wirkung ist

• a) deine Besucher rufen Inhalte deiner Website von mehreren Domains ab. Wenn diese alte irgendwann nicht mehr funktioniert, dann sehen sie die von dort ausgelieferten Inhalte (offenbar Bilder) nicht mehr.
• b) du deine Besucher in Bezug auf die Richtlinien der DSGVO über das Laden von Inhalten von anderen Domains informieren müsstest bevor sie geladen werden. Machst du das nicht, wäre deine Website abmahnfähig. Details dazu kann dir ein Anwalt sagen. Hier findet keine Rechtsberatung statt.

Die einfachste Lösung ist wie oben bereits von mir geschrieben:

Zitat

Solltest du anpassen, entweder manuell oder mit Hilfe von https://de.wordpress.org/plugins/better-search-replace/. Da du Elementor nutzt könnte das auch unter Elementor > Einstellungen > Werkzeuge > URL ersetzen möglich sein.

Und zu:

Zitat

Für die Änderung im Elementor brauch man ja - scheints - nur alte und neue URL eingeben, der Haken ist nur: ich kenne meine alte nicht mehr.

Deine aktuelle Domain mit wordpress. davor, wie oben schon geschrieben.