Увидел на хабре интереснейший пост.
|
Разработчикам |
Если нужно править init.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. Уверен, удивитесь как числу "попаданий", так и результатам вызовов;
Для этих целей нужно заводить отдельную папку и все тестовые скрипты хранить только в ней.
Если же речь идет о служебных механизмах, то те из них, которые могут быть запущены из терминала, следует располагать выше корневой директории сайта. Те же, что предназначены к запуску из браузера, следует размещать в административной части сайта с соответствующими проверками прав доступа.