Ein benutzerdefinierter Beitragstyp ist erforderlich, wenn Inhalte eine eigene Struktur, einen eigenen Lebenszyklus, eigene Taxonomien und eigene Ausgabevorlagen aufweisen. Beispielsweise ist es praktischer, Portfolio-Projekte oder Dienstleistungen nicht als reguläre Beiträge und Seiten, sondern als separate Entitäten mit eigenen URLs, Feldern und Bearbeitungsregeln zu speichern.

Inhalt

In diesem Artikel erfahren Sie, wie die Entwicklung von benutzerdefinierten Beitragstypen in WordPress funktioniert: vom Datendesign bis zur Registrierung. register_post_type, Einstellungen umschreiben, REST-API-Unterstützung durch show_in_rest und die ACF-Felder zu verknüpfen. Vor der Implementierung sollte die Lösung auf einer Testumgebung mit Backup getestet werden. Dabei sind die WordPress-Version, das aktive Theme, die Plugins und die Zugriffsrechte zu berücksichtigen.

Wann CPT benötigt wird und wie es mit dem Design, den Blöcken und der API zusammenhängt, wird in folgendem Abschnitt gezeigt: Überprüfung der individuellen WordPress-Entwicklung. Hier konzentrieren wir uns auf das Datenmodell.

Was ist ein benutzerdefinierter Beitragstyp?

Worin unterscheidet sich ein benutzerdefinierter Beitragstyp von Seiten und Beiträgen?

Ein benutzerdefinierter Beitragstyp (CPT) ist ein spezieller Beitragstyp in WordPress für Inhalte mit eigener Struktur und eigenem Zweck. Er ist nützlich, wenn sich Inhalte logisch von Blogbeiträgen und regulären Seiten unterscheiden, wie beispielsweise Projekte, Dienstleistungen, Immobilien, Spezialisten oder Stellenangebote.

Standardmäßig verwendet CPT das Standard-WordPress-Speichersystem und wird durch einen separaten Wert definiert. Beitragstyp. Dies erfordert nicht unbedingt eine neue Datenbanktabelle. Mit dem benutzerdefinierten Beitragstyp von WordPress können Sie Entitäten im Administrationsbereich trennen und ihnen eigene Vorlagen, Kategorien und Darstellungsregeln zuweisen.

Wenn Standardaufzeichnungen nicht ausreichen

Wählen Sie CPT, wenn Ihre Inhalte einen separaten Lebenszyklus haben. Beispielsweise veröffentlichen Sie einen Artikel nach Datum, aktualisieren aber einen Dienst bei geänderten Bedingungen und zeigen ihn in einem permanenten Katalog an. Die Vermischung dieser Entitäten erschwert Filterung, Verwaltung und Vorlagenerstellung.

Kriterium	Regelmäßige Aufzeichnung	Seite	CPT
Hauptzweck	Neuigkeiten und Artikel	Permanente Bereiche des Geländes	Ähnliche Unternehmen
Organisation	Kategorien, Schlagwörter, Datum	Seitenhierarchie	Benutzerdefinierte Taxonomien und Felder
Vorlagen	Vorlage für allgemeine Veröffentlichungen	Seitenvorlage	Separate Listen- und Objektvorlagen
Editierbarkeit	Geeignet für redaktionelle Abläufe	Praktisch für einzelne Inhalte	Anpassbar für eine bestimmte Entität

CPT ist nützlich, wenn Sie spezielle Taxonomien, eine wiederholbare Kartenstruktur und eine separate Ansicht im Admin-Bereich benötigen. Zusätzliche Merkmale können als Metadaten gespeichert werden; es wird häufig für eine benutzerfreundliche Bearbeitungsoberfläche verwendet. WordPress ACF-Felder. In diesem Fall sollte die Auswahl der Felder auf Grundlage der Ziele des Inhalts erfolgen und nicht «für die Zukunft» hinzugefügt werden.

Wenn sich nur das Erscheinungsbild einer einzelnen Seite ändert, ist ein neuer Beitragstyp möglicherweise übertrieben. Manchmal genügt eine Seitenvorlage, eine Blockvorlage oder eine bestehende Taxonomie. Berücksichtigen Sie zukünftige URLs im Voraus: Änderungen an einer bereits indexierten Struktur können Weiterleitungen erforderlich machen.

Beispiele: Fälle und Dienstleistungen

