Por que não cortamos o núcleo?

17

Eu não podia acreditar que esta pergunta ainda não foi respondida neste site, mas não a encontrei quando procurei, então ...

Por que um crime contra a natureza é tão ruim para invadir o núcleo?

É realmente ótimo poder atualizar sua versão principal? A maioria dos meus sites acaba tendo núcleos horrivelmente desatualizados, então por que se preocupar?
Mesmo que seja tão ruim para os proprietários de sites, por que a comunidade se importa tanto? Por que é referido como "matar gatinhos"? Isso não é hiperbólico?
O núcleo de hackers é tão fácil, não gostamos de seguir o caminho mais fácil para a solução de problemas?
Não existem problemas que só podem ser resolvidos com o hacking core? O que então?

community-official-site

— beth
fonte

Eu acho que se você está criando um pequeno site sozinho, sem equipe, talvez você possa hackear o núcleo, se precisar, mas por que você precisa disso? eu acredito que você pode resolver qualquer problema sem núcleo de hackers

— Petro Popelyshko

4

@ beth sou realmente muito sério sobre isso. Os patches necessários para páginas seguras no D7 foram suspensos há mais de um ano, devido a problemas nos testes de unidade. Tanto quanto me lembro, ainda existe um bug no D6 com o tamanho dos nomes das máquinas de menu. Nenhuma delas demonstrou qualquer progresso em se comprometer de verdade.

— mpdonadio

3

@MPD Esse é um ótimo exemplo, na verdade, eu conheço algumas pessoas que clamam por esses patches para fazer isso (inclusive eu). Gatinhos à parte, obviamente, às vezes, é absolutamente necessário corrigir o núcleo e não há nada de errado nisso, desde que esses patches estejam bem documentados e disponíveis para todos da equipe. Ele também fala da importância de ter um processo de implantação sólido, que não realize atualizações às cegas sem que as verificações semi-manuais ocorram antes. Na minha (pequena) equipe, apenas documentamos o que mudou e garantimos que todos saibam verificá-lo antes de atualizar.

— Clive

3

Aplique o patch e anote-o em um arquivo de texto que esteja na raiz do seu repositório.

— precisa saber é o seguinte

1

Eu a reformularia para "Nunca hackear o núcleo, a menos que você tenha um mecanismo para ainda ter suas atualizações". Isso requer alguma reflexão e tem implicações no seu fluxo de trabalho de desenvolvimento. Se você ou sua equipe não estão aptos para esse serviço extra de babá, não faça isso.

— 9788 donutixote

9

De um modo geral, existem três razões para não alterar o código principal do Drupal:

Suas alterações serão perdidas toda vez que você atualizar o Drupal, se você não tomar as etapas necessárias. Mesmo no caso de você criar um patch para a versão atual do Drupal em uso, o patch não pode ser aplicado à versão mais recente e você também precisará criar um patch para a nova versão.
As correções de segurança se aplicam ao núcleo do Drupal, conforme mantido no Drupal.org, mas não podem ser aplicadas à sua versão invadida. Isso significa que você deve verificar se sua versão não é afetada pelo problema de segurança levantado no núcleo do Drupal.
No caso de sua versão invadida apresentar um problema de segurança diferente, você é a única pessoa que o encontrará, pois não possui o suporte da equipe de segurança que investiga as falhas de segurança presentes no código principal do Drupal e em terceiros. módulos hospedados no Drupal.org.
As alterações introduzidas podem ser incompatíveis com o próprio Drupal, mas também com módulos de terceiros, necessários para trabalhar com o núcleo do Drupal, e não com qualquer versão invadida que possa ser criada.
Toda vez que o Drupal apresenta um novo recurso (que ainda acontece no Drupal 7 e no Drupal 6, embora com menos frequência), ou uma nova alteração na API, existe a chance de a versão invadida ser incompatível com as alterações recentes.

Dito isso, é possível criar uma versão invadida, mas essa não é a tarefa que um único desenvolvedor pode realizar, da mesma forma que o Drupal não é mantido por uma única pessoa. De fato, o Pressflow é uma versão hackeada do Drupal que foi criada com o desempenho em mente e para resolver alguns problemas de desempenho que um site do Drupal poderia ter.

Não existem problemas que só podem ser resolvidos por hackers? O que então?

Na maioria das vezes, é possível alterar os recursos / comportamento sem editar o código principal do Drupal. Sempre existe um gancho que permite alterar os recursos / comportamentos que o Drupal possui, e esse é o método preferido.

— kiamlaluno
fonte

4

Posso postar dois problemas do mundo real que encontrei que podem desafiar as afirmações do último parágrafo.

— mpdonadio

3

In the case your hacked version introduces a different security issue...Não vejo isso como um argumento particularmente forte modificando um arquivo principal em comparação com qualquer outra coisa. Se eu não estiver invadindo o núcleo, e ao invés disso apresentar um problema de segurança por meio de um módulo, meu sistema ainda estará comprometido. O comprometimento está comprometido, realmente não importa se isso veio de mim editando um arquivo existente ou adicionando um novo.

