¿Cómo se crea una página “virtual” en WordPress?

Hay dos tipos de reglas de reescritura en WordPress: reglas internas (almacenadas en la base de datos y analizadas por WP :: parse_request () ), y reglas externas (almacenadas en .htaccess y analizadas por Apache). Puede elegir de cualquier manera, dependiendo de la cantidad de WordPress que necesite en su archivo llamado.

Reglas externas:

La regla externa es la más fácil de configurar y seguir. Ejecutará my-api.php en su directorio de complementos, sin cargar nada de WordPress.

add_action( 'init', 'wpse9870_init_external' );
function wpse9870_init_external()
{
    global $wp_rewrite;
    $plugin_url = plugins_url( 'my-api.php', __FILE__ );
    $plugin_url = substr( $plugin_url, strlen( home_url() ) + 1 );
    // The pattern is prefixed with '^'
    // The substitution is prefixed with the "home root", at least a '/'
    // This is equivalent to appending it to 'non_wp_rules'
    $wp_rewrite->add_external_rule( 'my-api.php$', $plugin_url );
}

Reglas internas:

La regla interna requiere un poco más de trabajo: primero agregamos una regla de reescritura que agrega una vars de consulta, luego hacemos que esta var de consulta sea pública, y luego necesitamos verificar la existencia de esta var de consulta para pasar el control a nuestro archivo plugin En el momento en que hagamos esto, ya habrá ocurrido la inicialización habitual de WordPress (nos separamos justo antes de la consulta regular).

add_action( 'init', 'wpse9870_init_internal' );
function wpse9870_init_internal()
{
    add_rewrite_rule( 'my-api.php$', 'index.php?wpse9870_api=1', 'top' );
}

add_filter( 'query_vars', 'wpse9870_query_vars' );
function wpse9870_query_vars( $query_vars )
{
    $query_vars[] = 'wpse9870_api';
    return $query_vars;
}

add_action( 'parse_request', 'wpse9870_parse_request' );
function wpse9870_parse_request( &$wp )
{
    if ( array_key_exists( 'wpse9870_api', $wp->query_vars ) ) {
        include 'my-api.php';
        exit();
    }
    return;
}

Esto funcionó para mí. Nunca toco la API de reescritura, pero siempre estoy dispuesto a impulsarme en nuevas direcciones. Lo siguiente funcionó en mi servidor de prueba para 3.0 ubicado en una subcarpeta de localhost. No veo ningún problema si WordPress está instalado en la raíz web.

Simplemente coloque este código en un complemento y cargue el archivo llamado "taco-kittens.php" directamente en la carpeta del complemento. Necesitará escribir un color duro para sus enlaces permanentes. Creo que dicen que el mejor momento para hacerlo es en la activación del complemento.

function taco_kitten_rewrite() {
    $url = str_replace( trailingslashit( site_url() ), '', plugins_url( '/taco-kittens.php', __FILE__ ) );
    add_rewrite_rule( 'taco-kittens\.php$', $url, 'top' );
}
add_action( 'wp_loaded', 'taco_kitten_rewrite' );

Mis mejores deseos, -Mike

¿Alguna razón para no hacer algo como esto en su lugar?

enlace

Luego simplemente conecte su complemento a 'init' y busque esa variable de obtención. Si existe, haz lo que tu plugin debe hacer y muere ()

Puede que no entienda sus preguntas por completo, pero ¿un simple shortcode resolvería su problema?

Pasos:

1. Haga que el cliente cree una página, es decir, enlace
2. Haga que el cliente agregue un shortcode en esa página, es decir, [my-api-shortcode]

La nueva página actúa como un punto final de API y su código abreviado envía solicitudes a su código de complemento en enlace

(por supuesto, esto significa que my-api.php tendría el shortcode definido)

Probablemente pueda automatizar los pasos 1 y 2 a través del complemento.

Todavía no he tratado de reescribir tanto, así que probablemente sea un poco difícil, pero parece funcionar:

function api_rewrite($wp_rewrite) {
    $wp_rewrite->non_wp_rules['my-api\.php'] = 'wp-content/plugins/my-plugin/my-api.php';
    file_put_contents(ABSPATH.'.htaccess', $wp_rewrite->mod_rewrite_rules() );
}

Funciona si engancha esto en 'generate_rewrite_rules', pero debe haber una mejor manera, ya que no desea volver a escribir .htaccess en cada carga de página.
Parece que no puedo dejar de editar mis propias publicaciones ... probablemente debería ir más allá para activar la devolución de llamada y hacer referencia a $ wp_rewrite global. Y luego elimine la entrada de non_wp_rules y realice la salida a .htaccess nuevamente cuando desactive la devolución de llamada.

Y finalmente, la escritura en .htaccess debería ser un poco más sofisticada, solo quieres reemplazar la sección de wordpress allí.

Tenía un requisito similar y quería crear varios puntos finales basados en errores únicos que apuntaban al contenido generado por el complemento.

Eche un vistazo a la fuente de mi complemento: enlace

La técnica que utilicé comienza agregando un filtro para the_posts para examinar la solicitud entrante. Si el complemento lo controla, se genera una publicación ficticia y se agrega una acción para template_redirect .

Cuando se llama a la acción template_redirect , debe dar como resultado que se muestre y salga todo el contenido de la página, o debe regresar sin que se genere ningún resultado. Vea el código en wp_include/template-loader.php y verá por qué.

Estoy usando otro enfoque que consiste en obligar a la página de inicio a cargar un título, contenido y plantilla de página personalizados .

La solución es muy clara ya que puede implementarse cuando un usuario sigue un enlace amigable como enlace ? plugin_page = myfakepage

Es muy fácil de implementar y debería permitir páginas ilimitadas.

Código e instrucciones aquí: Genere una costumbre Página falsa / virtual de Wordpress sobre la marcha

Estoy usando un enfoque similar al de Xavi Esteve anterior, que dejó de funcionar debido a una actualización de WordPress por lo que pude ver en la segunda mitad de 2013.

Está documentado en gran detalle aquí: enlace

La parte clave de mi enfoque es usar la plantilla existente para que la página resultante parezca que forma parte del sitio; Quería que fuera lo más compatible posible con todos los temas, con suerte en las versiones de WordPress. ¡El tiempo dirá si tenía razón!