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.