Estou tentando criar um terminal de API personalizado no WordPress e preciso redirecionar solicitações para uma página virtual na raiz do WordPress para uma página real que é fornecida com meu plug-in. Então, basicamente, todos os pedidos para uma página são realmente roteados para a outra.
http://mysite.com/my-api.php=>http://mysite.com/wp-content/plugins/my-plugin/my-api.php
O objetivo é tornar o URL do terminal da API o mais curto possível (semelhante a http://mysite.com/xmlrpc.phpenviar o arquivo real do terminal da API com o plug-in, em vez de exigir que o usuário mova arquivos na instalação e / ou hack core .
Minha primeira tentativa foi adicionar uma regra de reescrita personalizada. No entanto, isso teve dois problemas.
O ponto final sempre teve uma barra final. Tornou-sehttp://mysite.com/my-api.php/
Minha regra de reescrita foi aplicada apenas parcialmente. Não redirecionaria para wp-content/plugins..., redirecionaria para index.php&wp-content/plugins.... Isso levou o WordPress a exibir um erro de página não encontrada ou apenas padronizar a página inicial.
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 .htaccesse analisadas pelo Apache). Você pode escolher de qualquer maneira, dependendo da quantidade de WordPress necessária no seu arquivo chamado.
Regras externas:
A regra externa é a mais fácil de configurar e seguir. Ele será executado my-api.phpno diretório do plugin, sem carregar nada do WordPress.
A regra interna requer mais trabalho: primeiro, adicionamos uma regra de reescrita que adiciona vários consultas, depois tornamos essa consulta pública e, em seguida, precisamos verificar a existência dessa consulta para passar o controle ao nosso arquivo de plug-in. Quando fizermos isso, a inicialização usual do WordPress terá acontecido (nos separamos logo antes da consulta de postagem regular).
Eu só quero acrescentar que é importante ir para a página Permalinks e clicar em "Salvar alterações" no WP-Admin. Eu estava brincando com isso por uma hora antes de pensar que precisava atualizar os permalinks ... A menos que alguém conheça uma função que possa fazer isso?
— Ethanpil 28/05
Para a regra externa: como o caminho para minha raiz da web tinha um caractere de espaço em branco, isso causou uma queda no apache. Espaços em branco precisam ser escapados se existirem no caminho para a instalação do wordpress.
Funciona, mas não consigo acessar nenhuma variável de consulta passada get_query_vars()no meu-api.php. Eu verifiquei quais variáveis ​​estão carregadas. E o único var definido é um WP objectchamado $wp. Como acessar ou transformar isso em um WP_Queryobjeto para que eu possa acessar as variáveis ​​passadas get_query_vars()?
@Jules: Quando você includeum arquivo, ele é executado no escopo atual. Nesse caso, é a wpse9870_parse_requestfunção que possui apenas o $wpparâmetro É possível que o $wp_queryobjeto global não tenha sido definido no momento, portanto get_query_var()não funcionará. No entanto, você tem sorte: $wpé a classe que contém o query_varsmembro que você precisa - eu mesmo o uso no código acima.
tentando criar regras de reescrita externas. acrescentou o seu pedaço punho de código, mas ainda estou recebendo 404. btw: reescrever as regras coradas
Isso funcionou para mim. Eu nunca toco na API de reescrita, mas estou sempre pronto para me impulsionar em novas direções. O seguinte funcionou no meu servidor de teste para 3.0, localizado em uma subpasta localhost. Não vejo nenhum problema se o WordPress estiver instalado na raiz da web.
Basta soltar esse código em um plug-in e enviar o arquivo chamado "taco-kittens.php" diretamente na pasta do plug-in. Você precisará escrever um hard flush para seus permalinks. Eu acho que eles dizem que o melhor momento para fazer isso é na ativação do plugin.
Muitas felicidades, -Mike
Recebi um erro de acesso negado ao tentar esse código. Suspeito que meu servidor ou WP não tenha gostado do URL absoluto. Por outro lado, isso funcionou bem:add_rewrite_rule( 'taco-kittens', 'wp-content/plugins/taco-kittens.php', 'top' );
Você pode me informar o que devo colocar no taco-kittens.php, não tenho conhecimento de .htaccess ou reescrita de URL.
— Prafulla Kumar Sahu
Alguma razão para não fazer algo assim?
Em seguida, basta conectar seu plug-in em 'init' e verificar se essa variável é obtida. Se existir, faça o que seu plug-in precisa fazer e morra ()
Isso funcionaria, mas estou tentando fornecer uma distinção muito clara entre as variáveis ​​de consulta e o ponto de extremidade real. Pode haver outros argumentos de consulta no futuro, e eu não quero que os usuários misturem as coisas.
E se você mantivesse a reescrita, mas reescrevesse para a var GET? Você também pode ver como a reescrita do robots.txt funciona. Pode ajudar você a descobrir como evitar o redirecionamento para my-api.php /
É a solução perfeita se você não se importa com robôs, como chamadas de API.
— beytarovski
Talvez eu não esteja entendendo suas perguntas completamente, mas um código de acesso simples resolveria seu problema?
Peça ao cliente que crie uma página, por exemplo, http://mysite.com/my-api
Peça ao cliente para adicionar um código curto nessa página, ou seja, [my-api-shortcode]
A nova página atua como um ponto final da API e seu código de acesso envia solicitações para o código do plug-in em http://mysite.com/wp-content/plugins/my-plugin/my-api.php
(é claro que isso significa que meu-api.php teria o código abreviado definido)
Provavelmente, você pode automatizar as etapas 1 e 2 através do plug-in.
Ainda não lidei com reescrever muito, então isso provavelmente é um pouco difícil, mas parece funcionar:
Funciona se você conectar isso a 'generate_rewrite_rules', mas deve haver uma maneira melhor, pois você não deseja reescrever .htaccess em cada carregamento de página.
Parece que não consigo parar de editar minhas próprias postagens ... provavelmente deve entrar em você para ativar o retorno de chamada e referenciar global $ wp_rewrite. E, em seguida, remova a entrada de non_wp_rules e a saída para .htaccess novamente, ao desativar o retorno de chamada.
E, finalmente, a escrita em .htaccess deve ser um pouco mais sofisticada, você deseja substituir apenas a seção wordpress.
Eu tinha um requisito semelhante e queria criar vários pontos de extremidade com base em slugs únicos que apontavam para o conteúdo gerado pelo plug-in.
Dê uma olhada na fonte do meu plugin: https://wordpress.org/extend/plugins/picasa-album-uploader/
A técnica que usei começa adicionando um filtro para the_postsexaminar a solicitação recebida. Se o plug-in deve lidar com isso, uma postagem fictícia é gerada e uma ação é adicionada template_redirect.
Quando a template_redirectação é chamada, ela deve resultar na saída de todo o conteúdo da página a ser exibido e sair ou deve retornar sem saída gerada. Veja o código wp_include/template-loader.phpe você verá o porquê.
Estou usando outra abordagem que consiste em forçar a página inicial a carregar um título, conteúdo e modelo de página personalizados .
A solução é muito elegante, pois pode ser implementada quando um usuário segue um link amigável, como http://example.com/ ? Plugin_page = myfakepage
É muito fácil de implementar e deve permitir páginas ilimitadas.
Código e instruções aqui: Gere uma página personalizada / falsa / virtual do Wordpress em tempo real
— Xavi Esteve
Estou usando uma abordagem semelhante à do Xavi Esteve acima, que parou de funcionar devido a uma atualização do WordPress, tanto quanto pude perceber no segundo semestre de 2013.
Está documentado em grandes detalhes aqui: https://stackoverflow.com/questions/17960649/wordpress-plugin-generating-virtual-pages-and-using-theme-template
A parte principal da minha abordagem é usar o modelo existente para que a página resultante pareça fazer parte do site; Eu queria que fosse o mais compatível possível com todos os temas, espero que nas versões do WordPress. O tempo dirá se eu estava certa!