¿Por qué no pirateamos el núcleo?

No podía creer que esta pregunta no haya sido respondida en este sitio, pero no la encontré cuando busqué, así que ...

¿Por qué es una idea tan mala que el crimen contra la naturaleza piratee el núcleo?

• ¿Es realmente genial poder actualizar tu versión principal? La mayoría de mis sitios terminan teniendo núcleos horriblemente desactualizados de todos modos, entonces, ¿por qué molestarse?
• Incluso si es tan malo para los propietarios del sitio, ¿por qué la comunidad se preocupa tanto? ¿Por qué se conoce como "matar gatitos"? ¿No es eso bastante hiperbólico?
• Hackear el núcleo es tan fácil, ¿no nos gusta tomar la ruta más fácil para la solución de un problema?
• ¿No hay problemas que solo puedan resolverse pirateando el núcleo? ¿Entonces que?

En términos generales, hay tres razones para no alterar el código central de Drupal:

• Sus cambios se perderán cada vez que actualice Drupal, si no realiza los pasos necesarios. Incluso en el caso de que cree un parche para la versión actual de Drupal que está utilizando, el parche no podría aplicarse a la versión más nueva, y también necesitaría crear un parche para la nueva versión.

• Las correcciones de seguridad se aplican al núcleo de Drupal como se mantiene en Drupal.org, pero no se pueden aplicar a su versión pirateada. Eso significa que debe verificar que su versión no se vea afectada por el problema de seguridad generado contra el núcleo de Drupal.
  En el caso de que su versión pirateada presente un problema de seguridad diferente, usted es la única persona que puede encontrarlo, ya que no cuenta con el apoyo del equipo de seguridad que investiga las fallas de seguridad presentes en el código central de Drupal y en terceros. módulos alojados en Drupal.org.

• Los cambios que introduzca podrían ser incompatibles con Drupal, pero también con módulos de terceros, que son necesarios para trabajar con Drupal core, no con ninguna versión pirateada que se pueda crear.
  Cada vez que Drupal introduce una nueva característica (que todavía ocurre en Drupal 7 y en Drupal 6, aunque con menos frecuencia), o un nuevo cambio de API, existe la posibilidad de que la versión pirateada sea incompatible con los cambios recientes.

Dicho esto, es posible crear una versión pirateada, pero esa no es la tarea que puede llevar a cabo un solo desarrollador, de la misma manera que Drupal no es mantenido por una sola persona. De hecho, Pressflow es una versión pirateada de Drupal que se ha creado teniendo en cuenta el rendimiento y para resolver algunos problemas de rendimiento que podría tener un sitio de Drupal.

¿No hay problemas que solo puedan resolverse pirateando el núcleo? ¿Entonces que?

La mayoría de las veces, es posible alterar las características / comportamiento sin editar el código central de Drupal. Siempre hay un enlace que permite cambiar las características / comportamientos que tiene Drupal, y ese es el método preferido.

Podría escribir una respuesta masiva aquí, pero solo voy a publicar este enlace: ¡ Nunca hackear core !

La razón principal, supongo, es que si hackea el núcleo para hacer algo que necesita y luego lo actualiza ... ¡BANG! Tus cambios se han ido. Perdido. Luego, puede intentar revertir el código de su VCS, pero dado que no puede revertir las actualizaciones de la base de datos del núcleo de Drupal, está buscando restaurar todo el código de VCS y luego restaurar las bases de datos de sus copias de seguridad. Todo el tiempo que intente revertir su código, probablemente notará que su última copia de seguridad de la base de datos previa a la actualización falló, y jurará más de lo que había jurado antes.

Además, lo más importante, si pirateas el núcleo, Dries y Webchick matan a un gatito: -o

"¿Qué no puede hacer el pirateo central por mí, el desarrollador?"

• Su sitio puede actualizarse para lanzamientos de seguridad
• Su sitio se puede actualizar para corregir errores molestos en el núcleo
• Su sitio puede actualizarse para admitir nuevos módulos
• Sus informes de errores y solicitudes de soporte en core y contrib podrán ser respondidos
• Desea utilizar un CMS compatible, por eso eligió Drupal. Cuando pirateas el núcleo, en palabras de webchick , "¡Si pirateas el núcleo, felicidades! ¡Has creado tu propio tenedor de Drupal, y ahora tú y tú solo son responsables de mantenerlo!"

"¿Qué no puede hacer hackear core para mi cliente?"

• Otra persona puede mantener su sitio después de despedir a su cliente / ganar la lotería / ser atropellado por un autobús

"¿Qué no puede hacer el hackear core para mi comunidad?"

• Sus informes de errores en realidad proporcionarán información útil para el responsable del mantenimiento de los módulos principales o contrib.
• Si encuentra un error legítimo en el núcleo que debe ser parcheado, la línea entre 'piratear el núcleo' y 'convertirse en un contribuyente principal' es tan simple como simplemente diferir sus cambios y cargarlos como un parche en un problema relevante. ¡Viola! Core es mejor para sus esfuerzos, y su nombre está asociado con la devolución de código a la comunidad.

