Como substituir a função conectável no tema?

Toda a documentação que encontrei discute a substituição da função conectável através do seu plugin.

E se você estiver desenvolvendo o tema?

Minhas funções.php requer outro arquivo que substitua a get_user_by()função, definida em pluggable.php.

Se eu omitir a if( function_exists() )chamada, recebo o erro "Não é possível redefinir ...".

Se eu incluir a if( function exists() )chamada, não receberei nenhum erro, mas é claro que minha função será ignorada, pois a versão conectável existe.

Com base na publicação impressionante de Dominic na ordem de inicialização do WordPress , é claro que ele pluggable.phpé carregado antes do tema functions.phpe assim por diante, o que explica o erro.

Portanto, a pergunta é: como você pode tirar proveito dessa bela arquitetura conectável de dentro de um tema, sem recorrer a escrever plug-ins que devem ser empacotados ou instalados com o tema?

Notas adicionais : Portanto, parece que o argumento é que os temas não devem estar tentando fazer o que os plug-ins fazem. Mas esse argumento tem mais de quatro anos (de acordo com o número trac de quatro dígitos). Eu adoraria ouvir de alguns críticos importantes se essa filosofia ainda se aplica, dada a topologia complexa do cenário atual de desenvolvimento de temas. Eu gostaria de acreditar que evoluímos desde então.

Contexto : estou desenvolvendo uma solução CMS única para um cliente, com muitos metadados personalizados, personalização do back-end de administrador, processo de login / autenticação e obras. E, é claro, existe o componente de design - é aí que entra a parte do tema. O fato é que esses simplesmente não são componentes reutilizáveis ​​- eles nunca se aplicam a outro cliente, nunca serão colocados sob a GPL e são de código aberto, e são mais certamente não deve ser distribuído / instalado em outras implantações do WordPress. Na melhor das hipóteses, existem algumas práticas recomendadas que utilizarei em projetos futuros, mas isso será estritamente um trabalho de referência / copiar e colar.

Isso não soa como um caso de uso para plugins para mim. O tema está instalado, talvez um tema filho do Twenty Eleven, talvez um autônomo, suas funções. O php chama um monte de inclusões, cada uma tratando de um aspecto diferente do CMS em questão. Em seguida, os arquivos de modelo de tema usam 'tags de modelo' personalizadas definidas nas inclusões. Eu não quero ter arquivos de tema com dependências de algum plug-in ou outro sendo ativado, etc. Não faz sentido criar complexidade no sistema. Claro, posso colocá-lo na pasta de plugins obrigatórios, mas isso ainda parece um hack - agora, tudo o que tem a ver com as personalizações feitas para este projeto está contido wp-content/themes/my-theme/. Também não quero considerar procurar coisas em algumas pastas de plugins.

Não me interpretem mal. Eu amo plugins e os uso e os escrevo. E eu uso plugins em conjunto com esse tipo de desenvolvimento de tema altamente personalizado quando o plug-in é de terceiros e representa práticas recomendadas muito além do que eu poderia implementar em um prazo razoável. Mas quando preciso modificar a funcionalidade principal para um cenário único, recorro a ganchos de ação, ganchos de filtro e gostaria de poder contar com funções conectáveis ​​também para o usuário e a autenticação.

Se você estiver criando isso para um único cliente, você deve absolutamente tirar proveito mu-plugins.

Há muitas coisas no WordPress que você não pode fazer functions.php. As funções conectáveis ​​são uma delas, mas mais óbvia, vários ganchos (ações e filtros) são acionados antes functions.php. Em alguns casos, esses ganchos mu-pluginssão acionados antes de plug-ins comuns, que exigem o uso de um plug-in ativado por rede. Ainda em outros casos, até um mu-plugin é tarde demais. Talvez você precise de algo sunrise.php. Ou mesmo algo (constante ou não) em wp-config.php.

Prefiro adicionar alguns ganchos às funções conectáveis, do que para facilitar a substituição deles. É provável que nunca mais tenhamos outra função conectável - eles pré-datam ganchos e eu quase nunca vi uma situação em que haja vantagem sobre eles em relação a um gancho antiquado (novo?).

Eu ainda concordo, seis anos depois, com Andy Skelton - "Existem muitas diferenças entre o arquivo de funções de um tema e um plug-in. Vamos continuar assim."

Tudo isso à parte, uma mudança como essa nunca poderia acontecer. Isso quebraria muitas coisas. Inúmeros temas chamam funções no corpo functions.phpque resultariam em um erro fatal se pluggable.phpjá não tivessem sido carregados - como current_user_can(), ou wp_create_nonce(). Todos eles falhariam. E também quebraria plugins, que normalmente poderiam começar a chamar essas funções plugins_loaded. (Apenas mova para pluggable.phpbaixo wp-settings.phpe aposto que metade do núcleo quebraria - ou, pelo menos, o personalizador quebraria.)

Por fim, existe a ideia inevitável de que um tema possa incluir um arquivo separado como o pluggable.phpque poderíamos carregar assim que carregarmos plug-ins e, portanto, substituir as funções conectáveis. Além de ser uma má idéia (consulte os quatro primeiros parágrafos deste comentário), ainda não seria compatível, porque até o setup_themegancho, seria possível substituir o tema a ser carregado, filtrando os valores da folha de estilo e do modelo.

Infelizmente, isso não é sustentável, considerando como o WordPress é arquitetado. O bom é que existem inúmeras (melhores) maneiras de fazer isso.

(Originalmente publicado aqui: http://core.trac.wordpress.org/ticket/2479#comment:5 )

No contexto de um projeto único, é absolutamente apropriado inserir código obrigatório mu-plugins. Se "ter tudo em um só lugar" for uma preocupação, basta fazer um link simbólico no diretório do tema para o mu-pluginsmenu suspenso, para que ele apareça ao pesquisar o diretório do tema.

Não consigo pensar em uma maneira de fazer isso, muito cedo na sequência de carregamento.

A solução mais próxima da sã seria adicionar inclusões personalizadas wp-config.php(por código ou pedir ao usuário), mas comparar com esse plug-in de agregação provavelmente faria mais sentido.