Für Projektportfolios dient ein separater WordPress-Beitragstyp dazu, Projekttitel, Branche, abgeschlossene Projekte und zugehörige Bilder zu speichern. Mithilfe der Taxonomie lassen sich Projekte nach Kundenbereich oder Schwerpunkt gruppieren. Sie können ein allgemeines Portfolio-Archiv und für jedes Projekt eine separate Projektkarte anzeigen, ohne diese mit Artikeln zu vermischen.

Für einen Servicekatalog eignet sich CPT, wenn jede Dienstleistung eine ähnliche Grundstruktur aufweist: Beschreibung, Nutzen, Phasen, zugehörige Spezialisten oder Projekte. Separate Taxonomien sind sinnvoll, um nach Bereich oder Kundentyp zu gruppieren.

Vor der Wahl einer Architektur sollten drei Fragen geklärt werden: Besitzt die Entität einen eigenen Lebenszyklus? Benötigt sie separate Taxonomien und Templates? Kann der Editor die Daten ohne manuelle Layoutbearbeitung verarbeiten? Die Kompatibilität der Lösung mit dem verwendeten Theme, den Plugins und der WordPress-Version sollte separat geprüft werden.

Entwerfen Sie die Struktur

Entwurf von Datensatzfeldtypen, Taxonomien und Beziehungen

Bevor Sie einen benutzerdefinierten Beitragstyp registrieren, legen Sie fest, welche Daten gespeichert werden sollen, wie Redakteure diese verwalten und wo die Inhalte auf der Website erscheinen sollen. Diese Struktur hilft zu vermeiden, dass einzelne Inhaltseigenschaften in Kategorien, benutzerdefinierte Felder oder themenfremde Seiten umgewandelt werden.

Beitragstypen und Taxonomien

Erstellen Sie einen separaten Beitragstyp, wenn der Inhalt einen eigenen Lebenszyklus, eigene Vorlagen und Klassifizierungsregeln hat. Portfolio-Projekte werden beispielsweise regelmäßig hinzugefügt und nach Branche und Technologie gefiltert, erscheinen aber nicht im Newsfeed. Der benutzerdefinierte Beitragstyp «Projekte» ist für diese Projekte geeignet, während «Branchen» und «Technologien» als Taxonomien konfiguriert werden können.

Für einen Servicekatalog sollte zunächst der Umfang geprüft werden. Bei mehreren Services mit jeweils eigener Seitenstruktur reichen Standardseiten möglicherweise aus. CPT (Customer Post-Term) eignet sich, wenn Services systematisch gruppiert, in Archiven angezeigt, mit Spezialisten verknüpft oder über eine API übertragen werden sollen. Regionen werden häufiger als Taxonomien oder Felder denn als separate Datensatztypen modelliert.

Legen Sie permanente URLs im Voraus fest. Sorgen Sie für stabile und von Marketingsprache unabhängige Systemnamen. Entscheiden Sie, ob ein gemeinsames Archiv benötigt wird, welche Seiten indexiert werden sollen und ob es Duplikate zwischen Archiven, Taxonomien und Landingpages geben wird.

Verwenden Sie eine Taxonomie, wenn ein Wert in mehreren Datensätzen wiederholt vorkommt und archiviert oder gefiltert werden muss. Wenn ein Parameter spezifisch für einen bestimmten Datensatz ist – beispielsweise der Budgetbereich eines Projekts oder die Leistungsdauer – ist ein Feld sinnvoller.

Felder und Zugriffsrechte

Beschreiben Sie jedes Feld, bevor Sie den Editor konfigurieren. Geben Sie Name, Format, Pflichtfeld, zulässige Werte und Ausgabeverzeichnis an. Für ein Portfolio könnten dies beispielsweise Kunde, Jahr, Link zum Ergebnis und Galerie sein. Für eine Dienstleistung könnten dies eine Kurzbeschreibung, die einzelnen Phasen, das erwartete Ergebnis und die beteiligten Spezialisten sein. ACF vereinfacht die Erstellung von Feldschnittstellen, ersetzt aber weder Schema-Design, Validierung noch Datenmaskierung bei der Ausgabe.

Definieren Sie außerdem Benutzerrollen: Wer darf Beiträge erstellen, bearbeiten, veröffentlichen und löschen? Verlassen Sie sich nicht allein auf das Ausblenden von Elementen in der Administrationsoberfläche – die Einschränkungen sollten über die WordPress-Berechtigungen überprüft werden. Wenn Sie Daten an die REST-API übertragen möchten, trennen Sie öffentliche und private Felder im Voraus.

