web-dev-qa-db-de.com

Warum der Init-Hook für benutzerdefinierte Beitragstypen

Ich habe eine Frage zu this documentation.

Warum sollte ich einen benutzerdefinierten Beitragstyp in der Init-Funktion registrieren, wie in den Dokumenten vorgeschlagen? Geht das nur, wenn ich kein Plugin benutze?

Soweit ich weiß, wird init jedes Mal ausgeführt, wenn WordPress/is-loaded vom Benutzer ausgeführt wird. Bedeutet dies nicht, dass die Website bei jedem Besuch unnötigerweise einen neuen Beitragstyp neu registriert? Warum nicht (wenn Sie ein Plugin erstellen) registrieren Sie den Beitragstyp in require_once plugin_dir_path( __FILE__ ), sobald das Plugin aktiviert wird?

Würde das nicht auch die Site beschleunigen? Oder interpretiere ich init() falsch? Sicherlich bleibt der benutzerdefinierte Beitragstyp irgendwo in der Datenbank erhalten, muss also nicht bei jeder init() aufgerufen werden?

Hier ist das Beispiel für einen benutzerdefinierten Beitragstyp aus den Dokumenten, das init() verwendet:

function create_post_type() {
  register_post_type( 'acme_product',
    array(
      'labels' => array(
        'name' => __( 'Products' ),
        'singular_name' => __( 'Product' )
      ),
      'public' => true,
      'has_archive' => true,
    )
  );
}
add_action( 'init', 'create_post_type' );
1

Die Funktion register_post_type sollte bei jeder Anforderung von WP ausgeführt werden. Standardposttypen haben diese Anforderung nicht. Sie können Ihren Code unverändert im MU-Plugin verwenden. Erstellen Sie einfach eine .PHP-Datei mit diesem Code und platzieren Sie sie im mu-plugins-Unterordner von wp-content. Sie müssen keine Standard-Plugin-Header bereitstellen.

Sicherlich bleibt der benutzerdefinierte Beitragstyp irgendwo in der Datenbank erhalten, muss also nicht bei jedem init () aufgerufen werden?

Nein, ist es nicht. Warum sollte es sein müssen? Ein benutzerdefinierter Beitragstyp ist eine Handvoll Variablen, die WordPress verwendet, um die Benutzeroberfläche für Daten einzurichten, die mit diesem Beitragstyp in der Datenbank gespeichert wurden.

Wenn sich die Daten häufig ändern würden und die Änderungen dauerhaft sein müssten, müssten sie in der Datenbank gespeichert werden, aber die Post-Typen ändern sich nach der Entwicklung nicht.

In Anbetracht dessen würde das Speichern der Einstellungen für den Beitragstyp in der Datenbank nur schaden die Leistung beeinträchtigen, da WordPress die Datenbank abfragen müsste, um die Einstellungen für registrierte Beitragstypen bei jedem Seitenaufruf abzurufen, was langsamer ist als nur die Ausführung den Registrierungscode jedes Mal (die sich nur eine Handvoll Variablen merken).

Der teuerste Teil der Registrierung eines Beitragstyps ist die Generierung seiner Umschreiberegeln. Aus diesem Grund werden diese in der Datenbank gespeichert und die Umschreiberegeln sollten in die Aktivierungs- und Deaktivierungs-Hooks geschrieben werden.

3
Jacob Peattie