Como muchos de ustedes saben, la semana pasada Syed Balkhi asistió a WordCamp Raleigh 2012. Durante el evento, uno de sus tweets generó un gran debate. En este artículo, nuestro fundador Syed Balkhi debatirá si los Tipos de Publicaciones Personalizadas de WordPress deben ir en el archivo functions.php o en plugins. A continuación, un tweet que inició este debate:
No agregues Tipos de Publicaciones Personalizadas en functions.php -> SIEMPRE debes usar un plugin específico del sitio – http://t.co/bebYXq2F #wcraleigh
— WordPress Beginner (@wpbeginner) 4 de noviembre de 2012
Después del tweet, muchas personas respetadas en la comunidad de WordPress opinaron. Puedes ver la conversación completa aquí. Curtis McHale fue un paso más allá y elaboró sobre el tema en su nuevo post de blog.
La conversación de Twitter planteó algunos puntos excelentes.
Resumen de Argumentos
Argumento de los Plugins: El usuario siempre tendrá los datos incluso si cambia el tema. Puede que no se vea tan bonito, pero permanecerá allí.
Argumento de functions.php: Los datos sin diseño serían irrelevantes. Confundiría aún más a los usuarios.
¿Con qué lado estás más de acuerdo? Claramente ambos lados tienen sus problemas, pero ¿cuál es el menor de dos males?
Aquí te explicamos por qué creemos que los Tipos de Publicación Personalizados deben SIEMPRE vivir en un plugin específico del sitio o en un plugin separado por completo.
Larga vida a los datos
Los Tipos de Publicación Personalizados son datos. En la mayoría de los casos, tus datos sobrevivirán al diseño actual. Habiendo cambiado nuestros temas varias veces, entendemos esa afirmación claramente. Las Entradas, Páginas, Enlaces, Adjuntos y Revisiones son todos tipos de publicaciones que vienen integrados con WordPress. Además de eso, tenemos tipos de publicación como Libros, Testimonios, Ofertas, etc. Ahora, ¿te imaginas si cambiamos un tema y todo esto desaparece? Seguramente, no querríamos que eso sucediera.
Teniendo desarrolladores en nuestro equipo, esto no debería importar mucho. Considerando que todos nuestros temas son diseñados a medida por nuestro equipo, ¿qué diferencia hace realmente? El secreto reside en dos palabras: tiempo y centralización. Mientras tengamos todos los datos necesarios, todo lo que tendríamos que hacer en el futuro es cambiar el estilo. No tendremos que preocuparnos por copiar y pegar las funciones de un archivo a otro cada vez. ¿Qué pasa si quieres replicar la funcionalidad? Simplemente toma el plugin y colócalo en tu nuevo sitio. Cambia el estilo y listo.
Reglas y Estándares
Cuando usas la palabra SIEMPRE como lo hicimos en nuestro tuit, puede significar tanto regla como estándar. Tanto las reglas como los estándares se hacen para la mayoría. Siempre habrá escenarios de casos especiales donde las reglas se doblan y los estándares se rompen, pero eso no significa que debamos deshacernos de los estándares por completo.
Hay muchísimos tipos de publicación genéricos que en su mayoría requieren el mismo conjunto de campos meta adicionales. Algunos ejemplos que se me ocurren serían: Citas, Libros, Recetas, Testimonios, Portafolio, etc.
Considerando la gran cantidad de temas de fotografía y portafolio que están disponibles en el mercado gratuito y comercial, no tiene casi ningún sentido que el usuario tenga que volver a ingresar toda la información de sus tipos de publicación personalizados cada vez que cambia de tema. Echemos un vistazo a un escenario de caso de ejemplo:
Fotógrafo – El usuario configuró un WordPress que tiene funcionalidad de blog (CPT “post” por defecto). Quiere agregar un portafolio de su trabajo (requiere un CPT de Portafolio). Quiere mostrar testimonios de clientes (requiere un CPT de Testimonio). Toda esta información seguramente vivirá más allá del diseño de un tema. Un año después, el usuario quiere cambiar el aspecto de su sitio y darle una renovación. Encuentra un nuevo tema que tiene todas las funciones similares. En el momento en que cambia el tema, BOOM. Todos los datos anteriores que ingresó han desaparecido. Hay un menú llamado Portafolio, y un menú llamado Testimonios, sin embargo, no hay datos allí. El usuario piensa: “SANTA MADRE, perdí todo mi contenido”. Crea nuevas preguntas de soporte en el foro. Envía correos electrónicos a sitios como WPBeginner, etc. Si no reciben una buena respuesta, tendrán que volver a ingresar todos los datos. Esta es una experiencia de usuario pésima.
Entonces, ¿cómo resolvemos este problema?
¿Solución posible?
Creamos una nueva base estándar. Justin Tadlock ya comenzó a trabajar en este problema hace tiempo creando un plugin base de portafolio. ¿Será la solución perfecta para todos? NO, pero lo será para la mayoría.
Como pregunta Justin en su publicación, ¿qué campos estándar deberían incluirse en el plugin de portafolio (refiriéndose a los metadatos de las publicaciones)? Este tipo de conversación necesita ocurrir entre los desarrolladores que crean funcionalidades similares en sus temas. ¿Por qué copiar y pegar lo mismo una y otra vez de un tema a otro cuando se puede hacer a través de un plugin? Una vez que se convierta en un estándar, otros autores de temas comenzarán a adaptarse a él.
Por ejemplo, estamos viendo un aumento en el soporte de estilos para Gravity Forms en frameworks de temas de WordPress como Genesis y otros. ¿Por qué? Porque entienden que sus usuarios lo están utilizando.
Existen algunos temas robustos de WordPress que vienen cargados con funcionalidades que creemos deberían ser plugins. Temas de bolsa de trabajo, temas de seguimiento de incidencias, temas de anuncios clasificados, temas inmobiliarios, etc. Todos deberían ser potenciados por un plugin base. Ya está sucediendo con WooCommerce. WooThemes ha lanzado numerosos temas que tienen soporte de estilo integrado para el plugin. Otras empresas de temas han prometido lanzar también temas de comercio electrónico basados en WooCommerce. Puedes cambiar de un tema a otro y mantener todos tus productos tal como están. Es casi como si el tema hubiera cambiado pero todo encajara perfectamente. Esa es la experiencia de cambio de tema a la que debemos aspirar.
¿Por qué no hacer lo mismo con Portafolio, Testimonios y otros tipos de publicaciones personalizadas genéricos? ¿Es porque es demasiado simple en comparación con el comercio electrónico, que es una bestia más grande a conquistar? Claramente, el comercio electrónico tiene demasiados campos en comparación con los otros, por lo que debería ser mucho más fácil para estos tipos de publicaciones genéricos. Es solo cuestión de hacer un esfuerzo consciente para mejorar las cosas.
Echa un vistazo al plugin ReciPress. Crea una metabox personalizada con campos de recetas y la adjunta a las publicaciones. Sin embargo, es posible adjuntarla a tipos de publicaciones personalizadas. Cualquiera que use este plugin puede cambiar de tema sin tener que pasar por tales molestias.
Sería bueno ver temas como AgentPress potenciados por un plugin base centralizado. Sería genial ver que la transición de cambio de temas sea más fácil. Por ejemplo, si un usuario cambia de un tema de fotografía a otro, no debería ser un caos. Podrían ocurrir errores menores, pero al menos en un sentido general, las cosas funcionarán.
Siempre puedes dar ejemplos de tipos de publicaciones súper personalizadas creadas para uso de clientes de una sola vez, pero esa es la excepción, no la regla.
¿Qué opinan ustedes sobre este tema? ¿Dónde debería residir el código de los tipos de publicaciones personalizadas? ¿En el archivo functions.php o en plugins?
Yazmin
Habiendo experimentado perder mis CPTs numerosas veces al cambiar de tema, me resulta frustrante tener que configurar la misma funcionalidad una y otra vez en functions.php.
Prefiero completamente la ruta del plugin y ese es el método que usaré de ahora en adelante para mis proyectos de negocio también.
Joshua Jarvis
Tengo exactamente este problema con un tema de bienes raíces. Los “listados” eran todos tipos personalizados en un tema que ahora es funcionalmente obsoleto. Cuando fui a actualizar el tema, perdí todo el contenido de publicaciones personalizadas, ahora tengo que encontrar una manera de transferirlo todo. Tengo opciones, pero si fuera un plugin, esto no sería necesario.
Personal editorial
Extremadamente apenados por su inconveniente. Por eso escribimos esta publicación porque sabemos que realmente le dificulta la vida al usuario final.
Administrador
Hugh H. Sands
“Ya no tendremos que preocuparnos por copiar y pegar las funciones de un archivo a otro cada vez.”
No me imagino a alguien escribiendo código para un CPT en functions.php cuando es tan fácil aislarlo con includes
Este debate gira la mayoría de las veces en torno a datos vs diseño y me pregunto, siendo bastante nuevo en WP, ¿qué pasa con el rendimiento? ¿Los plugins imponen alguna sobrecarga?
Personal editorial
Este artículo debería responder a tu pregunta sobre plugins y rendimiento:
https://www.wpbeginner.com/opinion/how-many-wordpress-plugins-should-you-install-on-your-site/
Administrador
Hugh Sands
¡Gracias por el enlace, muy útil!
Kelvin Alfonso
Siempre he incluido los CPT a través de un archivo separado en functions.php, ¡pero creo que pasaré a la ruta de los plugins. ¡Gracias!
Sudhakar
Soy principiante y no tengo experiencia para comentar a favor o en contra de un plugin o functions.php. Pero me pregunto si quiero seguir la ruta de functions.php y hacerlo bajo un tema hijo, ¿cuál es el problema entonces? ¿Por qué necesito tenerlo en un plugin? ¿No me salvaría mi tema hijo de futuras actualizaciones y cambios de temas?
Personal editorial
Tu tema hijo te salvaría de futuras actualizaciones de temas. Sin embargo, NO te salvará si cambias de tema. Porque cambias el tema hijo si cambias el tema activo.
Administrador
Pat Ramsey
Soy partidario de la ruta de los plugins para tipos de publicaciones personalizadas y taxonomías. La mención del autor de un plugin específico del sitio es como lo hago yo. Coloco cualquier tipo de publicación personalizada, taxonomías personalizadas y metaboxes en este plugin, adaptado al propósito del sitio. Con el tiempo, el tema del sitio cambiará, pero los datos perdurarán y seguirán siendo fácilmente accesibles.
shawn
Si los desarrolladores continúan ignorando el hecho de que separar los "datos" del "diseño" es necesario para crear aplicaciones modulares, y no importa dónde se coloquen los datos, la reutilización de esos datos / código siempre será un problema.
Parece que hay una percepción por parte de algunos en la comunidad de WP, por una u otra razón, de que solo se puede acceder a los datos en el ecosistema de WordPress si están encapsulados en un plugin, por lo que seguimos viendo discusiones como esta que contribuyen al debate "El gran debate de plugins vs. temas".
Es necesario centrarse en evolucionar el arcaico sistema de plugins de WordPress, para crear bibliotecas basadas en patrones de diseño modulares que separen el código / datos del diseño. Bibliotecas que puedan ser utilizadas tanto en temas como en plugins.
¡¡¡Los debates como estos son inútiles en la era posterior a PHP4 de WP!!! (republicado)
Mark Simchock
Re: "Como pregunta Justin en su publicación, ¿qué campos estándar deberían incluirse en el plugin de portafolio (refiriéndose a los metadatos de las publicaciones)? Este tipo de conversación debe ocurrir entre los desarrolladores que crean funcionalidades similares en sus temas."
¿Yo? Preferiría un plugin bien documentado y diseñado para ser mejorado que un enfoque "cerrado" de talla única que es difícil de manejar (ese código).
Mi punto es, quizás sea posible decir: "No estoy tratando de ser todo para todos. Aquí está mi plugin básico. Aquí les explico cómo mejorarlo. Está diseñado para ser mejorado". Y simplemente dejarlo así. No importa lo que hagas, es difícil anticipar cada caso de uso, cada necesidad de uso. Entonces, ¿por qué molestarse? ¿Por qué no abordarlo como un marco (de algún tipo) y dejar que el desarrollador que lo necesite lo personalice según sea necesario?
Justin Tadlock
Ese es el plan. Estoy construyendo una base extremadamente pequeña y fácil de personalizar. Pero, me gustaría saber qué campos, si los hay, deberían ser estándar.
Kevin Maines
¿Error tipográfico?:
“Considerando que todos nuestros equipos están diseñados a medida por nuestro equipo”
Personal editorial
Fixed it. Thanks for catching that
Administrador
Affan Ruslan
Creo que debería estar en un plugin.
En caso de que el usuario no necesite los datos en el futuro, siempre puede convertir la publicación del tipo de publicación personalizado al tipo de publicación "normal". Hay plugins para hacerlo, busca en el repositorio y encontrarás al menos uno.
Christophe Debruel
Realmente no me importa lo que diga la gente. El tipo de publicación personalizado va en un plugin. Un tema se puede modificar fácilmente para adaptarse al tipo de publicación personalizado en el frontend. Me parece más lógico estilizar el tema para el CTP que tener temas diferentes con el mismo código CTP.
Ingo
"Pods Framework" también podría ser una buena solución de plugin. Para CPT, CT y CF.
http://wordpress.org/extend/plugins/pods/
Personal editorial
Sí, Pods es increíble.
Administrador
Elliott Richmond
Plugin para mí. Al menos para un cliente no técnico, aunque el tema podría no funcionar correctamente, se hará evidente que hay un problema y eso los impulsará a contratar a un desarrollador.
Kailas Mahajan
Todo depende del proyecto…
Si se está manejando un proyecto que necesita cambiar el tema después de un cierto período de tiempo… se puede usar un plugin.
o si el proyecto se queda con un solo tema... se puede ir con function.php
Ross W
Todos hablan de cómo el tema necesita estilizar los datos, y ejemplos donde ese es el caso y donde los datos y el tema pueden separarse.
Lo que no veo es que alguien hable de casos en los que un tema depende de tener ciertos datos específicos disponibles. Digamos que tienes un tema que tiene un mapa de países y algunos datos específicos de países, y que, sin ese mapa y datos, el tema pierde parte de su funcionalidad clave.
Sí, aún podrías hacer esto con los datos en un plugin, pero ¿es razonable que un tema asuma que existen algunos datos? ¿Es razonable asumir que el plugin que crea los tipos de datos está instalado y habilitado? (Preguntas genuinas... ¡a debatir!)
¿Qué pasa si mi cliente, que no es muy técnico, quiere crear una copia del sitio con su 'tema'? Habilita el tema en una nueva instalación de WordPress solo para descubrir que faltan o están rotas muchas cosas. ¿Pensó que el tema contenía todo lo que necesitaba para que su sitio se viera bien?
Veo usos para ambos enfoques. Para la mayor parte del trabajo con mis clientes, configuro CPTs, meta-boxes y algunas funciones para que el acceso a ellos sea simple, en archivos de biblioteca y los incluyo. Esto mantiene todo lo que mi tema necesita para funcionar en un solo paquete, pero facilita la migración de los CPTs a un nuevo tema si así lo deseo.
Por supuesto, si un CPT parece que podría usarse en varios temas y no es tan específico que solo se aplique a los datos de un solo cliente, entonces lo conviertes en un plugin que se puede implementar a voluntad.
No creo que exista una relación simple y unidireccional entre los datos y los temas. No siempre es el caso de que 'tengo algunos datos que necesitan estilo'... a veces 'mi estilo necesita algunos datos'.
¿Opiniones al respecto?
Andres Hermosilla
Definitivamente estoy de acuerdo en que tener un paquete "completo" tiene un beneficio. A menudo hay funcionalidades muy específicas del tema que es mejor integrar directamente (es decir, P2 de Auttomatic) en lugar de un tema instalado y un plugin de tema.
Konstantin Kovshenin
Plugins. Punto.
Curtis McHale
Tu referencia a AgentPress es una de las razones por las que estoy 100% a favor de los CPT en plugins. He tenido que lidiar con temas como ese y es muy difícil darles estilo correctamente a menos que elimines la función personalizada del tema. Mi cliente y yo pasamos 20 horas para que el código llegara a un punto en el que pudiéramos trabajar en él.
Birgit
mi mejor y favorita solución recomendada es la herramienta ALTAMENTE flexible: http://wordpress.org/extend/plugins/toolbox/
Personal editorial
Buena idea. Ojalá pudiera entender lo que mostraba la captura de pantalla sin descargar el complemento.
-Syed
Administrador
Birgit
The plugin is a “toolbox” for code snippets, that you do normally in your functions.php.
But with a theme update, custom code in the theme’s function.php might get lost.
So I use within my network installation this plugin, activated it network-wide and then the plugin comes with “modules”, that you can access for example by FTP.
You can create modules as much as you like – I have one for each of my blogs within this network. In this modules (= just .php files, let’s say just like site-specific plugins) you can add all the code, that you normally put in your theme’s function.php.
Then at the options page of the plugin you can activate in each blog, which module you would like to load and whether to load it only for frontend or only for backend or for both.
So I only need to have 1 plugin to serve all blogs with individual code snippets, that normally go to their functions.php – and can decide, where to load these modules.
uff, hope this is understandable, because my English is not the best
Quizás esto te sirva para leerlo: http://tinyurl.com/bf5dflt
Personal editorial
Brigit, I did translate the WP.org page as well. I understood what the plugin was intended for. However the screenshots were in German, and google is not smart enough to translate images just yet. Same issue is with the link you posted
Sara
Siempre prefiero los plugins sobre functions.php para cualquier cosa que materialmente "rompa" en el front-end o pierda datos si se cambiara el tema. Esto es precisamente por las razones que citas, y también siento que es una LOCURA para aquellos de nosotros que no somos realmente programadores de php intentar solucionar conflictos cuando tienes que comentar cosas en functions.php para aislar un problema.
matt
ok, ¿qué plugin de CPT recomiendas?
Personal editorial
La idea es que registres los CPT en un plugin específico del sitio. Todavía no hay un plugin específico. Pero esto es solo una idea de crear un plugin base para tipos de publicación genéricos.
Administrador
Muhammad Waqas
Estoy más convencido con el uso de funciones locales. Pero en este caso, creo que el plugin puede ser más confiable. Por ejemplo, si empiezas a usar wp con un framework específico. En la mayoría de los casos, es posible que te conviertas en un esclavo por mucho tiempo a menos que contrates a un profesional de wp para que te ayude a escapar de ese framework sin perder tu configuración y datos. Por otro lado, los plugins pueden funcionar en casi todos los temas.
Cuando empecé a trabajar con wp, prefería un framework sobre un plugin. La realidad es que los desarrolladores de plugins consideran a los novatos y a las personas menos alfabetizadas al desarrollar algo. Personalmente, creo que la mayoría de los usuarios de wp prefieren los hacks de código manuales en lugar de depender de plugins para las funciones principales de los sitios. A largo plazo, los plugins no son confiables. Así lo siento..