Чому ми не зламаємо ядро?

Я не міг повірити, що на це питання ще не відповіли на цьому сайті, але я не знайшов його, коли шукав, так що ...

Чому так злобна ідея проти природи зламати ядро?

• Невже це чудово, щоб можна було оновити основну версію? Більшість моїх сайтів так чи інакше мають жахливо застарілі сердечники, то чому б це турбувати?
• Навіть якщо власникам сайтів це так погано, чому громада так сильно піклується? Чому його називають "вбивством кошенят"? Хіба це не дуже гіперболічно?
• Злом ядра настільки простий, чи не подобається нам простіше пройти до вирішення проблем?
• Хіба не там проблеми , які можуть тільки бути вирішені шляхом злому ядра? Що потім?

Взагалі кажучи, три причини не змінюють основний код Drupal:

• Ваші зміни втрачаються щоразу, коли ви оновлюєте Drupal, якщо не вживати необхідних заходів. Навіть у випадку, якщо ви створюєте патч для поточної версії Drupal, яку ви використовуєте, патч не може застосовуватися до нової версії, і вам потрібно буде створити патч і для нової версії.

• Виправлення безпеки застосовуються до ядра Drupal, як вони підтримуються на Drupal.org, але не можуть застосовуватися до вашої зламаної версії. Це означає, що слід перевірити, чи не впливає на вашу версію проблема безпеки, порушена проти ядра Drupal.
  У випадку, якщо ваша зламана версія вводить іншу проблему безпеки, ви є єдиною людиною, яку ви можете її знайти, оскільки у вас немає підтримки команди безпеки, яка розслідує недоліки безпеки, наявні в основному коді Drupal, а також у сторонній стороні модулі, розміщені на Drupal.org.

• Внесені вами зміни можуть бути несумісними з самим Drupal, але і з сторонніми модулями, які необхідні для роботи з ядром Drupal, а не з будь-якою зламаною версією, яку можна створити.
  Кожен раз, коли Drupal вводить нову функцію (що все ще трапляється в Drupal 7 та Drupal 6, хоча з меншою частотою) або нову зміну API, є шанс, що зламана версія буде несумісна з останніми змінами.

Однак, можна створити зламану версію, але це не завдання, яке може виконати один розробник, так само як Drupal не підтримується однією людиною. Насправді Pressflow - це зламана версія Drupal, створена з врахуванням продуктивності та вирішення деяких проблем із продуктивністю, які може мати сайт Drupal.

Хіба немає проблем, які можна вирішити лише злом ядра? Що потім?

У більшості випадків можливо змінити функції / поведінку без редагування основного коду Drupal. Завжди є гачок, який дозволяє змінити особливості / поведінку, яку має Drupal, і це є кращим методом.

Я міг би написати тут велику відповідь, але я просто опублікую це посилання: Ніколи не зламайте ядро !

Основна причина, на яку я здогадуюсь, полягає в тому, що якщо ви зламаєте core, щоб зробити щось необхідне, а потім оновіть його ... BANG! Ваших змін уже немає. Втрачено. Потім ви можете спробувати відкатати код зі свого VCS, але, бачачи, як ви не можете повернути оновлення бази даних з ядра Drupal - ви шукаєте відновлення всього коду з VCS, а потім відновлення баз даних зі своїх резервних копій. Весь час, коли ви намагаєтеся відмовити свій код, ви, мабуть, потім помітите, що остання резервна копія бази даних, що попередньо оновилася, не вдалася, і ви будете клястися більше, ніж ви коли-небудь присягали раніше.

Також - найголовніше - якщо ви зламаєте ядро, то Dries і Webchick вбивають кошеня: -o

"Що не може зламати сердечник для мене, розробника?"

• Ваш сайт можна оновити для випусків безпеки
• Ваш сайт можна оновити, щоб виправити дратівливі помилки в ядрі
• Ваш сайт можна оновити, щоб підтримувати нові модулі
• На ваші звіти про помилки та запити підтримки на core та contrib можна буде відповісти
• Ви хочете використовувати підтримуваний CMS, тому ви вибрали Drupal. Коли ви зламаєте core, словами webchick , "Якщо ви зламаєте ядро, вітаю! Ви створили свій власний форк Drupal, і тепер ви і тільки ви несете відповідальність за його підтримку!"

"Що не може зламати сердечник для мого клієнта?"

• Ваш сайт може підтримувати хтось інший після звільнення клієнта / виграти в лотерею / потрапити в автобус

"Що не може зламати серце для моєї громади?"

• Ваші звіти про помилки фактично надаватимуть корисну інформацію для обслуговуючого персоналу модулів core або contrib.
• Якщо ви знайдете легальну помилку в ядрі, яку потрібно виправити, лінія між "взломом ядра" та "перетворенням на ядро" є такою ж тонкою, як просто розмежування змін та завантаження їх як виправлення у відповідну проблему. Віола! Core краще для ваших зусиль, а ваше ім’я пов’язане з поверненням коду спільноті.