Checkliste für Datenstrukturen:

Inhalte haben einen separaten Lebenszyklus und einen eindeutigen Entitätsnamen;
Taxonomien dienen der wiederholbaren Klassifizierung, Felder werden für Datensatzeigenschaften verwendet;
Archive, Einzelvorlagen und URL-Logik sind definiert;
Art, Pflichtfeld und zulässige Werte jedes Feldes werden beschrieben;
zugewiesene Rechte zum Erstellen, Bearbeiten, Veröffentlichen und Löschen;
Es wird darauf hingewiesen, welche Daten über die API offengelegt werden können;
Es wurde geprüft, ob doppelte Seiten oder widersprüchliche URLs vorhanden sind.

Prüfen Sie vor der Implementierung, ob das Schema mit Ihrem aktuellen Theme, Ihren Plugins und Ihrer WordPress-Version kompatibel ist: Ohne diese Prüfung kann die Kompatibilität nicht gewährleistet werden. Testen Sie Änderungen zunächst auf einer Testumgebung Ihrer Website und erstellen Sie regelmäßig Backups Ihrer Produktionsdatenbank.

Eintragsart registrieren

Benutzerdefinierten Beitragstyp registrieren und auf das Kontrollfeld zugreifen

Plugin oder benutzerdefinierter Code

Sie können einen benutzerdefinierten WordPress-Beitragstyp entweder über den Plugin-Builder oder mit eigenem Code registrieren. Das Plugin ist praktisch, wenn Sie eine Benutzeroberfläche für die grundlegende Einrichtung benötigen und das Team keine Unterstützung für PHP-Code plant. Prüfen Sie jedoch vor der Auswahl die Kompatibilität der Lösung mit Ihrer aktuellen WordPress-Version, Ihrem Theme und anderen Plugins.

Benutzerdefinierter Code ist empfehlenswert, wenn der Beitragstyp Teil der Website-Architektur ist. Platzieren Sie ihn in einem separaten, funktionalen Plugin und nicht im Theme. So bleiben die Beiträge nach Designänderungen im Kontrollfeld zugänglich. Führen Sie die Änderungen zunächst in einer Testkopie durch und sichern Sie die Dateien und die Datenbank.

Funktion register_post_type() wird normalerweise bei einer Veranstaltung aufgerufen init. Der Systemtypname muss eindeutig sein, darf maximal 20 Zeichen lang sein und darf nur Kleinbuchstaben, Zahlen, Bindestriche oder Unterstriche enthalten. Fügen Sie ein eigenes Präfix hinzu, um Konflikte zu vermeiden.

function ua_site_register_project_cpt() {
    $labels = array(
        'name'          => 'Проекты',
        'singular_name' => 'Проект',
        'add_new_item'  => 'Добавить проект',
        'edit_item'     => 'Редактировать проект',
    );

    register_post_type(
        'ua_project',
        array(
            'labels'             => $labels,
            'public'             => true,
            'publicly_queryable' => true,
            'show_ui'            => true,
            'show_in_rest'       => true,
            'has_archive'        => true,
            'rewrite'            => array(
                'slug'       => 'projects',
                'with_front' => false,
            ),
            'supports'           => array(
                'title',
                'editor',
                'thumbnail',
                'excerpt',
            ),
            'capability_type'    => 'post',
            'map_meta_cap'       => true,
        )
    );
}
add_action( 'init', 'ua_site_register_project_cpt' );

show_in_rest Öffnet den Datensatztyp für die REST-API und ist für die Funktion des Blockeditors erforderlich. In diesem Beispiel werden Berechtigungen von regulären Datensätzen übernommen. Wenn Projekte nur bestimmte Rollen bearbeiten müssen, konfigurieren Sie Ihre eigenen Berechtigungen und testen Sie diese mit current_user_can(). Daten aus benutzerdefinierten Feldern müssen beim Speichern validiert und bei der Ausgabe maskiert werden.

Slugs und permanente Links

Parameter umschreiben definiert die URL. Für Typ ua_project öffentlicher Slug ausgewählt Projekte, Das Archiv befindet sich also unter /Projekte/, und ein separater Eintrag - /projects/project-name/. Systemname und URL-Slug müssen nicht übereinstimmen.

Prüfen Sie vor der Veröffentlichung, ob der Slug bereits von einer Seite, Kategorie, einem Produkt oder einem anderen Inhaltstyp belegt ist. Für einen Servicekatalog können Sie analog dazu einen Systemnamen mit einem Präfix und einer benutzerfreundlichen URL verwenden. /services/. Am besten verwendet man lateinische Zeichen für den Slug, hält ihn kurz und ändert ihn nur, wenn es unbedingt notwendig ist: Nach einer Änderung sind Weiterleitungen von den alten Adressen erforderlich.

Nach der ersten Registrierung oder Änderung umschreiben Aktualisieren Sie Ihre Permalink-Regeln: Speichern Sie die entsprechende Einstellungsseite oder rufen Sie die entsprechende Funktion auf. flush_rewrite_rules() Einmal pro Plugin-Aktivierung. Rufen Sie diese Funktion nicht bei jeder Anfrage auf – das verursacht unnötigen Aufwand.

Die Verfügbarkeit einer URL bestimmt nicht deren Indexierung. Direktive kein Index, Überprüfen Sie URL, Canonical-URL und Sitemap separat in den SEO-Einstellungen. Öffnen Sie vor dem Start das Archiv und einen separaten Beitrag ohne Anmeldung, um sicherzustellen, dass keine 404-Fehler auftreten, und überprüfen Sie die Routen nach der Aktualisierung des Themes oder der Plugins erneut.

Konfigurieren Sie den Editor und die Ausgabe.

Der Pfad der CPT-Daten vom Editor zur Seite und zum Archiv

REST-API-Unterstützung

Damit Ihr benutzerdefinierter Beitragstyp mit dem Block-Editor funktioniert und über die WordPress REST API zugänglich ist, geben Sie bitte bei der Registrierung Folgendes an: ''show_in_rest' => true. Anschließend erstellt WordPress standardmäßige REST-Routen zum Lesen und Verwalten von Objekten unter Berücksichtigung der Berechtigungen des aktuellen Benutzers.

Der Werkzeugsatz des Editors wird durch den Parameter bestimmt. unterstützt. Ein Portfolio kann einen Titel, einen Fließtext, ein Vorschaubild, eine Zusammenfassung und Überarbeitungen erfordern:

''supports' => array( 'title', 'editor', 'thumbnail', 'excerpt', 'revisions' )

Behalten Sie im Servicekatalog nur die tatsächlich verwendeten Elemente bei. Wenn beispielsweise Beschreibung, Preis und Dauer in strukturierten ACF-Feldern vorliegen, duplizieren Sie diese nicht im Haupteditor. Dies vereinfacht die Dateneingabe und verringert das Risiko von Inkonsistenzen.

Die Verfügbarkeit von ACF-Feldern über die API hängt von den Feldgruppeneinstellungen, der Plugin-Version und der Projektkonfiguration ab. Überprüfen Sie die tatsächliche JSON-Antwort in einer Testumgebung, anstatt Kompatibilität anzunehmen. Definieren Sie für benutzerdefinierte REST-Felder das Schema, die Berechtigungsprüfung, die Validierung und die Verarbeitung von Eingabewerten. Öffentlicher Lesezugriff auf einen Datensatz bedeutet nicht, dass anonymer Zugriff zulässig ist.

Archiv- und Einzeleintragsvorlage

Für einen Typ mit einer Kennung Projekt Dateien im Thema erstellen single-project.php für ein separates Projekt und archive-project.php für die Projektliste. Falls keine speziellen Dateien vorhanden sind, durchsucht WordPress weiterhin die Template-Hierarchie und verwendet gegebenenfalls gängige Templates. single.php, archive.php oder index.php.

Das Archiv ist nur verfügbar, wenn es entsprechend konfiguriert ist. hat_Archiv. Die URL hängt auch von Parametern ab. umschreiben. Bevor Sie Ihre URL-Struktur ändern, erstellen Sie eine Sicherungskopie und testen Sie die Ergebnisse auf einer Testumgebung: Durch die Änderung des Slugs können alte, fehlerhafte URLs entstehen, die Weiterleitungen erfordern.

Zeigen Sie in Ihrem Portfolio das Titelbild, den Titel, die Branche oder eine andere Kategorisierung sowie einen Link zur Detailseite an.
Bieten Sie in Ihrem Servicekatalog ein übersichtliches Archiv, eine Taxonomiefilterung und eine einheitliche Kartenvorlage an.
Klartext maskieren über esc_html(), URL - via esc_url(), und das aufgelöste HTML ist durch wp_kses_post().
Nach weiteren Zyklen werden die globalen Schreibdaten wiederhergestellt mithilfe von wp_reset_postdata().

