Як оновити сервер Live Drupal, не перезаписуючи вміст?

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

Моє запитання - як я завантажую цей сайт назад у пряме середовище та оновлюю базу даних, не перезаписуючи новий вміст нових користувачів, доданих за останні два тижні?

Томас Захреддін має рацію. Але залежно від того, що змінилося ("зайняло мене пару тижнів ..."), є ще щось, що слід врахувати.

1. Ви додавали / змінювали типи вмісту. Спробуйте їх експортувати та імпортувати. Переконайтеся, що ви не втрачаєте вміст.
2. Ви додали / змінили представлення даних? Ви можете їх безпечно експортувати та імпортувати.
3. Оновлення модуля Перевірте їх на поточних даних. Завжди є ймовірність, що дані користувача порушують оновлення.
4. Змінюється конфігурація модуля. Якщо їх не надто багато, робіть замітки та переробляйте їх. Ще спробуйте функції та потужні рукоятки . Інший варіант - визначити точні назви змінних і записати значення в settings.php.
5. У вас є додатковий вміст у системі розробників. Тут речі стають по-справжньому волохатими. Ви можете спробувати модуль розгортання або експорт вузла . Але вони не срібні кулі.

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

Ви повинні перевірити, що ви хочете змінити:

• contenttype або bundle -> вставити новий contenttype | пакет, експортувати та імпортувати вузли, або змінити тип вмісту | пакет в базі даних для цих записів
• найменування окремих полів і виникнення у типів вмісту | пакетів -> наприклад, з інтерфейсом адміністратора або
• значення в полях -> найскладніше завдання: ви можете зробити це через SQL в базі даних (можливо) або з таким модулем, як міграція

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

Відповіді, надані Томасом Загреддіном та BetaRide, були б достатні, щоб дати вам найкращі шанси на успішне завершення міграції. На цю тему справді немає святого грааля.

Я хотів би дати вам підказку щодо розробки, але це позбавить мене від багатьох проблем із оновленням наших веб-сайтів: Намагайтеся якомога більше зберігати свою логіку у своєму коді (модулі / теми). Мовляв, намагайтеся уникати створення переглядів якомога більше. Іноді вам доведеться це зробити, але для цього знадобиться ще одне оновлення бази даних ...

Використовуйте управління керуванням джерелами!

Якщо ви в змозі зберегти все до коду (звичайно, ви не завжди зможете це зробити), ви можете просто використовувати SCM на зразок Git , SubVersion або Mercury для оновлення джерела, а в гіршому випадку повернутися до попередня версія вашого джерела, якщо оновлення не працює, як було заплановано.

І, звичайно, як це було сказано в попередніх відповідях: резервне копіювання, резервне копіювання, резервне копіювання, резервне копіювання ...

Для більшості змін ви можете використовувати Модуль функцій. Цей модуль може змінювати лише ті зміни, які ви зробили в локальному середовищі.

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

У мене просто була така ж проблема. Щоб вирішити це, я зазначив, що єдиний вміст, який я мав у прямому ефірі, а не у розробці, - це нові дані про користувача. Я просто зайшов у вкладку «Люди» адміністратора і скопіював інформацію про людей у ​​програму Dev. У розробці я просто набрав їх без будь-якої автоматизації. Тож наступного разу, коли я завантажуватиму з Dev люди, деталі, звичайно, будуть правильними і не будуть перезаписані.