Ein WordPress Gutenberg Block Projekt aufsetzen bedeutet Webpack, Babel und SASS-Compiler installieren. Es gibt einen kurzen Weg, und einen langen Weg ein Gutenberg-Block Projekt auf zu setzen. Natürlich brauch ich auch eine lokale Entwicklungsumgebung.
Vorbereitungen
Man kann das zu Fuß — nur mit einem Code-Editor und viel Tipperei lösen. Wer sich öfter mit dem Thema auseinandersetzen will für den lohnt sich der Weg über zusätzliche Tools und Libraries.…
Lokale Entwicklungsumgebung
Code-Editor
Ich benutze VSCodium zum entwickeln.
Tools und Libraries
Neben dem Code-Editor benötige ich noch:
Ausserdem natürlich:
- Webpack
- Babel
- SASS-Compiler
Der kurze Weg: Create Guten Block
Der kurze Weg führt über das Zero Configuration Dev-Toolkit Create Guten Block von Ahmad Awais ein. Das spart mir die Installation/Konfiguration von React, Webpack und Babel. Dazu einfach im Terminal ins in Plugin Verzeichnis wechseln und führe zum testen npx aus:
|
1 2 3 |
npx create-guten-block mein-gutenberg-block-name |
Wobei mein-gutenberg-block-name der Name meines Plugins ist. Es wird ein Gerüst angelegt, das ich gleich starten kann.
Folgende Befehle stehen mir im Terminal zur Verfügung, die im Plugin-Verzeichnis ausgeführt werden müssen:
npm start— Den Code im Entwicklungsmodus kompilieren und ausführen. Webpack überwacht alle Änderungen im src-Verzeichnis und kompiliert den Code neu, wenn ich ihn ändere. Fehlermeldungen werden im Terminal zurückgemeldet.npm run build— Baut den Code für die Produktion im dist-Verzeichnis. Der Code wird kompiliert, komprimiert & alle Kommentare entfernt. Liefert die Größe der gzip-Datei des gebauten Codes zurück.npm run eject— Entfernt dieses Tool und kopiert Build-Abhängigkeiten, Konfigurationsdateien und Skripte in den Plugin-Ordner. Das ist eine Einbahnstraße. Achtung: Es gibt kein Zurück!
Jetzt kann ich im Terminal mit sudo apachectl -k start den lokalen Webserver starten. Die WordPress URL im Browser aufrufen — https://localhost/wp/wp-login.php — mich im Backend einloggen, das Block-Plugin aktivieren, und den Block im Editor ausprobieren. Hooray!
Ps. den langen Weg beschreibe ich hier.
Der lange Weg: Manuelle Installation
Ich öffne das Plugin-Verzeichnis im Terminal und mach dort erst mal ein
|
1 2 3 4 5 6 7 |
npm init npm install –save-dev @wordpress/scripts npm install –save-dev css-loader extract-loader file-loader postcss-loader sass-loader npm install –save-dev autoprefixer postcss-cli node-sass npm install –save-dev @wordpress/browserslist-config |
Was mir eine package.json und ein node-modules Verzeichnis anlegt, mit den benötigten Bibliotheken und allen Abhängigkeiten.
PostCSS konfigurieren
Eine postcss.config.js erstellen, und reinpacken:
|
1 2 3 |
module.exports = { plugins: { autoprefixer: { grid: true } } } |
und in der package.json ergänze ich:
|
1 2 3 |
“browserslist”: [ “extends @wordpress/browserslist-config” ], |
Über npx autoprefixer --info kann man sich die von WordPress unterstützten Browser und ihre Eigenschaften und Werte anzeigen lassen.
Webpack konfigurieren
Es ist keine eigene Config-Datei nötig wenn man nur eine Datei und Javascript kompilieren möchte. Das Modul @wordpress/scripts bringt eine Standard-Datei mit, die eine src/index.js zu einer build/index.js kompiliert.
Da ich aber etwas mehr möchte, erstelle eine webpack.config.js Datei, und packe folgendes Skript hinein:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
const defaultConfig = require(“./node_modules/@wordpress/scripts/config/webpack.config”); const path = require(‘path’); module.exports = { ...defaultConfig, entry: [’./blocks/index.js’, ‘./blocks/editor.scss’, ‘./blocks/frontend.scss’], output: { path: path.resolve(__dirname, ‘assets’), filename: ‘js/editor.blocks.js’, }, module: { rules: [ /** * Running Babel on JS files. */ …defaultConfig.module.rules, { test: /\.scss$/, use: [{ loader: ‘file-loader’, options: { name: ‘css/[name].blocks.css’, } }, { loader: ‘extract-loader’ }, { loader: ‘css-loader?-url’ }, { loader: ‘postcss-loader’ }, { loader: ’sass-loader’ }] }] } }; |
Was passiert hier?
- In
defaultConfigsteht Konfigurationsdatei des @wordpress/scripts-Pakets. - In
pathsteht das Node-Modul path (Ausgabeverzeichnis der Dateien). - Innerhalb von
module.exportsenthält die Webpack-Konfiguration. defaultConfigEnthält Standard-Konfiguration, die ich erweitern will:- Das
entryArray enthält die Quelldateien des Blocks. outputEnthält der Ausgabepfad “assets”, und ein Unterverzeichnis js mit dem Namen editor.blocks.js.moduleenthält Compiler-Regeln für die Dateien inentry.- Regeln der Standard-Konfiguration
defaultConfig.module.rules: Kompilierung der JavaScript-Datei. - Mehrere Regeln für scss Dateien um SASS in CSS zu kompilieren, und das Ergebnis nach dem Schema
[name].blocks.cssinnerhalb des css-Verzeichnisses abzulegen. Das ergibt zwei CSS-Dateienassets/css/editor.blocks.cssundassets/css/frontend.blocks.css.
- Regeln der Standard-Konfiguration
…
Zusätzliche NPM-Skripte für Webpack
In die Datei package.json im scripts Element folgenden Code einfügen:
|
1 2 3 |
‚“start”: “wp-scripts start”, “build”: “wp-scripts build” |
npm run startführt Webpack in der Entwicklung aus.npm run buildkompiliert die Dateien für die Produktion.
Jetzt kann ich mit den Dateien
- blocks/index.js
- blocks/editor.scss
- blocks/frontend.scss
in der Entwicklung arbeiten und bekommt mit Hilfe von Webpack alles in assets gepackt, die das Plugin einbinden kann.
… wird fortgesetzt…