Tipo de publicación personalizada, sin necesidad de vista única, además de reescrituras de enlaces permanentes que incluyen hash en URI


8

Estamos utilizando CPT para administrar una página de preguntas frecuentes en un sitio, donde la pregunta es el título de la publicación y la respuesta es el contenido de la publicación. Hay una página principal para las preguntas frecuentes que muestra todas las publicaciones (página de archivo de preguntas frecuentes). Con esta estructura, realmente no necesitamos la vista única para preguntas frecuentes y, de hecho, nos gustaría omitirla de la estructura del sitio. Para abordar los enlaces permanentes, nos gustaría configurarlos para que sean algo así como example.com/faq/#uniqueIdentifier, pensando que usaremos #uniqueIdentifier para que coincida con un div en la página de archivo que contiene la respuesta y llamaremos la atención en algunos Moda. El UniqueIdentifier podría ser ID de publicación, título de pregunta de preguntas frecuentes, datos de un cuadro de meta o algo más.

Permítanme resumir lo que necesito que necesitamos lograr:

(1) reescriba los enlaces permanentes de preguntas frecuentes para que sean / faq / # algo, y

(2) asegúrese de que todos / faq / enlaces se dirijan a la plantilla de archivo y no solo

Soy mayormente un novato, pero soy bastante bueno para buscar cosas. Sin embargo, nunca he intentado ninguna reescritura, por lo que agradecería alguna dirección particular al respecto.

Gracias.

Respuestas:


12

Hola @daxitude:

Déjame sugerirte primero que reconsideres. Si no tiene páginas de preguntas frecuentes individuales para cada pregunta frecuente:

  1. Reduce su superficie para la optimización de motores de búsqueda y reduce el tráfico potencial que podría obtener, y

  2. Hace imposible que alguien comparta preguntas frecuentes específicas con un amigo por correo electrónico y / o comparta con su red en Facebook, Twitter, etc. (Como usuario, siempre estoy frustrado por los desarrolladores del sitio que no me permiten tener una URL directa a un elemento y en su lugar me obligan a vincular a la página que enumera todos los elementos).

Sin embargo, si aún desea hacerlo, haga dos cosas:

1.) Usa el 'post_type_link'gancho

Use el 'post_type_link'enlace para modificar la URL como en el siguiente ejemplo * (supongo que su tipo de publicación personalizada es 'faq'). Agregue lo siguiente al functions.phparchivo de su tema :

add_action('post_type_link','yoursite_post_type_link',10,2);
function yoursite_post_type_link($link,$post) {
  $post_type = 'faq';
  if ($post->post_type==$post_type) {
    $link = get_post_type_archive_link($post_type) ."#{$post->post_name}";
  }
  return $link;
}

2.) unset($wp_rewrite->extra_permastructs['faq'])

Este es un truco , pero es un truco obligatorio para hacer lo que quieras. Use un 'init'gancho para unset($wp_rewrite->extra_permastructs['faq']). Elimina la regla de reescritura que register_post_type()agrega. Incluyo una llamada para register_post_type()poder proporcionar un ejemplo completo tanto para usted como para otros:

add_action('init','yoursite_init');
function yoursite_init() {
  register_post_type('faq',array(
      'labels' => array(
      'name' => _x('FAQs', 'post type general name'),
      'singular_name' => _x('FAQ', 'post type singular name'),
      'add_new' => _x('Add New', 'faq'),
      'add_new_item' => __('Add New FAQ'),
      'edit_item' => __('Edit FAQ'),
      'new_item' => __('New FAQ'),
      'view_item' => __('View FAQ'),
      'search_items' => __('Search FAQs'),
      'not_found' =>  __('No FAQs found'),
      'not_found_in_trash' => __('No FAQs found in Trash'),
      'parent_item_colon' => '',
      'menu_name' => 'FAQs'
    ),
    'public' => true,
    'publicly_queryable' => true,
    'show_ui' => true,
    'show_in_menu' => true,
    'query_var' => true,
    'rewrite' => array('slug'=>'faqs'),
    'capability_type' => 'post',
    'has_archive' => 'faqs',
    'hierarchical' => false,
    'supports' => array('title','editor','author','thumbnail','excerpt')
  ));

  global $wp_rewrite;
  unset($wp_rewrite->extra_permastructs['faq']);  // Removed URL rewrite for specific FAQ 
  $wp_rewrite->flush_rules(); // THIS SHOULD BE DONE IN A PLUGIN ACTIVATION HOOK, NOT HERE!
}

Eso es todo.

Por supuesto, el uso anterior de $wp_rewrite->flush_rules()en un 'init'gancho es una práctica realmente mala y realmente solo debe hacerse una vez, por lo que he implementado un complemento completo y autónomo llamado FAQ_Post_Typepara hacerlo bien. Este complemento agrega un tipo de publicación de preguntas frecuentes con las reglas de URL que desea y utiliza un register_activation_hook()para vaciar las reglas de reescritura; la activación es obviamente una de las pocas cosas que requiere código de complemento en lugar de código que puede ejecutarse en el functions.phparchivo de un tema .

Aquí está el código para el FAQ_Post_Typecomplemento; no dude en modificar sus requisitos:

