Pourquoi ne piratons-nous pas le noyau?

17

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?

community-official-site

— beth
source

Je pense que si vous créez vous-même un petit site Web sans équipe, vous pouvez peut-être pirater le cœur si vous en avez besoin, mais pourquoi en avez-vous besoin? Je crois que vous pouvez résoudre n'importe quel problème sans pirater le cœur

— Petro Popelyshko

4

@beth, je suis vraiment très sérieux à ce sujet. Les correctifs nécessaires pour les pages sécurisées dans D7 ont été suspendus depuis plus d'un an maintenant en raison de problèmes avec les tests unitaires. Pour autant que je me souvienne, il y a encore un bug dans D6 avec les longueurs de nom de machine de menu. Aucun de ceux-ci n'a montré de progrès dans l'engagement réel.

— mpdonadio

3

@MPD C'est un excellent exemple en fait, je connais un bon nombre de personnes qui réclament ces correctifs pour y arriver (moi inclus). Mis à part les chatons, il est évident que parfois vous devez absolument corriger le noyau et il n'y a rien de mal à cela tant que ces correctifs sont bien documentés et disponibles pour tout le monde dans l'équipe. Cela montre également l'importance d'avoir un processus de déploiement solide, un processus qui n'effectue pas aveuglément les mises à jour sans que des vérifications semi-manuelles ne se produisent au préalable. Dans ma (petite) équipe, nous documentons simplement ce qui a changé et nous assurons que tout le monde sait le vérifier avant la mise à jour

— Clive

3

Appliquez le correctif et notez-le dans un fichier texte à la racine de votre référentiel.

— Charlie Schliesser

1

Je reformulerais la phrase en "Ne piratez jamais le cœur, à moins que vous n'ayez un mécanisme pour conserver vos mises à jour". Cela nécessite une certaine réflexion et a des implications sur votre flux de travail de développement. Si vous ou votre équipe n'êtes pas prêts pour ce baby-sitting supplémentaire, ne le faites pas.

— donquixote

9

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.

— kiamlaluno
source

4

Je peux publier deux problèmes du monde réel que j'ai rencontrés et qui peuvent remettre en cause les affirmations du dernier paragraphe.

— mpdonadio

3

In the case your hacked version introduces a different security issue...Je ne vois pas cela comme un argument particulièrement fort modifiant un fichier core par rapport à autre chose. Si je ne pirate pas le cœur et que j'introduis un problème de sécurité via un module, mon système sera toujours compromis. Le compromis est compromis, peu importe que cela vienne de moi qui édite un fichier existant ou en ajoute un nouveau.

— Zoredache

@Zoredache Si le problème de sécurité est présent dans votre module, vous pouvez toujours le désactiver, et le reste du site fonctionnerait sans problème de sécurité, même sans fonctionnalités. Si vous introduisez un problème de sécurité dans le code principal de Drupal, et qu'il n'est pas possible de simplement recopier les fichiers d'origine parce que vous avez également modifié le schéma de certaines tables utilisées par Drupal, alors c'est un problème plus important.

— kiamlaluno

2

L'énoncé selon lequel "il y a toujours un crochet ..." n'est pas correct. Il n'est pas tout à fait rare qu'il y ait quelque chose qui est intégré dans le noyau drupal qui ne peut pas être contourné sans piratage, et aussi qu'il existe des problèmes ouverts pour drupal avec des correctifs qui n'ont pas été validés, auquel cas vous devez patcher le noyau pour résoudre ces problèmes.

— rooby

2

Absolument, mais c'est un exemple simple. Dans la plupart des cas, il existe des hooks, mais il y a encore des moments où vous devez patcher le core, sauf si vous voulez dupliquer beaucoup de code et créer quelque chose de plus personnalisé. Par exemple, pour permettre aux administrateurs d'administrer correctement les livres non publiés, vous avez besoin du correctif sur drupal.org/node/520786 ou si vous souhaitez que la recherche SQL par défaut de drupal corresponde à des mots partiels (y compris le filtre de recherche des vues), vous avez besoin du correctif sur drupal.org / node / 498752 # comment-6001310 - il n'est pas possible de contourner ces problèmes sans pirater le noyau.

— rooby

14

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

— Chapabu
source

4

Quoi, ils tuent le chaton? Je pensais que c'était Dieu. . Mon monde s'écroule autour de lui ...

— Clive

1

Vous savez, j'ai écrit mon commentaire ci-dessus avant de voir les chatons mentionnés ici.

— mpdonadio

13

"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!

— beth
source

3

Tous les correctifs ne sont pas engagés dans le noyau, même les plus simples.

— mpdonadio

1

Certes, mais en le téléchargeant, vous avez au moins un enregistrement du correctif, de ce qu'il fait, éventuellement des versions améliorées par d'autres, et la possibilité de le télécharger et de le réappliquer à votre projet si vous avez une mise à jour qui écrase votre changement. Et souvent une raison pour laquelle il n'a pas été engagé, et des suggestions alternatives. Tout cela gratuitement.

— beth

6

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.

— Pawel G
source

4

Cette. Si vous héritez d'un site qui a été construit sur un cadre donné, puis découvrez que le cadre a été piraté et que la documentation de ce cadre est donc potentiellement hors de propos, vous êtes dans un monde difficile. (en plus de toutes les autres raisons susmentionnées ci-dessus ...)

— Charlie Schliesser

5

Je parie que vous aimeriez avoir entendu parler de drupal.org/project/hacked plus tôt?

— Chris Burgess

Ça a l'air bien Chris. Je vais certainement y jeter un œil.

— Pawel G

Un système de contrôle de source décent devrait être en mesure de vous dire ce qui a changé et de montrer toutes les modifications apportées au noyau. La recherche de chaînes dans une base de code devrait être une partie standard de votre boîte à outils de débogage en php.

— Toby Allen

5

"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 :)

— rooby
source

2

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.

— jalal
source