Pourquoi ne piratons-nous pas le noyau?

Je n'arrivais pas à croire que cette question n'ait pas déjà été répondue sur ce site, mais je ne l'ai pas trouvée lors de ma recherche, alors ...

Pourquoi est-ce une si mauvaise idée de crime contre la nature de pirater le cœur?

• Est-ce vraiment génial de pouvoir mettre à jour votre version principale? La plupart de mes sites finissent de toute façon par avoir des cœurs horriblement obsolètes, alors pourquoi s'embêter?
• Même si c'est si mauvais pour les propriétaires de sites, pourquoi la communauté se soucie-t-elle autant? Pourquoi est-il appelé "tuer des chatons"? N'est-ce pas plutôt hyperbolique?
• Le piratage de base est si facile, n'aimons-nous pas emprunter la voie la plus simple pour résoudre les problèmes?
• N'y a-t-il pas des problèmes qui ne peuvent être résolus qu'en piratant le cœur? Et alors?

De manière générale, il y a trois raisons pour ne pas altérer le code core Drupal:

• Vos modifications seront perdues à chaque mise à jour de Drupal, si vous ne prenez aucune mesure nécessaire. Même dans le cas où vous créez un patch pour la version Drupal actuelle que vous utilisez, le patch ne peut pas s'appliquer à la version la plus récente, et vous devrez également créer un patch pour la nouvelle version.

• Les correctifs de sécurité s'appliquent au noyau Drupal tel que maintenu sur Drupal.org, mais ne peuvent pas s'appliquer à votre version piratée. Cela signifie que vous devez vérifier que votre version n'est pas affectée par le problème de sécurité soulevé par rapport au noyau Drupal.
  Dans le cas où votre version piratée introduit un problème de sécurité différent, vous êtes la seule personne que vous pouvez le trouver, car vous ne disposez pas du support de l'équipe de sécurité qui enquête sur les failles de sécurité présentes dans le code de base Drupal et dans des tiers modules hébergés sur Drupal.org.