— Zoredache 31/01

@Zoredache Se o problema de segurança estiver presente no seu módulo, você sempre poderá desativá-lo e o restante do site funcionará sem problemas de segurança, mesmo sem recursos. Se você introduzir um problema de segurança no código principal do Drupal, e não for possível simplesmente copiar de volta os arquivos originais, porque você também alterou o esquema de algumas tabelas usadas pelo Drupal, esse é um problema maior.

— kiamlaluno

2

A afirmação de que "sempre há um gancho ..." não está correta. Não é incomum que exista algo incorporado ao núcleo do drupal que não possa ser contornado sem hackers, e também que haja problemas em aberto para o drupal com patches que não foram confirmados; nesse caso, você deve corrigir o core para resolver esses problemas.

— ROOBY

2

Absolutamente, mas esse é um exemplo simples. Na maioria dos casos, existem ganchos, mas ainda há momentos em que você precisa corrigir o núcleo, a menos que queira duplicar muito código e criar algo mais personalizado. Por exemplo, para permitir que os administradores administrem adequadamente livros não publicados, você precisa do patch em drupal.org/node/520786 ou se deseja que a pesquisa SQL padrão do drupal corresponda a palavras parciais (incluindo o filtro de pesquisa de visualizações), você precisa do patch em drupal.org / node / 498752 # comment-6001310 - não é possível contornar esses problemas sem o núcleo do hacking.

— rooby 02/02

14

Eu poderia escrever uma resposta enorme aqui, mas vou postar este link: Nunca hackear o núcleo !

A principal razão que eu acho é que, se você cortar o núcleo para fazer algo que precisa, e atualizá-lo ... BANG! Suas alterações se foram. Perdido. Você pode tentar reverter o código do seu VCS, mas como não é possível reverter as atualizações do banco de dados a partir do núcleo do Drupal - você está tentando restaurar todo o código do VCS e depois restaurar os bancos de dados dos seus backups. Todo o tempo que você estiver tentando reverter seu código, provavelmente notará que seu último backup de banco de dados de pré-atualização falhou e jurará mais do que jamais jurou antes.

Além disso - o mais importante - se você cortar o núcleo, Dries e Webchick matam um gatinho: -o

— Chapabu
fonte

4

O que, eles matar o gatinho? Eu pensei que era Deus. . Meu mundo está caindo em torno de si ...

— Clive

1

Sabe, eu escrevi meu comentário acima antes de ver gatinhos mencionados aqui.

— mpdonadio

13

"O que o núcleo de hackers não pode fazer por mim, o desenvolvedor?"

Seu site pode ser atualizado para versões de segurança
É possível atualizar seu site para corrigir bugs irritantes no núcleo
Seu site pode ser atualizado para suportar novos módulos
Seus relatórios de bugs e solicitações de suporte no core e no contrib poderão ser respondidos a
Você deseja usar um CMS suportado, por isso escolheu o Drupal. Quando você corta o núcleo, nas palavras do webchick , "Se você corta o núcleo, parabéns! Você criou seu próprio fork do Drupal e agora você e você é responsável por mantê-lo!"

"O que o núcleo de hackers não pode fazer pelo meu cliente?"

Seu site pode ser mantido por outra pessoa após você demitir seu cliente / ganhar na loteria / ser atropelado por um ônibus

"O que o núcleo de hackers não pode fazer pela minha comunidade?"

Seus relatórios de bugs realmente fornecerão informações úteis para o mantenedor dos módulos principais ou de contribuição.
Se você encontrar um bug legítimo no núcleo que deve ser corrigido, a linha entre 'núcleo hacking' e 'tornar-se um colaborador principal' é tão boa quanto simplesmente diferenciar suas alterações e enviá-las como um patch para um problema relevante. Viola! O núcleo é melhor por seus esforços e seu nome está associado à devolução de código à comunidade.

Todo mundo é um vencedor quando você não invade o núcleo!

— beth
fonte

3

Nem todos os patches são comprometidos com o núcleo, mesmo os simples.

— mpdonadio

1

É verdade, mas ao fazer o upload, você tem pelo menos um registro do patch, o que ele faz, possivelmente algumas versões que foram aprimoradas por outros e a capacidade de fazer o download e aplicá-lo ao seu projeto novamente se houver uma atualização que substitua sua mudança. E frequentemente uma razão pela qual não foi confirmada e sugestões alternativas. Tudo de graça.

— beth 30/01

6

Atualmente, estou trabalhando em um site principal hackeado. Tenho dificuldade em descobrir como algo tão simples quanto a fonte está sendo configurado. Também passo alguns dias consertando um bug que foi introduzido pelo hack do núcleo. Eu o encontrei pesquisando uma string em todo o código drupal.

Se você não segue a estrutura padrão de programação no drupal, como alguém pode encontrar e editar as alterações introduzidas? Isso é especialmente doloroso porque, no drupal, todos os arquivos php podem implementar um gancho. Tente descobrir qual deles está causando problemas.

