it-swarm.com.de

Warum benötigt ein benutzerdefinierter Beitragstyp die Einstellung "hierarchische" Argumente?

Ich habe Probleme, einige Dinge über CPTs zu verstehen, und könnte Hilfe gebrauchen. Ich kann sehen, dass Taxonomien oft hierarchisch sein müssen, kann aber nicht sehen, wie/wann ein benutzerdefinierter Beitragstyp wäre.

ich habe ein CPT namens "Projekte". Für diesen Posttyp ist eine Taxonomie mit dem Namen "Felder" registriert. Unter 'Felder' habe ich viele Unterpunkte wie:

  • 'Dokumentarfilme'
  • 'Dokumentationen'> 'Selbstverpflichtungen'
  • 'Dokumentationen'> 'Klassik'
  • 'Corporate'
  • 'Corporate'> 'Digitales Marketing'
  • usw...

Um ein Projekt unter 'Dokumentationen'> 'Klassisch' anzuzeigen, verwende ich diese URL: mydomain.com/field/classic/

Hier habe ich ungefähr 30 Fragen :) aber ich werde nur die beiden dringendsten Fragen stellen:

  1. Warum und wie sollte das CPT "Projekte" jemals hierarchisch sein?
  2. Ist es möglich, Elemente im Feld "Klassisch" wie folgt anzuzeigen: mydomain.com/projects/classic (mydomain.com/projects zeigt alle Elemente an, bohrt jedoch weitere Brüche)

Für jede Hilfe dankbar, ich habe ungefähr 3 Stunden damit gespielt und gelesen und kann es nicht fassen!

Vielen Dank!

Unten ist mein (zugeschnittener) Code als Referenz:

function register_cpt_projects() {
$labels = array(
    'name' => _x('Projects', 'projects'),
    // all other labels etc..
);

$args = array(
    'labels' => $labels,
    'hierarchical' => true,
    'supports' => array('title', 'editor', 'author', 'thumbnail'),
    'taxonomies' => array('field'),
    'public' => true,
    'show_ui' => true,
    'show_in_menu' => true,
    'show_in_nav_menus' => true,
    'publicly_queryable' => true,
    'exclude_from_search' => false,
    'has_archive' => true,
    'query_var' => true,
    'can_export' => true,
    'rewrite' => true,
    'capability_type' => 'post'
);
register_post_type('projects', $args);
}

add_action('init', 'register_cpt_projects');

function create_projects_tax(){
    register_taxonomy('field', 'projects', array(
       'hierarchical' => true,
       'label' => 'Fields'
    ));
}
add_action('init', 'create_projects_tax');
3

Wenn Sie zwei Inhaltsobjekte mit einer ähnlichen Oberfläche oder gemeinsamen Eigenschaften haben, haben Sie einen guten Kandidaten für hierarchische Beitragstypen.

Nehmen Sie als Beispiel places (siehe diese Antwort ):

  • Asien
  • Europa
    • Deutschland
      • Berlin
    • Österreich
      • Wien

Jeder Ort hat ähnliche Metadaten: Bevölkerung, Geokoordinaten, gesprochene Sprachen. Sie können dieselbe Schnittstelle einfach wiederverwenden.

Wenn Sie für jede Art von Ort einen eigenen benutzerdefinierten Beitragstyp erstellen, wird WordPress angezeigt. Fehlende Beziehungstabelle von Beitrag zu Beitrag .

3
fuxia

Ein benutzerdefinierter Beitragstyp benötigt nur die hierarchische Einstellung, wenn sich der Beitragstyp wie Seiten verhalten soll.

Wenn Sie in der Lage sein möchten, ein übergeordnetes Element auszuwählen und die Metabox für die Menüreihenfolge zu verwenden, müssen Sie dem unterstützten Array auch 'Seitenattribute' hinzufügen.

Mit dem hierarchischen Argument können Sie auch hierarchische Beitragstypen behandeln, die sich von anderen unterscheiden, indem Sie das bedingte Tag is_post_type_hierarchical() verwenden. Es unterstützt Post-Objekt, Post-Typ-Name oder Post-ID als einzelnen Parameter.

Ist es möglich, Elemente im Feld "Klassisch" wie folgt anzuzeigen: mydomain.com/projects/classic (mydomain.com/projects zeigt alle Elemente an, bohrt jedoch weitere Brüche)

Mit dem Argument rewrite können Sie festlegen, wie URLs für einzelne Posts angezeigt werden:

slug: Der Slug, den Sie Ihren Posts voranstellen möchten.
with_front: Gibt an, ob Ihr Beitragstyp die vordere Basis aus Ihren Permalink-Einstellungen verwenden soll.

'rewrite' => array( 'slug' => 'classic', 'with_front' => false ),

würde deine URLs für einzelne Projektbeiträge so aussehen lassen:

yoursite.com/classic/post-name

Wenn Sie Ihre Archiv-URLs erstellen möchten: mydomain.com/projects/classic, müssen Sie ähnliche Umschreibregeln auf Ihre register_taxonomy-Argumente anwenden.

Sie müssten den Überschreibungs-Slug auf Projekte und with_front auf false setzen. Beachten Sie außerdem, dass das Array register_taxonomy rewrite auch Folgendes unterstützt: 'hierarchical' - true or false allow hierarchical urls Auf diese Weise können Sie die vollständige Hierarchie für die Taxonomiebegriffe in Ihren URLs verwenden:

3
Chris_O