Dlaczego nie zhakujemy rdzenia?

Nie mogłem uwierzyć, że na to pytanie nie ma jeszcze odpowiedzi na to pytanie, ale nie znalazłem go podczas wyszukiwania, więc ...

Dlaczego włamanie do rdzenia jest tak złym pomysłem, że przestępstwo przeciwko naturze?

• Czy naprawdę wspaniale jest móc zaktualizować swoją podstawową wersję? Większość moich witryn i tak ma strasznie nieaktualne rdzenie, więc po co się tym przejmować?
• Nawet jeśli jest to tak złe dla właścicieli witryn, dlaczego społeczność tak bardzo się przejmuje? Dlaczego nazywa się to „zabijaniem kociąt”? Czy to nie jest raczej hiperboliczne?
• Hakowanie rdzenia jest tak łatwe, czy nie lubimy łatwiejszej drogi do rozwiązania problemu?
• Czy nie ma problemów, które można rozwiązać tylko poprzez zhakowanie rdzenia? Co wtedy?

Ogólnie rzecz biorąc, istnieją trzy powody, dla których nie należy zmieniać podstawowego kodu Drupala:

• Twoje zmiany zostaną utracone przy każdej aktualizacji Drupala, jeśli nie podejmiesz żadnych niezbędnych kroków. Nawet w przypadku, gdy utworzysz łatkę dla bieżącej wersji Drupala, której używasz, łatka nie będzie mogła dotyczyć nowszej wersji, i będziesz musiał utworzyć łatkę również dla nowej wersji.

• Poprawki bezpieczeństwa dotyczą rdzenia Drupal utrzymanego na Drupal.org, ale nie mogą dotyczyć twojej zhakowanej wersji. Oznacza to, że powinieneś sprawdzić, czy na twoją wersję nie wpływa problem bezpieczeństwa podniesiony w stosunku do rdzenia Drupal.
  W przypadku, gdy twoja zhakowana wersja wprowadza inny problem bezpieczeństwa, jesteś jedyną osobą, którą możesz go znaleźć, ponieważ nie masz wsparcia zespołu bezpieczeństwa, który bada luki w zabezpieczeniach obecne w podstawowym kodzie Drupala i firmach trzecich moduły hostowane na Drupal.org.

• Wprowadzane zmiany mogą być niezgodne z samym Drupalem, ale także z modułami innych firm, które są wymagane do pracy z rdzeniem Drupala, a nie z żadną wersją hakera, którą można stworzyć.
  Za każdym razem, gdy Drupal wprowadza nową funkcję (która wciąż dzieje się w Drupal 7 i Drupal 6, choć z mniejszą częstotliwością) lub nową zmianę API, istnieje szansa, że ​​zaatakowana wersja jest niezgodna z ostatnimi zmianami.

To powiedziawszy, możliwe jest stworzenie zhakowanej wersji, ale nie jest to zadanie, które może wykonać pojedynczy programista, podobnie jak Drupal nie jest obsługiwany przez jedną osobę. W rzeczywistości Pressflow to zhakowana wersja Drupala, która została stworzona z myślą o wydajności i aby rozwiązać niektóre problemy z wydajnością, które mogłaby mieć witryna Drupal.

Czy nie ma problemów, które można rozwiązać tylko poprzez zhakowanie rdzenia? Co wtedy?

W większości przypadków można zmieniać cechy / zachowanie bez edycji podstawowego kodu Drupala. Zawsze istnieje hak, który pozwala zmienić cechy / zachowania Drupala i jest to preferowana metoda.

Mógłbym napisać tutaj ogromną odpowiedź, ale po prostu opublikuję ten link: Nigdy nie rąbaj rdzenia !

