plugin-development – Métodos para integrar datos de complementos con temas

Pregunta:

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

Para que tenga sentido al plantear esta pregunta, permítanme comenzar con un ejemplo hipotético de un escenario por el que tengo curiosidad. Imagina que creo un complemento llamado "Discografía". Discografía registra tres tipos de publicaciones personalizadas: "Bandas", "Álbumes" y "Pistas". El complemento también proporciona metacajas 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 se pueden asociar con álbumes, que, a su vez, se asocian con pistas, a todas las cuales se les agregarán muchos otros datos a través de metacajas 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 tomar 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, podría mostrar algo como (los paréntesis muestran las formas en que se puede mostrar la información en el orden de la jerarquía de la 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 bandas (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ían toda la información necesaria para cada uno de los tipos de publicaciones. Por ejemplo, el tema Twenty Eleven, de forma predeterminada, 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 incluya la banda, la fecha de lanzamiento, el sello discográfico, las versiones del álbum, las pistas, etc. Como desarrollador de complementos, creo que sería importante proporcionarlo. Sé que la plantilla no funcionaría para todos los temas, pero debería haber algunos predeterminados que se puedan integrar aún más con el tema del usuario.

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

Códigos cortos

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 lugar del sitio. Sería útil presentar bandas en páginas específicas o crear páginas separadas para cada banda (no es muy eficiente, pero algunos usuarios abordan las cosas de esta manera). El código abreviado 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 sería necesario 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 del tema para que el tema encuentre las plantillas adecuadas cuando se visualicen los tipos de publicaciones. Incluso podría llegar a proporcionar una interfaz que le permita al usuario mover los archivos con un solo clic (nota: no crearía archivos en la carpeta del tema 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 fuera de la carpeta del complemento, manteniendo todo autónomo. He visto los filtros "template_include" y "{$ type} _template" utilizados para este propósito. De hecho, puede 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 cuáles piensan los demás que son las mejores prácticas para estas situaciones, si las ideas presentadas son problemáticas de alguna manera y las alternativas que no he incluido.

¡Gracias!

Respuesta:

No puedo responder todas y cada una de las preguntas que preguntaste, ya que leer la Q me llevó bastante tiempo hasta ahora;), pero trato de darte algunas ideas sobre mi experiencia personal con el desarrollo de complementos de código abierto gratuitos.

1. Nunca hagas demasiado. Las características son la muerte de todos los complementos. Primero construya una versión básica y pruebe la reacción de sus usuarios. Si su complemento recibe mucha atención, puede integrar las funciones que más se solicitan.

2. Evite llenar todos los casos de uso. Necesita mantener su complemento. WP ofrece una nueva versión cada tres meses. Y a veces es difícil de 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 complementos o temas necesiten cambiar una gran parte del código y algunas personas, como yo, incluso hayan escrito una capa de abstracción por encima de la API. Por lo tanto, debe volver atrás, reescribir su capa de base / abstracción y luego volver a trabajar todo lo que llama partes de eso. Prometo que esto es mucho trabajo. Y aún más si está ligado estrictamente a su código. Cuando comienza a completar muchos casos de uso, también obtiene una gran cantidad de evolución del código central de WP que necesita monitorear, así como también tiene mucho trabajo para mantener su código actualizado.

3. Nunca intente incluir muchos ejemplos de código (o plantillas) en sus complementos o temas. Si desea dirigirse a desarrolladores y usuarios finales: utilice su blog como documentación. Los desarrolladores odian este tipo de cosas y los usuarios finales nunca están satisfechos (ver: completar todos los casos de uso).

4. Divida su código sabiamente en archivos individuales. Regla de oro: una lima para una parte. Ejemplo: styles.php, scripts.php, taxonomies.php, cpts.php, etc. Cargue todo desde una clase "madre" (de fábrica) y mantenga sus cosas "conectables". Si necesita reescribir algo, 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. Amo su complemento. Pero déjalo ir si estás aburrido. 🙂


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

A. Los archivos de plantilla son malos. Como dije: documente en su blog, ofrezca ejemplos de marcado y estilos allí. Tu blog se beneficiará (y tú también si tienes anuncios).

B. Los códigos cortos son kool. No dañan a nadie si el complemento desaparece (en la mayoría de los casos) y luego podrían 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 (vincúlelo en este caso) o no está activado (puede hacer esto 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.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top

web tasarım