laluluny

Lieber @hage,

der von dir verlinkte Artikel erstaunt mich doch sehr: die wp-config.php ins Hauptverzeichnis verschieben? Davon habe ich ja noch nie gehört (und es entsprechend auch noch nie gemacht).

Ich bin sonst eher immer Anleitungen wie dieser hier gefolgt: https://www.rietsch-design.de/wordpress-installation-unterverzeichnis-hauptdomain-aufrufen.html , d.h. sowohl index.php und auch .htaccess in BEIDEN Verzeichnissen, wo bei in der index.php im Hauptverzeichnis der Pfad angepasst werden muss.

Allerdings gibt es bei der o.g. Seite in den Kommentaren den Verweis auf eine Fehlermeldung beim Theme TwentyTwentyTwo mit weiteren Verweisen und einem Bug Report.

Auch hier ist eine Anleitung, bei der beide Dateien verschoben werden: https://developer.wordpress.org/advanced-administration/server/wordpress-in-directory/ Punkt 7; Und wenn ich Punkt 11 richtig verstehe, hat die .htaccess im Hauptverzeichnis aber Priorität, d.h. zur Not geht es wohl ohne die .htaccess im Unterverzeichnis, aber die im Hauptverzeichnis ist ein Muss (bzw. wird erzeugt, falls beschreibbar).

Womit wir wieder bei deinem TRICK für mich wären…

Danke und viele Grüße!
Karin

• Diese Antwort wurde vor 1 Jahr, 6 Monaten von laluluny geändert.

Also, meine Lieben,

es hat ein wenig gedauert (das Wetter war einfach zu schön -> andenSeeandenSee…)… heute habe ich mir die Sache nochmal ausführlich angesehen . Und bei Lektüre des von @la-geek verlinkten Artikels (der erste von den beiden) ist mir ein Licht aufgegangen…

In diesem Artikel steht nämlich:

WordPress registers colors in its default color palette with CSS custom properties that are available for all themes. This is so the default colors don’t break if the user switches themes, and to make it easier for us to use patterns from the pattern directory.

The palette is persistent: even if you hide it or add a new color palette, the CSS custom properties for these colors remain.

https://fullsiteediting.com/lessons/theme-json-color-options/#h-the-default-color-palette

Mein Fehler war, dass ich meine Custom Colors immer IN DIESE PALETTE eingespeist habe – man kann sie nämlich ebenfalls editieren und die Farbwerte ändern. Aber leider ist die Custom Color Palette eben „persistent“ – und überschreibt im Fall des Falles meine Anpassungen (= das war der „Fehler“, der mich zu diesem Thread inspirierte).

Ich habe auf der o.g. Seite weiter herumgestöbert und meine persönlichen Custom-Colors jetzt direkt in die theme.json des Child Themes (lieber @hage, ich benutze das von dir erwähnte Plugin zum erstellen von Child-Themes bereits, danke trotzdem für den Hinweis!) einfügt Und anschließend alle Elemente nochmal neu gestyled – statt mit von-mir-modifizierten-Standard-Farben mit den neuen Farben meiner eigenen, neuen Pallette. Ich bin ziemlich sicher, dass die nicht mehr überschrieben wird… 😉

Anyway, VIELEN DANK für eure Hilfe! All eure Hinweise haben mir echt auf die Sprünge geholfen!!

Herzliche Grüße
Karin

• Diese Antwort wurde vor 1 Jahr, 7 Monaten von laluluny geändert.

Hallo Hans-Gerd,

Danke für deinen Input – ich werde mir deinen Artikel durchlesen und dann selbst noch einmal weiter probieren. Ich habe heute Nacht darüber nachgedacht, wo wohl diese Standard-Farben abgespeichert sind. Ggf. in der Style.css? Ich werde noch ein bisschen stochern und meine Ergebnisse dann hier publizieren.
PS: Ich habe gestern mehrere WP-Sites aktualisiert, die ein gestyltes Child-Theme von TT3 verwenden. Bei allen hatte ich das Farben-Problem, manchmal waren auch die individuellen Google-Fonts weg. Aber vielleicht habe ich die Child-Themes alle auf die selbe Weise „falsch“ erstellt? Ich werde mir alles nochmal genau ansehen und weiter testen- ein paar Websites mit TT3-Child-Themes stehen beim Updaten noch aus… 🙂