Wydaje mi się, że głównym powodem jest to, że jeśli włamiesz rdzeń, aby zrobić coś, czego potrzebujesz, a następnie zaktualizujesz go ... BANG! Twoje zmiany zniknęły. Stracony. Możesz wtedy spróbować przywrócić kod z VCS, ale ponieważ nie możesz wycofać aktualizacji bazy danych z rdzenia Drupal - chcesz przywrócić cały kod z VCS, a następnie przywrócić bazy danych z kopii zapasowych. Przez cały czas próby przywrócenia kodu prawdopodobnie zauważysz, że ostatnia kopia zapasowa bazy danych przed aktualizacją nie powiodła się, i będziesz przeklinać więcej niż kiedykolwiek wcześniej.

Ponadto - co najważniejsze - jeśli zhakujesz rdzeń, zarówno Dries, jak i Webchick zabiją kociaka: -o

„Czego nie może zrobić hakowanie rdzenia dla mnie, programisty?”

• Twoja witryna może zostać zaktualizowana do wersji bezpieczeństwa
• Twoja strona może zostać zaktualizowana, aby naprawić irytujące błędy w rdzeniu
• Twoja witryna może zostać zaktualizowana w celu obsługi nowych modułów
• Odpowiedzi na twoje zgłoszenia błędów i prośby o wsparcie dotyczące rdzenia i wkładu będą możliwe
• Chcesz korzystać z obsługiwanego CMS, dlatego wybrałeś Drupal. Kiedy włamujesz się do rdzenia, słowami webchicka : „Jeśli włamujesz się do rdzenia, gratulacje! Stworzyłeś własny widelec Drupala, a teraz ty i ty jesteś odpowiedzialny za jego utrzymanie!”

„Co nie może zrobić hakowanie rdzenia dla mojego klienta?”

• Twoja strona może być utrzymywana przez kogoś innego po zwolnieniu klienta / wygraniu loterii / potrąceniu autobusu

„Co nie może zhakować rdzenia dla mojej społeczności?”

• Twoje raporty błędów faktycznie dostarczą użytecznych informacji dla opiekuna modułów podstawowych lub contrib.
• Jeśli znajdziesz uzasadniony błąd w rdzeniu, który musi zostać załatany, granica między „hackowaniem rdzenia” a „staniem się głównym współtwórcą” jest tak dobra, jak po prostu różnicowanie twoich zmian i przesyłanie ich jako łatki do odpowiedniego problemu do. Altówka! Rdzeń jest lepszy dla twoich wysiłków, a twoje imię jest związane z dawaniem kodu zwrotnego społeczności.

Każdy jest zwycięzcą, jeśli nie zhakujesz rdzenia!

Obecnie pracuję nad zhakowaną główną witryną. Mam trudności ze znalezieniem, jak konfiguruje się coś tak prostego jak czcionka. Spędzam także kilka dni naprawiając błąd, który został wprowadzony przez hack rdzeniowy. Znalazłem go, szukając ciągu w całym kodzie drupala.

Jeśli nie przestrzegasz standardowej struktury programowania w Drupalu, to jak ktoś inny może znaleźć i edytować wprowadzone zmiany? Jest to szczególnie bolesne, ponieważ w Drupal każdy plik php może zaimplementować hook. Spróbuj dowiedzieć się, który z nich powoduje problemy.

„Czy nie ma problemów, które można rozwiązać tylko poprzez zhakowanie rdzenia? Co wtedy?”

Aby odpowiedzieć na to pytanie, tak, czasami są problemy, które musisz rozwiązać, co oznacza, że ​​musisz zhakować rdzeń (lub moduł contrib).

W tym przypadku uważam, że włamanie jest dopuszczalne, o ile umieścisz wiele komentarzy w zhakowanym kodzie i udokumentujesz wszystko, co zmienisz.

Na przykład dla każdej zmiany rdzenia lub wkładu tworzę łatkę. Jeśli jest ogólny i przydatny dla innych osób, przesyłam go do drupal.org w jednym wydaniu, w przeciwnym razie jest to na własny użytek.

Następnie zatwierdzam plik łaty do kontroli wersji wraz ze zmianą kodu.

Oznacza to, że widzę, szukając plików łat, jeśli coś zostało zhakowane.