¡Todos son ganadores cuando no pirateas el núcleo!

Actualmente estoy trabajando en un sitio web central pirateado. Tengo dificultades para encontrar cómo se configura algo tan simple como la fuente. También paso unos días arreglando un error que fue introducido por el hack core. Lo encontré buscando una cadena en todo el código drupal.

Si no sigue la estructura estándar de programación en drupal, ¿cómo puede otra persona encontrar y editar los cambios que introduce? Esto es especialmente doloroso porque en drupal cada archivo php puede implementar un enlace. Intenta descubrir cuál está causando problemas.

"¿No hay problemas que solo puedan resolverse pirateando el núcleo? ¿Qué, entonces?"

Para responder a esta pregunta, sí, a veces hay problemas que debes superar, lo que significa que debes hackear el núcleo (o un módulo contrib).

En este caso, creo que está bien hackear siempre que coloque muchos comentarios en su código pirateado y documente todo lo que cambie.

Por ejemplo, para cualquier cambio de núcleo o contribución que realizo, creo un parche. Si es genérico y útil para otras personas, lo envío a drupal.org en un problema, de lo contrario es para mi propio uso.

Luego confirmo el archivo de parche a mi control de versiones junto con el cambio de código.

Esto significa que puedo ver buscando archivos de parches si algo ha sido pirateado.

Además de eso, también agrego una lista de hacks a la documentación del desarrollador para el sitio (realmente deberías tener documentación del desarrollador por el bien de otros que podrían trabajar en el sitio y por ti mismo cuando olvides cosas inevitablemente).

En esta documentación de hacks, enumero cada hack con lo que hace el hack y por qué, los módulos / archivos afectados, el nombre del archivo de parche que contiene el código de hack y un enlace a un problema relacionado con drupal.org si hay uno (casi siempre en mi caso lo hay).

Entonces, usted y cualquier otra persona que trabaje en el sitio en el futuro tiene una lista completa de hacks y no tiene que preocuparse por romper accidentalmente algo con una actualización.

Luego, para el proceso de actualización, verifico mi lista de hacks y busco rápidamente los archivos de parches en todos los módulos que estoy actualizando. Si hay un hack y tiene un problema con drupal.org, verifico el problema para ver si la última versión tiene el parche incluido, en cuyo caso elimino el hack con la actualización y lo elimino de mi lista de hacks (make Asegúrese de mirar los mensajes de confirmación de drupal.org de que lo que se confirmó fue el mismo que la versión del parche que está utilizando, o al menos funcionalmente igual).

Si el parche no se confirmó, todo lo que tengo que hacer es actualizar los módulos y volver a aplicar los parches. En muchos casos, los parches se aplicarán de manera limpia y el proceso es fácil, pero a veces hay que volver a ejecutar los parches para la nueva versión y luego enviar la nueva versión del parche a su repositorio local (junto con publicarlo en el correspondiente problema de drupal.org donde corresponda).

Otra cosa que me gusta hacer si tengo parches más sustanciales o parches que interactúan con la funcionalidad central de un módulo (o solo módulos personalizados que se extienden en la parte superior de un módulo drupal.org), es verificar las notas de la versión del módulo actualizado ( eso significa toda la versión entre su versión actual y la versión a la que está actualizando) y asegúrese de que no haya nada allí que pueda romper su código. Nota: Muchos mantenedores de módulos son buenos en estos días con notas de lanzamiento completas, pero todavía hay muchas que hacen notas de lanzamiento de basura. En este caso, en algunos casos reviso todos los mensajes de confirmación desde mi versión actual (esto suele ser solo en los casos en que tengo un código complejo que interactúa profundamente con otro módulo). Nota:

Luego, después de actualizar (en una copia de desarrollo del sitio), realice una prueba exhaustiva. Eventualmente aprenderá lo que significa completamente después de que se escapen algunos errores.

Luego, cuando se haya probado lo suficiente, actualice el sitio en vivo o aumente sus actualizaciones locales o lo que sea que sea su proceso de implementación.

La razón por la que todos dicen que no lo hagas, incluso si es más fácil: porque la mayoría de las personas no tienen un sistema como el que he descrito, así que cuando llega el momento de hacer actualizaciones, o el sitio se entrega a otra persona para que trabaje en adelante, se convierte en una pesadilla y se debe dedicar mucho tiempo (a veces una cantidad enorme de tiempo) a resolver errores y rastrear hacks y averiguar por qué están allí, etc.

Si alguna vez heredas un sitio como ese, lo entenderás completamente :)

Si se gana la vida instalando y creando sitios web de Drupal, entonces es necesario mantenerlos actualizados. Si la mayoría de sus sitios terminan desactualizados, entonces usted no es profesional.