— Pawel G
fonte

4

Este. Se você herdar um site que foi criado em qualquer estrutura específica e descobrir que a estrutura foi invadida e, portanto, a documentação dessa estrutura é potencialmente irrelevante, você estará em um mundo de dificuldades. (para além de todas as outras razões acima mencionadas acima ...)

— Charlie Schliesser

5

Aposto que você gostaria de ter ouvido falar sobre drupal.org/project/hacked anteriormente?

— Chris Burgess

Parece bom Chris. Definitivamente vou dar uma olhada.

— Pawel G

Um sistema de controle de origem decente deve ser capaz de informar o que mudou e mostrar todas as modificações no núcleo. Procurar por strings em uma base de código deve ser parte padrão do seu kit de ferramentas de depuração no php.

— Toby Allen

5

"Não existem problemas que só podem ser resolvidos com o hacking core? E então?"

Para responder a essa pergunta, sim, às vezes há problemas que você precisa superar, o que significa que você precisa invadir o núcleo (ou um módulo de contribuição).

Nesse caso, acredito que não há problema em invadir, desde que você coloque muitos comentários em seu código invadido e documente tudo o que mudar.

Por exemplo, para qualquer alteração no núcleo ou no contrib, eu crio um patch. Se for genérico e útil para outras pessoas, eu o envio ao drupal.org em uma edição, caso contrário, é para meu próprio uso.

Em seguida, submeto o arquivo de correção ao meu controle de versão, juntamente com a alteração do código.

Isso significa que eu posso ver procurando arquivos de correção se algo foi invadido.

Além disso, também adiciono uma lista de hacks à documentação do desenvolvedor do site (você realmente deve ter a documentação do desenvolvedor para o bem de outras pessoas que possam funcionar no site e para si mesmo quando inevitavelmente esquecer as coisas).

Nesta documentação sobre hacks, listo cada hack com o que o hack faz e por que, módulos / arquivos afetados, o nome do arquivo de correção que contém o código de hack e um link para um problema relacionado do drupal.org, se houver um (quase sempre no meu caso existe).

Então você e quem mais trabalha no site no futuro tem uma lista completa de hacks e não precisa se preocupar em quebrar acidentalmente algo com uma atualização.

Então, para o processo de atualização, verifico minha lista de hacks e dou uma olhada rápida nos arquivos de correção em todos os módulos que estou atualizando. Se houver um hack e houver um problema no drupal.org, eu verifico o problema para ver se a versão mais recente inclui o patch. Nesse caso, eu explodo o hack com a atualização e o removo da minha lista de hacks (faça Certifique-se de olhar para o drupal.org confirmar mensagens de que o que foi confirmado era o mesmo que a versão do patch que você está usando, ou pelo menos funcionalmente o mesmo).

Se o patch não foi confirmado, tudo o que tenho a fazer é atualizar os módulos e reaplicar os patches. Em muitos casos, os patches ainda serão aplicados de maneira limpa e o processo é fácil, mas às vezes é necessário rolar novamente os patches para a nova versão e, em seguida, confirmar a nova versão do patch no repositório local (juntamente com a publicação no site relevante). drupal.org, quando aplicável).

Outra coisa que gosto de fazer se tiver patches ou patches mais substanciais que interajam com a funcionalidade do núcleo de um módulo (ou apenas módulos personalizados que se estendem sobre o módulo drupal.org), é verificar as notas de versão do módulo atualizado ( isso significa toda a versão entre a versão atual e a versão para a qual você está atualizando) e verifique se não há nada que possa quebrar seu código. Nota: Atualmente, muitos mantenedores de módulos são bons em fornecer notas de versão completas, mas ainda existem muitas que fazem notas de versão de lixo. Nesse caso, em alguns casos, passo todas as mensagens de confirmação desde a minha versão atual (isso geralmente ocorre apenas nos casos em que tenho código complexo que interage profundamente com outro módulo). Nota:

Em seguida, após a atualização (em uma cópia de desenvolvimento do site), faça um teste completo. Você finalmente aprenderá o que significa completamente depois que alguns erros passarem.

Depois, quando tiver sido testado o suficiente, atualize o site ativo ou atualize suas atualizações locais ou qualquer que seja o processo de implantação.

A razão pela qual todo mundo diz que não faz isso, mesmo que seja mais fácil: porque a maioria das pessoas não tem um sistema como eu descrevi, então quando chega a hora de fazer atualizações ou o site é entregue a outra pessoa para trabalhar isso se torna um pesadelo e é necessário muito tempo (às vezes uma quantidade enorme de tempo) solucionando bugs, rastreando hacks e descobrindo por que eles estão lá, etc.

Se você herdar um site como esse, entenderá completamente :)

— rooby
fonte

2

Se você ganha a vida instalando e criando sites do Drupal, é necessário mantê-los atualizados. Se a maioria dos sites acabar desatualizada, você não é profissional.

— jalal
fonte