YS
component_mixture
Size: a a a
2020 April 09
AH
component_mixture
тогда получается в названии указано не полное название одной таблицы
YS
ну тогда либо смиристь вот с таким "mixture_mixture_component" либо именуй как-то по другому )
AH
понял. спасибо, наверное лучше смириться чтобы было по рекмоендациям
Ю
привет всем.
подскажите как бы правильнее реализовать дочерние(?) .env файлы конфигурации?
по триггеру - APP_DEBUG
грузить разные наборы констант. тестовые яндекс-кассы аккаунты, например. учетки к сервисам (тест/прод)
подскажите как бы правильнее реализовать дочерние(?) .env файлы конфигурации?
по триггеру - APP_DEBUG
грузить разные наборы констант. тестовые яндекс-кассы аккаунты, например. учетки к сервисам (тест/прод)
Ю
а еще удобнее было бы по
strtolower(substr($_SERVER["SERVER_PROTOCOL"], 0, strpos($_SERVER["SERVER_PROTOCOL"], '/'))) . '://')
. $_SERVER['SERVER_NAME'];
определять локальная разработка на тестовые наборы учеток - или серверные живые
strtolower(substr($_SERVER["SERVER_PROTOCOL"], 0, strpos($_SERVER["SERVER_PROTOCOL"], '/'))) . '://')
. $_SERVER['SERVER_NAME'];
определять локальная разработка на тестовые наборы учеток - или серверные живые
Ю
ну и так чтобы пароли в гит не залезли ненароком
АЗ
привет всем.
подскажите как бы правильнее реализовать дочерние(?) .env файлы конфигурации?
по триггеру - APP_DEBUG
грузить разные наборы констант. тестовые яндекс-кассы аккаунты, например. учетки к сервисам (тест/прод)
подскажите как бы правильнее реализовать дочерние(?) .env файлы конфигурации?
по триггеру - APP_DEBUG
грузить разные наборы констант. тестовые яндекс-кассы аккаунты, например. учетки к сервисам (тест/прод)
Если прям правда по апп дебаг, то тебе надо лоадер энвов свой сделать
АЗ
А откуда необходимость такая?
АЗ
Ты что на одном и том же стенде разрабатываешь и клиентам показываешь?
АЗ
В смысле ты прям на проде разрабатываешь что ле?)
Ю
какогото промежуточного сервака нет.
тут спорить конечно можно о правильности подхода - что важнее качество или обогнать конкурентов...
потому бывает что и на проде какойто баг возникнет - включишь апп_дебаг, а потом выключить можешь запариться
тут спорить конечно можно о правильности подхода - что важнее качество или обогнать конкурентов...
потому бывает что и на проде какойто баг возникнет - включишь апп_дебаг, а потом выключить можешь запариться
АЗ
Чтобы не включать апп дебаг на проде существуют логи:)
АЗ
На проде дебаг включать не надо. Хотя бы по той причине, что он замедляет твое приложение
АЗ
Если пользователей будет много, включенный дебаг положит тебе сервер
Ю
"лоадер энвов свой сделать" - вот это интересно. он из kernel грузится?
АЗ
"лоадер энвов свой сделать" - вот это интересно. он из kernel грузится?
Это ты можешь в исходниках фреймворка найти
Ю
погуглю. главное чтоб вендора не ковырять
АЗ
Но я бы не советовал
АЗ
Разрабатываешь-то ты не на проде