Einfügen von JavaScript-Variablen in den benutzerdefinierten WordPress-Blockeditor

Lesezeit: 5 Minuten

lejahmies Benutzeravatar
lejahmie

Ich erstelle ein paar benutzerdefinierte Blöcke in einem Design und habe ein Problem. Manchmal muss ich im Blockeditor benutzerdefinierte Daten an meine Blöcke übergeben.

Mit anderen Worten: Ich benötige Daten, die in „blocks/myBlock/index.js“ (dem Editor-Skript) verfügbar sind.

Ich registriere meine Blöcke mit der empfohlenen neuen Methode. register_block_type(__DIR__ . '/build/blocks/myBlock');das im Grunde die Datei block.json lädt, die dann alle dort definierten Editor-, Frontend- und Render-Skripte registriert.

In meinem Fall besteht es aus:

"editorScript": "file:./index.js",
  "style": [
    "file:./style.css"
  ],
  "render": "file:./render.php"

Man könnte meinen, ich könnte die Funktion nutzen wp_add_inline_script im Haken admin_enqueue_scripts, aber es scheint nicht zu funktionieren. Hook wird ausgelöst, aber es werden keine Inline-Skripte hinzugefügt. Meine beste Vermutung nach einigen Nachforschungen ist, dass Blockskripte zu früh geladen werden und die wp_add_inline_script wird laut Kommentaren in der offiziellen Dokumentation ausgelöst, nachdem das Skript bereits geladen wurde oder so; https://developer.wordpress.org/reference/functions/wp_add_inline_script/#comment-5828

Beispiel:

add_action('admin_enqueue_scripts', function () {
    wp_add_inline_script('my-namespace-my-block-editor-script-js', 'window.myBlockConfig = ' . json_encode(array(
        'foo' => 'bar',
    )), 'before');
});

Und sogar Brute-Forcing in den Skripten admin_head-hook scheint, wie im Kommentar vorgeschlagen, auch nicht zu funktionieren, obwohl wp_footer als Beispiel verwendet wurde. Ich kann dann sehen, dass mein Inline-Skript geladen ist, aber es wird nach dem Blockeditor-Skript geladen und bis dahin sind keine der über das Inlien-Skript zugänglich gemachten Daten erreichbar.

Beispiel:

add_action('admin_head', function () {
    echo '<script>window.myBlockConfig = ' . json_encode(array(
     'foo' => 'bar'
    )) . '</script>';
});

Inline-Skript, das nach Skripten geladen wird, die die Daten benötigen

Was wäre also der „richtige“ Weg, dies zu tun?

UPDATE 1:

Die einzige Möglichkeit, die ich gefunden habe, um dieses Problem zu lösen, ist die Verwendung der WordPress-REST-API, z.

function myBlockRestApiGetConfig($request)
{
    $response = array(
      'foo' => 'bar',
    );

    return rest_ensure_response($response);
}

add_action('rest_api_init', function () {
    register_rest_route('myBlock/v1', '/config', array(
      'methods' => 'GET',
      'callback' => 'myBlockRestApiGetConfig',
    ));
});

Und dann kann ich es in meinem Blockeditor-Skript abrufen;

const config = await apiFetch({
   path: `/myBlock/v1/config`,
});

Aber die Frage ist immer noch; Was wäre der „richtige“ Weg, dies zu tun? Vielleicht ist es besser, die API zu verwenden? Das React-Backend ist sehr API-zentriert, daher macht es Sinn, aber das „Vorladen der Konfiguration“ macht es schneller. Es ist also ein Pro/Contra, denke ich.

Ich finde es immer noch seltsam, dass es für keine Hooks unmöglich erscheint, irgendwelche Skript-Tags vor Blöcken zu laden.

Vielen Dank für Ihre Zeit 🙂

UPDATE 2:

Es stellt sich heraus, dass ich wie immer ein Idiot bin. Der in verwendete Handlename wp_add_inline_script. Ich habe die vollständige Skript-ID verwendet, wie sie im Quellcode zu sehen ist. my-namespace-my-block-script-jsAber -js wird von WordPress zu Skripten hinzugefügt und ist nicht Teil des Handle-Namens. Es sollte also einfach sein my-namespace-my-block-editor-script. Und dann funktioniert es einfach…

