Восстановление системных файлов
Начинали с самой первой версии shop-script. За долгие годы устанавливалось и удалялось много плагинов, менялся код по инструкциям плагинов для интеграции и не только, переносился сайт между хостингами, восстанавливался из резервных копий и сейчас встал вопрос актуальности системных файлов и ошибок с этим связанных. Плагин Здоровье сайта нашел 340 измененных системных файлов, Плагин Управление плагинами нашел тоже немало измененных файлов.
Как-то можно их восстановить?
21 ответ
Главный вопрос - какую цель вы преследуете?
Сейчас все работает? ли что-то не работает? в чем проблема?
Если были внесены какие-то нужные Вам изменения в файлы - то когда вы их восстановите - сайт перестанет работать.
в общем: напишите цель, для чего вы это делаете
Работает, но с ошибками, которые связываем с измененным кодом. Многие внесенные изменения связаны со старыми плагинами, которые уже не поддерживаются разработчиком и были удалены.
может обновите движок?
все обновлено
тогда можно скачать движок и вручную заменить файлы
только надо знать что делаешь, а то можно хуже сделать :)
больше 90% так называемых измененных системных фаллов это htaccess и разница в том, что сейчас все они без пустых строк в конце файла. Не понятно кто их оттуда убрал во всех файлах. Так может webasyst при очередном обновлении уберет во всех файлах htaccess пустые строки, чтобы все встало на свои места?
Вот пример файлов htacces по адресу public_html/wa-system
Свежеустановленный
и старый ("измененный")
В первом случае может не понятно, но есть пустая строка после текста
пустая строка не вызвала б проблем
судя по всему - у вас там где-то сидели скрытые символы
И это не проблема движка, а, скорее всего, проблема переноса файлов
новый
старый
В общем разница в пробеле и типе конца строк. Свежие имеют тип Unix (LF), а старые на сайте Windows (CR LF), но почему остальные файлы с правильным типом и как это массово исправить?
Похоже, что разработчики движка в разных редакторах работают.
давайте ка еще разок вам повторю:
движок здесь не-при-чем
это сугубо ваша проблема.
Ваша позиция понятна, Павел. Больше интересует как это произошло, чтобы не допустить в будущем и как исправить?
это не моя позиция - это факт
Исправить - вручную
чтобы не повторялось - надо выяснить как произошло. Вспоминайте какие массовые действия вы производили с файлами? Например - развернули бэкап на пк и залили его на сервер. Или скачали с одного сервера и залили на другой
Windows (CR LF) без винды не получатся сами по себе. Так что - файлы точно побывали на компе с виндой, а на сервере линух
В процессе восстановления часть оригинальных файлов htaccess Unix (LF), а часть Windows (CR LF).
Это по прежнему моя проблема, но вы также по прежнему уверены, что движок здесь не-при-чем?
да. абсолютно уверен.
движок ни коем образом не отвечает и не может поменять кодировку файлов (особенно htaccess)
Нашли очередную магию?) Павел всё верно вам говорит, ведь у всех других пользователей движка всё хорошо) А измениться концы строк могли и после каких-то ваших доработок, после заливки файлов на сервер какими-то файл-менеджерами или используемыми при изменении кода IDE. Предполагаю, что это еще как-то может зависеть от настроек вашего сервера, вдруг там как-то настроено, чтобы концы строк были именно такими)
Нашему движку уже очень много лет. Можно сказать с основания фреймворка и с тех пор только обновлялся накатыванием на предыдущие версии и конечно за это время много раз переносился между хостингами и восстанавливался и бэкапов, поэтому точно выяснить причину уже не получится. Если начали появляться приложения контроля целостности файлов, то и было бы здорово если будут инструменты их восстановления, что судя по всему очень снизит нагрузку на разработчиков при разборе проблем и позволит сосредоточится на глобальных доработках и улучшениях. А пока ручками
Я предлагаю вообще свести весь функционал движка к одной большой кнопке "шоб было збс" - и всё.
будет идеальный продукт
что касается системных файлов почему бы и нет.
Если у вас всё настолько древнее, перезалитое, переобновленное и столько раз доработанное/переработанное - не проще взять "збс"-вариант чисто установленного движка, установить туда заново чистые не доработанные плагины (возможно от каких-то избавиться, какие-то заменить современными раз многие не поддерживаются уже) и забыть про все эти мучения с восстановлениями, откатами, контролем целостности, концами файлов и прочей ерундой, вызывающей всё больше проблем и вопросов, чем ответов... и будет у вас новый идеальный продукт)
А то как-то не логично получается, сначал вы для чего-то дорабатывали эти плагины, а сейчас просто хотите их откатить к исходным файлам, это в свою очередь уберет смысл этих доработок, перестанет работать функицонал, что-то сломается и тд и тп...
Есть проект, который живет с 5 версии SS. Это тоже достаточно давно. Есть и такие, которые пережили миграцию с 309-й и сейчас на актуальном ПО. Там вообще всё сложно с историей.
Все изменения документированы. Заменил файл - записал. Поставил комментарии. Сохранил исходный. Да, это муторно, хотя не настолько, чтобы отнимало много времени, но зато в любом момент можно сказать какие строки и в каких файлы были изменены, когда это произошло и что именно менялось.
Если откровенно, то критически важных изменений файлов даже за большой период времени накапливается не так много. Какие-то изменения со временем перестают быть актуальными и откатываются в исходник. Речь именно о файлах исходного кода движка и исходниках плагинов, а не о теме дизайна и прочих пользовательских мелочах. Тот же корневой .htaccess - это вообще личное и движку в нём делать нечего со своей исходной версией, мне лучше знать что там и как.
Всяким плагинами типа "Здоровье сайта" не доверяю. От таких держусь подальше. По опыту скажу, что нет ничего лучше собственного документирования и пофигу что там какие-то плагины мне скажут по итогу кол-ва изменений. Поглядел в свой реестр правок и точно знаю, что в Магазине 14 измененных файлов, в Сайте - 1, в ЦРМ - 2, в Контактах - 2, во Фрейворке - 8 и точно знаю какие это файлы, что в них исправлено, зачем и когда. На каждый файл есть исходник и версия с правками. Всё четко по полочкам. Для справки в моем зоопарке на проектах 110 только плагинов! Без документирования это превратится в свалку, в которой никто ничего никогда не найдет. Порядок должен быть в первую очередь, если подходите к делу основательно.
Перед обновлением плагина всегда смотрю были ли в нем изменения и, если да, то после накатки обновления сравниваю код. Если нет, то просто ставлю обновление.
Есть документирование - нет вопросов.
Хотите откатить и не сломать? Ставьте рядом исходную версию и пошло сравнение по списку подозрительных. Только так. Начать с нуля не предлагаю, хотя имеет право на жизнь и такая история.