Adicionar ponto final do reescrita quebra a frente estática

Eu tenho uma página inicial estática para o meu conjunto de instalação WP a partir das settings > reading . Então eu adicionei um ponto final de URL usando.

 add_rewrite_endpoint('foo', EP_ALL); 

Então, a primeira página deve ser acessível através de

 http://example.com/ http://example.com/foo http://example.com/foo/bar 

Para o # 1 Tudo funciona bem, mas para # 2 e # 3 default home.php é mostrado em vez de página inicial estática. Testado localmente na instalação de um único e multisite.

É um comportamento desejado ou acerta algo incomum? Mais importante ainda, como posso fazer WP para mostrar a página inicial estática na condição dada?

Solução

Eu já estava parse_request no parse_request para processar parte do código se houver. Assim, de acordo com a solução da @mackzap. Eu só preciso desbloqueá-lo depois. Não é necessário necessidade de function adicional gancho para ignorar o erro.

 add_action('parse_request', function(&wp){ $key = 'foo'; if (!array_key_exists( $key, $wp->query_vars ) ) { return; } // do things when foo exists // we no longer need 'foo' unset($wp->query_vars[$key]); }); 

Solutions Collecting From Web of "Adicionar ponto final do reescrita quebra a frente estática"

Talvez eu não tenha obtido isso muito bem, mas se você precisa simplesmente remover 'foo' da consulta, o vars não seria muito mais simples de usar o filtro 'request' e remover o var a partir dele?

Código necessário:

 add_filter('request', function($query_vars) { return array_diff_key($query_vars, array('foo'=>'')); }); 

Isto:

  • é executado somente na consulta principal
  • remova o object var para $wp
  • age antes que a consulta seja definida em $wp_query , então não é necessário remover a consulta a partir daí
  • não afeta todas as outras variables

Editar:

Um problema deste código é que ele é executado muito cedo, de modo que será difícil pegar a presença da variável de consulta e fazer algo com base em sua presença / valor.

Uma solução pode ser executar as condições no mesmo filtro 'request' , antes de remover a var. Consulta (por exemplo, usando o mesmo gancho com maior prioridade).

Outra solução pode ser adicionar uma bandeira para $wp object:

 add_filter('request', function($query_vars) { $GLOBALS['wp']->_foo = isset($query_vars['foo']) ? $query_vars['foo'] : false; return array_diff_key($query_vars, array('foo'=>'')); }); 

Depois disso, seria possível verificar a variável ‘foo’ em qualquer gancho triggersdo após 'request' , o mais antigo é 'parse_request'

 add_action('parse_request', function($wp) { $foo = $wp->_foo; // do something with foo }); 

O último é 'shutdown' :

 add_action('shutdown', function() { $foo = $GLOBALS['wp']->_foo; // do something with foo }); 

Este é um erro 25143 como o @toscho apontou e será corrigido em 4.3

Solução encontrada no bilhete e modificada um pouco

WordPress adiciona foo como consulta var que causa o problema. Então, precisamos removê-lo antes do WP consultar o database

 add_action( 'pre_get_posts', 'wpse191771_unset_query_arg' ); function wpse191771_unset_query_arg($query){ if ( is_admin() || ! $query->is_main_query() ) { return; } $key = 'foo'; $query_vars =& $query->query_vars; if ( array_key_exists($key, $query_vars) ) { // unset ref var from $wp_query $query->set( $key, null ); global $wp; // unset ref var from $wp unset( $wp->query_vars[ $key ] ); // if in home (because $wp->query_vars is empty) and 'show_on_front' is page if ( empty( $wp->query_vars ) && get_option( 'show_on_front' ) === 'page' ) { // reset and re-parse query vars $wp->query_vars['page_id'] = get_option( 'page_on_front' ); $query->parse_query( $wp->query_vars ); } } }