Я бы такую фичу создавал бы на основе другой фичи, это усложняет общую картину, но других вариантов нет, имхо. Лучше, конечно, избегать такого на этапе планирования. Со схемой как у вас я работал, но у нас были rolling-releases (с такими требованиями по-другому никак) и это работало даже при слабом тестировании из-за слабого зацепления кода, поймать регрессию было редкостью. Соответственно, если фича зависела от другой фичи, то первую в любом случае ждали в продакшн, поэтому реализация первой, в прод, затем второй, либо ветвиться как написал выше.
Чтобы не путаться в своем проекте, он должен иметь логичную и строгую структуру. А отдельный репозиторий создаётся для отдельного проекта или микросервиса, т.е. в том случае, когда код независим.
Дмитрий, подтверждение тому, что я написал, если после merge был просто создан новый коммит такой же как в ветке из которой мержили, то это поведение fast-forward, в принципе стандартное для git.
Дмитрий, вполне достаточно, в PHPStorm все сделано как нужно, просто кому-то нравится иное оформление графа истории коммитов. Я к тому, что ваш вопрос (если я угадал причину) хоть в командной строке, хоть в GUI придется решать.
h0w4rd, спасибо, просто у всех разное понимание что такое плохо, для кого-то отсутствие эксепшенов в тестовом примере уже не допустимо. Инструменты которые используются для переменных очень странные, безусловно (честно говоря проглядел real_escape_string и странное оформление переменной, когда писал коммент), тут каждый день выкладывают код подверженный sql-инъекциям, но меня просто смутила фраза про стиль написания, все-таки стиль это не ошибки, но может имелись ввиду все-таки ошибки.
Оптимальная защита от sql-инъекций это подготовленные запросы с привязкой переменных, присутствуют в любых драйверах, и в PDO, и в специализированных для MySQL, PostgreSQL, Oracle.
Примерно так это выглядит для mysqli:
$stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (?)");
$stmt->bind_param("i", $id);
$stmt->execute();
Насколько большой массив? При большом массиве применение array_reverse и for приведет к большим затратам памяти, в этом случае смотрите array iterators.
Возможно, стоит пересмотреть формат хранения данных, или пойти на сознательную денормализацию добавив вычисляемое значение. Хотя, если подходит вариант со 100 строками, то это излишне.
Melkij, выпилили наркоманскую настройку в php.ini, когда неявно вместо string используется mbstring. Наверное имеется ввиду это.
Я бы все равно не стал ставить старую версию ради, может быть когда-нибудь... Когда наступит этот момент окажется что что-то еще требует сосвсем другое и т.д. Sanes, а с Битриксом все печально, они не собираются обновляться?
notmad, а что выводится в сообщении?
$_REQUEST это всего-лишь объединение $_GET и $_POST, если там есть, а в $_POST нет, значит это get-параметр, смотрите $_GET.