Ser un desarrollador de temas o complementos es un trabajo difícil. Entre las actualizaciones de WordPress, las correcciones de errores, las incompatibilidades de la versión de PHP y la atención al cliente, tiene mucho con lo que lidiar. Y no se olvide de los grupos de usuarios potenciales que preguntan, ¿ es compatible Multisite ? Es una pregunta bastante común, y puede que no sea algo que todos los desarrolladores hayan considerado. Así que quería profundizar un poco más en el desarrollo multisitio de WordPress y, específicamente, cuándo debe tener en cuenta las instalaciones multisitio en su proceso de desarrollo.
Aquí está la cosa. Cuando está instalando WordPress y creando sitios web, cuando se pregunta ¿ debería crear para WordPress Multisite? , la respuesta será no mucho más que sí . Sin embargo, la situación cambia si estás en el desarrollo de complementos y temas. Maura Teal analiza algunas de las razones en su charla de WordCamp San Diego llamada Por qué los buenos desarrolladores no ignoran los sitios múltiples. Adivina en qué punto está tratando de llegar.
Puede consultar nuestra descripción general de lo que es Multisite, pero la esencia básica es esta: una instalación de WordPress alimenta una red de sitios . WordPress.com es en realidad un ejemplo de esto en la práctica.
Es una característica realmente genial, y Maura Teal tiene razón: no debes ignorarla. Sin embargo, si desea que su complemento o tema funcione con él, debe hacer un esfuerzo especial. Vea, las instalaciones multisitio comparten una base de datos, y algunas tablas en esa base de datos se comparten entre sitios (por ejemplo, usermeta ), mientras que otras no. También puede encontrarse con problemas importantes con la activación en toda la red, la creación de tablas, la desactivación de complementos y algunos otros obstáculos.
Entonces… ¿por qué debería tomarse el tiempo para resolver esos problemas?
Bueno, primero que nada…
Mucha gente pide compatibilidad multisitio
En realidad. Puede que no sea la configuración predeterminada, pero la gente la usa. Mucho. En un episodio de WP Water Cooler , el panel analiza lo que debe hacer después de iniciar un complemento de WordPress. Como parte de esa discusión, hablaron sobre problemas comunes de soporte y solicitudes de funciones.
La traducción fue la primera que mencionaron. WordPress es mega-global, ¿verdad? Pero después de eso… La compatibilidad multisitio fue el siguiente problema que surgió. Y no solo aparece en los episodios de podcast con los desarrolladores. La pregunta está plasmada en todos los foros de soporte de WordPress.org.
Sí, la mayoría de las instalaciones de WordPress son instalaciones de un solo sitio. Pero hay muchos usuarios de WordPress multisitio, y esos webmasters quieren complementos y temas multisitio que funcionen bien con sus versiones de WP.
No es tan difícil si…
En esa misma charla de WP Water Cooler, Jon Brown de 9Seeds habló sobre la principal razón para desarrollar Multisite: no es tan difícil si lo codificas desde el principio.
Es decir, si realiza pruebas en un entorno multisitio y codifica teniendo en cuenta la compatibilidad multisitio, entonces en realidad no es mucho trabajo adicional. La mayor parte del trabajo real que tiene que hacer es simplemente seguir las mejores prácticas. Puede agregar un poco a su línea de tiempo general, pero no duplicará su tiempo de desarrollo ni nada tan drástico.
Agregar compatibilidad multisitio más tarde, aunque…
Aquí es donde puedes entrar en una situación difícil. Agregar compatibilidad multisitio desde el principio no es tan difícil ya que puede planificarlo. Volver a su base de código después del hecho e intentar agregar compatibilidad multisitio implicará desentrañar una gran cantidad de código espagueti .
Supongamos que ignora la compatibilidad multisitio porque desea que un complemento funcione lo más rápido posible. ¿Qué sucede si su complemento se convierte en un éxito rotundo? ¡Genial! ¡Felicidades! Ahora que empiezan a llegar los tickets de soporte, recibe muchos comentarios y preguntas con respecto a Multisitio, y si dice que no… eso es una gran cantidad de clientes perdidos, ingresos y, sinceramente, lealtad a la marca. Porque o ignoras a esa gente y sigues. O puede intentar volver a entrar y tratar de adaptar todo.
Ninguna solución es particularmente atractiva.
Cuestiones específicas a tener en cuenta al crear para WordPress multisitio
Entonces, digamos que está convencido de comenzar a desarrollar para Multisite. Sin embargo, ¿qué implica eso realmente?
Si bien esta no es una lista completa, estos son algunos de los problemas más importantes a considerar al planificar su desarrollo.
Por cierto, puede haber una gran cantidad de código involucrado en la clasificación del desarrollo multisitio frente al desarrollo de un solo sitio, y hay personas que ya tienen algunos ejemplos fantásticos. Deberías revisarlos totalmente. Estos son algunos de los excelentes recursos que recomiendo consultar.
- ShibaShake’s Write a Plugin para WordPress Multi-Site
- Publicación de WPHub sobre cómo hacer que los complementos sean compatibles con WordPress Multisite
- Cómo codificar correctamente su complemento para un multisitio de WordPress de Oneextrapixel
1. Ponga un enfoque adicional en la escalabilidad
Obviamente, siempre debe esforzarse por hacer que su código sea lo más eficiente posible. Pero cuando trabaja con instalaciones típicas de WordPress, tiene un poco más de libertad de acción. Y no estoy diciendo que hagas esto, pero… puedes volverte un poco perezoso cuando se trata de optimizar el rendimiento. ¿Ordenar cada consulta de base de datos? Mmmm…
Ese tipo de accesos directos se suman cuando los usuarios administran 300 sitios en su red. El rendimiento y la escalabilidad de su complemento o tema son mucho más importantes. Tanto más que puede perder clientes y usuarios si el código no está lo suficientemente optimizado.
2. Use nombres de tabla de base de datos adecuados
Debido a la forma en que Multisite funciona con las tablas de la base de datos, debe evitar realizar llamadas a nombres de tablas codificados de forma rígida. Eat site en la red comparte una sola base de datos, pero cada uno crea sus propias tablas. Entonces, si intenta ejecutar algo en wp_posts , por ejemplo, tendrá algunos problemas con Multisite.
La forma correcta es usar el objeto global $wpdb para asegurarse de que siempre obtenga los nombres correctos de las tablas de la base de datos tanto para un sitio único como para varios sitios, sin importar quién esté ejecutando su código. No es un cambio difícil de hacer, pero es un cambio, no obstante.
3. Piense en la activación y desactivación
Si su complemento, por ejemplo, crea una tabla durante el proceso de activación, deberá iterar eso en cada blog en una instalación multisitio (suponiendo que el complemento se haya activado en toda la red, como muchos).
¿Qué sucede cuando se agrega un nuevo blog a esa red multisitio después de que su complemento ya se activó? En ese tipo de situaciones, deberá asegurarse de que su código ejecute la función de activación para crear la tabla de base de datos requerida cada vez que se agregue un nuevo sitio.
Y, por supuesto, las mismas reglas se aplican a la desactivación y desinstalación. Asegúrate de limpiar tu desorden antes de irte.
4. Considere las opciones de administración y los permisos de usuario
Más allá de los cambios de código específicos, también debe pensar un poco más en las opciones de interfaz. Por ejemplo, ¿hay alguna característica específica de su complemento que el superadministrador multisitio pueda necesitar para desactivar toda la red?
El ejemplo de Maura de una llamada wp-cron que se ejecutó en toda la tabla de publicaciones es una buena ilustración. ¡En un sitio, seguro! Eso está bien… pero en 300? Puede hundir una red tan rápido como obtener un enlace en la página principal de Reddit.
Además, he oído hablar de algunos problemas con los temas en varios sitios donde solo el superadministrador puede administrar la configuración del tema. Eso está bien en algunas situaciones, pero si el superadministrador quiere que los usuarios de cada sitio puedan cambiar la apariencia de su sitio… nuevamente, problemas. Parte de la codificación para Multisite es considerar posibles posibilidades y casos de uso como este.
¿Por lo que debería?
Con todo, WordPress Multisite genera algunas opiniones sólidas en la comunidad de WP. Algunas personas realmente lo aman. Algunas personas realmente lo odian. Lo odio lo suficiente como para dar charlas de WordCamp tituladas No use WordPress Multisite . Una vez más, adivine el punto que están tratando de hacer. (Es cierto que esa es una charla anterior antes de que hubiera muchas actualizaciones de la función, pero mi punto es la ideología).
Al final, si los desarrolladores de complementos y temas deben compilar para multisitio es un gran problema, tal vez . Si está desarrollando para el público en general, colocando sus temas y complementos en el repositorio o vendiéndolos por su cuenta, debe tomarse el tiempo necesario para codificar su proyecto para que funcione con Multisite. Abre más oportunidades de las que ocupa el tiempo de desarrollo.
Pero si está desarrollando sitios web para clientes, Multisite no suele ser la respuesta. Tendrá ciertas situaciones en las que usar Multisite tendrá sentido, pero la mayoría de las veces no será así. Para muchos clientes, las funciones adicionales que brindan las instalaciones multisitio son más abrumadoras que útiles.
¿Qué piensas sobre el desarrollo multisitio de WordPress?
Imagen en miniatura del artículo destacado por Jiw Ingka / shutterstock.com