Tipuri personalizate de postări: Cum să elimini editorul (meta box)

13 ian. 2011, 06:30:30
Vizualizări: 19.4K
Voturi: 12

Mă întreb cum pot să elimin editorul de postări (vizual + HTML). Am încercat să nu înregistrez suportul pentru tipul de postare, dar tot apare (dezînregistrarea funcționează pentru toate celelalte meta box-uri implicite pe ecranul de editare). Am încercat și să-l elimin cu remove_meta_box, dar nici asta nu a funcționat (merge pentru orice altceva în afară de meta box-ul de titlu). Poate îmi scapă ceva. Am căutat deja pe internet și nu am găsit nimic. Sper să mă poată ajuta cineva. Mulțumesc!

Ps. Aș fi fericit și de o soluție pentru dezactivarea câmpului de titlu, dar asta e pe locul doi (neînregistrarea lui cu tipul de postare funcționează).

(Versiunea WordPress este 3.0.4.)

0
Toate răspunsurile la întrebare 5
13
20

Transmiterea unui array gol la parametrul 'supports' în declarația tipului de postare ar trebui să elimine editorul și titlul, împreună cu toate celelalte casete implicite din pagina de editare a postării.

$supports = array ('');
    $args = array(
      'label' => 'persoane',
      'supports' => $supports,
      'hierarchical' => false,
      'public' => true,
      'rewrite' => true
         );

    register_post_type( 'persoane', $args);

Rezultat: text alternativ Completează parametrul 'supports' cu elementele pe care dorești să le afișezi, cum ar fi trackbacks, comentarii, etc. Sau lasă-l gol pentru a avea pagina goală, cu excepția casetei care îți permite să salvezi postările. Asigură-te că vizitezi acest link dacă dorești să elimini și metabox-urile taxonomiei ierarhice.

13 ian. 2011 07:04:21
Comentarii

Mulțumesc până acum. Problema mea este că nu pot seta totul ca fiind gol. Am creat trei clase pentru a accelera generarea de tipuri de postări personalizate, taxonomii personalizate și etichete. Acestea au valori implicite. În cazul tipurilor de postări personalizate, este practic totul. Dar trebuie să dezactivez unele casete pentru anumite tipuri de postări. Și pentru unul dintre ele trebuie să dezactivez și caseta editorului.

kaiser kaiser
13 ian. 2011 07:58:51

Sunt curios ce înțelegi prin setarea totului ca fiind gol? Dacă vrei să elimini editorul, pur și simplu nu include 'editor' în array-ul 'supports' când creezi tipul de postare în clasa ta.

Manny Fleurmond Manny Fleurmond
13 ian. 2011 08:09:40

@kaiser dacă sunt clasele tale, care este problema? Fă-le să gestioneze asta?..

Rarst Rarst
13 ian. 2011 08:26:13

@Rarst: Este doar o bază care realizează următoarele lucruri: înregistrează tipuri de postări și taxonomii dintr-un array și oferă un filtru pentru $labels și $args (implicit și specific). Clasa pentru termeni generează doar termeni care nu pot fi șterși, care se actualizează și se atribuie dintr-un array. Cutii meta pot fi gestionate ușor fără clasă și nu ar avea sens să le integrez. Clasele sunt acolo doar pentru a-mi economisi timpul și pentru a împiedica clienții să șteargă termenii de care sistemul are nevoie. Dar mulțumesc pentru că te-ai uitat. Ajutorul tău este foarte apreciat (din nou) :)

kaiser kaiser
13 ian. 2011 08:33:48

@Manny Fleurmond: Refolosesc clasele în diferite configurații (parte din framework-ul meu). Nu vreau să modific comportamentul implicit "suportă tot". Am filtre pentru a schimba asta pentru toate tipurile de postări sau doar pentru anumite (suprascriere sau adăugare la $args). Funcționează pentru tot, dar nu și pentru editor. Am încercat și funcția remove_meta_box fără succes (nici pentru cutia meta a titlului).

kaiser kaiser
13 ian. 2011 08:35:44

Sună cam rigid. Ai putea să-ți rescrii clasa astfel încât să poți schimba unele setări implicite de la o instanță la alta. În felul ăsta ai un control mai bun asupra a ceea ce apare când creezi un tip de postare personalizat.

Manny Fleurmond Manny Fleurmond
13 ian. 2011 08:41:20

@kaiser scopul argumentelor implicite este că le poți suprascrie cu argumente non-implicite atunci când este necesar. Altfel, acestea nu sunt implicite, ci hardcodate și aceasta este o configurare rigidă într-adevăr.

Rarst Rarst
13 ian. 2011 08:47:18

@Rarst: Cred că m-ai înțeles greșit. Am setat un filtru după etichete și argumente, ca în exemplul următor. Argumentele $args includ totul, cu excepția structurii permalink-ului, care este setată conform opțiunii din baza de date după aplicarea filtrului. Deci nu, nu este hardcodat.

// Filtru pentru toate tipurile de postare personalizate (schimbă comportamentul implicit) $args = apply_filters( 'config_cpt_args', $args ); // Filtru pentru un anumit tip de postare personalizată $args = apply_filters( 'config_cpt_args_'.$post_type_name, $args );

kaiser kaiser
13 ian. 2011 08:50:19

@kaiser atunci care este problema cu setarea supports la un array gol prin intermediul filtrului?

Rarst Rarst
13 ian. 2011 09:04:34

@Rarst: Că editorul (& titlul) pur și simplu nu vor să dispară...

kaiser kaiser
13 ian. 2011 09:31:37

@Rarst: O "fel de" soluție ca în al treilea răspuns...

kaiser kaiser
13 ian. 2011 09:37:18

