it-swarm.com.de

Einen benutzerdefinierten Beitragstyp als Plugin erstellen? Warum?

Ich habe versucht, einen benutzerdefinierten Beitragstyp als Plug-in zu erstellen (da dies an verschiedenen Stellen empfohlen wurde).

Aber ich habe eine Frage nicht über das Wie , sondern das Warum CPTs als Plugin zu erstellen.

Ja ... Das Hinzufügen des CPT als Plugin hält meine functions.php schön aufgeräumt.

Aber...

  1. Angenommen, ich habe has_archive aktiviert, ich muss noch archive-cpt.php erstellen, oder?
  2. Außerdem: Um die CPT anzuzeigen, muss ich eine benutzerdefinierte Schleife erstellen, also muss ich immer noch single-cpt.php erstellen ... richtig?
  3. Und diese Dateien müssen erstellt werden im Thema , richtig?

Wenn ich das richtig verstehe,

  1. Wenn ich das Plugin deaktiviere: Ich immer noch muss die Seiten archive-cpt.php und single-cpt.php entfernen (oder verstecken).
  2. Wenn ich Themen wechseln : Ich muss noch diese beiden Seiten in das neue Thema hinzufügen. Recht?

Ich habe noch nicht einmal das Problem des Hinzufügens eines CPT zur Standardschleife angesprochen (und dessen Auswirkungen auf Plug-in-basierte CPTs).

Warum also ein CPT Plugin?

7
sleeper

die Antwort von toscho ist in Bezug auf die technischen Gründe für die Definition Ihres CPT in einem Plugin richtig, aber es scheint mir, dass viele Ihrer Fragen auf ein Missverständnis der Vorlagenhierarchie zurückzuführen sind. Fast, aber nicht ganz, jede Vorlagendatei, die Sie gesehen haben, ist optional.

Mit Ausnahme der grundlegenden Vorlagendatei index.php können Theme-Entwickler wählen, ob sie eine bestimmte Vorlagendatei implementieren möchten oder nicht. Wenn WordPress keine Vorlagendatei mit einem passenden Namen finden kann, wird zum nächsten Dateinamen in der Hierarchie gesprungen. Wenn WordPress keine passende Vorlagendatei findet, wird index.php (die Homepage-Vorlagendatei des Themas) verwendet.

http://codex.wordpress.org/Template_Hierarchy

WordPress verwendet die speziellen spezialisierten Dateien, wenn sie existieren, greift jedoch auf eine andere Datei zurück - letztendlich index.php -, wenn es keine speziellen Dateien gibt. Ihr Theme muss nichts Besonderes implementieren, um die CPTs Ihres Plugins zu verarbeiten oder zu kompensieren. Das Thema kann aber nicht muss.

  1. Angenommen, ich habe has_archive aktiviert, ich muss noch archive-cpt.php erstellen, oder?

archive.php wird verwendet und wenn das fehlschlägt, dann index.php

  1. Außerdem: Um die CPT anzuzeigen, muss ich eine benutzerdefinierte Schleife erstellen, also muss ich immer noch single-cpt.php erstellen ... richtig?

Wieder nein. Gleicher Grund. single.php wird verwendet und wenn nicht, index.php.

  1. Und diese Dateien müssen erstellt werdenim Theme, richtig?

Ja, aber sie sind optional. Du brauchst sie überhaupt nicht.

  1. Wenn ich das Plugin deaktiviere: Inochmuss die Seiten archive-cpt.php und single-cpt.php entfernen (oder verstecken).

Nein, Sie müssen nichts tun. Die Vorlagen werden nicht verwendet.

  1. Wenn ich das Thema wechsle : Ich muss diese beiden Seiten noch zum neuen Thema hinzufügen. Recht?

Falsch. Die Vorlagen sind optional. Sie benötigen sie nur, wenn Sie eine benutzerdefinierte Anzeige für den Beitragstyp wünschen.

Wenn Sie verstehen, dass das Thema und das CPT nicht so eng miteinander verbunden sind, wie es Ihre Frage vermuten lässt, sollte ein Teil der anderen Logik etwas sinnvoller sein.

4
s_ha_dum

Das Design wird nicht geladen, wenn die Konstante SHORTINIT auf TRUE gesetzt ist (benutzerdefinierte AJAX Handler, Importer oder APIs). Zu einem solchen benutzerdefinierten Beitragstyp oder einer solchen Taxonomie können dann keine Beiträge hinzugefügt werden.

Die Vorlagen sind die views für den benutzerdefinierten Inhalt. Sie sollten nicht die Logik definieren oder sich auf diese verlassen.

Außerdem kann der Benutzer nach einem Themenwechsel nicht mehr auf den Inhalt des Beitragstyps zugreifen und ihn ändern, da es ohne die Registrierung keine Benutzeroberfläche geben würde.

Nachdem Sie ein plugin deaktiviert haben, müssen Sie das Thema nicht mehr ändern. Die Vorlagen werden einfach nicht mehr verwendet.

Update: Ein weiterer Vorteil von Plugins ist die Möglichkeit, sie netzwerkweit zu aktivieren. Ich bin der Hauptentwickler für Multilingual Press und wir bieten unseren Benutzern eine Funktion zum Übersetzen und Verbinden von benutzerdefinierten Posts. Dies kann jedoch nicht funktionieren, wenn sie an ein Thema gebunden sind, da ein Thema immer aktiv ist pro Site, nicht im gesamten Netzwerk. Themenposttypen sind wirklich schwer zu übersetzen.

Siehe auch: Wo soll ich meinen Code ablegen: plugin oder functions.php?

3
fuxia