We recommend you to put all configurations for the preset in the YAML configuration. However, it is still possible to override these settings through the page TSconfig.

You can find a list of configuration properties in the Page TSconfig reference, chapter RTE.

Quelle: https://docs.typo3.org/c/typo3/cms-rte-ckeditor/main/en-us/Configuration/Reference.html

 

Leider habe ich keine Beispiel YAML Konfiguration gefunden, wie man bestehende RTE TSConfig in YAML für den neuen CKEditor ab TYPO4 V12 überträgt. Daher hier eine Beispiel-Konfiguration von mir.

Ziel war es insbesondere einen Link mit Button Klassen aus Bootstrap einzufügen. Mehrere Klassen für einen Link über den Link Wizard einzufügen gab es leider erst ab TYPO3 7 über TSConfig. Diese Config hatte bei mir nicht mehr funktioniert. Mit der u.g. YAML Konfiguration kann ich einem Link direkt zwei Button Klassen geben „btn btn-secondary-cta“ und diesen sogar im Link Wizard benutzerfreundlich bennenn.

imports:
    - { resource: "EXT:my_base_sitepackage/Configuration/RTE/my_general.yaml" }

editor:
    config:
        contentsCss:
            - 'EXT:my_sitepackage/Resources/Public/CSS/rte.min.css'
        style:
          definitions:
            - { name: "Lead Text", element: "p", classes: ['lead'] }
            - { name: "Colored Box", element: "p", classes: ['bgcolor-green', 'p-3', 'rounded-corners-1'] }
            - { name: "White Box", element: "p", classes: ['bg-white', 'p-3', 'rounded-corners-1'] }
            - { name: "Checklist", element: "ul", classes: ['checklist'] }
            - { name: "Link Download", element: "a", classes: [ 'link-download' ] }
            - { name: "Link Related", element: "a", classes: [ 'link-related' ] }
            - { name: "Primary CTA", element: "a", classes: [ 'btn' , 'btn-primary-cta'] }
            - { name: "Secondary CTA", element: "a", classes: [ 'btn' , 'btn-secondary-cta'] }

        format_tags: "p;h2;h3;h4;h5;h6"

buttons:
    link:
        properties:
            class:
                allowedClasses: 'link-download, link-related, btn btn-primary-cta, btn btn-secondary-cta'
classes:
    link-download:
        name: 'Link Download'
    link-related:
        name: 'Link Related'
    btn btn-primary-cta:
        name: 'Primary CTA'
    btn btn-secondary-cta:
        name: 'Secondary CTA'

To remove the slug completely from the permalink structure, rewrite has to be set and the slug has to be a slash and with_front should be false.
'rewrite' => array(
'slug' => '/',
'with_front' => FALSE
),

Visit settings->permalinks to flush the cache for old rewrite styles!

1. WordPress im Hauptverzeichnis installieren (document root vom hoster oder der Ordner, der als Ziel einer domain.de angegeben wurde).
2. WordPress im Unterordner installieren zB domain.de/kurse/
3. kurse darf es als Seite oder Blog Artikel nicht auf der Website aus dem Hauptverzeichnis existieren.
4. .htaccess Datei aus dem Unterverzeichnis öffnen und die Zeile

RewriteRule . /index.php [L] ändern in 
RewriteRule . /kurse/index.php [L]
 

Nun haben wir zwei WordPress Installationen. Eine unter domain.de und eine unter domain.de/kurse

Das macht dann Sinn, wenn die technische Grundlage ganz unterschiedlich ist oder sein soll.

Wünschen Sie eine Beratung oder Schulung ? Ich helfe gerne. Mailen Sie mir: info [ät] sitegefuehl [punkt] de

Tatsächlich ist bisher der Fehler nie aufgefallen. Erst jetzt! Da ich recht lange recherchieren musste, um eine Lösung zu finden, nehme ich das mal als Grund über das Problem in meinem Blog zu schreiben.

Ich hatte folgende Konstellation: Eine WordPress Instanz sollte über mehrere Domains erreichbar sein. In diesem Fall war es einmal die Hauptdomain www.xyz.de und die Subdomains namens stadt1.xyz.de + stadt2.xyz.de + stadt3.xyz.de + stadt4.xyz.de

Je nach Domain wurde ein anderer Inhalt ausgegeben. Dies habe ich mit einer kleinen HTTP Host Abfrage in WordPress gelöst.

Nun sollten auch Webfonts über font-face und auch die komplette Website über https laufen. Ich habe hier ein nettes, schlankes Plugin gefunden, welche alle Links (auch in der CSS Datei) zum Protokoll https zwingt (WordPress HTTPS war mir zu viel des Guten). So wird schonmal keine Info über unsichere Inhalte ausgegeben. Das Plugin nimmt einem die Arbeit ab, alle Inhalte und Plugins nach http Verbindungen abzusuchen.

Folgender Fehler trat nun auf: Besuchte man eine der Subdomains über den Firefox (bei mir war’s noch die Version 15) und dem IE9, so wurden die Webfonts nicht geladen. Ich probierte absolute Pfad, z.B. https://www.xyz.de/font.eot oder //font.eot oder /font.eot aus. Relative Pfade brachten leider auch nicht das gewünschte Ergebnis. Lustigerweise sah im Chrome auf den Subdomains alles super aus. Die Hauptdomain war auch in allen Browsern ok.

Nach einiger Zeit Recherche und nachdem ich die Web-Konsole über den Firefox öffnete, sah ich den Fehler:

Firefox meckerte aufgrund eines Cross-Domain Problems. Er versuchte nämlich weiterhin über die Hauptdomain die Fonts aufzurufen. Da man sich jedoch auf der Subdomain befand, wurden diese nicht aufgerufen.

Ich habe nun folgende Einstellungen in die .htaccess eingefügt:

AddType application/vnd.ms-fontobject .eot
AddType font/ttf .ttf
AddType font/otf .otf
AddType font/woff .woff

<FilesMatch "\.(ttf|otf|eot|woff)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>

Die AddType Zeilen fügen die MIME types zur HTTP response hinzu. Danach prüfen wir, ob eine der Dateiendungen abgerufen wird und ob mod_headers vorhanden ist und erlauben den Zugriff über andere Domains.

Das Ganze kann man auch die Apache Config (z.B. hier zu finden /etc/apache2/apache2.conf ) schreiben.

Folgendermaßen sieht nun meine font-face CSS Bereich aus:

@font-face {
    font-family: "Font XY";
	src: url('https://www.xyz.de/wp-content/themes/xyz/fonts/Font-XY.eot'); 
	src: url('/wp-content/themes/xyz/fonts/Font-XY.woff') format('woff');
	font-weight: normal;
	font-style:normal;
}