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

¿Existe un esquema fácil de entender para decidir qué tipo de código pertenece a un complemento o al tema functions.php?

No son muchos los casos y muchos debates sobre ese tema, sobre todo porque hay algunos conceptos erróneos sobre el funcionamiento interno de WordPress. Estoy pidiendo una respuesta basada en hechos, no en opiniones.

Debería explicar cómo manejar estos puntos (y probablemente más):

• tipos de publicaciones personalizadas y taxonomías
• formularios de contacto
• códigos cortos
• widgets personalizados
• add_theme_support( 'automatic-feed-links' );
• Funciones de SEO como metaelementos personalizados
• cambio de tema

A menudo hay ventajas y desventajas para ambos lados. Nuestra pregunta más popular La mejor colección de código para su archivo functions.php tiene muchos fragmentos de código como respuestas que son al menos discutibles.
Necesitamos criterios que un principiante pueda entender, tal vez una lista de verificación, con razones.

Vea también la pregunta relacionada de Chip Bennett en nuestro meta sitio: Preguntas que piden específicamente una solución "sin un complemento"

Relacionado: ¿Dónde pongo los fragmentos de código que encontré aquí o en otro lugar en la web?

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

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

• Modificación de los filtros centrales de WP ( wp_headcontenido, como enlaces canónicos, generador y otros meta HTML, etc.
• Sitio Favicon
• Códigos cortos posteriores al 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 la presentación de contenido , entonces es un candidato para ser incluido en el Tema. En este punto, volvería al criterio de cambio de tema de @ Raf912 : ¿extrañaría la funcionalidad cuando cambie de tema? Si la respuesta a esa pregunta es no , entonces la funcionalidad pertenece al Tema. Algunos ejemplos:

• Eliminar / anular el CSS de la galería principal de WP
• Filtrar la longitud del extracto de la publicación, el 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 publicaciones personalizadas

Los tipos de publicaciones personalizadas, por ejemplo, son un poco un híbrido único de generación y presentación de contenido, dada la forma en que la Jerarquía de plantillas funciona para páginas de índice de archivo de tipo de publicación única 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 del complemento; sin embargo, los complementos no pueden definir páginas de plantilla que encajen inherentemente en el diseño / diseño / estilo para un tema determinado (especialmente si el CPT muestra otro título / contenido / meta habitual, o tiene taxonomías personalizadas asociadas a él).

A largo plazo, la solución a esta disparidad, en mi humilde opinión, 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, entradas de libros / bibliotecas de medios, etc. .). De esa manera, el contenido generado por el usuario permanecería portátil entre los Temas que implementan la definición estándar / convención de un CPT dado, mientras que los desarrolladores de Temas 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

Del mismo modo, normalmente diría que los enlaces de perfil de redes sociales, que se han vuelto omnipresentes en los Temas actuales, son Territorio de complementos, porque no tienen nada que ver con la presentación de contenido. La mejor solución sería que estos perfiles se definan en algún lugar del núcleo; sin embargo, actualmente no hay medios 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 queda expuesto en la plantilla? etc.

De nuevo, a largo plazo, la solución a esta disparidad es que el núcleo defina dónde se definen estos enlaces o que la comunidad de desarrolladores de Theme 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:

• escribe el código en functions.php
• cambiar de tema

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

  • sí: ponerlo en un complemento

  • no: déjalo en functions.php

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

Escriba una función para enumerar 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 bosquejo de tal diagrama de flujo, que puede y debe expandirse. ¡Comenta con sugerencias!

• ¿Este código se alojará en una instalación de WordPress en un solo sitio?
  • Sí, ¿el tema del sitio solo cambia con importantes rediseños y cambios en la funcionalidad?
    • Sí, ¿el código en cuestión es específico para este diseño actual ?
      • Sí: functions.php
      • No: complemento
    • No (cambia a menudo o por capricho) - Complemento
  • No (Multsisite): ¿está alojando la instalación multisitio O es una solución alojada multisitio que permite complementos?
    • Sí: ¿la funcionalidad en cuestión es específica de este sitio , o puede / debería ser utilizada por otros sitios en la red?
      • Específico para este sitio: functions.php
      • Compartido entre múltiples sitios: ¿Desea forzarlo en cada sitio?
        • Sí: complemento, almacenado en el directorio de complementos mu 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 vio o activó 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: complemento
          • No: probablemente plugin
    • No (alojado por 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 poner la funcionalidad en el archivo functions.php del tema principal.
• Los directorios de complementos de grandes instalaciones multisitio pueden volverse rápidamente rebeldes, por lo que a veces la funcionalidad compartida utilizada por un bajo porcentaje de sitios (p. Ej., <1%) sería mejor duplicar en archivos functions.php.

Desde aquí Temas VS Complementos

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 del sitio que también contenga todo su código personalizado.

En cuanto a escribir código versus complementos, puede usar 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 meta cuadros donde puede considerar usar un complemento a menos que Eres 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');

http://codex.wordpress.org/Plugin_API/Filter_Reference/user_contactmethods

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

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

Si se gana la vida con la programación y se encuentra trabajando en sitios de WordPress dentro de los plazos, encontrará que realmente 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 agregar lo que necesites en un tema y ponerlo en práctica.

Dicho esto, si trabaja en WordPress de forma semi regular, debería considerar seriamente hacer lo siguiente :

1. Construye un esqueleto de plugin

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 lleva mucho tiempo adicional agregar funcionalidad a través de complementos
• Puede comenzar a crear una lista sólida de complementos para reutilizar en otros proyectos según sea necesario, ahorrándose mucho tiempo a largo plazo.
• Puede ponerlos a disposición del público si desea visibilidad adicional

Ahora puede construir las cosas correctamente y realizar proyectos futuros más rápidamente.

2. Construye un esqueleto temático

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

• Una hoja de estilo central 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á tanto, pero seguirá siendo útil.

Una vez que lo hayas hecho, construye un esqueleto de tema hijo que use tu tema principal.

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

Una vez que haya hecho estas dos cosas, crear nuevos sitios para las personas se vuelve mucho más rápido.

Si hace lo anterior, puede trabajar en lo siguiente:

• Dedique su nuevo tiempo libre a familiarizarse con PHP, WordPress, JavaScript, CSS y / o mySQL ... cuanto más aprenda de ellos, más rápido podrá hacer las cosas.
• Actualice su plugin, tema y esqueletos de temas secundarios 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 hace todo lo anterior , encontrará que la respuesta de Chip no solo será ideal, sino que se volverá ó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 ponga un tema.

¿Desea que este código sea transferible entre sitios y entre temas? Si es así, entonces agregue un complemento.

Si la respuesta es no a las dos anteriores, imagínese el sitio 5 años en el futuro, cuando sea el momento de un rediseño. ¿La función del código que está escribiendo es algo que sobrevivirá a la próxima actualización de diseño? En caso afirmativo, agregue un complemento.

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