Einen Custom Post Type zu bauen ist nichts Neues; zehn andere Plugins tun das auch. Anders sind hier zwei Entscheidungen zur Speicherung. Feldwerte landen als gewöhnliche Meta in postmeta statt in einer eigenen Tabelle, denn eine eigene Tabelle sieht im Benchmark besser aus, und WP_Query sieht sie nicht. Definitionen landen in einer JSON-Datei statt in einer autoload-Option, denn eine Website mit dreißig Feldgruppen entpackt bei jedem Request hundert Kilobyte — auch bei der Mehrheit, die nie ein Feld ansieht. Die Pro-Stufe baut aus denselben Werten JSON-LD und exportiert eine eigenständige PHP-Datei für ein Child-Theme.
Das ist ein voller Markt, und „baut Post-Types“ ist keine Neuigkeit. Seltener gestellt wird die Frage, was ein solches Plugin die Website bei jedem Request kostet — und die Antwort ergibt sich aus zwei Entscheidungen zur Speicherung, bei denen der übliche Reflex in beiden Fällen falsch liegt.
Die erste: Feldwerte gehen als gewöhnliche Meta nach postmeta, nicht in eine eigene Tabelle. Eine eigene Tabelle sieht im Benchmark besser aus und ist in der Praxis nutzlos — WP_Query sieht sie nicht, orderby => meta_value_num kann nicht danach sortieren, die REST-API zeigt sie nicht, und kein anderes Plugin weiß, dass es dort nachsehen müsste. Und die Form zählt so viel wie die Tabelle: Eine Galerie, die als ein serialisiertes Array in einer Zeile liegt, ist für jeden SQL-Vergleich für immer unsichtbar. Hier bekommt jeder Wert eine eigene Zeile unter einem Schlüssel — eine Zeile mehr je Eintrag, dafür überhaupt abfragbar.
Die zweite: Definitionen gehen in eine JSON-Datei, nicht in eine autoload-Option — und ausdrücklich nicht, weil „Dateien schneller sind als die Datenbank“, was die README selbst als falsch bezeichnet. Eine autoload-Option kostet keine zusätzliche Abfrage; sie kommt in derselben alloptions-Abfrage mit, die WordPress ohnehin macht, und bei einem kleinen Wert gewinnt die Option. Der Grund ist, was passiert, wenn der Wert nicht mehr klein ist: Eine Website mit dreißig Feldgruppen entpackt hundert Kilobyte bei jedem Request — Loginseite, admin-ajax, REST, Cron — auch bei der überwältigenden Mehrheit, die nie ein Feld ansieht. Eine Kopie bleibt mit abgeschaltetem autoload in der Datenbank, damit ein schreibgeschütztes Dateisystem etwas Geschwindigkeit kostet und nicht sämtliche Post-Types der Website.
Die stärkste Aussage hier ist die Folge genau dieser Entscheidung. Die Datei liegt im uploads-Verzeichnis, also kontrolliert sie alles, was dort schreiben kann — ein anderes Plugin, eine Upload-Lücke an anderer Stelle, ein geliehener FTP-Zugang. Ihr Inhalt gilt deshalb als genauso unvertrauenswürdig wie ein abgeschicktes Formular: gelesen mit json_decode und nie mit include oder unserialize, und jeder Wert läuft durch dieselbe Bereinigung wie ein abgeschickter. Ohne das könnte ein Label <img src=x onerror=…> lauten, und WordPress gibt name_admin_bar unescaped aus — Skriptausführung auf jeder Adminseite. Es gibt Obergrenzen für die Zahl der Einträge, für die Listen darin und für das Produkt aus Post-Types und Feldern, denn die Dateigröße zu begrenzen begrenzt nichts davon: Eine 14-KB-Datei kann zwanzigtausend register_post_meta-Aufrufe auf init erzeugen. Über der Grenze wird das Speichern verweigert statt stillschweigend gekürzt.
Die kostenlose Stufe verweigert außerdem Namen, die die Website beschädigen, und sagt, was passiert wäre: die Namen von WordPress selbst, Query-Variablen wie author und name, und alles über zwanzig Zeichen, weil die Spalte zwanzig Zeichen hat und ein längerer Name dort stillschweigend gekürzt wird, in PHP aber vollständig bleibt. Die Pro-Stufe baut aus denselben Werten JSON-LD und gibt bei einer unvollständigen Zuordnung nichts aus, sondern warnt; und sie exportiert eine eigenständige PHP-Datei für ein Child-Theme, nach der man das Plugin deaktivieren kann und Post-Types, Meta-Schlüssel und Inhalte genau dort bleiben, wo sie waren.
Vorher
Die Felddefinitionen liegen in einer autoload-Option und werden bei jedem Request entpackt, auch auf der Loginseite und im Cron.
Nachher
Definitionen liegen in einer Datei und werden gelesen, wenn sie gebraucht werden; die Kopie in der Datenbank hat autoload aus.
Vorher
Galerien und Checkbox-Werte liegen als serialisiertes Array in einer Zeile, und keine Abfrage sieht hinein.
Nachher
Jeder Wert bekommt eine eigene Zeile unter demselben Schlüssel, damit meta_query und orderby wirklich funktionieren.
Vorher
Sie haben einen Post-Type namens author angelegt, keinerlei Fehlermeldung bekommen und Monate später gemerkt, dass sein Archiv nie aufgeht.
Nachher
Der Name wird abgelehnt, und das Plugin erklärt, was passiert wäre — bevor irgendetwas angelegt wird.
Im Menü CPT & Schema auf Post-Type hinzufügen. Den Namen in lateinischen Kleinbuchstaben schreiben; würde ein Name die Website beschädigen, wird er auf der Stelle abgelehnt, mitsamt Begründung.
Wählen Sie, auf welchen Post-Types die Gruppe erscheint, und legen Sie dann die Felder an. Jeder Feldtyp sagt daneben, wie er gespeichert wird und was das sortierbar macht.
Mit einem der beiden Blöcke im Editor oder mit einer Funktion im Template. Beide lesen den Wert beim Aufbau der Seite und nicht aus etwas, das in den Beitragsinhalt eingefroren wurde.
Websites, die wirklich eigene Post-Types brauchen · Kataloge und Listen, die nach einem Feld sortieren und filtern müssen · Content-Websites, die strukturierte Daten ohne SEO-Plugin wollen · Entwicklerinnen, die nicht bei jedem Request hundert Kilobyte autoloaden möchten · Designerinnen, die eine Website mit einem Plugin bauen und es danach entfernen wollen · Agenturen, die eine Website übergeben und die Datenstruktur nicht als Geisel zurücklassen möchten · alle, die einmal einen Post-Type namens author angelegt haben.
Kein Composer, keine eigene Datenbanktabelle, kein externer Dienst und kein jQuery. Was Sie bauen, bleibt dort, wo WordPress es ablegt.
Eine eigene Tabelle sieht im Benchmark besser aus und ist in der Praxis nutzlos: WP_Query sieht sie nicht, orderby => meta_value_num kann nicht danach sortieren, die REST-API zeigt sie nicht, und kein anderes Plugin weiß, dass es dort nachsehen müsste. Hier ist jeder Wert gewöhnliche Beitrags-Meta mit dem Präfix hd_ncs_ und ohne führenden Unterstrich — denn verborgene Meta ist die Meta, die die Betreiberin nicht sieht und nicht reparieren kann, wenn etwas schiefgeht.
Eine Galerie als ein serialisiertes Array sieht in einer longtext-Spalte etwa so aus: a:3:{i:0;s:2:"12";…}. Kein SQL-Vergleich sieht hinein, sie ist also für jede Abfrage für immer unsichtbar, und die einzige Reparatur ist eine Migration. Hier ist ein wiederholtes Feld mehrere Zeilen unter einem Schlüssel. Auch Zahlen werden als Zahlen gespeichert, damit die Sortierung 10 nach 9 stellt und nicht davor.
Nicht weil „Dateien schneller sind als die Datenbank“ — das stimmt nicht. Eine autoload-Option kostet keine zusätzliche Abfrage; sie kommt in derselben alloptions-Abfrage mit, die WordPress ohnehin macht, und bei einem kleinen Wert gewinnt sie. Der Grund ist, was passiert, wenn der Wert nicht mehr klein ist: dreißig Feldgruppen sind hundert Kilobyte, die bei jedem Request entpackt werden, auch bei der Mehrheit, die nie ein Feld ansieht.
Es gibt reichlich echtes Hosting, das auf Dateisystemebene schreibgeschützt ist. Lässt sich die Datei nicht lesen, läuft alles aus der Datenbankkopie weiter, und die Werkzeug-Ansicht sagt, woher gerade gelesen wird; Lesen ist etwas langsamer, verloren geht nichts. Geschrieben wird atomar — temporäre Datei und dann rename —, damit eine Leserin nie ein halbes Dokument sieht.
Alles, was in das uploads-Verzeichnis schreiben kann, kontrolliert diese Datei — ein anderes Plugin, eine Upload-Lücke an anderer Stelle, ein geliehener FTP-Zugang. Sie wird deshalb mit json_decode gelesen und nie mit include oder unserialize, und jeder Wert läuft durch dieselbe Bereinigung wie ein abgeschickter Formularwert. Ohne das könnte ein Label <img src=x onerror=…> lauten, und WordPress gibt name_admin_bar unescaped aus.
Die Dateigröße zu begrenzen begrenzt nichts davon: Eine 14-KB-Datei kann hundert Post-Types mal zweihundert Felder beschreiben, also zwanzigtausend register_post_meta-Aufrufe auf init bei jedem Request. Deshalb ist auch das Produkt begrenzt, bei zweitausend Registrierungen. Und mehr als die Obergrenze zu speichern wird verweigert statt stillschweigend gekürzt — die Arbeit der Kundin zu verlieren und „gespeichert“ zu melden ist schlimmer als eine Ablehnung.
WordPress nimmt einen Post-Type namens author bereitwillig an und lässt sein Archiv danach für immer unerreichbar. Drei Gruppen werden abgelehnt, jeweils mit Begründung: die Namen von WordPress selbst; Query-Variablen wie author, type und name; und alles über zwanzig Zeichen, weil die Datenbankspalte zwanzig Zeichen hat und ein längerer Name dort gekürzt wird, in PHP aber vollständig bleibt. Keiner davon scheitert sofort — sie kommen Monate später als nicht nachvollziehbarer Fehler zurück.
Text, Textbereich, Zahl, URL, Bild, Galerie, Auswahl, Radio, Checkbox und Ja/Nein. Der Textbereich läuft durch wp_kses_post, ein Link bleibt also erhalten und ein Skript nicht. URLs werden nur mit http und https angenommen. Auswahl und Radio nur mit einer der deklarierten Optionen. Bild und Galerie speichern die Anhang-ID statt der URL — damit ein Domainwechsel das Bild nicht zerstört — und die ID wird darauf geprüft, wirklich ein Anhang zu sein.
Einer zeigt ein einzelnes Feld, der andere listet alle Felder des Beitrags. Serverseitiges Rendern heißt, der Wert wird beim Aufbau der Seite gelesen und nicht in den Beitragsinhalt eingefroren; ändern Sie den Wert morgen, ändert sich die Seite mit. Für den klassischen Editor gibt es Meta-Boxen, mit einer Medienauswahl auf Basis von wp.media und ohne jQuery.
Dieser Aufruf macht einen Wert für die REST-API und damit für den Block-Editor sichtbar; sein Fehlen ist der mit Abstand häufigste Grund, warum eine selbstgebaute Meta-Box „in Gutenberg nicht funktioniert“. Die REST-Sichtbarkeit jedes Feldes folgt der des Post-Types, und ein Feld, das nicht öffentlich gelesen werden soll, kann aus REST herausgehalten werden — mit dem Hinweis auf dem Bildschirm, dass es weiterhin in der Datenbank steht und eine Administratorin es sieht.
Product, Article, LocalBusiness, Event und FAQ, gebaut aus den von Ihnen definierten Feldern und in wp_head eingefügt — ohne SEO-Plugin. Nur auf einer Einzelansicht und nur für einen Beitrag, den die Besucherin tatsächlich sehen darf: Ein passwortgeschützter oder unveröffentlichter Beitrag ergibt nichts. Kodiert wird mit JSON_HEX_TAG, damit ein Feldwert das script-Element nicht schließen kann, in dem er ausgegeben wird.
Haben die erforderlichen Eigenschaften eines Typs keinen Wert — ein Name bei Product, eine Überschrift bei Article, Name und Startdatum bei Event, Name und Adresse bei LocalBusiness —, wird nichts ausgegeben, und die Adminansicht benennt die leeren Eigenschaften. Suchmaschinen behandeln ein halbes Product als Qualitätsproblem, und nichts ist besser als halb.
Sie laden eine Datei herunter, fügen sie in die functions.php des Child-Themes ein und deaktivieren das Plugin. Post-Types, Taxonomien, die Meta-Registrierung und jeder bereits eingetragene Wert bleiben genau dort, wo sie waren; weg sind die Adminansichten, die Feldboxen und die JSON-LD-Ausgabe. Jeder Wert wird über einen Literal-Writer ausgegeben statt per Interpolation, und die Testsuite führt die erzeugte Datei aus, um zu belegen, dass ein feindliches Label als wirkungslose Zeichenkette ankommt.
Eine vollständige fa_IR-Übersetzung liegt bei — 191 von 191 Zeichenketten — und der Adminbereich lädt admin-rtl.css, wenn is_rtl() gilt. Die Ansichten sind mit echtem ARIA gebaut: Reiter, zwischen denen man mit den Pfeiltasten wechselt, beschriftete Fieldsets für Radio- und Checkbox-Gruppen, sichtbare Fokusringe und Statusfarben immer zusammen mit einem Wort. Kein jQuery — reines ES6, nur auf den eigenen Seiten des Plugins.
| Funktion | Beschreibung | Enthalten |
|---|---|---|
| Werte sind gewöhnliche Beitrags-Meta | Keine eigene Tabelle, Präfix hd_ncs_ | |
| Wiederholte Felder, eine Zeile je Wert | Ein serialisiertes Array wird nie abfragbar | |
| Zahlen als Zahlen gespeichert | meta_value_num sortiert sie: 10 nach 9 | |
| Meta-Schlüssel ohne führenden Unterstrich | Verborgene Meta ist Meta, die die Betreiberin nicht reparieren kann | |
| register_post_meta für jedes Feld | Die REST-Sichtbarkeit folgt der des Post-Types | |
| Zehn Feldtypen mit typgerechter Bereinigung | Jeder weiß, wie ein gültiger Wert für ihn aussieht | |
| Anhang-IDs werden geprüft | Bei Bild und Galerie, damit eine verirrte Zahl nicht auf eine Seite zeigt | |
| Textbereiche durch wp_kses_post | Ein Link bleibt, ein Skript nicht | |
| URLs nur mit http und https | Andere Schemata werden nicht angenommen | |
| Auswahl und Radio auf ihre Optionen begrenzt | Ein Wert außerhalb der deklarierten Liste wird nicht gespeichert | |
| Definitionen in einer JSON-Datei im uploads-Verzeichnis | Nicht in einer autoload-Option | |
| Eine Ausweichkopie in der Datenbank | Mit abgeschaltetem autoload, für ein schreibgeschütztes Dateisystem | |
| Atomares Schreiben | Temporäre Datei, dann rename; niemand sieht ein halbes Dokument | |
| Gelesen mit json_decode | Nie mit include oder unserialize | |
| Beim Zurücklesen erneut geprüft | Eine fehlerhafte Definition wird übersprungen statt an register_post_type gereicht | |
| Obergrenzen für Größe und Tiefe | Zwei Megabyte und sechzehn Verschachtelungsebenen | |
| Obergrenze für Einträge je Abschnitt | Zweihundert, mehr als jede reale Website hat | |
| Obergrenze für Post-Types mal Felder | Zweitausend Meta-Registrierungen in einem Request | |
| Über der Grenze wird das Speichern verweigert | Statt still gekürzt und als gespeichert gemeldet | |
| Wächterdateien nie über einen Symlink geschrieben | Ein toter Link kann das Schreiben nicht umleiten | |
| Das Verzeichnis muss innerhalb von uploads liegen | Der Pfad wird vor der Nutzung aufgelöst | |
| Ein nicht erratbarer Verzeichnisname | Zwölf zufällige Zeichen, weil .htaccess unter nginx nichts bewirkt | |
| Die Namen von WordPress selbst werden abgelehnt | post, page, attachment, wp_block und die übrigen | |
| Query-Variablen werden abgelehnt | author, type, name, year, order und die übrigen | |
| Namen über zwanzig Zeichen werden abgelehnt | Die Spalte hat zwanzig, und länger wird still gekürzt | |
| Ein von anderer Seite registrierter Name wird übersprungen | Statt überschrieben, und der Grund wird angezeigt | |
| Menüsymbole eingeschränkt | Ein Dashicons-Name oder eine base64-SVG-Data-URI | |
| Caches werden bei switch_blog geleert | Eine Website im Netzwerk kann nicht die Post-Types einer anderen registrieren | |
| Die Migrationssperre trägt ein Token | Damit sie nur von dem Request freigegeben wird, der sie hält | |
| Jede REST-Route hinter einer Berechtigungsprüfung | Ohne Pflichtargumente, damit ein anonymer Aufruf am permission_callback landet | |
| JSON-LD kodiert mit JSON_HEX_TAG | Ein Feldwert kann das script-Element nicht schließen | |
| Unvollständige Zuordnung: Warnung, keine Ausgabe | Statt einer halben strukturierten Angabe | |
| Erzeugtes PHP über einen Literal-Writer | Ein feindliches Label wird eine Zeichenkette, kein Code |
| Punkt | Minimum |
|---|---|
| WordPress | 6.2 oder neuer, getestet bis 6.8 |
| PHP | 8.0 bis 8.3 — beides wird geprüft, und das Plugin startet mit einer Erklärung nicht statt mit einem fatalen Fehler |
| uploads-Verzeichnis | Beschreibbar, wenn möglich; ist es das nicht, läuft alles aus der Datenbankkopie weiter, und die Werkzeug-Ansicht sagt es |
| Berechtigung | manage_options zur Verwaltung des Plugins, änderbar über hd_ncs_manage_capability |
| Abhängigkeiten | Keine — kein Composer, kein vendor-Verzeichnis, kein externer Dienst und keine eigene Datenbanktabelle |
Für eine Website, die eigene Post-Types und Felder wirklich braucht und jahrelang damit arbeiten wird: ein Katalog, ein Projektarchiv, Fallstudien, Immobilienlisten — alles, wonach Sie sortieren und filtern müssen. Wenn Sie zwei zusätzliche Felder brauchen, funktioniert alles, und dieses Plugin hat wenig zu sagen. Das zweite Publikum sind Designerinnen und Agenturen, die eine Website bauen und übergeben und die Datenstruktur nicht für immer an ein Plugin binden wollen — genau das löst der PHP-Export der Pro-Stufe.
Im Benchmark ja, in der Praxis nein. WP_Query sieht eine eigene Tabelle nicht, orderby => meta_value_num kann nicht danach sortieren, die REST-API zeigt sie nicht, und kein anderes Plugin weiß, dass es dort nachsehen müsste — jede Stelle, an der Sie den Wert nutzen wollen, braucht also eigenen Code. Gewöhnliche Meta ist etwas schwerer und funktioniert überall. Die Form zählt genauso: Ein wiederholtes Feld wird zu mehreren Zeilen unter einem Schlüssel, nicht zu einem serialisierten Array, in das kein SQL-Vergleich hineinsehen kann.
Doch, und genau deshalb wird sie wie ein abgeschicktes Formular behandelt. Alles, was in das uploads-Verzeichnis schreiben kann, kontrolliert die Datei. Also: Sie wird mit json_decode gelesen und nie mit include oder unserialize; jeder Wert läuft durch dieselbe Bereinigung wie ein Formularwert, denn ohne das könnte ein Label <img src=x onerror=…> lauten, und WordPress gibt name_admin_bar unescaped aus; es gibt Obergrenzen für die Zahl der Einträge, für verschachtelte Listen und für das Produkt aus Post-Types und Feldern, denn die Dateigröße zu begrenzen begrenzt nichts davon; und Verzeichnis und Wächterdateien werden nie über einen Symlink geschrieben, und das Verzeichnis muss innerhalb von uploads liegen.
In Ihrem uploads-Verzeichnis, in einem Ordner namens native-cpt-schema- gefolgt von zwölf zufälligen Zeichen. Der zufällige Teil ist kein Geheimnis — in der Datei stehen Feldnamen und Beschriftungen, keine Zugangsdaten —, aber .htaccess bewirkt unter nginx nichts, und ein nicht erratbarer Pfad ist das Meiste, was ein Plugin für ein Verzeichnis tun kann, das der Webserver unbedingt ausliefern will. Wächterdateien werden daneben abgelegt.
Dann läuft alles aus der Datenbankkopie weiter, und die Werkzeug-Ansicht sagt, woher gelesen wird. Diese Kopie hat autoload aus, kostet also eine separate Abfrage auf genau den Requests, die tatsächlich ein Feld ansehen. Lesen ist etwas langsamer, verloren geht nichts. Wenn das Plugin die Datei gar nicht erst anfassen soll, gibt es dafür eine Einstellung.
Weil er in eine von drei Gruppen fiel, die eine Website beschädigen. Die Namen von WordPress selbst, etwa post, page und attachment: Eine Registrierung darüber wirft keinen Fehler und lässt den eingebauten Typ seltsam werden. Query-Variablen wie author, type, name und year: Ein Post-Type mit einem solchen Namen macht sein eigenes Archiv unerreichbar. Und Namen über zwanzig Zeichen: WordPress legt den Namen in einer entsprechend kurzen Spalte ab, er wird in der Datenbank gekürzt und bleibt in PHP vollständig. Alle drei beginnen ohne Fehler und kommen Monate später als nicht nachvollziehbarer Fehler zurück, deshalb nennt das Plugin den Grund, statt sie anzunehmen.
Nichts. Die Beiträge bleiben in der Datenbank und tauchen wieder auf, sobald der Post-Type erneut definiert wird — von diesem Plugin, von der exportierten PHP-Datei oder von irgendetwas anderem. Dasselbe gilt beim Deinstallieren: Inhalte werden nie gelöscht.
Ja, und dafür ist die Speicherung so gebaut. Zahlen werden als Zahlen gespeichert, damit meta_value_num korrekt sortiert — 10 nach 9, nicht davor. Ein wiederholtes Feld ist mehrere Zeilen unter einem Schlüssel, damit meta_query jeden Wert einzeln sieht; in einem serialisierten Array ginge das nie.
Ja. Die Werte sind gewöhnliche Beitrags-Meta, und genau das liest die Dynamic-Data-Funktion jedes Builders. Nichts hier ist auf den Block-Editor zugeschnitten; die Blöcke und die klassischen Meta-Boxen sind zwei Anzeigewege von mehreren.
Ein ZIP mit allem: Post-Types und Taxonomien über die volle WordPress-Parameterfläche, die Ablehnung gefährlicher Namen, zehn Feldtypen mit abfragbarer Speicherung, register_post_meta und zwei serverseitig gerenderte Blöcke — dazu die JSON-LD-Ausgabe für Product, Article, LocalBusiness, Event und FAQ und der eigenständige PHP-Export für ein Child-Theme.
Die Adminansichten, die Feldboxen auf der Beitragsseite und die JSON-LD-Ausgabe. Es bleiben: die Post-Types, die Taxonomien, die Meta-Registrierung und jeder bereits eingetragene Wert. Sie können die Website also mit dem Plugin bauen, den Export in ein Child-Theme legen und das Plugin entfernen; die Datenstruktur bleibt keine Geisel. Der erzeugte Code wird vom Plugin selbst nie ausgeführt, und jeder Wert läuft über einen Literal-Writer, damit ein Label, das wie Code aussieht, als Zeichenkette ankommt.
Voreingestellt wird nichts entfernt. Wer ein Plugin deinstalliert, probiert oft ein anderes aus oder wechselt den Hoster, und ein Plugin, das dabei Definitionen und Feldwerte mitnimmt, hat stundenlange Arbeit vernichtet, um die niemand gebeten hat. Es gibt eine Einstellung, die Sie bewusst suchen und einschalten müssen; ist sie an, entfernt das Löschen des Plugins die Definitionen, die Einstellungen und die Feldwerte. Selbst dann werden die Beiträge nie gelöscht.
Fehlerbehebung im Plugin, Hilfe bei Installation und Einrichtung, Unterstützung beim Entwurf von Post-Types und Feldgruppen sowie bei den Schema-Zuordnungen. Eigener Template-Code zur Anzeige der Werte, die Optimierung der Website selbst und Probleme, die von anderen Themes oder Plugins verursacht werden, liegen außerhalb des Supports und werden separat vereinbart.