Ich werde berichten!

Viele Grüße
Karin

PS: Vielleicht kann ich das Problem folgendermaßen präzisieren:

• Ich binde in statische Html-Seiten Elemente aus einer WP-Seite ein. Funktionierte früher problemlos, funktioniert jetzt nicht mehr.
• Im Netz fand ich eine Lösung (https://robertmarshall.dev/blog/wordpress-rest-api-cors-issues/), implementierte sie, die Einbindung klappte wieder
• Aber diese Lösung verhindert, dass der Block-Editor korr. funktioniert: man kann Seiten, die man bearbeitet hat, nicht mehr abspeichern.

Daraus ergibt sich meine Frage: Warum ist das so? Was macht dieses Script (aus der „Lösung“, s.o.), das dazu führt, dass nun der Block-Editor „spinnt“?

Ich habe jetzt auch noch eine weitere „Anleitung“ ergoogelt: https://webdevstudios.com/2020/11/17/resolve-cors-errors/
Leider bin ich kein Programmierer… ich checke das mit dem Code nicht; der Autor erklärt eine ganze Menge, aber mir ist nicht klar, mit welcher Zeile magischen Codes ich alles wieder zum Laufen bekomme…

Und hier ist auch nochmal was ähnliches: https://wordpress.org/support/topic/cors-error-13/ – sehr aktuell…

Danke und Grüße,
Karin

Moderationshinweis: deine Antwort wurde von der Forensoftware zurückgehalten. Ich musste die Antwort erst freischalten.

• Diese Antwort wurde vor 1 Jahr, 9 Monaten von laluluny geändert.
• Diese Antwort wurde vor 1 Jahr, 9 Monaten von Hans-Gerd Gerhards geändert.
• Diese Antwort wurde vor 1 Jahr, 9 Monaten von Hans-Gerd Gerhards geändert.
• Diese Antwort wurde vor 1 Jahr, 8 Monaten von Hans-Gerd Gerhards geändert.

Hallo Hans-Gerd,

Danke für deine Rückmeldung.

Aber, oh, da hast du mich missverstanden: die Seite(n), auf denen jeweils ganz unterschiedliche (WordPress-)Seiten(Teile) eingebunden werden, sind ganz normale, statische (!) HTML-Seiten.
Beispiel: https://no2do.com/hexagramme/778787.htm

Nur das, was eingebunden wird, kommt von WP.

Aber wegen „Blocked by CORS“ erlaubt WP eben leider nicht, dass Teile des WP-Auftritts irgendwoanders eingebunden werden…

Klarer?
(klarer auch, warum wiederverwendbare Blöcke nicht weiterhelfen? Weil die Seite, die einbindet, ja keine WP- sondern eine HTML-Seite ist…)

Danke und LG,
Karin

PS, just in case: Die ergänzte functions.php hat folgenden Inhalt:

<?php
/**
* Child theme stylesheet einbinden in Abhängigkeit vom Original-Stylesheet
Und einen Fehler mit WordPress REST API CORS loesen per
https://robertmarshall.dev/blog/wordpress-rest-api-cors-issues/
*/

function child_theme_styles() {
wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
wp_enqueue_style( 'child-theme-css', get_stylesheet_directory_uri() .'/style.css' , array('parent-style'));

}

add_action('init', 'handle_preflight');
function handle_preflight() {
    $origin = get_http_origin();
    if ($origin === 'https://www.no2do.com/synopse') {
        header("Access-Control-Allow-Origin: https://www.no2do.com/synopse");
        header("Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE");
        header("Access-Control-Allow-Credentials: true");
        header('Access-Control-Allow-Headers: Origin, X-Requested-With, X-WP-Nonce, Content-Type, Accept, Authorization');
        if ('OPTIONS' == $_SERVER['REQUEST_METHOD']) {
            status_header(200);
            exit();
        }
    }
}
add_filter('rest_authentication_errors', 'rest_filter_incoming_connections');
function rest_filter_incoming_connections($errors) {
    $request_server = $_SERVER['REMOTE_ADDR'];
    $origin = get_http_origin();
    if ($origin !== 'https://www.no2do.com/synopse') return new WP_Error('forbidden_access', $origin, array(
        'status' => 403
    ));
    return $errors;
}
add_action( 'wp_enqueue_scripts', 'child_theme_styles' );?>