Кожен переможець, коли ви не зламаєте ядро!

Зараз я працюю на злому основного веб-сайту. У мене є труднощі з пошуку того, як створюється щось таке просте, як шрифт. Я також витрачаю кілька днів на виправлення помилки, яку вніс ядро ​​hack. Я знайшов це, шукаючи рядок у всьому друпальському коді.

Якщо ви не дотримуєтесь стандартної структури програмування в drupal, то як ще хтось може знайти та відредагувати внесені вами зміни? Це особливо болісно, ​​оскільки в друпалі кожен окремий файл PHP може реалізувати гачок. Спробуйте дізнатися, хто з них викликає проблеми.

"Хіба не існують проблеми, які можна вирішити лише взломом ядра? Що тоді?"

Щоб відповісти на це запитання, так, іноді виникають проблеми, які доводиться долати, це означає, що вам потрібно зламати ядро ​​(або модуль contrib).

У цьому випадку я вважаю, що нормально зламати, поки ви помістите багато коментарів у свій зламаний код і документуєте все, що ви змінили.

Наприклад, для будь-якої зміни ядра або contrib я створюю виправлення. Якщо він є загальним і корисним для інших людей, я надсилаю його на drupal.org у випуску, інакше це для мого власного використання.

Потім я фіксую патч-файл для контролю моєї версії разом із зміною коду.

Це означає, що я бачу, шукаючи файли патчів, якщо щось було зламано.

На додаток до цього, я додаю також список хакерів до документації для розробників для сайту (ви дійсно повинні мати документацію для розробників заради інших, які можуть працювати на сайті, і для себе, коли ви неминуче забудете речі).

У цій документації про хаки я перераховую кожен хак із тим, що робить хак і чому, на які впливають модулі / файли, ім'я файлу патча, що містить код хаку, та посилання на пов'язану проблему drupal.org, якщо така є (майже завжди у моєму випадку є).

Тоді ви та хто ще працюватиме на сайті в майбутньому, маєте повний список хак і вам не доведеться турбуватися про те, щоб випадково зламати щось із оновленням.

Потім для процесу оновлення я перевіряю свій список хаків і швидко шукаю патч-файли у всіх модулях, які я оновлюю. Якщо є злом, і він має проблему drupal.org, я перевіряю проблему, щоб побачити, чи є в останній версії включений патч, і в такому випадку я знімаю хак з оновленням і видаляю його зі свого списку хаків (зробити переконавшись, що переглядає drupal.org повідомлення повідомлень про те, що те, що було зроблено, збігається з версією виправлення, яку ви використовуєте, або, принаймні, функціонально однаковою).

Якщо виправлення не було зроблено, все, що мені потрібно зробити, це оновити модулі та повторно застосувати виправлення. У багатьох випадках патчі все-таки будуть застосовуватися чисто і процес простий, але іноді доводиться перекручувати патчі для нової версії, а потім здійснювати нову версію патча у вашому локальному сховищі (разом з розміщенням його у відповідному випуск drupal.org, де застосовано).

Ще одна річ, яку мені подобається зробити, якщо у мене є більш значні виправлення або виправлення, які взаємодіють з базовою невідповідністю модуля (або просто спеціальні модулі, що розширюються поверх модуля drupal.org), - це перевірити нотатки до випуску оновленого модуля ( це означає, що вся версія між вашою поточною версією та версією, до якої ви оновлюєтесь), і переконайтеся, що в ній немає нічого, що може порушити ваш код. Примітка. Дуже багато технічних обслуговувачів модулів корисні в наші дні, коли вони дають нотатки про повний випуск, але все ще багато таких, що роблять нотатки про випуск сміття. У цьому випадку в деяких випадках я проходжу всі повідомлення про фіксацію з моєї поточної версії (зазвичай це лише у випадках, коли у мене складний код, який глибоко взаємодіє з іншим модулем). Примітка:

Потім, після оновлення (на розробці копії сайту), ретельно протестуйте. Зрештою ви дізнаєтесь, що всебічно означає після того, як проскочить кілька помилок.

Потім, коли він буде достатньо протестований, оновіть веб-сайт, що перебуває в реальному часі, або підсуньте місцеві оновлення вгору або будь-який процес розгортання.

Причина, по якій всі кажуть, не робіть цього, навіть якщо це простіше: Тому що більшість людей не має такої системи, як у мене, а тому, коли настає час робити оновлення, або сайт передають комусь іншому для роботи далі, це стає кошмаром, і багато часу (іноді величезної кількості часу) потрібно витратити на вирішення помилок і відстеження хак-хав, а також на пошук того, чому вони там і т.д.

Якщо ви коли-небудь успадковуєте такий сайт, ви повністю зрозумієте :)

Якщо ви заробляєте на життя, встановлюючи та створюючи веб-сайти Drupal, то необхідно постійно їх оновлювати. Якщо більшість ваших сайтів закінчуються жахливо застарілими, то ви не професіонали.