Métodos de integración de datos de complementos con temas

Me gustaría obtener algunas opiniones sobre las mejores prácticas para desarrollar complementos de WordPress que brinden integración de temas.

Para tener sentido al hacer esta pregunta, permítanme comenzar con un ejemplo hipotético de un escenario que me interesa. Imagine que creo un complemento llamado "Discografía". La discografía registra tres tipos de publicaciones personalizadas: "Bandas", "Álbumes" y "Pistas". El complemento también proporciona meta cuadros que proporcionan detalles para cada tipo de publicación, así como taxonomías personalizadas para organizar cada tipo de publicación. Estos tipos de publicaciones están vinculados con el complemento Publicaciones 2 Publicaciones . Dentro del administrador, el usuario puede agregar nuevas bandas, que pueden asociarse con álbumes, que, a su vez, están asociadas con pistas, a todas las cuales se les agregarán muchos otros datos a través de meta cajas y taxonomías.

Ahora, no quiero que este complemento simplemente configure un administrador para que los usuarios ingresen esta información; Me gustaría que proporcionara algunas pantallas predeterminadas para los datos. Un usuario / desarrollador más avanzado estaría bien si solo tuviera este administrador. Sería bastante fácil para ella obtener esos datos y usarlos en el tema; sin embargo, sin algunas vistas predeterminadas, este complemento sería inútil para la mayoría de los usuarios. Para este ejemplo, puede mostrar algo como (los paréntesis muestran las formas en que se puede mostrar la información en orden de jerarquía de plantilla)

• Bandas (single-prefix-band.php, single.php, index.php, shortcode)
• Álbumes (single-prefix-album.php, single.php, index.php, shortcode)
• Pistas (single-prefix-track.php, single.php, index.php, shortcode)
• Listado de banda (template-band-list.php, page-band-listing.php, page- {id} .php, page.php, index.php, shortcode)
• Listado de álbumes (template-album-list.php, page-album-listing.php, page- {id} .php, page.php, index.php, shortcode)
• Línea de tiempo del álbum (template-album-timeline.php, page-album-timeline.php, page- {id} .php, page.php, index.php, shortcode)

Es importante que haya una presentación predeterminada para estos tipos de publicaciones, ya que los archivos de plantilla predeterminados no mostrarán toda la información necesaria para cada uno de los tipos de publicaciones. Por ejemplo, el tema Twenty Eleven, por defecto, solo mostraría el nombre, las categorías, la descripción y la fecha de publicación de un álbum. No es muy útil para un álbum. Me gustaría proporcionar una plantilla de publicación única que atraiga a la banda, la fecha de lanzamiento, el sello discográfico, las versiones del álbum, las pistas, etc. Como desarrollador de complementos, sentiría que sería importante proporcionar eso. Sé que la plantilla no funcionaría para todos los temas, pero debería haber algún valor predeterminado que pueda integrarse aún más con el tema del usuario.

Nuevamente, tengo curiosidad acerca de cuál es la mejor manera de manejar esta situación. Creo que podrías hacer cualquiera de los siguientes.

Shortcodes

Los códigos cortos se pueden usar como una forma muy flexible y fácil de usar para permitir que los no desarrolladores agreguen bandas, álbumes, pistas, listas de bandas, etc. en cualquier parte del sitio. Sería útil para presentar bandas en páginas específicas o crear páginas separadas para cada banda (no muy eficiente, pero algunos usuarios abordan las cosas de esta manera). El shortcode generaría HTML, que estaría vinculado a un archivo CSS proporcionado que proporcionaría una buena vista predeterminada de los datos deseados. Todo estaría contenido dentro de los archivos del complemento y no habría que hacer nada con el tema.

Archivos de plantilla

El complemento también podría enviarse con archivos de plantilla. Los archivos de plantilla se pueden marcar y diseñar para una buena vista predeterminada. Puede proporcionar instrucciones para que su usuario mueva los archivos a la carpeta de temas para que el tema encuentre las plantillas correctas cuando se vean los tipos de publicaciones. Incluso podría ir tan lejos como proporcionar una interfaz que permita al usuario mover los archivos con un solo clic (nota: no crearía archivos en la carpeta de temas del usuario en la activación porque agregar archivos a su tema sin que ellos lo inicien es malo) .

También puede usar filtros para utilizar estos archivos sin moverlos de la carpeta de complementos, manteniendo todo autocontenido. He visto los filtros "template_include" y "{$ type} _template" utilizados para este propósito. De hecho, podría usar plantillas de la carpeta de temas y, si no están presentes, puede recurrir a estos filtros para proporcionar las vistas predeterminadas.

La pregunta

Me gusta saber lo que otros piensan que son las mejores prácticas para estas situaciones, si las ideas presentadas son problemáticas de alguna manera, y cualquier alternativa que no haya incluido.

¡Gracias!

No puedo responder a cada una de las preguntas que solicitó, ya que leer la pregunta tomó suficiente tiempo hasta el momento;), pero trato de darle algunas ideas sobre mi experiencia personal con el desarrollo de complementos gratuitos de código abierto.

