No se puede traducir un slug de tipo de publicación personalizada en WPML

5 minutos de lectura

avatar de usuario
caída del terror

He planteado este problema en los foros de WPML, pero espero que alguien aquí pueda ayudar.

Estoy tratando de traducir el slug para un tipo de publicación personalizada

La URL en inglés es http://brigade-electronics.com/nl/products/backeye360/

La URL traducida debe ser http://brigade-electronics.com/nl/producten/backeye360/

En su lugar, recibo un error 404 cuando navego a la URL después de habilitar la opción de traducir slug

Pasos para duplicar el problema:

  • Haga clic en WPML -> Opciones de traducción
  • Habilite Traducir slugs de publicaciones personalizadas (a través de WPML String Translation).
  • En la configuración de Publicaciones personalizadas (en la misma página), haga clic en la casilla de verificación Traducir
  • Se agregó el slug traducido para cada idioma.
  • Presiona guardar
  • Navegue hasta el front-end y verá un error 404 solo en la sección de productos.

He ejecutado todas las opciones en la página de solución de problemas para limpiar la base de datos.

Esto solo parece aplicarse a ciertas páginas dentro de la sección de productos. La parte más extraña de esto es la sección canadiense del sitio, ya que el término ‘producto’ está en inglés, por lo tanto, las URL siguen siendo las mismas con o sin los slugs traducidos en su lugar, sin embargo, sigo recibiendo el error 404 en estas páginas.

También vale la pena señalar que todos los demás tipos de publicaciones personalizadas funcionan sin problemas.

Los tipos de publicaciones personalizadas se han registrado de forma estándar.

function register_products_post_type() {

    $labels = array(
        'name' => __( 'Products', '' ),
        'singular_name' => __( 'Product', '' )
    );

    $args = array(
        'label' => __( 'Products', '' ),
        'labels' => $labels,
        'description' => '',
        'public' => true,
        'publicly_queryable' => true,
        'show_ui' => true,
        'show_in_rest' => false,
        'rest_base' => '',
        'has_archive' => false,
        'show_in_menu' => true,
        'exclude_from_search' => false,
        'capability_type' => 'post',
        'map_meta_cap' => true,
        'hierarchical' => true,
        'rewrite' => array( 'slug' => 'products', 'with_front' => false ),
        'query_var' => true,
        'menu_position' => 6,
        'menu_icon' => 'dashicons-cart',
        'supports' => array( 'title', 'thumbnail', 'page-attributes' )
    );

    register_post_type( 'products', $args );

}
add_action( 'init', 'register_products_post_type' );

Según la respuesta a continuación, el código anterior se ha actualizado a

add_action( 'init', 'create_post_type');
function create_post_type() {
    $labels = array(
        'name'               => _x( 'Products', 'general name of the post type' ),
        'singular_name'      => _x( 'Products', 'name for one object of this post type' ),

    );
    $args = array(
        'labels' =>  $labels, // An array that defines the different labels assigned to the custom post type
        'public' =>  true, // To show the custom post type on the WordPress dashboard
        'supports' => array( 'title', 'thumbnail', 'page-attributes' ),
        'has_archive' =>  true, //Enables the custom post type archive at
        'hierarchical' =>  true, //Enables the custom post type to have a hierarchy
        'rewrite' => array( 'slug' =>  _x('products', 'URL slug')),
    );
    register_post_type( 'products', $args );
    }

La nueva traducción para el slug aparece en la sección ‘Traducción de cadenas’, al actualizar estas cadenas, aparece el mismo error 404. Si dejo estos como ingles la seccion de productos funciona sin problema.

Gracias

  • donde está el slug de traducción $etiquetas = array( ‘nombre’ => __( ‘Productos’, ” ), ‘nombre_singular’ => __( ‘Producto’, ” ) ); – Falta el dominio de texto

    – muy solo

    8 de junio de 2017 a las 16:53

  • Esto no ha hecho una diferencia con todos los demás tipos de publicaciones personalizadas, todos están configurados de la misma manera, pero lo intentaré y te lo haré saber.

    – caída del terror

    8 de junio de 2017 a las 17:07

  • Hola, @MujeebuRahman, agregar un dominio no ha hecho la diferencia.

    – caída del terror

    10 de junio de 2017 a las 12:36

  • ¿Has probado _e() ?

    – muy solo

    10 de junio de 2017 a las 12:47

  • @MujeebuRahman __e() hace eco de la cadena, que no funcionará en este caso

    – caída del terror

    10 de junio de 2017 a las 12:53

Prueba esto

    add_action( 'init', 'create_post_type');
    function create_post_type() {
        $labels = array(
        'name'               => _x( 'Products', 'general name of the post type' ),
        'singular_name'      => _x( 'Products', 'name for one object of this post type' ),

       );
       $args = array(
         'labels' =>  $labels, // An array that defines the different labels assigned to the custom post type
         'public' =>  true, // To show the custom post type on the WordPress dashboard
         'supports' => array( 'title', 'thumbnail', 'page-attributes' ),
         'has_archive' =>  true, //Enables the custom post type archive at 
         'hierarchical' =>  true, //Enables the custom post type to have a hierarchy
         'rewrite' => array( _x('slug' => 'products'), 'with_front' => false ),
    );
    register_post_type( 'products', $args );
    }

  • Lee esto wpml.org/2016/08/how-to-create-and-translate-custom-post-types

    – Vela

    13 de junio de 2017 a las 10:15

  • Me temo que esto no marca la diferencia, y sigue recibiendo un error 404 al cambiar a un slug traducido.

    – caída del terror

    14 de junio de 2017 a las 13:42

  • ¿Has intentado deshabilitar y volver a habilitar “Pretty Permalinks”?

    – Vela

    14 de junio de 2017 a las 13:58

  • Sí, todavía no hay diferencia.

    – caída del terror

    14 de junio de 2017 a las 14:14

  • @terrorfall Acepte esta respuesta para que pueda ayudar a otros usuarios que tienen un problema similar.

    – Jignesh Bhavani

    21 de septiembre de 2017 a las 10:33

avatar de usuario
zendka

¿Has vaciado las reglas de reescritura?

Vaya a Configuración > Enlaces permanentes y actualice.

Nota: Si registra un tipo de publicación dentro de un complemento, llame a flush_rewrite_rules() en su enlace de activación y desactivación (consulte Flushing Rewrite on Activation a continuación). Si no se usa flush_rewrite_rules(), tendrá que ir manualmente a Configuración > Enlaces permanentes y actualizar su estructura de enlaces permanentes antes de que su tipo de publicación personalizada muestre la estructura correcta.

fuente: https://codex.wordpress.org/Function_Reference/register_post_type

¿Ha sido útil esta solución?