¿Cómo anular la función conectable en el tema?

Toda la documentación que he encontrado trata sobre la anulación de la función conectable a través de su complemento.

¿Qué pasa si estás desarrollando un tema en su lugar?

My functions.php requiere otro archivo que anule la get_user_by()función, definida en pluggable.php.

Si omito la if( function_exists() )llamada, aparece el error "No se puede volver a declarar ...".

Si incluyo la if( function exists() )llamada, no recibo ningún error, pero, por supuesto, mi función se ignora, ya que existe la versión conectable.

Según la impresionante publicación de Dominic en el pedido de inicio de WordPress , está claro que pluggable.phpse carga antes que el tema functions.phpy así sucesivamente, por lo que eso explica el error.

Entonces, la pregunta es: ¿cómo puede aprovechar esa agradable arquitectura enchufable desde un tema, sin recurrir a escribir complementos que luego se deben agrupar o instalar con el tema?

Notas adicionales : Parece que el argumento es que los temas no deberían estar tratando de hacer lo que hacen los complementos. Pero ese argumento tiene más de cuatro años (según el número de trac de 4 dígitos). Me encantaría saber de algunos grandes bateadores si esta filosofía aún se aplica, dada la compleja topología del panorama actual de desarrollo de temas. Me gustaría creer que hemos evolucionado desde entonces.

Contexto : estoy desarrollando una solución única de CMS para un cliente, con muchos metadatos personalizados, personalización del back-end de administración, el proceso de inicio de sesión / autenticación, el trabajo. Y, por supuesto, está el componente de diseño, ahí es donde entra la parte del tema. El hecho es que estos simplemente no son componentes reutilizables: nunca se aplicarán a otro cliente, nunca se colocarán bajo GPL y de código abierto, y son la mayoría ciertamente no se distribuirá / instalará en otras implementaciones de WordPress. En el mejor de los casos, hay algunas mejores prácticas que aprovecharé en futuros proyectos, pero eso será estrictamente un trabajo de referencia / copiar y pegar.

Esto no me parece un caso de uso de complementos. El tema está instalado, tal vez un tema secundario de Twenty Eleven, tal vez de forma independiente, sus funciones. Php invoca un montón de incluye, cada uno manejando un aspecto diferente del CMS en cuestión. Luego, los archivos de plantilla de tema usan 'etiquetas de plantilla' personalizadas que se definen en las inclusiones. No quiero que se activen archivos de tema con dependencias de algún complemento u otro, etc. Simplemente no tiene sentido crear complejidad en el sistema. Claro, puedo ponerlo en la carpeta de complementos de uso obligatorio, pero eso todavía se siente como un truco: en este momento, todo lo que tiene que ver con las personalizaciones realizadas para este proyecto está contenido wp-content/themes/my-theme/. Tampoco quiero tener que considerar buscar cosas en algunas carpetas de complementos.

No me malinterpretes. Me encantan los complementos y los uso y los escribo. Y uso complementos junto con este tipo de desarrollo de temas altamente personalizado cuando el complemento es de un tercero y representa las mejores prácticas mucho más allá de lo que podría implementar en un plazo razonable. Pero cuando necesito modificar la funcionalidad principal para un escenario único, recurro a ganchos de acción, ganchos de filtro, y me gustaría poder confiar en funciones conectables para el lado del usuario y la autenticación también.

Si está creando esto para un solo cliente, debería aprovecharlo mu-plugins.

Hay muchas cosas en WordPress que no puedes hacer functions.php. Las funciones conectables son una de ellas, pero más obvio, una serie de ganchos (tanto acciones como filtros) se activan antes functions.php. En algunos casos, estos ganchos incluso se mu-pluginsactivan antes que los complementos normales, lo que luego requiere que uses un complemento activado por la red. En otros casos, incluso un plugin mu es demasiado tarde. Quizás necesites algo adentro sunrise.php. O incluso algo (constante o no) en wp-config.php.

Prefiero agregar algunos ganchos a las funciones conectables, que hacer que sea más fácil anularlas. Es probable que nunca más tengamos otra función enchufable: son anteriores a los ganchos y casi nunca he visto una situación en la que tengan ventaja sobre un buen gancho anticuado (¿nuevo?).

Todavía estoy de acuerdo, seis años después, con Andy Skelton: "Hay muchas diferencias entre el archivo de funciones de un tema y un complemento. Mantengámoslo así".

Aparte de eso, un cambio como este nunca podría suceder. Rompería muchas cosas. Innumerables funciones de llamadas de temas en el cuerpo de functions.phpeso darían como resultado un error fatal si pluggable.phpaún no se hubiera cargado, como current_user_can(), o wp_create_nonce(). Todos fallarían. Y también rompería los complementos, que normalmente podrían comenzar a activar estas funciones plugins_loaded. (Simplemente muévase pluggable.phpmás abajo wp-settings.phpy apuesto a que la mitad del núcleo se rompería, o al menos, el personalizador lo haría).

Finalmente, existe la idea inevitable de que un tema podría incluir un archivo separado como el pluggable.phpque podríamos cargar tan pronto como carguemos los complementos y, por lo tanto, podría anular las funciones conectables. Además de ser una mala idea (ver los primeros cuatro párrafos de este comentario), aún no sería compatible, porque hasta el setup_themegancho, uno podría anular qué tema se cargará al filtrar los valores de la hoja de estilo y la plantilla.

Desafortunadamente, esto no es sostenible debido a la arquitectura de WordPress. Lo bueno es que hay innumerables (mejores) formas de hacerlo.

(Publicado originalmente aquí: http://core.trac.wordpress.org/ticket/2479#comment:5 )

En el contexto de un proyecto único, es absolutamente apropiado colocar código de uso obligatorio mu-plugins. Si "tenerlo todo en un lugar" es una preocupación, simplemente haga un enlace simbólico en el directorio del tema al mu-pluginsmenú desplegable, para que aparezca cuando busque en el directorio del tema.

No puedo pensar en una forma de lograr esto, demasiado pronto en la secuencia de carga.

La solución más cercana a la sensata sería agregar inclusión personalizada a wp-config.php(por código o pedirle al usuario que lo haga), pero la comparación con ese complemento de paquete probablemente tendría más sentido.