• Les modifications que vous introduisez pourraient être incompatibles avec Drupal lui-même, mais aussi avec les modules tiers, qui sont requis pour fonctionner avec le noyau Drupal, et non avec toute version piratée que l'on peut créer.
  Chaque fois que Drupal introduit une nouvelle fonctionnalité (qui se produit toujours dans Drupal 7 et Drupal 6, bien qu'avec moins de fréquence), ou un nouveau changement d'API, il y a une chance que la version piratée soit incompatible avec les changements récents.

Cela dit, il est possible de créer une version piratée, mais ce n'est pas la tâche qu'un seul développeur peut effectuer, de la même manière que Drupal n'est pas maintenu par une seule personne. En fait, Pressflow est une version piratée de Drupal qui a été créée en pensant aux performances et pour résoudre certains problèmes de performances qu'un site Drupal pourrait avoir.

N'y a-t-il pas des problèmes qui ne peuvent être résolus qu'en piratant le cœur? Et alors?

La plupart du temps, il est possible de modifier les fonctionnalités / le comportement sans modifier le code core Drupal. Il y a toujours un crochet qui permet de changer les fonctionnalités / comportements de Drupal, et c'est la méthode préférée.

Je pourrais écrire une réponse massive ici, mais je vais juste poster ce lien: ne jamais pirater le cœur !

Je suppose que la principale raison est que si vous piratez le noyau pour faire quelque chose dont vous avez besoin, puis le mettez à jour ... BANG! Vos modifications ont disparu. Perdu. Vous pouvez ensuite essayer de restaurer le code de votre VCS, mais étant donné que vous ne pouvez pas annuler les mises à niveau de base de données à partir du noyau Drupal - vous envisagez de restaurer tout le code à partir de VCS, puis de restaurer les bases de données à partir de vos sauvegardes. Tout le temps que vous essayez de restaurer votre code, vous remarquerez probablement que votre dernière sauvegarde de base de données de pré-mise à jour a échoué, et vous jurez plus que vous ne l'avez juré auparavant.

Aussi - le plus important - si vous piratez le noyau, alors Dries et Webchick tuent tous les deux un chaton: -o

"Qu'est-ce qu'un noyau de piratage ne peut pas faire pour moi, le développeur?"

• Votre site peut être mis à niveau pour les versions de sécurité
• Votre site peut être mis à niveau pour corriger des bogues ennuyeux dans le noyau
• Votre site peut être mis à niveau pour prendre en charge de nouveaux modules
• Vos rapports de bogues et demandes de support sur core et contrib pourront être traités
• Vous souhaitez utiliser un CMS pris en charge, c'est pourquoi vous avez choisi Drupal. Lorsque vous piratez le noyau, selon les mots de Webchick , "Si vous piratez le noyau, félicitations! Vous avez créé votre propre fork de Drupal, et maintenant vous et vous seul êtes responsable de le maintenir!"

"Qu'est-ce qu'un hacking core ne peut pas faire pour mon client?"

• Votre site peut être entretenu par quelqu'un d'autre après avoir licencié votre client / gagné à la loterie / vous faire frapper par un bus

"Qu'est-ce qu'un noyau de piratage ne peut pas faire pour ma communauté?"

• Vos rapports de bogues fourniront en fait des informations utiles au mainteneur des modules de base ou contrib.
• Si vous trouvez un bug légitime dans le noyau qui doit être corrigé, la ligne entre `` pirater le cœur '' et `` devenir un contributeur principal '' est aussi fine que simplement diff'er vos modifications et les télécharger en tant que correctif dans un problème de do pertinent. Alto! Le noyau est meilleur pour vos efforts, et votre nom est associé à redonner du code à la communauté.

Tout le monde est gagnant lorsque vous ne piratez pas le cœur!

Je travaille actuellement sur un site Web principal piraté. J'ai du mal à trouver comment quelque chose d'aussi simple que la police est mis en place. J'ai également passé quelques jours à corriger un bug introduit par le hack de base. Je l'ai trouvé en recherchant une chaîne dans tout le code drupal.

Si vous ne suivez pas la structure standard de la programmation dans drupal, comment quelqu'un d'autre peut-il trouver et éditer les changements que vous introduisez? C'est particulièrement pénible car dans drupal, chaque fichier php peut implémenter un hook. Essayez de déterminer lequel cause des problèmes.

"N'y a-t-il pas des problèmes qui ne peuvent être résolus qu'en piratant le noyau? Et alors?"

Pour répondre à cette question, oui, il y a parfois des problèmes que vous devez surmonter, ce qui signifie que vous devez pirater le cœur (ou un module contrib).

Dans ce cas, je pense qu'il est correct de pirater tant que vous mettez beaucoup de commentaires dans votre code piraté et documentez tout ce que vous changez.

Par exemple, pour tout changement de cœur ou de contribution que je fais, je crée un patch. S'il est générique et utile à d'autres personnes, je le soumets à drupal.org dans un numéro, sinon c'est pour mon usage personnel.

Je valide ensuite le fichier de correctif dans mon contrôle de version avec le changement de code.

Cela signifie que je peux voir en recherchant des fichiers de correctifs si quelque chose a été piraté.

En plus de cela, j'ajoute également une liste de hacks à la documentation développeur pour le site (vous devriez vraiment avoir une documentation développeur pour le bien des autres qui pourraient travailler sur le site et pour vous-même lorsque vous oubliez inévitablement des choses).

Dans cette documentation de hacks, je liste chaque hack avec ce que fait le hack et pourquoi, les modules / fichiers affectés, le nom du fichier de patch qui contient le code de hack et un lien vers un problème drupal.org connexe s'il y en a un (presque toujours dans mon cas il y en a).

Ensuite, vous et toute autre personne travaillant sur le site à l'avenir disposez d'une liste complète de hacks et n'avez pas à vous soucier de casser accidentellement quelque chose avec une mise à jour.

Ensuite, pour le processus de mise à jour, je vérifie ma liste de hacks et jette un œil aux fichiers de correctifs dans tous les modules que je mets à jour. S'il y a un hack et qu'il y a un problème avec drupal.org, je vérifie le problème pour voir si la dernière version a le patch inclus, auquel cas je supprime le hack avec la mise à jour et le supprime de ma liste de hacks (make en regardant les messages de validation de drupal.org, assurez-vous que ce qui a été validé était la même que la version du correctif que vous utilisez, ou du moins fonctionnellement la même).

Si le correctif n'a pas été validé, tout ce que j'ai à faire est de mettre à jour les modules et de réappliquer les correctifs. Dans de nombreux cas, les correctifs s'appliqueront toujours proprement et le processus est facile, mais parfois vous devez relancer les correctifs pour la nouvelle version, puis valider la nouvelle version du correctif dans votre référentiel local (avec la publication sur le site concerné) problème drupal.org le cas échéant).

Une autre chose que j'aime faire si j'ai des correctifs plus substantiels ou des correctifs qui interagissent avec la fonctionnalité principale d'un module (ou simplement des modules personnalisés qui s'étendent au-dessus d'un module drupal.org), est de vérifier les notes de publication du module mis à jour ( cela signifie que toutes les versions entre votre version actuelle et la version vers laquelle vous effectuez la mise à jour) et assurez-vous qu'il n'y a rien là-dedans susceptible de casser votre code. Remarque: Beaucoup de mainteneurs de modules sont bons de nos jours avec des notes de version complètes, mais il y en a encore beaucoup qui font des notes de version. Dans ce cas, dans certains cas, je passe par tous les messages de validation depuis ma version actuelle (ce n'est généralement que dans les cas où j'ai du code complexe qui interagit profondément avec un autre module). Remarque:

Ensuite, après la mise à jour (sur une copie de développement du site), testez soigneusement. Vous apprendrez finalement ce que signifie complètement après que quelques bogues se soient glissés.

Ensuite, quand il a été suffisamment testé, mettez à niveau le site en direct ou augmentez vos mises à jour locales ou quel que soit votre processus de déploiement.

La raison pour laquelle tout le monde dit de ne pas le faire, même si c'est plus facile: parce que la plupart des gens n'ont pas de système comme je l'ai décrit, donc quand vient le temps de faire des mises à jour, ou que le site est remis à quelqu'un d'autre pour travailler sur, cela devient un cauchemar et beaucoup de temps (parfois énormément de temps) doit être consacré à résoudre les bugs et à traquer les hacks et à trouver pourquoi ils sont là, etc.

Si vous avez hérité d'un site comme celui-ci, vous comprendrez parfaitement :)

Si vous gagnez votre vie en installant et en créant des sites Web Drupal, il est nécessaire de les tenir à jour. Si la plupart de vos sites sont horriblement obsolètes, vous n'êtes pas professionnel.