Am încercat din nou acum - funcționează.

kaiser kaiser
24 aug. 2012 00:37:19

Mă bucur că te-a ajutat!

Manny Fleurmond Manny Fleurmond
24 aug. 2012 04:51:55
Arată celelalte 8 comentarii
6
17

Dacă nu transmiți nimic pentru argumentul supports, setările implicite ale 'title', 'editor' sunt utilizate (unde "nimic" înseamnă orice valoare care este empty()).

Cu toate acestea, la fel cum poți adăuga suport pentru ceva după înregistrarea tipului de postare cu add_post_type_support( $post_type, $feature ), poți elimina suportul pentru ceva prin apelarea remove_post_type_support( $post_type, $feature ). Deci, apelarea acestei funcții după înregistrarea tipului tău de postare ar trebui să elimine editorul:

remove_post_type_support( 'my_post_type', 'editor' );

Aceste funcții manipulează doar variabila globală $_wp_post_type_features, dar este întotdeauna mai bine să faci acest lucru prin funcțiile API decât să te ocupi manual de ea.

13 ian. 2011 10:25:38
Comentarii

SOLUȚIE! Întotdeauna am crezut că asta e doar pentru a elimina, de exemplu, thumbnail-urile sau nav_menu prin intermediul unui tema copil. Mulțumesc mult!

kaiser kaiser
13 ian. 2011 10:38:06

Uf, am ratat asta. Bun punct, transmiterea unui array gol va fi evaluată ca gol... Transmiterea valorilor goale este întotdeauna atât de haotică, este contraintuitivă, fiind tratată ca implicit în loc de nimic. :(

Rarst Rarst
13 ian. 2011 11:31:03

@Rarst: Cred că ar funcționa și dacă ai transmite un nume de funcționalitate fals. Este doar o cheie de array, deci nu contează dacă se introduc date false. Eu am folosit odată 0.1 în loc de 0 pentru un parametru pentru a trece de verificarea empty().

Jan Fabry Jan Fabry
13 ian. 2011 11:36:27

@Jan Fabry da, nu e prima oară când calc pe mina empty(). Ca mai sus - extrem de contraintuitiv.

Rarst Rarst
13 ian. 2011 11:42:46

Hm. Nu funcționează cu chei și de aceea cred că "valorile dummy" ar putea deveni o altă "mină" la upgrade-uri viitoare (încearcă să găsești valoarea greșită). Oricum: mulțumesc mult amândurora! :)

Edit: ar fi util dacă valorile nu ar fi doar prezente, ci ar fi perechi cheie/valoare. Ex. 'support' => array('thumbnail' => true, 'editor' => false);

kaiser kaiser
13 ian. 2011 11:59:00

Răspuns frumos, @Jan.

Manny Fleurmond Manny Fleurmond
13 ian. 2011 17:17:13
Arată celelalte 1 comentarii
3

Folosesc plugin-ul Custom Post Type UI pentru a crea tipuri personalizate de postări. Folosind acest plugin, poți dezactiva editorul de postări din opțiunile avansate.

Gestionare Tip Post -> Vizualizare Opțiuni Avansate

Aici este un link către plugin: http://wordpress.org/extend/plugins/custom-post-type-ui/

PS - De asemenea, îți permite să dezactivezi și câmpul pentru titlu :)

13 ian. 2011 07:01:59
Comentarii

După cum am menționat mai sus, am scris trei clase și, prin urmare, nu pot trece la un plugin. Adică, nici nu m-aș gândi să folosesc un plugin oricum. Plugin-urile sunt (după părerea mea) pentru lucruri de dezvoltare sau elemente ușor de înlocuit, cum ar fi formularele de comentarii, și nu pentru elemente esențiale precum tipurile de postări sau taxonomiile. Oricum, mulțumesc!

kaiser kaiser
13 ian. 2011 08:00:22

De fapt, plugin-urile pot personaliza aproape orice în WordPress, inclusiv tipurile personalizate de postări. Tocmai lucrez la un plugin care creează numeroase tipuri de postări, meta-casetele lor și diferite câmpuri personalizate.

Manny Fleurmond Manny Fleurmond
13 ian. 2011 08:29:37

@Manny Fleurmond: Dacă intenționezi să împărtășești, te rog să-mi lași un link. Încă mă gândesc să scriu poate-poate o rutină pentru meta-casete avansate în clasele mele.

kaiser kaiser
13 ian. 2011 08:37:01
0

Verifică register_post_type(); în codex. În secțiunea Argumente, derulează în jos până când vezi Supports.

Începând cu versiunea 3.5, poți folosi valoarea booleană false în loc de un array pentru a preveni comportamentul implicit (titlu și editor).

Sau poți personaliza tipul tău de postare personalizată adăugând valorile pe care le dorești, de exemplu:

'supports' => array(
    'title',
    'author',
    'thumbnail',
    'post-formats'
),

Aceste opțiuni suportate din array-ul meu vor apărea în backend-ul WordPress.

14 sept. 2015 22:04:09
1
-2

De asemenea, poți seta stiluri pentru pagina de editare din administrare pentru a ascunde anumite elemente, cum ar fi editorul etc.

function custom_colors() {
   echo '<style type="text/css">
            body.post-type-events #postdivrich {
            display: none;
            }
         </style>';
}

add_action('admin_head', 'custom_colors');
3 sept. 2014 21:55:43
Comentarii

Mulțumesc pentru răspuns, dar acest lucru ar face (a) să nu mai poată fi eliminat, deoarece nu este înregistrat cu API-ul Dependencies și (b) ar face codul accesibil pentru persoanele care știu să utilizeze instrumentele de dezvoltare din browser.

kaiser kaiser
3 sept. 2014 22:20:09