Der Thread ist als „gelöst“ markiert, weil eine für den Thread-Ersteller passende Lösung des Problems mit typografischen Anführungszeichen gefunden wurde. Da wir hier aber möglichst vielen Anwendern weiterhelfen wollen, möchte ich die Lösung noch ein wenig erörtern.
Die WordPress-Core-Funktion wptexturize() verwandelt verschiedene Zeichen in einem Text eines Beitrags oder einer Seite in seine typografisch korrekte Entsprechung. Aus einfachen Anführungszeichen "…" werden typografischen Anführungszeichen „…“, aus dem Auslassungszeichen mit drei Punkten ... das typografisch korrekte Auslassungszeichen …, aus einem (grammatikalisch falsch verwendeten) Silbentrennungszeichen - der richtige Gedankenstrich – (etwas länger) usw. (Für einige typische Schreibweisen in Cockney-English wurden sogar Ausnahmen gemacht. `nuff said …)
Durch die typografisch korrekte Zeichensetzung wird nicht nur die Lesbarkeit eines Texts erhöht, sondern auch die Barrierefreiheit der Webseite verbessert. Schließlich möchten wir nicht, dass ein Screenreader "Hallo Welt" als „Inch Hallo Welt Inch“ vorliest oder das Auslassungszeichen als „Punkt Punkt Punkt“ ausgegeben wird. (Vgl. Accessible Typography – Myth 3: Smart quotes are not needed. Die Ausgabe mag in verschiedenen Browsern/Screen Readern unterschiedlich ausfallen.) Vor allem sieht ein typografisch korrekt gesetzten Text professioneller aus.
Nun lautet die Eingangsfrage:
Da ich aber teilweise Konfigurations-dateien poste ist diese Art der Änderung der Apostrophe eine Katastrophe. wie kann ich das deaktivieren ?
Wer auf einer Webseite eine Konfigurationsdatei oder überhaupt irgendeine Form von Code platzieren möchte, kann dabei keine typografischen Ersetzungen brauchen – völlig klar. Wird zum Beispiel die Zeile
define( 'WP_DEBUG', true );
umgewandelt in
define( ‚WP_DEBUG‘, true);
entsteht bei Verwendung dieses Codes ein Syntaxfehler. (Übrigens ein Grund, wieso ich sehr oft hier in Forenbeiträgen anderer Anwender als Text eingefügten Code nachträglich umformatiert habe.)
Die WordPress-Entwickler haben dies Problematik aber erkannt und die Funktion wptexturize() schließt deshalb Text aus, der in folgenden HTML-Tags steht:
<pre>, <code>, <kbd>, <style>, <script>, <tt>
Die einfachste Lösung ist also, Code in einer Webseite/einem Beitrag auch als Code zu formatieren, in unserem Beispiel also die Zeile als
<code>define( 'WP_DEBUG', true );</code>
einzufügen.
Wem die Liste der HTML-Tags, in denen die typografische Umwandlung übersprungen wird, nicht ausreicht, kann mit dem Filter no_texturize_tags geholfen werden. Sollen zum Beispiel in den Zellen einer Tabelle keine typografischen Ersetzungen vorgenommen werden, kann dieser Code (z.B. in der functions.php eines Child-Themes) verwendet werden:
add_filter( 'no_texturize_tags', 'my_no_texturzie_tags' );
function my_no_texturzie_tags( $tags ) {
$tags[] = 'td';
return $tags;
}
Die „Lösung“ für das geschilderte Problem (vielleicht in Anlehung an den Blogbeitrag von Kulturbanause, in dem das Thema etwas verkürzt behandelt wird?) verweist auf die Möglichkeit, für the_content, the_title und the_excerpt die Funktion wptexturize() ganz zu entfernen.
Das ist zum einen eine recht brachiale Methode, weil damit die (wie bereits erläutert, durchaus sinnvolle) typografische Ersetzung komplett ausgeschaltet wird, zum anderen schießt sie aber auch über das Ziel hinaus: wieso im Titel die Funktion abschalten, wenn im Beitrags-/Seiten-Inhalt ein Code ausgegeben werden soll? Wieso sollte bereits ein Auszug Code-Passagen enthalten? Die Verwendung des Filters no_texturize_tags ist da ein wenig subtiler und deshalb IMHO vorzuziehen.
Rasch möchte ich noch auf den Hinweis von @bscu eingehen:
… aber das Problem haben wir in diesem Forum auch, das ist echt ärgerlich.
Tatsächlich werden in PHP-Code gnadenlos einfache und doppelte Anführungszeichen ersetzt, wenn der Code nicht in einen eigenen Code-Block gesetzt oder zumindest als Inline-Code formatiert wird.
Zu den ehrenwerten Aufgaben der Forenmoderation gehört dann, die Formatierung nachträglich anzupassen, was entsprechend zeitaufwendig ist (vor allem, wenn der Beitrag dann statt HTML-Tags auch noch HTML-Entities ausgibt). Aber die Moderatoren haben ausreichend andere Aufgaben, als auch noch die Anwender um eine korrekte Formatierung ihrer Forenbeiträge zu bitten.
Die Moderatoren hier haben übrigens keinen Einfluss auf die Forensoftware.
Wie immer an dieser Stelle noch der freundliche Hinweis: Wir bevormunden hier niemanden, belehren nicht und weisen nur darauf hin, was bewährte Vorgehensweisen („Good practice“) sind. 🤓
Was du auf deiner eigenen Website machst, bleibt alleine dir überlassen. Nutze WordPress, wie du magst und mach etwas Tolles damit.