add_action('admin_enqueue_scripts', function () {
    // Add pre-loaded data for my-namespace/my-block
    wp_add_inline_script('my-namespace-my-block-editor-script', 'window.myBlockConfig = ' . json_encode(array(
        'foo' => 'bar',
    )), 'before');
});

Die Antwort von @Ruvee hat mir dabei geholfen, dies zu erkennen, und ist als „richtige“ Antwort markiert.

  • Es stellte sich heraus, dass mein Problem dummerweise der darin verwendete Handle-Name war wp_add_inline_script. Ich habe die vollständige Skript-ID verwendet, wie sie im Quellcode zu sehen ist; myBlock-editor-script-jsAber -js wird von WordPress zu Skripten hinzugefügt und ist nicht Teil des Handle-Namens. Es sollte also einfach sein myBlock-editor-script. Und dann funktioniert es einfach…

    – lejahmie

    27. April um 21:23

Ruvees Benutzeravatar
Ruvee

Im Kommentarbereich ist nicht genügend Platz, daher schreibe ich meine Antwort hier!

Ich habe herumgebastelt "Gutenberg blocks" Ich denke, ich kann Ihnen schon seit geraumer Zeit weiterhelfen!

Kurze Antwort:

Ja, es gibt eine bessere oder, wie Sie sagen, „richtige“ Möglichkeit, dies zu tun, und es ist kein zusätzlicher API-Aufruf erforderlich, obwohl dies in bestimmten Situationen eine Option sein könnte! Aber was Sie suchen, ist wp_localize_scriptDokumente


Ausführlichere Antwort:

Da Sie keinen spezifischen Code angegeben und nur einige allgemeine Fragen gestellt haben, gebe ich Ihnen allgemeine Schritte, die ich unternehmen würde, wenn ich versuche, darauf zuzugreifen javascript Variablen im globalen Bereich!

Registrieren Sie Ihren Block bei initDokumente Action-Hook, etwa so:

add_action('init', 'your_block_admin_assets');

function your_block_admin_assets()
{
  // This is a javascript file you would need as a "handle" when you use wp_localize_script function
  wp_register_script('your-new-blocktype', 'path/to/js/file.js', array('wp-blocks', 'wp-element', 'wp-editor'));

  // Inside this function you would need to use above js file name you just registered
  register_block_type('name_of_your_block', array(
    'editor_script' => 'your-new-blocktype',
    'render_callback' => ('your_HTML_callback')
  ));

  // Use the name of the script you registered above as first argument and second argument would be a name you pick and choose to access your data in the global scope (i.e ruveeTestData.root_url)
  wp_localize_script('your-new-blocktype', 'ruveeTestData', array(
    'root_url' => get_site_url(),
    'dummy_data' => 'dummy_stuff'
  ));
}

Wenn Sie auf der Administratorseite Beiträge laden, die diesen Block enthalten, können Sie auf diese globalen Variablen zugreifen. Ich habe es gerade getestet und hier ist ein Screenshot von meiner Seite

Geben Sie hier eine Bildbeschreibung ein

Notiz:

  • Zuerst müssen Sie sich registrieren javascript fileverwenden wp_register_script Funktion, um ihren Namen als Referenz in zu verwenden wp_localize_script Funktion.
  • Sie können auch einige bedingte Prüfungen verwenden, z is_adminDokumente um das Laden Ihrer globalen Variablen einzugrenzen.

Ich hätte genauer sein und Ihnen mehr Details geben können, wenn Sie mehr Einzelheiten zu Ihrer Frage angegeben hätten, aber ich denke, dass die Referenzen, die ich Ihnen gerade gegeben habe, ausreichen würden, um Sie auf den richtigen Weg zu bringen!

  • Danke schön! Deine Antwort hat geholfen! Hat sich herausgestellt wp_add_inline_script Funktioniert auch wp_localize_script. Es stellte sich heraus, dass mein Problem der Name des Handlers war. ich benutzte myBlock-editor-script-js Aber -js wird automatisch von WordPress hinzugefügt. Der richtige Handler ist also myBlock-editor-script. Und es funktioniert sogar, wenn Sie den Blocks.json-Weg verwenden, um Ihren Block zu registrieren. register_block_type('path/to/build/blocks/myBlock');

    – lejahmie

    27. April um 21:34

1451230cookie-checkEinfügen von JavaScript-Variablen in den benutzerdefinierten WordPress-Blockeditor

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy