De ce un tip de postare personalizată (CPT) necesită setarea 'hierarchical' în argumente?
Mă confrunt cu înțelegerea unor aspecte legate de CPT-uri și aș avea nevoie de ajutor. Văd că taxonomiile au adesea nevoie să fie ierarhice, dar nu înțeleg cum/când un tip de postare personalizată ar avea nevoie de asta.
De exemplu, am un CPT numit 'proiecte'. Există o taxonomie înregistrată pentru acest tip de postare numită 'domenii'. Sub 'domenii' am multe sub-elemente precum:
- 'Documentare'
- 'Documentare' > 'Auto-comenzi'
- 'Documentare' > 'Clasice'
- 'Corporative'
- 'Corporative' > 'Marketing Digital'
- etc...
Pentru a vizualiza un proiect în 'Documentare' > 'Clasice' folosesc acest URL: domeniulmeu.ro/domeniu/clasice/
Aici aș avea de fapt vreo 30 de întrebări :) dar voi pune doar cele mai urgente două:
- De ce și cum ar putea fi vreodată ierarhic tipul de postare 'proiecte'?
- Este posibil să vizualizez elementele din domeniul 'clasice' astfel: domeniulmeu.ro/proiecte/clasice (domeniulmeu.ro/proiecte afișează toate elementele, dar navigarea mai departe nu funcționează)
Orice ajutor este binevenit, am petrecut cam 3 ore încercând să rezolv asta și nu reușesc să înțeleg!
Mulțumesc!
Mai jos este codul meu (trunchiat) pentru referință:
function register_cpt_projects() {
$labels = array(
'name' => _x('Proiecte', 'proiecte'),
// toate celelalte etichete etc..
);
$args = array(
'labels' => $labels,
'hierarchical' => true,
'supports' => array('titlu', 'editor', 'autor', 'thumbnail'),
'taxonomii' => array('domeniu'),
'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('proiecte', $args);
}
add_action('init', 'register_cpt_projects');
function create_projects_tax(){
register_taxonomy('domeniu', 'proiecte', array(
'hierarchical' => true,
'label' => 'Domenii'
));
}
add_action('init', 'create_projects_tax');

Când aveți două obiecte de conținut cu o interfață similară sau proprietăți comune, aveți un bun candidat pentru tipurile de postare ierarhice.
Luați locuri ca exemplu (vezi acest răspuns):
- Asia
- Europa
- Germania
- Berlin
- Austria
- Viena
- Germania
Fiecare loc are metadate similare: populație, coordonate geografice, limbi vorbită. Puteți pur și simplu refolosi aceeași interfață.
În plus, dacă creați un tip de postare personalizat separat pentru fiecare tip de loc, veți întâmpina problema tabelului lipsă de relații post-la-post din WordPress.

Mulțumesc, acest lucru ar putea fi util atunci. Am citit celălalt post și am încercat să înțeleg cum să setez un CPT ca părinte, dar nu am reușit. Nu văd meniul derulant pentru părinte nicăieri pe pagina de editare a CPT-ului 'projects'. Contează care este 'capability_type' al CPT-ului meu? Era 'post', dar l-am schimbat în 'page' și am testat, dar încă nu apare meniul derulant. Am mai multe postări 'projects' adăugate, deci ar trebui să existe ceva care să poată fi părinte acolo. Mulțumesc mult până acum :)

Un tip de postare personalizat necesită setarea ierarhică doar dacă doriți ca tipul de postare să se comporte ca paginile.
Dacă doriți să puteți alege un părinte și să aveți caseta meta pentru ordinea în meniu, trebuie să adăugați 'page-attributes' în array-ul supports.
Argumentul hierarchical vă permite, de asemenea, să tratați tipurile de postări ierarhice diferit de altele folosind eticheta condițională is_post_type_hierarchical()
. Aceasta acceptă ca parametru un obiect de tip post, numele tipului de postare sau ID-ul postării.
Este posibil să vizualizați elementele în câmpul 'clasic' astfel: mydomain.com/proiecte/clasic (mydomain.com/proiecte afișează toate elementele, dar navigarea mai departe nu funcționează)
Puteți folosi argumentul rewrite pentru a defini cum apar URL-urile pentru postările individuale:
slug: Prefixul pe care doriți să-l utilizați pentru postări.
with_front: Dacă tipul de postare ar trebui să utilizeze baza frontală din setările de legături permanente.
'rewrite' => array( 'slug' => 'clasic', 'with_front' => false ),
ar face ca URL-urile pentru postările individuale de proiect să arate astfel:
siteuldvs.com/clasic/numele-postarii
Dacă doriți ca URL-urile arhivei să fie: mydomain.com/proiecte/clasic
, va trebui să aplicați reguli similare de rescriere în argumentele register_taxonomy.
Va trebui să setați slug-ul de rescriere la proiecte și with_front la false. De remarcat este faptul că array-ul rewrite din register_taxonomy acceptă și: 'hierarchical' - true sau false pentru a permite URL-uri ierarhice
Acest lucru vă permite să utilizați ierarhia completă a termenilor de taxonomie în URL-urile dvs.:
