Erstellen eines benutzerdefinierten Beitragstyps als Plugin? Warum?

Ich habe mit dem Erstellen eines benutzerdefinierten Beitragstyps als Plugin experimentiert (da ich dies an verschiedenen Stellen empfohlen habe).

Aber ich habe eine Frage nicht nach dem Wie , sondern nach dem Warum , CPTs als Plugin zu erstellen.

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

Aber...

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

Wenn ich das richtig verstehe,

1. Wenn ich das Plugin deaktiviere: Ich muss die und Seiten noch entfernen (oder verstecken oder so) .archive-cpt.phpsingle-cpt.php
2. Wenn ich das Thema wechsle : Ich muss diese beiden Seiten noch zum neuen Thema hinzufügen. Recht?

Ich habe noch nicht einmal das Problem des Hinzufügens eines CPT zur Standardschleife angesprochen (und seine Auswirkungen auf Plugin-basierte Cpt's).

Warum also ein CPT- Plugin?

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 ein Großteil Ihrer Fragen auf einem Missverständnis der Vorlagenhierarchie beruht. Fast, aber nicht ganz, jede Vorlagendatei, die Sie gesehen haben, ist optional.

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

http://codex.wordpress.org/Template_Hierarchy

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

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

Nr archive.phpwird verwendet , und wenn das nicht funktioniert , dannindex.php

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

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

1. Und diese Dateien müssen im Thema erstellt werden , oder?

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

1. Wenn ich das Plugin deaktiviere: Ich muss die und Seiten noch entfernen (oder verstecken oder so) .archive-cpt.phpsingle-cpt.php

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.

Das Thema wird nicht geladen, wenn die Konstante SHORTINITauf TRUE(benutzerdefinierte AJAX-Handler, Importeure oder APIs) festgelegt ist. Dann können einem solchen benutzerdefinierten Beitragstyp oder einer solchen benutzerdefinierten Taxonomie keine Beiträge hinzugefügt werden.

Die Vorlagen sind die Ansichten für den benutzerdefinierten Inhalt. Sie sollten die Logik nicht definieren oder sich darauf verlassen.

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

Nach dem Deaktivieren eines Plugins 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 pro Site aktiv ist und nicht im gesamten Netzwerk. Themenposttypen sind wirklich schwer zu übersetzen.

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