Viele WordPress-Plugins lassen sich nach EmDash portieren. Das Plugin-Modell unterscheidet sich—TypeScript statt PHP, Hooks statt Actions/Filters, strukturierter Speicher statt wp_options—aber die meisten Funktionen lassen sich klar abbilden.
Eignungsprüfung
Nicht jedes Plugin sollte portiert werden. Bewerte Kandidaten vor dem Start.
Gute Kandidaten
Benutzerdefinierte Felder, SEO-Plugins, Content-Prozessoren, Admin-UI-Erweiterungen, Analytics, Social Sharing, Formulare
Schlechte Kandidaten
Multisite-Features, WooCommerce-/Gutenberg-Integrationen, Plugins, die WordPress-Core intern patchen
Plugin-Struktur im Vergleich
WordPress
wp-content/plugins/my-plugin/
├── my-plugin.php # Main file with plugin header
├── includes/
│ ├── class-admin.php
│ └── class-api.php
└── admin/
└── js/ EmDash
my-plugin/
├── src/
│ ├── index.ts # Plugin definition (definePlugin)
│ └── admin.tsx # Admin UI exports (React)
├── package.json
└── tsconfig.json Hook-Zuordnung
WordPress nutzt add_action() und add_filter() mit String-Hook-Namen. EmDash nutzt typisierte Hooks in der Plugin-Definition.
Lifecycle-Hooks
| WordPress | EmDash | Hinweis |
|---|---|---|
register_activation_hook() | plugin:install | Einmal bei erster Installation |
| Plugin aktiviert | plugin:activate | Bei Aktivierung |
| Plugin deaktiviert | plugin:deactivate | Bei Deaktivierung |
register_uninstall_hook() | plugin:uninstall | event.deleteData = Nutzerwahl |
Content-Hooks
| WordPress | EmDash | Hinweis |
|---|---|---|
wp_insert_post_data | content:beforeSave | Geänderten Inhalt zurückgeben oder werfen |
save_post | content:afterSave | Seiteneffekte nach dem Speichern |
before_delete_post | content:beforeDelete | false zurückgeben zum Abbrechen |
deleted_post | content:afterDelete | Aufräumen nach Löschung |
WordPress
add_action('save_post', function($post_id, $post, $update) {
if ($post->post_type !== 'product') return;
$price = get_post_meta($post_id, 'price', true);
if ($price > 1000) {
update_post_meta($post_id, 'is_premium', true);
}
}, 10, 3);
EmDash
hooks: {
"content:afterSave": async (event, ctx) => {
if (event.collection !== "products") return;
const price = event.content.price as number;
if (price > 1000) {
await ctx.kv.set(`premium:${event.content.id}`, true);
}
},
} Media-Hooks
| WordPress | EmDash | Hinweis |
|---|---|---|
wp_handle_upload_prefilter | media:beforeUpload | Validieren oder transformieren |
add_attachment | media:afterUpload | Reaktion nach Upload |
Speicher-Zuordnung
Options-API → KV-Store
WordPress
$api_key = get_option('my_plugin_api_key', '');
update_option('my_plugin_api_key', 'abc123');
delete_option('my_plugin_api_key'); EmDash
const apiKey = await ctx.kv.get<string>("settings:apiKey") ?? "";
await ctx.kv.set("settings:apiKey", "abc123");
await ctx.kv.delete("settings:apiKey"); Eigene Tabellen → Storage-Collections
WordPress
global $wpdb;
$table = $wpdb->prefix . 'my_plugin_items';
// Insert
$wpdb->insert($table, ['name' => 'Item 1', 'status' => 'active']);
// Query
$items = $wpdb->get_results(
"SELECT \* FROM $table WHERE status = 'active' LIMIT 10"
);
EmDash
// Declare in plugin definition
storage: {
items: {
indexes: ["status", "createdAt"],
},
},
// In hooks or routes:
await ctx.storage.items.put("item-1", {
name: "Item 1",
status: "active",
createdAt: new Date().toISOString(),
});
const result = await ctx.storage.items.query({
where: { status: "active" },
limit: 10,
}); Settings-Schema
WordPress nutzt die Settings-API für Admin-Formulare. EmDash nutzt ein deklaratives Schema mit automatisch generierter UI.
WordPress
add_action('admin_init', function() {
register_setting('my_plugin', 'my_plugin_api_key');
add_settings_section('main', 'Settings', null, 'my-plugin');
add_settings_field('api_key', 'API Key', function() {
$value = get_option('my_plugin_api_key');
echo '<input type="text" name="my_plugin_api_key"
value="' . esc_attr($value) . '">';
}, 'my-plugin', 'main');
}); EmDash
admin: {
settingsSchema: {
apiKey: {
type: "secret",
label: "API Key",
description: "Your API key from the dashboard",
},
enabled: {
type: "boolean",
label: "Enabled",
default: true,
},
limit: {
type: "number",
label: "Item Limit",
default: 100,
min: 1,
max: 1000,
},
},
} Admin-UI
WordPress-Admin-Seiten sind PHP. EmDash nutzt React-Komponenten.
import { useState, useEffect } from "react";
export const widgets = {
summary: function SummaryWidget() {
const [count, setCount] = useState(0);
useEffect(() => {
fetch("/_emdash/api/plugins/my-plugin/status")
.then((r) => r.json())
.then((data) => setCount(data.count));
}, []);
return <div>Total items: {count}</div>;
},
};
export const pages = {
settings: function SettingsPage() {
// React component for settings page
return <div>Settings content</div>;
},
};
In der Plugin-Definition registrieren:
admin: {
entry: "@my-org/my-plugin/admin",
pages: [{ path: "/settings", label: "Dashboard" }],
widgets: [{ id: "summary", title: "Summary", size: "half" }],
},
REST-API → Plugin-Routes
WordPress
register_rest_route('my-plugin/v1', '/items', [
'methods' => 'GET',
'callback' => function($request) {
global $wpdb;
$items = $wpdb->get_results("SELECT * FROM items LIMIT 50");
return new WP_REST_Response($items);
},
]); EmDash
routes: {
items: {
handler: async (ctx) => {
const result = await ctx.storage.items.query({ limit: 50 });
return { items: result.items };
},
},
}, Routes liegen unter /_emdash/api/plugins/{plugin-id}/{route-name}.
Portierungsprozess
-
WordPress-Plugin analysieren
Dokumentiere Hooks, Datenbankzugriffe, Admin-Seiten, REST-Endpunkte.
-
Auf EmDash-Konzepte abbilden
WordPress-Hooks → EmDash-Hooks.
wp_options→ctx.kv. Eigene Tabellen → Storage-Collections. Admin-Seiten → React-Komponenten. REST → Plugin-Routes. -
Plugin-Gerüst anlegen
import { definePlugin } from "emdash"; export function createPlugin() { return definePlugin({ id: "my-ported-plugin", version: "1.0.0", capabilities: [], storage: {}, hooks: {}, routes: {}, admin: {}, }); } -
Reihenfolge der Implementierung
Storage → Hooks → Admin-UI → Routes
-
Gründlich testen
Prüfe, dass Hooks feuern, Storage funktioniert und die Admin-UI rendert.
Beispiel: Lesezeit-Plugin
WordPress
add_filter('wp_insert_post_data', function($data, $postarr) {
if ($data['post_type'] !== 'post') return $data;
$content = strip_tags($data['post_content']);
$word_count = str_word_count($content);
$read_time = ceil($word_count / 200);
if (!empty($postarr['ID'])) {
update_post_meta($postarr['ID'], '_read_time', $read_time);
}
return $data;
}, 10, 2);
EmDash
export function createPlugin() {
return definePlugin({
id: "read-time",
version: "1.0.0",
admin: {
settingsSchema: {
wordsPerMinute: {
type: "number",
label: "Words per minute",
default: 200,
min: 100,
max: 400,
},
},
},
hooks: {
"content:beforeSave": async (event, ctx) => {
if (event.collection !== "posts") return;
const wpm = await ctx.kv.get<number>("settings:wordsPerMinute") ?? 200;
const text = JSON.stringify(event.content.body || "");
const readTime = Math.ceil(text.split(/\s+/).length / wpm);
return { ...event.content, readTime };
},
},
});
} Capabilities
Plugins müssen benötigte Capabilities für die Security-Sandbox deklarieren:
| Capability | Ermöglicht | Anwendungsfall |
|---|---|---|
network:fetch | ctx.http.fetch() | Externe API-Aufrufe |
read:content | ctx.content.get(), list() | CMS-Inhalte lesen |
write:content | ctx.content.create(), usw. | Inhalte ändern |
read:media | ctx.media.get(), list() | Medien lesen |
write:media | ctx.media.getUploadUrl() | Medien hochladen |
Typische Stolpersteine
Kein globaler Zustand — Nutze Storage statt globaler Variablen.
Alles asynchron — Storage- und API-Aufrufe immer awaiten.
Kein direktes SQL — Nutze strukturierte Storage-Collections.
Kein Dateisystem — Nutze die Media-API für Dateien.
Nächste Schritte
- Hooks Reference — Alle Hooks mit Signaturen
- Storage API — Collections und Abfragen
- Settings — Settings-Schema und KV-Store
- Admin UI — Admin-Seiten bauen