Como você cria uma página “virtual” no WordPress?

50

Estou tentando criar um ponto de extremidade de API personalizado no WordPress e preciso redirecionar solicitações para uma página virtual na raiz do WordPress para uma página real fornecida com meu plug-in. Então, basicamente, todas as solicitações para a única página são roteadas para a outra.

Exemplo:% http://mysite.com/my-api.php = > http://mysite.com/wp-content/plugins/my-plugin/my-api.php

O objetivo é tornar a URL do ponto de extremidade da API o mais curta possível (semelhante a http://mysite.com/xmlrpc.php , mas enviar o arquivo de ponto de extremidade da API real com o plug-in, em vez de exigir que o usuário mova os arquivos instalação e / ou corte do núcleo.

Minha primeira tentativa foi adicionar uma regra de reescrita personalizada. No entanto, isso teve dois problemas.

  1. O terminal sempre teve uma barra final. Tornou-se http://mysite.com/my-api.php/
  2. Minha regra de regravação foi aplicada apenas parcialmente. Ele não redirecionaria para wp-content/plugins... , ele redirecionaria para index.php&wp-content/plugins... . Isso levou o WordPress a exibir um erro de página não encontrada ou simplesmente padronizar a página inicial.

Idéias? Sugestões?

    
por EAMann 20.02.2011 / 05:05
fonte

8 respostas

54

Existem dois tipos de regras de reescrita no WordPress: regras internas (armazenadas no banco de dados e analisadas por WP :: parse_request () ) e regras externas (armazenadas em .htaccess e analisadas pelo Apache). Você pode escolher de qualquer forma, dependendo de quanto WordPress você precisa no seu arquivo chamado.

Regras externas:

A regra externa é a mais fácil de configurar e seguir. Ele executará my-api.php no diretório do seu plugin, sem carregar nada do 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 );
}

Regras internas:

A regra interna requer um pouco mais de trabalho: primeiro adicionamos uma regra de reescrita que adiciona uma consulta vars, então tornamos esta consulta var public, e então precisamos verificar a existência dessa consulta var para passar o controle para nossa arquivo de plugin. No momento em que fizermos isso, a inicialização normal do WordPress terá acontecido (nós nos separamos logo antes da consulta normal do post).

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;
}
    
por Jan Fabry 21.02.2011 / 14:57
fonte
11

Isso funcionou para mim. Eu nunca toquei na API de reescrita, mas estou sempre me preparando para novas direções. O seguinte trabalhou no meu servidor de teste para 3.0 localizado em uma subpasta de localhost. Eu não vejo nenhum problema se o WordPress estiver instalado no web root.

Basta soltar este código em um plugin e fazer o upload do arquivo chamado "taco-kittens.php" diretamente na pasta do plugin. Você precisará escrever um hard flush para seus permalinks. Acho que eles dizem que a melhor hora para fazer isso é na ativação do plugin.

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' );

Felicidades, -Mike

    
por mfields 20.02.2011 / 07:00
fonte
8

Qualquer motivo para não fazer algo assim em vez disso?

enlace

Em seguida, apenas conecte seu plug-in no 'init' e verifique essa variável. Se existir, faça o que seu plugin precisa fazer e morra ()

    
por Will Anderson 20.02.2011 / 05:49
fonte
3

Eu posso não estar entendendo suas perguntas por completo, mas um código curto simples resolveria seu problema?

Etapas:

  1. Peça ao cliente para criar uma página, por exemplo enlace
  2. Peça ao cliente que adicione um código de acesso nessa página, por exemplo, [my-api-shortcode]

A nova página atua como um end point da API e seu shortcode envia solicitações para o código do seu plug-in em enlace

(claro que isso significa que my-api.php teria o shortcode definido)

Você provavelmente pode automatizar os passos 1 e 2 através do plugin.

    
por rexposadas 20.02.2011 / 09:13
fonte
1

Eu não lidei muito com a reescrita, mas isso é provavelmente um pouco difícil, mas 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 se você ligar isso em 'generate_rewrite_rules', mas deve haver uma maneira melhor, já que você não quer reescrever .htaccess em cada carregamento de página.
Parece que não consigo parar de editar meus próprios posts ... provavelmente deveria preferir ativar o retorno de chamada e fazer referência global ao $ wp_rewrite. E, em seguida, remova a entrada de non_wp_rules e a saída para .htaccess novamente para desativar o retorno de chamada.

E, finalmente, a gravação no .htaccess deve ser um pouco mais sofisticada, você quer apenas substituir a seção wordpress aqui.

    
por wyrfel 20.02.2011 / 06:26
fonte
1

Eu tinha um requisito semelhante e queria criar vários end-points com base em slugs exclusivos que apontavam para o conteúdo gerado pelo plug-in.

Dê uma olhada na fonte do meu plugin: enlace

A técnica que usei começa adicionando um filtro para the_posts para examinar a solicitação recebida. Se o plug-in deve lidar com isso, uma postagem fictícia é gerada e uma ação é adicionada para template_redirect .

Quando a ação template_redirect é chamada, ela deve resultar na saída de todo o conteúdo da página a ser exibida e sair ou deve retornar sem saída gerada. Veja o código em wp_include/template-loader.php e você verá o porquê.

    
por Ken 09.04.2011 / 00:22
fonte
1

Estou usando outra abordagem que consiste em forçar a página inicial a carregar um título, um conteúdo e um modelo de página personalizados .

A solução é muito simples, pois pode ser implementada quando um usuário segue um link amigável, como enlace ? plugin_page = myfakepage

É muito fácil de implementar e deve permitir páginas ilimitadas.

Código e instruções aqui: Gerar um personalizado / Página do Wordpress falsa / virtual na mosca

    
por Xavi Esteve 18.01.2012 / 12:50
fonte
0

Estou usando uma abordagem semelhante à de Xavi Esteve, que parou de funcionar devido a uma atualização do WordPress, tanto quanto eu poderia dizer no segundo semestre de 2013.

Está documentado em grande detalhe aqui: enlace

A parte principal da minha abordagem é usar o modelo existente para que a página resultante pareça parte do site; Eu queria que fosse o mais compatível possível com todos os temas, esperançosamente, nos lançamentos do WordPress. O tempo dirá se eu estava certo!

    
por Brian C 01.03.2014 / 06:39
fonte