1. Nunca hagas demasiado. Las características son la muerte de cada complemento. Cree una versión básica primero y pruebe la reacción de sus usuarios. Si su complemento recibe mucha atención, puede integrar las funciones que se solicitan principalmente.

2. Evite llenar cada caso de uso. Necesita mantener su complemento. WP ofrece una nueva versión cada tres meses. Y a veces es difícil seguir con todos sus complementos. Para hacer un ejemplo: una nueva versión de la API de configuración se discute actualmente en Trac. Cuando esto termine, existe la posibilidad de que muchos desarrolladores de plugins o temas necesiten cambiar una gran parte del código y algunas personas, como yo, incluso hayan escrito una capa de abstracción sobre la API. Por lo tanto, debe regresar, reescribir su capa de base / abstracción y luego volver a trabajar todo lo que se llama parte de eso. Prometo que esto es mucho trabajo. Y aún más si está vinculado a su código. Cuando comienza a llenar una gran cantidad de casos de uso, también obtiene una gran cantidad de evolución del código central de WP que necesita monitorear, así como mucho trabajo para mantener su código actualizado.

3. Nunca intentes incluir muchos ejemplos de código (o plantillas) en tus complementos o temas. Si desea dirigirse a desarrolladores y usuarios finales: use su blog para obtener documentación. Los desarrolladores odian cosas así y los usuarios finales nunca están satisfechos (ver: llenar cada caso de uso).

4. Divida su código sabiamente en archivos individuales. Regla general: un archivo para una parte. Ejemplo: styles.php, scripts.php, taxonomies.php, cpts.php, etc. Cargue todo desde una clase "madre" (fábrica) y mantenga sus cosas "conectables". Si necesita reescribir cosas, lo encontrará fácilmente. Si los desarrolladores están buscando algo: lo encontrarán fácilmente. Muchos archivos bien nombrados, no te hacen daño.

5. Si tiene una lista de estilos básicos (clases), déjela en manos del usuario . Las posibilidades son simplemente demasiado altas, que los estilos del tema u otros complementos interceptarán sus definiciones (sin importar cuánta especificidad agregue). Solo trata de explicarlo en algún lugar con la menor cantidad de texto posible.

6. Me encanta tu plugin. Pero déjalo ir si estás aburrido. :)

Ahora, en pocas palabras, algo sobre su idea de complemento en detalle:

A. Los archivos de plantilla son malos. Como dije: documentarlo en su blog, ofrecer ejemplos de marcas y estilos allí. Su blog se beneficiará (y usted también si tiene anuncios).

B. Los códigos cortos son kool. No le hacen daño a nadie si el complemento se ha ido (en la mayoría de los casos) y luego podría extenderse / evolucionar a botones TinyMCE (que a la gente le encanta).

C. Deje en claro que su complemento necesita otro complemento. Cuestione esto y agregue una nota a admin_notices (a través de register_activation_hook) si el otro complemento no sale (enlace en este caso) o no está activado (puede hacerlo para el usuario en la activación). También tenga en cuenta que este complemento proviene de una fuente confiable y se mantendrá durante los próximos años.

Nota: Nada de lo que escribí es más que mi opinión personal, que refleja mi experiencia.

En algunos aspectos, debe sopesar el equilibrio entre crear un complemento o un tema, si su escenario requiere mucha personalización / características, generalmente siempre es mejor crear un tema. De esa manera, el usuario puede personalizar en términos de apariencia, lo que siempre es más fácil que lograr que el usuario personalice la funcionalidad (al atascar códigos cortos en todas partes), tiene un mayor control de funciones, funciona con otros complementos, etc.

Un complemento que intenta integrarse fuertemente con toda la variedad de temas en el mercado seguramente causará muchos problemas y, honestamente, mucho trabajo para usted.

Por ejemplo, en lugar de crear un complemento muy integrado basado en la gestión de la música y la discografía, cree un tema para ese propósito, esto se está volviendo más popular para los mercados especializados que requieren un trabajo personalizado. Un ejemplo del mundo real sería un tema basado en bienes raíces, no hay forma de que use un complemento para esto, ya que tiene un conjunto de características tan profundo, en su lugar, se crea desde cero como un tema, ya que los temas pueden aprovechar todas las características de los complementos de todos modos.

También es probable que, desde una perspectiva de marketing, un tema de nicho funcione mejor que un complemento al equilibrar las características de front-end.

Páginas virtuales

Una tercera técnica que vi fue asignar una página especial como el marcador de posición para su complemento y usar el filtro 'the_content' para generar lo que necesite.

De esta manera, puede hacer plantillas que se combinen con la estructura del tema, ya que no tiene que lidiar con encabezados, barras laterales, pies de página y divisiones de envoltura.

Un gran ejemplo de esto se puede encontrar en el complemento bbPress:

http://bbpress.trac.wordpress.org/browser/branches/plugin/bbp-includes/bbp-core-compatibility.php?rev=3434#L931