Я правильно понимаю, что предлагаемое решение — это делать правки по живому, на удачу, и если все поломалось, быстро все починить?
Вообще:
1) Авария на продуктивном сайте по вине программиста, пусть даже и на секунду — это повод для харакири;
2) Чисто служебные файлы (вроде init_recovery.php), которые попали на продуктивный сайт, имеют тенденцию оставаться там навсегда. Иногда это приводит к печальным последствиям. Ради интереса, рекомендую пройтись по произвольным сайтам на Битриксе и попробовать вызвать /test.php. Уверен, удивитесь как числу "попаданий", так и результатам вызовов;
3) Если проект не находится под контролем версий — это верный признак того, что прежде чем работать над сайтом, надо сначала поработать над заказчиком.
Но это лирика. Что касается самой задачи, то для правки init.php на боевом сайте, можно придумать множество куда как более аккуратных подходов. Начиная от тестирования кода через eval в командной строке PHP, что в инструментах Битрикс, и заканчивая подключением альтернативного init.php при установленном значении cookie.
Вообще:
1) Авария на продуктивном сайте по вине программиста, пусть даже и на секунду — это повод для харакири;
2) Чисто служебные файлы (вроде init_recovery.php), которые попали на продуктивный сайт, имеют тенденцию оставаться там навсегда. Иногда это приводит к печальным последствиям. Ради интереса, рекомендую пройтись по произвольным сайтам на Битриксе и попробовать вызвать /test.php. Уверен, удивитесь как числу "попаданий", так и результатам вызовов;
3) Если проект не находится под контролем версий — это верный признак того, что прежде чем работать над сайтом, надо сначала поработать над заказчиком.
Но это лирика. Что касается самой задачи, то для правки init.php на боевом сайте, можно придумать множество куда как более аккуратных подходов. Начиная от тестирования кода через eval в командной строке PHP, что в инструментах Битрикс, и заканчивая подключением альтернативного init.php при установленном значении cookie.