2011-03-01 11 views
13

¿Alguna forma de tener save_post solo para publicaciones personalizadas? La forma en que my functions.php está codificado es atacar muchos campos personalizados para publicaciones normales y páginas que no los necesitan ni los usan.¿Qué acción puedo usar en WordPress que se activa cada vez que se guarda o actualiza una publicación personalizada?

+0

tratando de codificar hasta el apoyo mensajes personalizados, cada uno con sus propios campos personalizados, pero el ahorro de los campos de save_post interfiere con cualquier otro tipo de mensaje en Wordpress. ¿Hay una var accesible desde la acción save_form que dice qué tipo de publicación se está guardando? ¿Hay eventos para las publicaciones personalizadas que se guardan? –

+0

Compruebe mi respuesta. – Sandwich

Respuesta

14

actualizado desde 3.7.0 - puntales @Baptiste para el recordatorio

3.7.0 introdujo el "save_post_{$post->post_type}" gancho, que se desencadena por el tipo de correos. Esto le permite agregar una acción específica a su tipo de publicación personalizada (o "página" o "publicación", etc.). Esto te ahorra una línea de abajo.

El método aceptado es agregar una acción en save_post_{post-type} (sustituyendo la barra de tipo de publicación para {post-type} en el ejemplo anterior). Hay un número de cheques que puede/debe probablemente todavía hacer dentro de devolución de llamada de su acción, que se documentan en el siguiente ejemplo:

de the Codex:

/* Register a hook to fire only when the "my-cpt-slug" post type is saved */ 
add_action('save_post_my-cpt-slug', 'myplugin_save_postdata', 10, 3); 

/* When a specific post type's post is saved, saves our custom data 
* @param int  $post_ID Post ID. 
* @param WP_Post $post Post object. 
* @param bool $update Whether this is an existing post being updated or not. 
*/ 
function myplugin_save_postdata($post_id, $post, $update) { 
    // verify if this is an auto save routine. 
    // If it is our form has not been submitted, so we dont want to do anything 
    if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) 
     return; 

    // verify this came from the our screen and with proper authorization, 
    // because save_post can be triggered at other times 

    if (!wp_verify_nonce($_POST['myplugin_noncename'], plugin_basename(__FILE__))) 
     return; 


    // Check permissions 
    if ('page' == $post->post_type) 
    { 
    if (!current_user_can('edit_page', $post_id)) 
     return; 
    } 
    else 
    { 
    if (!current_user_can('edit_post', $post_id)) 
     return; 
    } 

    // OK, we're authenticated: we need to find and save the data 

    $mydata = $_POST['myplugin_new_field']; 

    // Do something with $mydata 
    // probably using add_post_meta(), update_post_meta(), or 
    // a custom table (see Further Reading section below) 

    return $mydata; 
} 

Si va a registrar varios tipos de envíos personalizados y se le gustaría consolidar su funcionalidad save_post en una sola función, luego enganche en la acción genérica save_post. Pero recuerde hacer su verificación de tipo de publicación dentro de su función si hay alguna diferencia en la forma en que esos tipos guardan sus datos.

por ejemplo: if ('my-cpt-1' == $post->post_type){ // handle my-cpt-1 specific stuff here ...

+0

¿Cuántas veces puede agregar 'add_action ('save_post', 'myplugin_save_postdata');'? ¿Debería agregar uno nuevo para cada nuevo metabox (obviamente cambiando los nonces y 'myplugin_save_postdata' a cualquiera que sea el nombre de su función, cada vez)? – Amanda

+3

@Amanda: Aparte de un golpe de rendimiento (leve), el enfoque que sugiere funcionará, y probablemente sea más fácil de analizar para humanos porque puede asociar la operación "Guardar" con el mismo bloque de código en el que define el metabox, para mantener las cosas limpias y ordenadas. El enfoque alternativo es definir una devolución de llamada de la función "Guardar" para todo el tema o complemento, tal vez incluso encapsulado dentro de su propia clase o al menos un archivo separado, y luego usar una declaración de cambio para definir las salvaciones individuales de metacaja. Una cuestión de estilo de codificación y preferencia personal. –

+0

este enfoque ya no es necesario desde 3.7, verifique la respuesta justo debajo. – Baptiste

24

WordPress 3.7 introdujo una nueva manera de manejar esto con el save_post_{$post_type} gancho.

Digamos que su tipo de publicación personalizada es "member-directory". Ahora puede ejecutar save_post en ese tipo de puestos de trabajo sólo mediante el uso de algo como esto:

function my_custom_save_post($post_id) { 

    // do stuff here 
} 
add_action('save_post_member-directory', 'my_custom_save_post'); 
+0

Impresionante, ¿dónde lo descubriste? Me las arreglé para resolver esto a través de la experimentación, pero no vi nada sobre hacer esto en la documentación oficial: http: //codex.wordpress.org/Plugin_API/Action_Reference/save_post Solo se supone que debe hacerlo después de mirar la nueva acción add_meta_boxes {post-type} (ver: http://codex.wordpress.org/Plugin_API/Action_Reference/add_meta_boxes). – hallodom

+0

Estaba siguiendo el desarrollo 3.7 y lo noté. El compromiso donde se agregó es [aquí] (https://core.trac.wordpress.org/changeset/25050). No creo que haya sido documentado en el Codex en ninguna parte. Al menos no fue la última vez que miré. – mindctrl

+0

Si bien tiene razón sobre el nuevo gancho de acción, este ejemplo es engañoso porque le falta un montón de capacidades y controles de contexto que realmente deberían incluirse. Consulte http://stackoverflow.com/a/6270232/467386 para obtener una solución más completa. –

Cuestiones relacionadas