Das Ändern einer Vorlage allein garantiert nicht, dass eine Seite erneut gecrawlt wird. Wenn sich URLs, kanonische URLs oder die Barrierefreiheit von Inhalten geändert haben, überprüfen Sie Ihre Sitemap, Weiterleitungen, HTTP-Statuscodes und Indexierungsregeln. Prüfen Sie außerdem die Kompatibilität von Vorlage, REST-API und ACF mit Ihren WordPress-Versionen, Ihrem Theme und Ihren Plugins.

Vorveröffentlichungsprüfung

Bevor Sie einen benutzerdefinierten Beitragstyp auf eine Live-Website übertragen, testen Sie ihn in einer Testumgebung und sichern Sie die Dateien und die Datenbank. Die Kompatibilität kann nicht im Voraus garantiert werden: Die Ergebnisse hängen von der WordPress-Version, dem aktiven Theme, den Plugins, den Permalink-Regeln und der Serverkonfiguration ab.

Bitte füllen Sie die folgende Checkliste aus:

Anmeldung: Stellen Sie sicher, dass der Beitragstyp in den richtigen Abschnitten des Kontrollfelds angezeigt wird und dass seine System-ID nicht mit dem Seitennamen, der Taxonomie oder einer bestehenden Rewrite-Regel in Konflikt steht.
URL: Öffnen Sie einen einzelnen Beitrag und, falls aktiviert, das Archiv. Prüfen Sie, ob die URLs lesbar sind, die Seitennummerierung funktioniert und keine 404-Fehler auftreten. Speichern Sie die Permalinks nach Änderungen der Rewrite-Einstellungen einmalig neu oder aktualisieren Sie die Regeln bei der Aktivierung des Plugins. Vermeiden Sie eine Aktualisierung bei jeder Anfrage.
Kanonisch: Überprüfen Sie die primäre URL, die das SEO-Plugin für das Archiv und die einzelnen Inhalte angibt. Wenn Sie gerade erst anfangen, Was ist eine kanonische URL?, Man kann es sich als einen Hinweis an die Suchmaschine auf die bevorzugte Version der Seite unter den verfügbaren Duplikaten vorstellen.
Rechte: Melden Sie sich als Administrator, Redakteur oder anderes Projektmitglied an. Benutzer sollten nur Inhalte sehen, erstellen, bearbeiten und löschen können, für die sie die entsprechenden Berechtigungen besitzen. Überprüfen Sie bei der Formularverarbeitung zusätzlich die Berechtigungen und die Nonce.
Daten: Prüfen Sie erforderliche und optionale ACF-Felder, leere Werte, Bilder und sich wiederholende Blöcke. Validieren und bereinigen Sie Eingabedaten und wenden Sie kontextsensitives Escaping auf die Ausgabe an: Text, Attribute, URLs oder HTML.
REST-API: verwendet show_in_rest, Prüfen Sie, ob Datensätze über die API abgerufen werden, ob die erforderlichen Felder zugänglich sind und ob private Daten vor unberechtigten Anfragen geschützt sind. Der Parameter selbst macht benutzerdefinierte Felder nicht automatisch öffentlich.
Vorlagen: Öffnen Sie einzelne Seiten, Archive, Suchergebnisse und zugehörige Taxonomien auf Mobilgeräten und Desktop-Computern. Prüfen Sie, ob Einträge ohne Bild, Beschreibung oder zugewiesenen Begriff vorliegen.
Integrationen: Testen Sie Caching, SEO-Plugin, Mehrsprachigkeit, Suche und Page-Builder separat, sofern diese im Projekt verwendet werden.

Nach der Migration sollte der Test in der Produktionsumgebung wiederholt werden. Auch wenn Test- und Produktionsumgebung ähnlich sind, können sich PHP-Versionen, Cache, Webserver und Routing-Regeln unterscheiden. Veröffentlichen Sie zunächst einen Testbeitrag, prüfen Sie URL und API und laden Sie anschließend den Hauptinhalt hoch.

Dokumentieren Sie den CPT-Identifikator, den Slug, die Taxonomie, die Feldgruppe und die Zugriffsregeln in der Projektdokumentation. Dies vereinfacht die Wartung und verringert das Risiko, dass zukünftige Entwicklungen benutzerdefinierter Beitragstypen bestehende URLs oder Datenstrukturen beeinträchtigen.

Offizielle Dokumentation: Registrierung benutzerdefinierter Beitragstypen.