Oprócz tego dodałem również listę hacków do dokumentacji programisty dla witryny (naprawdę powinieneś mieć dokumentację programisty ze względu na innych, którzy mogą pracować w witrynie i dla siebie, gdy nieuchronnie zapomnisz rzeczy).

W tej dokumentacji hakerskiej wymieniam każdy hack wraz z tym, co robi hack i dlaczego, dotyczy to modułów / plików, nazwy pliku łatki zawierającego kod hacka oraz link do powiązanego problemu drupal.org, jeśli taki istnieje (prawie zawsze w moim przypadku jest).

Wtedy Ty i ktokolwiek inny będzie pracował na stronie w przyszłości, ma pełną listę hacków i nie musisz się martwić o przypadkowe uszkodzenie czegoś podczas aktualizacji.

Następnie w celu aktualizacji sprawdzam swoją listę hacków i szybko szukam plików łatek we wszystkich aktualizowanych modułach. Jeśli jest hack i ma problem z drupal.org, sprawdzam ten problem, aby zobaczyć, czy najnowsza wersja zawiera łatkę, w którym to przypadku zdmuchnę hacka z aktualizacją i usunę go z mojej listy hacków (wykonaj z pewnością patrząc na komunikaty zatwierdzania drupal.org, że to, co zostało popełnione, było takie samo jak wersja używanej łatki lub przynajmniej funkcjonalnie takie samo).

Jeśli łatka nie została zatwierdzona, wszystko, co muszę zrobić, to zaktualizować moduły i ponownie zastosować łatki. W wielu przypadkach łatki będą nadal stosowane czysto, a proces jest łatwy, ale czasami trzeba przerzucić łaty do nowej wersji, a następnie zatwierdzić nową wersję poprawki do lokalnego repozytorium (wraz z opublikowaniem jej w odpowiednim problem z drupal.org, jeśli dotyczy).

Inną rzeczą, którą lubię, jeśli mam bardziej znaczące łaty lub łaty, które współdziałają z podstawową funkcją modułu (lub po prostu niestandardowe moduły, które rozciągają się na moduł drupal.org), jest sprawdzenie informacji o wydaniu zaktualizowanego modułu ( oznacza to wszystkie wersje między bieżącą wersją a wersją, którą aktualizujesz) i upewnij się, że nie ma w niej nic, co mogłoby uszkodzić kod. Uwaga: Wielu opiekunów modułów jest obecnie dobrych, podając pełne informacje o wydaniu, ale wciąż jest wiele, którzy robią śmieci. W tym przypadku w niektórych przypadkach przeglądam wszystkie komunikaty zatwierdzenia od mojej bieżącej wersji (zwykle dzieje się tak tylko w przypadkach, gdy mam złożony kod, który głęboko współdziała z innym modułem). Uwaga:

Następnie po aktualizacji (na kopii rozwojowej witryny) przetestuj dokładnie. W końcu dowiesz się, co dokładnie oznacza po kilku błędach.

Następnie, gdy zostanie wystarczająco przetestowany, uaktualnij działającą witrynę lub wypchnij lokalne aktualizacje w górę, lub jakikolwiek proces instalacji.

Powód, dla którego wszyscy mówią, nie rób tego, nawet jeśli jest to łatwiejsze: ponieważ większość ludzi nie ma systemu takiego jak ja zarysowałem, więc kiedy przychodzi czas na aktualizację lub witryna jest przekazywana komuś innemu do pracy dalej staje się koszmarem i dużo czasu (czasem ogromnej ilości czasu) trzeba poświęcić na rozwiązywanie problemów i śledzenie włamań i ustalanie, dlaczego się tam znajdują itp.

Jeśli kiedykolwiek odziedziczysz taką witrynę, w pełni to zrozumiesz :)

Jeśli zarabiasz na życie dzięki instalowaniu i tworzeniu stron internetowych Drupal, musisz je aktualizować. Jeśli większość Twoich witryn okaże się nieaktualna, nie jesteś profesjonalistą.