Как очистить Drupal от накопившегося «мусора», сократить объем базы данных, восстановить исчезнувшие административные настройки модулей, обеспечить корректность установки новых модулей, повысить производительность движка и, в итоге, сделать так, чтобы Drupal снова заработал, как новенький 😳 Редакция от 08.12.2024.
Создан 28.01.2011 13:48:46
Все может быть, все может статься —
Машина может поломаться,
Девчонка может разлюбить...
Но бросить пить... НЕ МОЖЕТ БЫТЬ!!!
© 
Чем Drupal отличается от девчонки или машины? Ничем: такой же конечный автомат, совершает (накапливает) ошибки, требует внимания и ласки (технического обслуживания и ремонта), см. рисунок ниже.
Побитый жизнью и админом Drupal, помимо замедления своей работы, порождает ряд дополнительных проблем, в частности проблему исчезновения настроек вновь или ранее установленных модулей. С подобным, если верить поисковым системам, сталкивались многие. Наиболее точная формулировка приведена ниже.
Похожих постов в форуме немало, просто искать тщательнЕЕ надо 
Но эффект суслика, упомянутого в статье «CMS Drupal + AuthorIT против CMS Drupal + CKEditor», — имеет место быть. Модуль есть, а настроек не видно.
Внезапное исчезновение (отсутствие) в админке меню настроек установленных модулей Drupal, появление «белых экранов» при попытке открыть их ссылкой /admin/settings/<название модуля> часто (и справедливо) связывают с недостатком памяти, выделяемой под php хостинг–провайдером: если объем оперативки менее 64 Мб, то стоит ли вообще рассчитывать на устойчивую работу Drupal? Но как объяснить причину того, что схожие проблемы проявились у автора на хостинге it–patrol, где php по умолчанию выделяется 256 Мб оперативной памяти даже на самых недорогих тарифах? Все дело, похоже, в кривых руках и в безудержном стремлении к звездам 😂
Итак, в настоящей статье:
- рассмотрены «расстройства» функционирования Drupal со схожей симптоматикой, выявлены возможные причины их возникновения и намечены пути чудесного исцеления;
- расписан комплекс мероприятий, направленных на предотвращение возникновения побочных эффектов;
- приведена пошаговая схема лечения Drupal через временное зеркалирование;
- проведен разбор полетов и подведены итоги.
Начнем.
Drupal: функциональные расстройства и возможные их причины
... и отправился искать свою звезду...
© Крематорий, «Космос»
В статье «Мультисайтинг на Drupal, или...» было рассказано о пошаговой реализации оного на Drupal через создание синонима alias.ru к существующему домену domain.ru, а также показаны преимущества мультисайтинга, в частности — возможности макетирования и отладки на живом хостинге без фатальных последствий. Лучшее — враг хорошего 🤣: воодушевленный успехом автор, отлаживаясь на синониме alias.ru, включил aggregator, настроил его, после чего попытался перенести настройки ленты новостей на domain.ru... Но не тут–то было: меню Сборщик RSS–лент по адресу /admin/content/aggregator попросту отсутствовало...
Примечание — Работа проводилась с реальным доменом http://tdocs.su и его синонимом http://техническая–документация.рф, но для простоты изложения материала реальным доменом считаем domain.ru, а его синонимом — alias.ru.
И господь бы с ним, но... история изо дня в день повторялась и с другими модулями: Live Translation сутки трудился на domain.ru, после чего перестал формировать ссылки для обновления переводов; pathauto также установился без настроек и тихо занялся своим делом, едва не порушив тысячу с лишним синонимов, введенных автором вручную (из корыстных соображений, см. «CMS Drupal + AuthorIT против CMS Drupal + CKEditor»).
Что происходит? Грешить на память грешно, поскольку на it–patrol ее достаточно, «ядреные» модули стандартны, какие–либо дополнительные супертяжеловесы не устанавливались, см. рисунок ниже, да и на alias.ru все прекрасно работает...
Но вспомним: Drupal для domain.ru был установлен более года назад, претерпел множественные инсталляции–деинсталляции модулей и тем оформления, целый ряд восстановлений из резервных копий базы данных, переезд с хостинга на хостинг — судьба его нелегка. Сайт же alias.ru — свеженькая, только что установленная копия Drupal...
Известно, что после десятка–двух инсталляций–деинсталляций программ свежеустановленная операционная система (речь о винде, разумеется) начинает тормозить, терять настройки и т.д. Терапевтическое лечение вроде чистки реестра редко приводит к положительному эффекту, радикально вопрос решается лишь хирургическим вмешательством — сносом винды и повторной ее установкой. Подобным образом успешно «лечится» и Drupal.
Drupal: путь к исцелению
Подраздел добавлен 30.01.2011 г. с учетом отзывов читателей с drupal.ru, и задача его — досказать недосказанное в базовом варианте статьи. Действительно, изначально путь к исцелению Drupal был прописан неявно, что и привело ко множеству справедливых замечаний. Исправим ситуацию. Итак, путь к исцелению:
- Имеются два сайта с единой базой данных и общей файловой системой, см. рисунок ниже;
- Сайт domain.ru, который надо спасать, грязный и глючный. Сайт alias.ru — никакой. На нем ничего нет;
- Для спасения domain.ru мы создаем его ЧИСТОЕ зеркало на сайте alias.ru, для этого:
- расшариваем таблицы сайта domain.ru, содержащие контент, таксономию и меню изменением настроек в файле settings.php, см. инструкции в соответствующем подразделе;
- удаляем все «системные» таблицы, принадлежащие сайту alias.ru, см. инструкции в соответствующем подразделе;
- запускаем установку Drupal на alias.ru, в результате чего alias.ru становится ЧИСТЫМ зеркалом domain.ru, поскольку все «системные» таблицы Drupal при установке создает заново, а расшаренные таблицы не трогает, см. инструкции в соответствующем подразделе.
- Теперь, когда у нас есть ЧИСТОЕ зеркало alias.ru сайта domain.ru:
- удаляем все «системные» таблицы, принадлежащие сайту domain.ru, см. инструкции в соответствующем подразделе;
- запускаем установку Drupal на domain.ru, в результате чего domain.ru становится ЧИСТЫМ зеркалом alias.ru, поскольку все «системные» таблицы Drupal при установке создает заново, а расшаренные таблицы не трогает, см. инструкции в соответствующем подразделе.
- Вот и все! Мы восстановили сайт domain.ru без потерь данных, он стал чистеньким, новеньким, на нем прекрасно устанавливаются и настраиваются любые модули, работать он стал очень шустро. Что было непонятно, камрады?
Далее — все по шагам, а не в виде тезисов 😎
Очистка Drupal: предотвращение возникновения побочных эффектов
Перед очисткой Drupal необходимо провести ряд важных подготовительных процедур:
- Создать backup (резервную копию) базы данных Drupal;
- Создать копии настроек модулей и блоков, включая визуальное расположение блоков;
- Внести изменения в настройки файла settings.php синонима alias.ru;
- Удалить таблицы базы данных, относящихся к alias.ru.
Создание backup'а базы данных Drupal
Для создания backup'а базы данных Drupal удобно воспользоваться бесплатным скриптом Sypex Dumper Lite 1.0.8. Детали установки и настройки излишни, поскольку с Dumper'ом все просто и до слез понятно, но стоит упомянуть вот что:
- Dumper очень быстро сжимает огромные базы MySQL и умеет сохранять стомегабайтные архивы непосредственно в файловой структуре сайта, что немаловажно при слабом uplink'е, свойственном асимметричному доступу в интернет. phpMyAdmin возится гораздо дольше и норовит создать архив базы на локальном пользовательском компьютере (альтернативных вариантов сохранения архива автор не обнаружил);
- Dumper так же лихо распаковывает архивы и восстанавливает БД, phpMyAdmin же импортирует архив с локального компьютера, причем долго и очень часто с ошибками.
Таким образом, для решения задач архивирования–восстановления Dumper можно считать вариантом наиболее предпочтительным. Единственная мелочь: сам dumper.php имеет смысл сначала перекодировать в utf–8, а затем уж устанавливать на хостинге. В винде перекодировку можно сделать с помощью Dreamweaver или Sysutilizer's Kaboom: последний является бесплатной программой и обеспечивает возможность пакетной перекодировки файлов. В линуксе вопросы перекодировки решаются вообще без заморочек.
Создание копий настроек модулей и блоков Drupal
С бумаги читать проще, чем переключаться между окнами, поэтому решено было снять и распечатать скриншоты настроек модулей и блоков Drupal. В редакторе изображений GIMP не обнаружилось возможности скопировать окно браузера со скроллингом, поэтому пришлось воспользоваться виндовой программой SnagIT, у которой опция захвата Scrolling window имеется.
Внесение изменений в настройки файла settings.php синонима alias.ru
Для внесения изменений в настройки файла settings.php синонима alias.ru следует:
- Изменить права каталога, содержащего settings.php, см. рисунок ниже. Автор воспользовался клиентом gFTP;
- По аналогии изменить права самого settings.php, хранящегося в указанном каталоге;
- Скачать settings.php на локальный компьютер;
- Привести содержимое settings.php к виду, изображенному на рисунке ниже;
- Закачать скорректированный settings.php на хостинг, в каталог /domains/domain.ru/sites.
Удаление таблиц базы данных, относящихся к alias.ru
Удаление таблиц базы данных, относящихся к alias.ru, удобно выполнить с помощью phpMyAdmin. Для этого следует открыть собственно базу данных, отметить таблицы, подлежащие удалению (все таблицы с префиксом al_), а затем из списка С отмеченными выбрать Удалить. И подтвердить операцию удаления.
На этом все подготовительные мероприятия можно считать завершенными.
Очистка Drupal: зеркалирование домена синонимом
Для зеркалирования домена синонимом следует:
- Строкой http://alias.ru/install.php запустить установку Drupal для alias.ru. По завершении установки (см. Установка Drupal для синонима домена в статье «Мультисайтинг на Drupal, или...») Drupal откроет окно, изображенное на рисунке ниже;
- Войти в режим администрирования и включить ранее установленную тему оформления (/admin/build/themes). Окно изменит свой вид, см. рисунок ниже;
- Включить модули book и PHP filter, если контент domain.ru организован в виде страниц подшивки и подгружается оператором include. Если страницы подшивки и фильтр PHP не использовались, то включать их не обязательно. Сайт полностью воспроизвелся в синониме, см. рисунок ниже.
Итак, для домена создано зеркало в виде синонима.
Очистка Drupal: зеркалирование синонима доменом
Для зеркалирования синонима доменом следует:
- Удалить из базы данных (ВНИМАНИЕ!) все таблицы с префиксом dm_, ЗА ИСКЛЮЧЕНИЕМ указанных в файле settings.php, см. рисунок ниже;
- Строкой http://domain.ru/install.php запустить установку Drupal для domain.ru;
- Повторно выполнить пп. 2 и 3 предшествующего подраздела статьи.
Очистка Drupal: разбор полетов и подведение итогов
Теперь словами о том, о чем было рассказано ранее, а также ответы на всевозможные «зачем» и «почему». Вопросы ожидаемы: зачем использовать мультисайтинг, когда можно просто сделать backup базы данных, удалить лишние системные таблицы и заново установить Drupal, получив, в итоге, такой же результат?
Ответ: конечно, можно, но для этого необходимы некоторые навыки работы с Drupal. Имеется печальный опыт организации мультисайтинга, в результате которого рухнул сайт http://author–it.ru. Как такое могло случиться — совершенно непонятно, но факт остается фактом. И еще: где же вы были раньше, почему не поделились своими умными и исчепывающими советами? Быть может, не пришлось бы и писать эту статью, вызвавшую черно–белую реакцию читателей...
Далее. Ранее настроенный мультисайтинг, на котором проводилось макетирование, дал возможность понять причины происходящего путем сравнительного анализа работы домена и синонима, осторожно отобрать таблицы, содержащие контент, таксономию и меню, и манипулировать с ними без риска потери работоспособности основного сайта.
По подготовительным процедурам: первые две вопросов не вызовут, по третьей — в файл settings.php добавлены таблицы, содержащие контент, таксономию и меню, которые необходимо спасти. После установки Drupal на синониме по поведению синонима сразу становится понятно, какие таблицы были упущены при отборе. У автора, в частности, блоки, расположенные в левой и правой колонках страницы, частично поменяли свой вес, т.е. визуально поменялись местами. Правда, восстановить взаимное расположение блоков — минутное дело, поэтому разрабатывать тему глубже автор не счел необходимым.
По четвертой процедуре: удалив служебные таблицы базы данных синонима, не содержащие контент, таксономию и меню, мы, фактически, снесли Drupal на синониме. В винде аналогичная процедура выполняется форматированием логического диска (носителя данных), на котором винда была ранее установлена.
Теперь по установке Drupal на синоним. При запуске установки строкой http://alias.ru/install.php Drupal читает файл settings.php и начисто создает недостающие (удаленные нами системные) таблицы, не задевая при этом таблицы с контентом, таксономией и меню — общие таблицы, изображенные на рисунке (выше). В файловой системе, судя по всему, никаких изменений не происходит. При включении темы оформления получаем ЧИСТОЕ и на все 100 % работоспособное зеркало alias.ru домена domain.ru. И теперь уже нечего бояться за функционирование domain.ru — чистая установка Drupal с сохранением контента, таксономии и меню у нас уже есть. Все вышеизложенное похоже на установку винды на логический диск C, при этом данные, хранящиеся на логическом диске D, установкой не затрагиваются.
О создании зеркала синонима на домене. Все то же самое, только удаляются системные таблицы домена (форматирование диска C), а затем строкой http://domain.ru/install.php выполняется чистая установка Drupal на боевом домене и воспроизводится настройка модулей либо по скриншоту, либо с нуля, что значительно интересней, познавательней и дает возможность «тряхнуть стариной»...
Вот и все. Зеркало alias.ru, чтобы не дразнить поисковые системы, лучше перевести в режим обслуживания, указав на соответствующей странице текст приглашения на domain.ru — получится такой честный doorway'чик 😂 Именно так автор поступил и с http://техническая–документация.рф, поскольку от кириллических доменов пока толку мало – разве что забить название компании для попадания на первые страницы поисковиков, хотя...
и
«значит, все не так уж плохо на сегодняшний день» 🤣, хотя ситуация меняется при любом неосторожном движении...
И еще: настройки settings.php для alias.ru следует НЕЗАМЕДЛИТЕЛЬНО вернуть на родину, как показано на рисунке ниже, иначе при дальнейшем экспериментировании «поползет» domain.ru.
Наверное, очищать Drupal способом, описанным в настоящей статье, имеет смысл при малейших подозрениях на некорректную работу движка, а также при непонятках, когда «Не устанавливается (не работает, не настраивается) модуль xyz!!!» Следует отметить, что предложенный способ очистки Drupal с гарантией 99,(9) % сработает не только на it–patrol, но и на любом другом хостинге, не говоря уж о локальных установках Drupal.
Подведем итоги: сделано все, что задумано Показано, как:
- очистить Drupal от скопившегося «мусора», сократить объем базы данных,
- восстановить исчезнувшие административные настройки модулей,
- обеспечить корректность установки новых модулей,
- повысить общую производительность движка и, в итоге,
- сделать так, чтобы Drupal снова заработал, как новенький 😳