WordPress está listo para comenzar a implementar la propuesta de actualización automática de sitios antiguos a 4.7

Colaboradores de WordPress de todo el mundo se unieron a una animada reunión ayer para continuar la discusión sobre la propuesta de actualizar automáticamente los sitios antiguos a la versión 4.7 en una implementación controlada. La idea es que los sitios se actualicen gradualmente de una versión principal a la siguiente (no todas a la vez). La discusión fue dirigida por el líder de lanzamiento de WordPress 3.7, Andrew Nacin, con la ayuda de Ian Dunn y el líder del equipo de seguridad, Jake Spurlock.

Según las respuestas de los participantes durante la reunión, hubo un puñado de disidentes que no se sienten cómodos con la actualización de sitios antiguos sin el consentimiento explícito del propietario del sitio, lo cual es difícil de adquirir cuando los correos electrónicos y los avisos administrativos no llegarán a todos los afectados.

La mayoría de los contribuyentes se inclinan por encontrar la mejor implementación para seguir adelante con la propuesta, que esencialmente toma una decisión audaz para los usuarios habituales que pueden no saber que no están en la última versión de WordPress y aquellos que han abandonado sus sitios. Los propietarios de sitios que eligen activamente quedarse con versiones anteriores probablemente ya hayan optado por no recibir actualizaciones automáticas, y el sistema de actualización respetará esas decisiones.

Dunn dijo que su objetivo para la discusión era "escuchar ideas y, con suerte, acercarse a algún tipo de decisión". Al principio, comenzó con un mayor enfoque en los detalles de implementación y marketing, en lugar de la cuestión de si WordPress debería o no actualizar automáticamente los sitios a las versiones principales.

“Creo que se necesita un gran impulso de marketing en torno a esto”, dijo Spurlock. “Queremos adelantarnos a cualquier noticia sobre los sitios de última hora de WordPress y estar en condiciones de enmarcar esta actualización como un gran beneficio para los millones de sitios que se están actualizando”. Después del estímulo de la directora ejecutiva de WordPress, Josepha Haden, aquellos ansiosos por discutir el proceso de implementación se retiraron para abordar el asunto más central de las actualizaciones automáticas. Spurlock resumió las tres opciones que tiene el equipo de seguridad para los sitios más antiguos:

1. Abandone las actualizaciones de seguridad para sitios más antiguos
2. Continúe con las actualizaciones de seguridad, a un gran costo
3. Actualice manualmente los sitios, dejando los sitios más antiguos sin actualizaciones.

“Vale la pena señalar que estos propietarios de sitios ya han tenido hasta seis años de avisos administrativos”, dijo Nacin. “Los sitios más antiguos probablemente recibieron más de 30 correos electrónicos. La forma en que podríamos comunicar una nueva función (por ejemplo, 5.3 o 5.4) para agregar compatibilidad con las principales actualizaciones automáticas de versiones podría ser drásticamente diferente de cómo podríamos manejar un sitio antiguo que ejecuta 3.7 que nos gustaría mover a 3.8 y superior”.

Los colaboradores sopesan las consecuencias de dejar sitios antiguos sin actualizaciones

El colaborador principal Zebulan Stanphill fue uno de los oponentes más vocales de la actualización automática a versiones principales sin consentimiento.

“La función de actualización automática en 3.7 no se anunció como que incluyera actualizaciones importantes, por lo que parece engañoso en mi opinión cambiarla repentinamente para incluir eso”, dijo Stanphill. “Se siente como asumir más control sobre un sitio web que el que el propietario le había dado originalmente a WordPress. Estoy de acuerdo con que las actualizaciones principales automáticas se conviertan en las predeterminadas en las nuevas versiones de WordPress, pero aplicarlas retroactivamente a las versiones anteriores me parece incorrecto”.

