WordPress: uso de wp_insert_post () para completar campos de tipo de publicación personalizados

5 minutos de lectura

avatar de usuario
Manas Chaturvedi

He creado un tipo de publicación personalizada. wrestling y creó sus campos personalizados correspondientes usando Campos personalizados avanzados. Ahora, quería que los usuarios llenaran este formulario personalizado en la parte delantera, para que al enviarlos, los datos se actualizaran automáticamente en el tipo de publicación personalizada en el tablero. Para este propósito, creé una página personalizada y le asigné una plantilla personalizada que contenía el formulario requerido. Hay cuatro campos de formulario HTML que los usuarios deben completar, llamados name, venue, main_event y fee respectivamente.

Los campos de formulario personalizados que creé usando Campos personalizados avanzados se denominan como promotion_name, venue, main_event_ y price respectivamente. Ahora, para completar los datos ingresados ​​por los usuarios en el front-end en los campos de tipo de publicación personalizada en el tablero, intenté usar el wp_insert_post() funcionar de la siguiente manera:

$post_information = array(
        'promotion_name' => $_POST['name'],
        'venue' => $_POST['venue'],
        'main_event_' => $_POST['main_event'],
        'price' => $_POST['fee'],
        'post_type' => 'wrestling',
    );

    wp_insert_post( $post_information );

Sin embargo, después de que el usuario envía el formulario, aparece una nueva entrada (no_title) en mi tipo de publicación personalizada, pero los campos del formulario personalizado aún están vacíos (vea las imágenes a continuación 🙂

ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquí

Estoy seguro de que esto se debe a que no estoy usando el wp_insert_post() correctamente para actualizar los tipos de publicaciones personalizadas. Realmente agradecería algo de ayuda aquí. Gracias.

PD: Así es como he definido mi tipo de publicación personalizada en functions.php:

<?php 
function wrestling_show_type()
{
    register_post_type('wrestling',
                    array('labels' => array('name' => 'Wrestling Shows', 'singular_name' => 'Wrestling Show'),
                        'public' => true,
                        'has_archive' => true,
                        'rewrite' => array('slug' => 'wrestling')));

    flush_rewrite_rules();
}
add_action('init', 'wrestling_show_type');
?>

avatar de usuario
Caio Felipe Pereira

Si ha usado ACF, debe usar su API para interactuar con los campos. Hay un método llamado update_field() que hace exactamente lo que estás buscando. Este método toma 3 parámetros:

update_field($field_key, $value, $post_id)

$field_key es un ID que ACF otorga a cada campo que crea. Esta imagen, tomada de su propia documentación, le muestra cómo obtenerlo:

Cómo obtener la clave de campo

Editar: $field_key También aceptará el nombre del campo.

$value y $post_id son bastante sencillos, representan el valor con el que desea establecer el campo y la publicación que está actualizando.

En su caso, debe hacer algo para recuperar este $post_id. Afortunadamente, eso es lo que wp_insert_post() devoluciones. Entonces, puedes hacer algo como esto:

$post_information = array(
    //'promotion_name' => $_POST['name'],
    'post_type' => 'wrestling'
);

$postID = wp_insert_post( $post_information ); //here's the catch

Con la identificación, entonces las cosas son fáciles, solo llame update_field() para cada campo que desee actualizar.

update_field('whatever_field_key_for_venue_field', $_POST['venue'], $postID);
update_field('whatever_field_key_for_main_event_field', $_POST['main_event'], $postID);
update_field('whatever_field_key_for_fee_field', $_POST['fee'], $postID);

Básicamente, lo que está haciendo es crear la publicación primero y luego actualizarla con los valores.

He hecho este tipo de cosas en el functions.php archivo, y funcionó bien. Por lo que he visto, creo que está utilizando esta rutina en algún tipo de archivo de plantilla. Creo que funcionará bien, solo debes asegurarte de que el complemento ACF esté activado.

EDITAR:

olvidé el promotion_name campo. Comenté la línea dentro $post_information, ya que no va a funcionar. Deberías usar update_field() en cambio, al igual que los otros 3.

update_field('whatever_field_key_for_promotion_name_field', $_POST['name'], $postID);

  • Logré actualizar los campos de mi formulario usando el add_post_meta() función, que creo que es exactamente similar a la update_field() función, ¿verdad?

    – Manas Chaturvedi

    12 de agosto de 2015 a las 12:03

  • Creo que finalmente hace eso, pero me quedaría con la API del complemento, ya que es más consistente con un campo creado por el complemento. Si tiene diferentes tipos de campos, como editores WYSIWYG, o tal vez subcampos, usando add_post_meta() puede volverse bastante complicado, entonces, ¿por qué no dejar que el complemento haga el trabajo por usted?

    –Caio Felipe Pereira

    12 de agosto de 2015 a las 12:11

  • Oh, está bien, intentaré modificar mi código, esta vez usando el update_field() método en su lugar. Gracias.

    – Manas Chaturvedi

    12 de agosto de 2015 a las 12:14

  • sí, déjame saber si encuentras algún problema.

    –Caio Felipe Pereira

    12 de agosto de 2015 a las 12:15

  • Hola, pero si desarrolla en localhost y luego publica en producción, ¿la producción tendrá diferentes claves para los mismos campos? Entonces, ¿’update_field’ fallaría?

    –Jiro Matchonson

    5 de diciembre de 2018 a las 12:30

avatar de usuario
bramchi

Hay una manera de agregar datos de campos personalizados directamente al crear una publicación. Se menciona en el wp_insertar_post() documentos Simplemente pase una matriz con claves y valores de campo personalizados a meta_input como esto:

wp_insert_post([
  'post_status' => 'publish',
  'post_type'   => 'wrestling',
  'meta_input'  => [
    'my_custom_field_1' => 'beep',
    'my_custom_field_2' => 'boop',
  ]
]);

Estoy investigando este enfoque para evitar una docena de llamadas a la base de datos update_field() y hacerlo menos intensivo en recursos, pero aún tengo que demostrar que este enfoque en realidad hace menos llamadas a la base de datos en segundo plano.

¿Ha sido útil esta solución?