Я правильно понимаю, что предлагаемое решение — это делать правки по живому, на удачу, и если все поломалось, быстро все починить?
Вообще:
1) Авария на продуктивном сайте по вине программиста, пусть даже и на секунду — это повод для харакири; 2) Чисто служебные файлы (вроде init_recovery.php), которые попали на продуктивный сайт, имеют тенденцию оставаться там навсегда. Иногда это приводит к печальным последствиям. Ради интереса, рекомендую пройтись по произвольным сайтам на Битриксе и попробовать вызвать /test.php. Уверен, удивитесь как числу "попаданий", так и результатам вызовов; 3) Если проект не находится под контролем версий — это верный признак того, что прежде чем работать над сайтом, надо сначала поработать над заказчиком.
Но это лирика. Что касается самой задачи, то для правки init.php на боевом сайте, можно придумать множество куда как более аккуратных подходов. Начиная от тестирования кода через eval в командной строке PHP, что в инструментах Битрикс, и заканчивая подключением альтернативного init.php при установленном значении cookie.
Иван, полностью согласен в полной недопустимости каких бы то ни было правок init.php на боевом сайте. Но случаи в нашей деятельности бывают разные... И иметь такую возможность в своем арсенале все-таки стоит
А по поводу файлов test.php и им подобных - это уже аккуратность кодинга. Тут уж ничто не спасет ...
1) Авария на продуктивном сайте по вине программиста, пусть даже и на секунду — это повод для харакири;2) Чисто служебные файлы (вроде init_recovery.php), которые попали на продуктивный сайт, имеют тенденцию оставаться там навсегда. Иногда это приводит к печальным последствиям. Ради интереса, рекомендую пройтись по произвольным сайтам на Битриксе и попробовать вызвать /test.php. Уверен, удивитесь как числу "попаданий", так и результатам вызовов;3) Если проект не находится под контролем версий — это верный признак того, что прежде чем работать над сайтом, надо сначала поработать над заказчиком.
перегиб палки
Но править сайт и тем более init без доступа ftp/ssh вот это уже экстрим
Не нужно работать, хотя бы без FTP, должно быть железное правило, нет доступа - нет работы. Вообще init.php, часто закрывают от записи по http. Сама идея не плохая, но пользоваться в крайнем безвыходном случае.
Неожиданно. Я готовился защищать первый пункт. Всегда полагал, что обучение клиента правильному использованию и ведению сайта — это одна из наиболее очевидных и важных обязанностей разработчика. Иначе, как хорошо не делай свою работу, все будет загублено.
Иван написал: Ради интереса, рекомендую пройтись по произвольным сайтам на Битриксе и попробовать вызвать /test.php. Уверен, удивитесь как числу "попаданий", так и результатам вызовов;
Для этих целей нужно заводить отдельную папку и все тестовые скрипты хранить только в ней.
Калашнов Антон написал: Для этих целей нужно заводить отдельную папку и все тестовые скрипты хранить только в ней.
Нет, для этих целей надо запретить отгрузку каких-либо тестовых скриптов в продуктивную среду. Тестовым скриптам место лишь в тестовой среде.
Если же речь идет о служебных механизмах, то те из них, которые могут быть запущены из терминала, следует располагать выше корневой директории сайта. Те же, что предназначены к запуску из браузера, следует размещать в административной части сайта с соответствующими проверками прав доступа.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
Вообще:
1) Авария на продуктивном сайте по вине программиста, пусть даже и на секунду — это повод для харакири;
2) Чисто служебные файлы (вроде init_recovery.php), которые попали на продуктивный сайт, имеют тенденцию оставаться там навсегда. Иногда это приводит к печальным последствиям. Ради интереса, рекомендую пройтись по произвольным сайтам на Битриксе и попробовать вызвать /test.php. Уверен, удивитесь как числу "попаданий", так и результатам вызовов;
3) Если проект не находится под контролем версий — это верный признак того, что прежде чем работать над сайтом, надо сначала поработать над заказчиком.
Но это лирика. Что касается самой задачи, то для правки init.php на боевом сайте, можно придумать множество куда как более аккуратных подходов. Начиная от тестирования кода через eval в командной строке PHP, что в инструментах Битрикс, и заканчивая подключением альтернативного init.php при установленном значении cookie.
А по поводу файлов test.php и им подобных - это уже аккуратность кодинга. Тут уж ничто не спасет ...
Но править сайт и тем более init без доступа ftp/ssh вот это уже экстрим
Но править сайт и тем более init без доступа ftp/ssh вот это уже экстрим
Но я дополнительно еще закачивал скрипт для выполнения shell команд. Мне почему-то так спокойнее.
Вы всё ещё продолжаете нянчиться с тем клиентом, у которого хостинг кривой?
Вообще init.php, часто закрывают от записи по http.
Сама идея не плохая, но пользоваться в крайнем безвыходном случае.
перегиб палки
п3
Ради интереса, рекомендую пройтись по произвольным сайтам на Битриксе и попробовать вызвать /test.php. Уверен, удивитесь как числу "попаданий", так и результатам вызовов;
Для этих целей нужно заводить отдельную папку и все тестовые скрипты хранить только в ней.
Если же речь идет о служебных механизмах, то те из них, которые могут быть запущены из терминала, следует располагать выше корневой директории сайта. Те же, что предназначены к запуску из браузера, следует размещать в административной части сайта с соответствующими проверками прав доступа.