Gary Pendergast, un colaborador patrocinado a tiempo completo de Core, respondió que el problema es que millones de propietarios de sitios no verán el aviso y se quedarán atascados en versiones antiguas que eventualmente se volverán inseguras. Stanphill argumentó que no es responsabilidad de WordPress actualizar los sitios de las personas si no dan permiso.

“Es nuestra responsabilidad no sentar las bases para una red de bots en una parte considerable de Internet”, dijo Pendergast.

WordPress tiene una huella mucho más grande en la web que en 2013 cuando se implementó el sistema de actualización automática en 3.7. La cuota de mercado de la plataforma ha crecido hasta el 34,5% de los 10 millones de sitios web principales en agosto de 2019. Los sitios que ejecutan 3,7 se han estimado informalmente en alrededor de 2 millones, pero no se ha confirmado un recuento definitivo.

“Si, sin saberlo, le damos a alguien una plataforma para hacer el mal real, somos lo suficientemente grandes como para tener consecuencias”, dijo Mary Baum, colaboradora central.

La falta de consentimiento explícito y la posibilidad de rotura fueron las dos principales preocupaciones de quienes se oponían al plan. Los que están a favor creen que se puede hacer sin romper millones de sitios web. El exlíder del equipo de seguridad, Aaron Campbell, destacó las ventajas de un lanzamiento de actualización por niveles:

Hablando de comenzar con 3.7 usuarios como base de prueba (que es parte del plan que propuso Ian), una de las mejores cosas que podemos ofrecer a los usuarios que les resulta difícil hacer por sí mismos es una actualización lenta de una versión a otra. El botón en el tablero de un sitio 3.7 actualizará el sitio a 5.2, lo que es comprensiblemente aterrador. Estaríamos actualizando 3.7->3.8, luego 3.8->3.9, etc., hasta 4.6->4.7. Ofrecerá un camino más suave de 3.7 a 4.7 Y nos dará muchos lugares para mejorar el proceso en el camino si es necesario.

Creo que hay algunos beneficios de enrollarse. Uno de ellos son los cambios de la base de datos, que se implementarían en partes de la misma manera que ocurrieron en los últimos 6 años en lugar de agruparse en una sola actualización. Parece que también causaría menos errores de memoria y límite de tiempo.

Como ha declarado en discusiones anteriores de P2, Nacin reiteró que el plan del equipo central siempre ha sido traer actualizaciones automáticas para las versiones principales:

Quiero compartir un poco de historia y contexto: solo la última versión de WordPress es, por supuesto, oficialmente compatible. Las actualizaciones automáticas en segundo plano en 3.7 (octubre de 2013) cambiaron completamente el cálculo: por primera vez, pudimos enviar versiones de seguridad a sucursales más antiguas. Pero no anunciamos ni documentamos estas versiones anteriores, no las ofrecemos para su descarga regular ni las expusimos en la pantalla Tablero → Actualizaciones. No hubo ninguna intención, y todavía no la hay, de cambiar nuestra política a menudo declarada de que solo se admite oficialmente la última versión de WordPress. Sin embargo, nos dimos cuenta de que si estamos desarrollando la capacidad de enviar rápidamente correcciones de seguridad a sitios antiguos no compatibles, estaríamos locos si no usáramos esa función.

Esperábamos lograr un progreso más rápido en las actualizaciones automáticas para los principales lanzamientos, mejorando la seguridad y la resistencia de esas actualizaciones. Eso nos habría permitido actualizar estos sitios más antiguos, hasta la versión 3.7, a versiones más recientes de WordPress. Ese fue siempre el plan. Simplemente no esperábamos que nos tomaría seis años llegar allí.

Eventualmente, el objetivo a largo plazo es cambiar el valor predeterminado para las actualizaciones importantes a "excluirse", una vez que hayan demostrado su estabilidad. La propuesta de actualizar automáticamente las versiones anteriores a la 4.7 sería el siguiente paso para avanzar gradualmente en esa dirección. Nacin sostiene que los sitios más antiguos "ya están habilitados en virtud de tener una instalación de WordPress 3.7+".

