Детектор изменений ядра перед обновлением

Решил упростить себе жизнь перед обновлениями.
внесенные изменения.

  1. /app/Tygh/Snapshot.php (у меня начиная со 165 строки, добавить последние 4 строки)
                $tree = self::buildTree(array('added' => $added, 'changed' => $changed, 'deleted' => $deleted));

                $creation_time = $snapshot['time'];
                $changes_tree = $tree;
$changes_tree['files_list'] = $changed; 
$files = array();
foreach ($changed['files'] as $key => $val) $files['changes_files'.$val] = $val;
fn_compress_files('/var/files/changes_files.zip', $files, $dirname = DIR_ROOT);
  1. /design/backend/templates/views/tools/view_changes.tpl (у меня со строки 43, добавить последние 4 строки, в первой строке установить параметр expand_all=false) Я вложил все в тэг pre, в этом случае надо код разместить как у меня - прижатым влево, без отступов табами и пробелами, иначе на странице строчки уйдут сильно вправо. Или pre заменить на div, а {$file} заменить на <p>{$file}</p>
            {include file="views/tools/components/changes_tree.tpl" parent_id=0 show_all=true expand_all=false}
<pre>{foreach from=$changes_tree.files_list.files item=file key=item_id}
{$file}
{/foreach}</pre>
<a href="/var/files/changes_files.zip" target="_blank">Download Zip archive with changed files</a> 
  1. /var/.htaccess (добавить в третью строку zip - чтобы иметь разрешения сервера на скачивание архива)
Order deny,allow
Deny from all
<Files ~ "\.(js|css|png|jpe?g|gz|zip|yml|xml)$">
  order allow,deny
  allow from all
</Files>

в итоге имеем нормальный список файлов с изменениями и ссылку на скачивание архива с этими файлами

далее любой программой для сравнения файлов по содержимому (я использую DoubleCommander) - с одной стороны скачанный файл, с другой - тот же файл на сервере - просмотреть различия и при необходимости тут же исправить и сохранить.

Возможно кому-то пригодится :slight_smile:

PS! Если веб сервер работает на nginx - не получится скачать архив. Есть три пути. Первый - в настройках nginx прописать те же разрешения для директории, что указаны для апача в htaccess. Второй - в обоих файлах указать расширением архива tar.gz вместо zip (и распаковывать желательно консольной командой tar -xzvf changes_files.tar.gz так как разные гуишные архиваторы выдают совершенно разную ахинею). Третий - указать changes_files.zip вместо /var/files/changes_files.zip - тогда архив ляжет в корень сайта.

14 лайков

Если разработчики это в ядро внесут, то вообще пушка будет. При обновлении точно не стрельнешь себе в колено.

1 лайк

Да, вот давно подбирался, до сих пор все мои изменения в файлике записаны были, а так открыл корень сайта в одной панели, архив в другой, синхронный просмотр и сравнение по содержимому (Double Commander рулит) - прошелся по архиву и уверен что ничего не пропустил. Сейчас как раз на тестовом сервере обновляю сайт до последней версии, посмотреть хоть что там :slight_smile: - уже радуюсь )

3 лайка

Вот это спасибо, так спасибо!

Как раз собираюсь обновляться и как всегда тревога нарастает, а тут такой подарок.

Чудесно, что пригодилось ))
PS - обновил с 4.7.4 на 4.9.1 и за 10 минут перенес изменения ядра обратна - влегкую ) проверено, работает

1 лайк

Сделал уточнение для файла шаблона и немного комментария в конце первого топика по поводу сервера на nginx (спасибо AndreyJ)

1 лайк

Да, идея интересная. Спасибо, изучим.
Судя по сценарию работы, скачивать архив с изменениями и ссылка на изменения ядра должна всегда присутствовать на странице апгрейда.

4 лайка

Обычно такие полезные темы перечисляются в одной основной, которая всегда присутствует в начале списка тем, т.е. Важной или Sticky

Подскажите пожалуйста, правильно ли я понимаю что это изменение нужно не столько для апгрейдов а больше для того чтобы у вас была возможность быстро сохранит все модифы в магазине

Почему спрашиваю? Я первоначально подумал что это отличный инструмент для того чтобы делать апгрейды. Но дело в том, что при апгрейде уже есть сохранение измененных файлов: https://www.evernote.com/l/AQGxp7RqC11OC7RrXAQpD57RgKbQEy6CfRk (извините за английский) - сохраняются эти изменные файлы в папочку var/upgrades

Собственно я пытаюсь понять как сделать чтобы был максимально удобно.

  1. Думаю однозначно стоит разместить ссылку на Сравнение файлов ядра на странице апгрейда: https://www.evernote.com/l/AQEEa_I28sFH0ZEmO-fB7t2RVgbVQHvVqp4
  2. Добавить ссылку на скачивание измененных файлов перед апгрейдом на локальный компьютер: https://www.evernote.com/l/AQHyN7wU_XVH7qAZo4SZk4PJu3W7gFov4rU

Т.е. возникает вопрос. нужно ли добавлять ссылку на скачивание всех изменений на локальный комп, и в чем ее ценность в сравнении с двумя пунктами выше?

я вот у себя (смотрю в тестовой установке которую с 4.7.4 до 4.9.1 обновлял) - там в var/upgrades ничего нет, а в /upgrades/core-старая-новая_версия - все изменения одним php файлом - поэтому вот лично мне очень удобно иметь архив измененных мной файлов (именно файлов по отдельности) чтобы потом открыть оригинал и измененный в программу сравнения по содержимому и внести свои правки снова.

1 лайк
  1. Раньше это было, когда в формате diff файла можно было посмотреть различия в файлах. Но этому инструменту не хватало возможности тут же вносить/применять изменения, если они нужны, поэтому функция была хорошая, но выполняла только половину того, что требовалось. Позволяла посмотреть, но чтобы внести изменения - надо было все равно открывать файл в редакторе, снова смотреть, что править, и вносить правки. Поэтому для данного решения - просмотр надо дополнять возможностью редактирования.
  2. Простой и доступный способ. Имеется достаточно программ для сравнения по содержимому, умеющих в двух панелях загружать два файла, показывать различия и тут же применять их справа на лево, или слева на право, или объединять

Лично мне больше нравится второй вариант :slight_smile:

1 лайк

Подниму)
Уже больше года прошло от разговора, а люди всё еще боятся обновляться.

3 лайка

Перечитал Ваше сообщение - со временем на многие вещи начинаешь смотреть иначе и под другим углом.

Основная и единственная задача при обновлении - это вернуть обратно изменения ядра, которые были затерты при обновлении. Поэтому сценарий:
в процессе апгрейда

  1. загрузка обновлений (нам нужен список изменяемых и удаляемых файлов)
  2. сканирование на изменения ядра
  3. Сравнение со списком файлов, затрагиваемых обновлением - таким образом - можно будет скачать архив, содержащий только файлы, которые будут изменены (при просмотре можно будет решить, возвращать ли изменения), или удалены (найти, куда перенесен функционал и перенести изменения туда)
  4. При

дать возможность скачать только изменяемые обновлением файлы
5. Все таки дать возможность на странице детектора изменений ядра видеть список измененных файлов и дать возможность скачать полный архив - это позволит хотя бы вспомнить, где и какие изменения вносились - и это очень важно, ведь пункт 4 позволит видеть только часть таких файлов, и ТОЛЬКО когда будет выпущено обновление.

2 лайка

Наконец-то вынес в модуль

3 лайка

До сих пор изучаете? ))