¿Dónde colocar mi código: plugin o functions.php?

Comenzaría con esta pregunta: ¿Está la funcionalidad relacionada con presentación de contenido, o con generación / administración de contenido, o del sitio, o de la identidad del usuario?

Si la funcionalidad no está relacionada específicamente con presentación de contenido , entonces está directamente dentro del territorio de Plugin. Esta lista es larga:

• Modificación de los filtros principales de WP ( wp_head de contenido, como enlaces canónicos, generador y otros meta HTML, etc.
• Site Favicon
• Códigos abreviados de contenido
• Publicar enlaces para compartir
• scripts de pie de página de Google Analytics (y similares)
• herramientas / controles de SEO
• etc.

Si la funcionalidad está relacionada con presentación de contenido , entonces es un candidato para ser incluido en el Tema. En este punto, volvería a criterio de cambio de tema de @ Raf912 : perdería la funcionalidad cuando ¿Cambia de tema? Si la respuesta a esa pregunta es no , la funcionalidad pertenece al tema. Algunos ejemplos:

• Eliminando / anulando el CSS de la galería principal de WP
• Filtrado de la longitud del extracto de la publicación, texto "leer más", etc.
• Todo lo implementado a través de add_theme_support() (supongo que este debería ser obvio)
• CSS personalizado

Normalmente, estas dos preguntas proporcionarán una línea de diferenciación bastante clara; sin embargo, hay excepciones.

Tipos de mensajes personalizados

Los tipos de publicación personalizados, por ejemplo, son un poco de un híbrido único de generación y presentación de contenido, dada la forma en que funciona la Jerarquía de plantillas para el tipo de publicación única archivar las páginas de índice y páginas de publicación única . El aspecto de generación de contenido de los CPT normalmente los ubicaría directamente en el territorio de Plugin; sin embargo, los complementos no pueden definir páginas de plantilla que se ajusten de manera inherente al diseño / diseño / estilo de un tema determinado (especialmente si el CPT muestra un título / contenido / meta distinto del habitual, o tiene taxonomías personalizadas asociadas a él).

A largo plazo, la solución a esta disparidad, IMHO, es tener una convención / consenso estándar para la definición de CPT para determinados tipos de contenido (listados de bienes raíces, eventos de calendario, productos de comercio electrónico, biblioteca de libros / medios entradas, etc.). De esa manera, el contenido generado por el usuario se mantendría portátil entre los Temas que implementan la definición estándar / convención de un CPT dado, mientras que los desarrolladores del Tema conservan la flexibilidad para definir el diseño / diseño / estilo de ese CPT en los archivos de plantilla del Tema.

Enlaces de redes sociales

De forma similar, normalmente diría que los enlaces de perfil de redes sociales, que se han convertido en casi todos los temas actuales, son Territorio de Plugins, porque no tienen nada que ver con la presentación de contenido. La mejor solución sería que estos perfiles se definieran en algún lugar del núcleo; sin embargo, actualmente no existe un medio estándar / de consenso para definir estos enlaces. ¿Están mejor definidos en el nivel de configuración del sitio, o por usuario? Si es por usuario, ¿qué meta del usuario se expone en la plantilla? etc.

De nuevo, a largo plazo, la solución a esta disparidad es que cualquiera de los núcleos defina dónde se definen estos enlaces, o bien que la comunidad de desarrolladores del Tema desarrolle su propio consenso. Mientras tanto, realmente no hay nada más que mantenerlos definidos dentro de cada tema.

Una prueba fácil donde el código está mejor ubicado:

• escriba el código en functions.php
• cambiar tema

• ¿Echas de menos la funcionalidad, el blog no funciona correctamente o quedan fragmentos del tema anterior (por ejemplo, códigos cortos)?

  • sí: póngalo en un complemento

  • no: déjelo en functions.php

Ejemplos: Escribe un código corto. Después de cambiar el tema, los códigos cortos se dejan en tus publicaciones. Por lo tanto, se colocará mejor en un complemento.

Escribe una función para listar los últimos comentarios. Después de cambiar el tema, todo está bien porque quizás el otro tema tenga una función equivalente.

Realmente depende del código y de lo que hará. Algunos códigos solo influyen en el estilo o el contenido del tema, otros modificarán las publicaciones del blog.

No creo que haya una respuesta fácil a esta pregunta, pero apuesto a que podríamos hacer un diagrama de flujo para ayudar con la decisión. Aquí hay un resumen aproximado de dicho diagrama de flujo, que puede y debe expandirse. ¡Comenta con sugerencias!

• ¿Este código se alojará en una instalación de WordPress de un solo sitio?
  • Sí. ¿El tema del sitio solo cambia con los principales rediseños y cambios en la funcionalidad?
    • Sí. ¿Es el código en cuestión específico para este diseño actual ?
      • Sí: functions.php
      • No: Plugin
    • No (cambia a menudo o por capricho) - Complemento
  • No (Multsisite): ¿Aloja la instalación multisitio O es una solución multisitio alojada que permite complementos?
    • Sí: ¿Es la funcionalidad en cuestión específica de este sitio , o puede / debe ser utilizada por otros sitios en la red?
      • Específico a este sitio: functions.php
      • Compartido entre varios sitios: ¿quieres forzarlo en todos los sitios?
        • Sí: complemento, almacenado en el directorio mu-plugins o activado por red
        • No: ¿Es esta una red de sitios no relacionados ? (por ejemplo, diferentes clientes)
          • Sí: ¿sería malo o poco profesional si el cliente A viera o activara el complemento que escribió para los clientes B, C y D? (por ejemplo, tal vez rompería el sitio o causaría una funcionalidad no deseada)
            • Sí: functions.php
            • No: Plugin
          • No: probablemente plugin
    • No (alojado en un servicio como VIP que no permite complementos): use functions.php

• Temas principales: a veces, con la funcionalidad compartida, sería mejor crear un tema principal y colocar la funcionalidad en el archivo functions.php del tema principal.
• Los directorios de complementos de grandes instalaciones multisitio pueden convertirse rápidamente en ingobernables, por lo que a veces la funcionalidad compartida utilizada por un bajo porcentaje de sitios (por ejemplo, < 1%) sería mejor duplicar en los archivos functions.php.

Desde aquí Themes VS Plugins

Agregue código personalizado a un tema secundario para que cuando actualice el tema principal, su código personalizado no se pierda.

También puede crear un complemento específico para el sitio que también contiene todo su código personalizado.

En cuanto a la escritura de código frente a los complementos, puede usar los complementos y las funciones; sin embargo, para la mayoría de lo que desea, la codificación manual es la mejor, ya que es más fácil de modificar, excepto en algunos casos, como los metacuadros, en los que puede considerar usar un plugin a menos que seas un desarrollador de temas.

 function modify_contact_methods($profile_fields) {

// Add new fields
$profile_fields['twitter'] = 'Twitter Username';
$profile_fields['facebook'] = 'Facebook URL';
$profile_fields['gplus'] = 'Google+ URL';

return $profile_fields;
}
add_filter('user_contactmethods', 'modify_contact_methods');

enlace

1. Agregar un nuevo tipo de publicación personalizada: Código
2. Agregue nuevos campos a los usuarios - Código arriba
3. Agregar nuevos widgets - Código
4. Agregue enlaces permanentes personalizados - Configuración de Permalink de WordPress

Sé que este es un caballo muerto y que Chip lo ha cubierto bastante, pero quería agregar algunas ideas.

Si te ganas la vida de una programación y te encuentras trabajando en sitios de wordpress con fechas límite, descubrirás que todo se reduce a tiempo.

La mayoría de las veces, especialmente para aquellos que recién comienzan, es mucho más rápido y sencillo simplemente agregar lo que necesite en un tema y terminarlo.

Dicho esto, si trabajas en wordpress de forma regular, deberías considerar seriamente hacer lo siguiente :

1. Crea un esqueleto de complementos

Esto debería manejar todo lo que normalmente necesitará hacer con un complemento, incluida la activación, desactivación, actualización de versiones, creación de paneles de administración y desinstalación.

Si se toma el tiempo para hacer esto, encontrará:

• Ya no toma mucho tiempo extra para agregar funcionalidad a través de complementos
• Puede comenzar a crear una lista sólida de complementos para reutilizarlos en otros proyectos según sea necesario, ahorrándose mucho tiempo a largo plazo.
• Puede hacer que estén disponibles públicamente si desea visibilidad adicional

Ahora puedes construir las cosas correctamente y hacer que los proyectos futuros se realicen más rápidamente.

2. Crea un esqueleto de tema

Esto debería manejar todo lo que comúnmente se necesita en un tema:

• Una hoja de estilo principal que contiene los estilos que usa comúnmente (restablecimientos, etc.)
• Un archivo index.php adecuado, que maneja todo lo que necesita para cualquier plantilla
• Un archivo functions.php: no lo usarás casi tanto, pero seguirá siendo útil.

Una vez que hayas hecho eso, crea un esqueleto de tema secundario que use tu tema principal.

• Agregue la hoja de estilo, haciendo referencia a su tema principal.
• Agrega el archivo functions.php

Una vez que haya hecho estas dos cosas, la creación de nuevos sitios para las personas se vuelve mucho más rápida.

Si haces lo anterior, puedes trabajar en lo siguiente:

• Pase su nuevo tiempo libre encontrado para familiarizarse con PHP, WordPress, JavaScript, CSS y / o mySQL ... cuanto más aprenda de estos, más rápido podrá hacer las cosas.
• Actualice los esqueletos de su plugin, tema y tema infantil a medida que encuentre cosas que debería mejorar. No importa lo bueno que seas, si sigues aprendiendo, encontrarás mejoras por hacer.

Y, si haces todo lo anterior , encontrarás que la respuesta de Chip no solo será ideal, sino que también será óptima.

La respuesta simple es esta ...

¿El código depende de alguna de las funciones integradas en un tema específico? Si es así, entonces pon un tema.

¿Desea que este código sea transferible entre sitios y entre temas? Si es así, a continuación, coloque un complemento.

Si la respuesta es negativa a las dos anteriores, entonces imagínese el sitio 5 años en el futuro, cuando sea el momento de un nuevo diseño. ¿Es la función del código que está escribiendo algo que sobrevivirá a la próxima actualización de diseño? Si es así, pon un plugin.

Además, si no está utilizando temas secundarios y planea actualizar el tema, también le sugiero que use un complemento.