En un momento determinado de la reunión, la discusión en torno a la ética de la actualización automática de sitios antiguos a 4.7 se dividió en analogías relacionadas con el mantenimiento de automóviles, vacunas, cadáveres en descomposición y cualquier cosa que los colaboradores pudieran sacar del mundo real para que sus opiniones fueran más identificables. al tema que nos ocupa.

“Es difícil hablar de 'autonomía' para sitios que efectivamente han sido abandonados”, dijo Mark Jaquith. “Por ejemplo, si caes muerto en la calle, la sociedad no te deja pudrirte allí simplemente porque no has dado tu consentimiento para el entierro”.

El colaborador principal, John James Jacoby, dijo que no se siente del todo cómodo con el consentimiento implícito de optar por no participar frente a optar por participar, pero finalmente estuvo de acuerdo en que es "algo que debe suceder".

"Pero parafraseando a Mark de antes, creo que siento que WordPress no debería estar limpiando sus propios cadáveres de la web a menos que incluya un meta-cuadro grande en el Tablero que diga 'Oye, tuvimos que hacer esto por ti y he aquí por qué'”, dijo Jacoby.

Otros se oponen más firmemente a que WordPress cambie los archivos en los servidores de los usuarios, después de haber comunicado originalmente que 3.7 solo realizaría actualizaciones de seguridad automáticas a menos que decidieran optar por actualizaciones importantes.

“Estoy totalmente en contra de impulsar una actualización importante desatendida de cualquier software”, dijo Gabor Javorszky. “WordPress Core no tiene la autoridad para cambiar el código en mi servidor sin mi solicitud explícita. Estoy de acuerdo con que se actualice solo para versiones menores, porque eso es para lo que me registré, y así es como funciona el actualizador automático actual de forma predeterminada. Puedo cambiarlo para permitir actualizaciones importantes, y puedo cambiarlo para que no permita ninguna actualización en absoluto, pero WP anula esa opción es incorrecta”.

Michael Panaga sostuvo que los usuarios estarían más dispuestos a entender que sus sitios web antiguos han sido pirateados, en lugar de descubrir que sus sitios se han roto debido a una actualización automática no autorizada. Quienes se oponen a la propuesta no creen que sea responsabilidad de WordPress evitar que los sitios de las personas se vean comprometidos, incluso si millones de sitios son pirateados. Ven esto como un problema del usuario o como algo que las empresas de hosting deberían manejar.

“Las personas razonables pueden y estarán en desacuerdo con esto, pero nuestra filosofía es que no creemos que sea responsabilidad exclusiva del usuario si su sitio es pirateado”, dijo Nacin. “También sentimos esa responsabilidad, y haremos absolutamente todo lo que podamos para asegurarnos de que su sitio se mantenga actualizado y que estén ejecutando la última y mejor versión de WordPress”.

No se ha anunciado ninguna decisión oficial, pero quienes tienen el poder de implementar el plan están firmemente decididos y parecen haber obtenido un consenso en la reunión de ayer.

“Al final del día, solo hay unas pocas personas que tienen la capacidad de enviar el cambio al servidor de actualización automática para hacer esta exclusión voluntaria en lugar de participar y parece que están decididos, por lo que no tiene sentido. continuar con las [discusiones] de P2, también podría pasar a la fase de implementación y tratar de minimizar la destrucción”, dijo el desarrollador de WordPress Earle Davies.

Nacin agradeció a los contribuyentes por prestar sus voces a la discusión y dijo que habrá algunas publicaciones de seguimiento y posiblemente se publique una hoja de ruta para hacer / core en los próximos días, documentando decisiones anteriores desde 2007.

“Estoy muy contento de que todos hayan venido a hablar sobre este tema”, dijo Nacin. “Incluso después de 10 años, sigo profundamente impresionado con la comunidad de WordPress y cuánto se preocupa por sus usuarios. La web se lo merece”.