- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Я понимаю, что боль в пятой точке с виду вызывает перенос изменений в БД, так вот для этого есть механизм миграций, когда изменения в БД делаются не в админке руками, а кодом в файле, но надо понимать, что миграциями, как правило, не переносят контент, а меняют структуру таблиц и прочее,
В принципе ничего не мешает в миграцию добавить активацию плагина в БД. Может это не самая лучшая практика, но в той же джанге есть фикстуры, которые прекрасно с этим справятся.
а контент и конфиг можно зайти на боевой сайт и через админку проставить нужные,
Я бы скорее это делал через .env файл
Ну то есть всё равно заходим на боевой сервер и творим там всё, что хотим.
Это вариант для тебя, извини, потому что ты не понимаешь как это работает. А специалист и это сможет сделать через миграции и фикстуры, причем не будет необходимости руками править что-то в админке.
Именно. Иначе получится так, что затрутся изменения, сделанные другими людьми.
Ты снова путаешь мягкое с теплым. Меняя настройки в БД - как ты трогаешь код сайта? что ты планируешь затереть? Да, ты можешь отключить плагин который включили. Но если ты через админку попробуешь поставить плагин - гит это увидит и сообщит тебе.
Снова здорово. А как же вносить изменения в базу данных?
Ты опять путаешь работу с БД в админке сайта и работу на сервере с кодом. Это разные уровни доступа, открою тебе тайну;
Я все время забываю одну вещь. Я пытаюсь тут разговаривать с программистами или теми кто им хочет быть, а со мной спорят частные вебмастера, которые судя по уровню компетенций вообще не программисты. А активировать плагин в админке - это вообще не программирование, расстрою вас, господа.
Я изначально написал, что затёрлись, например, новости, опубликованные за последнюю неделю. Но любители гита начали меня поучать, и писать, какой я недотёпа.
Новости за последнюю неделю это записи в БД, при чем тут гит если он хранит состояние файлов? Значит вам развернули бэкап БД с тестового сайта, но это не проблема гита, а проблема этих людей, не будь у них доступа к разворачиванию БД они бы не откатили новости за неделю
Снова здорово. А как же вносить изменения в базу данных?
Если контент то руками, вот смотрите у нас в компании прилетают десятки тысяч заказов в сутки, они нужны для разработки? Нет. Они нужны на деве? Нет. Значит такие изменения не переносятся между площадками. Переносятся изменения в структуре, например в заказе добавилось новое поле, вот его можно добавить либо руками в админке, либо кодом, если хотите чтобы везде было одинаковое состояние БД, то вносите кодом иначе будет грустно со временем, когда состояния БД на разных площадках будут разные.
Вот скажите честно, Вы сами с Битриксом через гит работаете, или всё же через админку?
Всегда через гит, у битрикса клевый модуль есть, через него даже контент и настройки можно переносить, но не всех модулей правда. А так да, только через миграции и я уже привык даже, просто моя команда в deploy.php чуть длинее:
Она автоматом не только файлы но и изменения в базе сделает сама что даже в админку заходить не надо будет
В принципе ничего не мешает в миграцию добавить активацию плагина в БД. Может это не самая лучшая практика, но в той же джанге есть фикстуры, которые прекрасно с этим справятся.
Я бы скорее это делал через .env файл
Это все сложно на начальных этапах, все надо начинать делать постепенно чтобы не отпугивать людей сразу, а то реально получается космолет если начать рассказывать про все что можно делать для удобства, но с этими проблемами люди должны столкнуться чтоб искать их решение, вот сейчас сталкиваются тем что перезатирают изменения и заливаются шелы - это и есть боль и на примере этой боли можно и рассказывать про инструменты
Новости за последнюю неделю это записи в БД, при чем тут гит если он хранит состояние файлов?
Вот и я про то же. Это был мой комментарий на совет работать с локальной копией сайта, а мои оппоненты почему-то начали учить меня гиту.
Она автоматом не только файлы но и изменения в базе сделает сама что даже в админку заходить не надо будет
И что, администраторы сайта тоже делают миграции и работают через гит? Это им удобно?
Вот и я про то же. Это был мой комментарий на совет работать с локальной копией сайта, а мои оппоненты почему-то начали учить меня гиту.
Немного не так. Развернули, потому что был доступ к сайту боевому, то есть надо закрыть доступ всем к боевому сайту, но как тогда вносить изменения на сайт? Правильно через гит и локальную разработку. Могу чуть удлинить предложение если текущих 14 страниц недостаточно =)))
И что, администраторы сайта тоже делают миграции и работают через гит? Это им удобно?
Я не знаю как уже донести до вас, но что вы подразумеваете под администраторы сайта? Давайте на примере битрикса:
1. Заливают контент в инфоблоки (новости например) через админку прода, эти изменения не нужны в гите
2. Добавляется инфоблок через миграции, так как инфоблок нужен везде, но инфоблок добавляет разработчки и локально, так как для инфоблока нужен компонент который будет выводить из него информацию
Давайте на примере какие именно изменения в БД вам надо переносить с локальной площадки на боевую?
что вы подразумеваете под администраторы сайта? Давайте на примере битрикса:
Ну вот, например, администратор сайта решил изменить количество новостей, выводимых на странице. Он должен делать это через гит?
Ну вот, например, администратор сайта решил изменить количество новостей, выводимых на странице. Он должен делать это через гит?
Если это какой нибудь news.list где в файле php записан LIMIT => 10, то да через гит, но это можно делать не локально, это можно например сделать и прям на проде а потом эти изменения кто то закоммитит или можно зайти в гитлаб и прям там поправить коммитом и оно выкатиться автоматом, если вы прям каждый день меняете количество новостей, то это значение можно вынести в битриксе, например, в b_option и добавить в админку. Все ваши вопросы решаемы, зависит от того как сделан проект, криво и косо по самым говяным канонам битрикса или по человечески и по современному. Я например не делаю и не даю возможность делать статичные страницы в битриксе, когда контент прям в php файле запилен, потому что возникает проблема как раз таки с изменением контента. Поэтому все делается через инфоблоки, я даже на одном из последних проектов запилил небольшой синтаксический сахар, чтобы в контент инфоблока можно было вставлять компоненты
кто то закоммитит
Ну то есть если вернуться к теме ТС, то ему всё же нужен как минимум один проверенный программист, который будет всё переносить на рабочий сервер и никого больше туда не пускать. Иначе никакой гит ему не обеспечит никакой безопасности.
А что касается лично меня, то почитав вот это всё про локальные копии, репозитории, миграции и прочая, не нахожу для себя никакого удобства. По крайней мере по состоянию на настоящий момент. Пока это всё крайне громоздко и неудобно.
Ну то есть если вернуться к теме ТС, то ему всё же нужен как минимум один проверенный программист, который будет всё переносить на рабочий сервер и никого больше туда не пускать. Иначе никакой гит ему не обеспечит никакой безопасности.
Я накидываю лишь варианты. Их много, каждый из них решает какую то проблему, но добавляет новую. Все что автоматизировано может сломаться, так что за этим кто то должен следить в любом случае. Но тут зависит от подхода, например можно доверить свою жизнь опытному хирургу или студенту 3го курса мед института. Так и тут, если проект важный, за счет него живет бизнес, от туда приходят деньги, то лучше найти "опытного хирурга", если это личный блог про то как какает и писает домашнее животное владельца, то можно и к "студенту 3го курса". Гит лишь инструмент, который дает возможность контролировать изменения в файлах и как то это автоматизировать, ничего более и он не заменит опытного технаря.
А что касается лично меня, то почитав вот это всё про локальные копии, репозитории, миграции и прочая, не нахожу для себя никакого удобства. По крайней мере по состоянию на настоящий момент. Пока это всё крайне громоздко и неудобно.
Так можно сказать и про чистку зубов например =)) Это дело привычки, кажется громоздко и неудобно, потому что непривычно, а так на самом деле когда все процессы доведены до автоматизма оно и удобнее и под контролем и проще и надежнее. Ни разу через админку битры в init.php еще не вносили синтаксическую ошибку что ли не имея доступа к хостингу? Даже на этом примере, администратор сайта каждый по вашему должен иметь доступ к хостингу, фтп, ссх? Вот он внес изменения в init.php потому что там шаблон на событие какой то, например отправка письма при заказе, сохранил и не поставил точку с запятой, все упало и поправить можно только по ftp =)) и где ж тут безопасность то? )) Я много работаю с битриксом, у меня под все уже шаблоны, под всю рутину, с каждым проектом битрикса в гите лежит "свой open server с блекджеком и девочками". То есть, где бы я ни был, если есть комп с интернетом и установленным докером и гитом, я проект подниму за 5 минут локально, и внесу изменения достаточно быстро, может не на столько быстро как изменить количество новостей (но это прям очень редкая задача), но любые фиксы, доработки функционала, да банально какой то эксперимент с настройками битрикса, я сделаю локально, проверю локально чтоб не было ошибок, доделаю работу, запушу в гит и оно само выкатиться, я просто напишу заказчику что все готово и он может проверять при том боевой сайт даже не чихнет и мне никто не напишет а что там за непонятные кракозябры вылезли на такой то странице или почему сайт упал у нас тут активно с директа льется трафик. Мне же самому спокойнее что я могу дебажить и выводить принтом любую служебную инфу прям на странице.