<?php
/*
Plugin Name: FAQ Post Type
Description: Answers the question "Custom post type, no need for single view, plus want permalink rewrites that include hash in URI" on WordPress Answers.
Plugin URL: http://wordpress.stackexchange.com/questions/12762/custom-post-type-no-need-for-single-view-plus-want-permalink-rewrites-that-incl
*/
if (!class_exists('FAQ_Post_Type')) {
  class FAQ_Post_Type {
    static function on_load() {
      add_action('post_type_link', array(__CLASS__,'post_type_link'),10,2);
      add_action('init', array(__CLASS__,'init'));
    }
    static function post_type_link($link,$post) {
      if ('faq'==$post->post_type) {
        $link = get_post_type_archive_link('faq') ."#{$post->post_name}";
      }
      return $link;
    }
    static function init() {
      register_post_type('faq',array(
          'labels' => array(
          'name' => _x('FAQs', 'post type general name'),
          'singular_name' => _x('FAQ', 'post type singular name'),
          'add_new' => _x('Add New', 'faq'),
          'add_new_item' => __('Add New FAQ'),
          'edit_item' => __('Edit FAQ'),
          'new_item' => __('New FAQ'),
          'view_item' => __('View FAQ'),
          'search_items' => __('Search FAQs'),
          'not_found' =>  __('No FAQs found'),
          'not_found_in_trash' => __('No FAQs found in Trash'),
          'parent_item_colon' => '',
          'menu_name' => 'FAQs'
        ),
        'public' => true,
        'publicly_queryable' => true,
        'show_ui' => true,
        'show_in_menu' => true,
        'query_var' => true,
        'rewrite' => array('slug'=>'faqs'),
        'capability_type' => 'post',
        'has_archive' => 'faqs',
        'hierarchical' => false,
        'supports' => array('title','editor','author','thumbnail','excerpt'),
      ));
      global $wp_rewrite;
      unset($wp_rewrite->extra_permastructs['faq']);  // Remove URL rewrite for specific FAQ
    }
    static function activate() {
      global $wp_rewrite;
      $wp_rewrite->flush_rules();
    }
  }
  FAQ_Post_Type::on_load();
  register_activation_hook(__FILE__,array('FAQ_Post_Type','activate'));
}

También podría mantener las reglas de vaciado dentro del 'init'uso de un cheque para un valor de opción si lo prefiere:

// Add this code in your 'init' hook at your register_post_type('faq',...)
if (!get_option('faq_rewrite_rules_updated')) {
  global $wp_rewrite;
  unset($wp_rewrite->extra_permastructs['faq']);  // Remove URL rewrite for specific FAQ
  $wp_rewrite->flush_rules();
  update_option('faq_rewrite_rules_updated',true);
}

Tu elección.

De todos modos, avíseme si hay casos de uso que descubra que esto no resuelve.


Hola @MikeSchinkel. ¡GUAUU! Ciertamente eres un individuo servicial. Estoy totalmente de acuerdo con sus puntos de reconsideración # 1 y # 2, pero creo que hemos abordado principalmente estas preocupaciones. Para el n. ° 1: dado que estamos mostrando la pregunta y la respuesta completas en la página del archivo cpt, ¿no sería una vista única para cada faq contenido duplicado y, por lo tanto, no necesariamente favorable para el SEO? Además de esto, hemos sentido que una página completa para una sola pregunta frecuente es un poco agitar el brazo y preferimos entregar a la gente el contenido más rápido en lugar de tener que hacer clic a través de más enlaces para llegar allí.
daxitude

(¡aparentemente hay límites de caracteres para los comentarios y soy una persona detallada!) Para el n. ° 2: todo después del hash en la uri se corresponde con un div en la página que contiene la respuesta. todas las demás respuestas están ocultas en la carga de la página y se abren las diapositivas de respuestas coincidentes. De esta manera, preservamos completamente la capacidad de compartir y guardar enlaces ... siempre y cuando no nos volvamos inconstantes y cambiemos esta estructura por alguna razón tonta.
daxitude

En cuanto a su respuesta, ¡el paso 1 es fantástico! No estaba familiarizado con este gancho y no había previsto una solución tan clara. Como curiosidad, me doy cuenta de que puede implementar el paso 1 y no el paso 2. Esto envía enlaces de preguntas frecuentes a la uri apropiada, pero también conserva las páginas individuales ... y nunca los enlazamos a través del sitio. ¿Parece esto un camino razonable? Gracias.
daxitude

@daxitude: es mejor no permitir la indexación de motores de búsqueda en una página de archivo y permitirles indexar las páginas individuales. Las dos cosas más importantes para SEO son la página <title>y <h1>Heading</h1>obtendrá solo una de ellas en una página de archivo, pero tiene una para cada una de las páginas de preguntas frecuentes individuales. Estoy de acuerdo en que todo el contenido de preguntas frecuentes es mejor en la página de archivo, pero puede proporcionar todo el contenido en la página principal y una página de desglose para aquellos que lo deseen (que incluye motores de búsqueda) , y ciertamente no hace daño; simplemente agregue un "Enlace permanente" cerca de la pregunta frecuente.
MikeSchinkel

@daxitude - ¿Por qué crees que no implementé el # 2? Ese es el propósito del código que sigue al encabezado "2.) unset($wp_rewrite->extra_permastructs['faq'])" que, por supuesto, estoy argumentando que no usa. :)
MikeSchinkel
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.