Антон Иванов

Сервису не хватает минусов для ответов. Бывает не очень опытный человек публикует плохой ответ, который вроде работает, но является очень плохим решением. Самое интересное, что такие ответы часто набирают плюсы. Если бы была возможность поставить минус, уверен они бы были заминусованы и не сбивали с толку людей столкнувшихся с похожей проблемой.

UPD: По поводу вкладки Избранное еще в комментариях к вопросу написал.

Добавьте возможность игнорировать вопросы определенных личностей (Черный список).

Встречаются ошибочные (либо ну очень кривые) ответы, помеченые решением.
Никакого инструмента повлиять на это нет - только язвительные и бессильные комментарии (
Доколе?

Поговаривают что last_insert_id() возвращает ID последней вставленной записи в рамках текущего подключения. То есть оно будет всегда вам возвращать то, что вам нужно, даже не смотря на то, что у вас много приложений пишущих в базу

Я меня карточки висят в Done пока по ним не получена оплата. После этого переносятся в архив. Использую трелло.

Если "максимально безопасно" то, разумеется, шифровать.
Для поиска можно тупо повторить в соседнем поле в незашифрованном виде 4 цифры, которые получаете от банка.
И да, если "максимально безопасно", то каждая запись должна шифроваться своим ключом, который, разумеется, не должен лежать рядом с записью.

Вообще, это всё словоблудие: 100%-й безопасности не бывает. Определите сценарий угрозы - от чего именно вы хотите защититься, определите наиболее вероятные векторы атаки на ваши данные, постарайтесь закрыть хотя бы их. Безопасность - это КОМПЛЕКС мероприятий (начиная с того, насколько вы уверены в надёжности своих менеджеров/админов, что они не сольют базу злоумышленнику). Подкуп иногда бывает дешевле взлома.

Если это не модная SPA, то функция ангуляров и прочих реактов сводится к тому, чтобы мешаться под ногами.

Для начала, подумайте что такое Фреймворк. Это что-то очень большое, огромный набор разных элементов.
Грид - лишь одна малая часть, туда же обычно входят миллионы других элементов (чекбоксы, инпуты, кнопки, заголовки, стили оформления текста и т.д.).

Фреймворк позволяет собрать интерфейс из готовых блоков, так сказать черновую версию, без привлечения больших усилий дизайнера и фронтендера. По сути фреймворком может воспользоватья любой бекендер что-бы что-то там собрать на коленке.

Фреймворки сильно облегчают работу и удешевляют ее. Миллион прекрасных инструментов появились благодаря им.

Если вы сделали просто action="...php" (и не указали method="get | post"), то вы мало того что перейдёте на другую страницу, у вас в адресной строке появится ряд параметров вроде:
site.ru/form_result.php?name1=1&name2=str
где name1 и name2 - именя инпутов в вашей форме.
Так вот, смысл в том, что ваша страница form_result.php должна обработать GET параметры (name1=1 и name2=str), в процессе, возможно записав что-то в базу данных.
А уже из БД вы выгрузите в удобном вам формате.
Ну или сразу php должен создать csv/xls, но тут надо ещё смотреть как файлы создавать/изменять.

Посмотрите php.net/manual/ru/tutorial.forms.php

array_walk_recursive($array, function(&$item) {
  $item = strtolower($item);
});

Пункты самовывоза - штука переменная во времени, да еще и иногда закрывающиеся-открывающиеся... Плюс история.
Так что явно пункт самовывоза - это id на таблицу пунктов самовывоза.
Притом последняя может оказаться нетривиальной по составу:
- пункт закрывается, но поток уже заказанного для него идет - нужен флажок отображать ли его в новых формах заказа
- пункт имеет ограничения по габаритам, ассортименту, времени работы и т.п. - значит это может/должно фигурировать при заказе

Нет
php.net/manual/ru/function.password-hash.php

Использованный алгоритм, стоимость и соль будут возвращены как часть хеша. Таким образом, информация необходимая для проверки хеша будет в него включена. Это позволит функции password_verify() проверять хеш без необходимости отдельного хранения информации о соли и алгоритме.

Скорее всего цены не сверяют, а берут из второго магазина Toys. Это тоже, что на столе лежит два каталога, Один по городу, другой по области. Открываете один, одни цены, берете другой, другие.
Однако, можно взять сразу два и сравнивать цены поштучно. Компьютер тоже делает это поштучно, но очень быстро. Для него сложность измеряется в объеме данных. Вот сколько времени надо, чтоб скопировать на флешку войну и мир (более 30000 строк?)? Несколько секунд. Если с картинками :) Тоже самое сравнить цены на 30000 товаров, это объем данных несколько мегабайт, если сравнивать по двум параметрам, артикул товара + его цена.

А мы переверстали последний сайт с бутстрапа 4 на 3
и этому есть причина. Бесспорная популярность бутстрапа это его простота!
А так же минимальный просто минимальнейший уровень вхождения. Что дает нам возможность с легкотсью перевешать задачи по верстке адаптивного контента, на контентщиков, стоимость которых 500 р.
А так-же даже сами владельцы сайтов могут выучить азы верстки.
Теперь что мы имеем
Верстка бутстрап 4 стала сложней.
Уровень вхождения увеличился. А следоватлеьно и привлекательность.
Да есть куча плюсов, но и появился реальный минус.
Теперь сложные страницы нужно верстать верстаку. А ему как бутстрап особо не нужен.

Часто к тестам относятся как к религии, потому что все вокруг говорят, что они нужны и это полезно. И часто их делают "шоб было". Тесты дают прирост только в долгой перспективе, на больших долгоживущих проектах.

Против:
1. Тесты это такая же кодовая часть проекта, на нее тратятся ресурсы (человеко-часы), а их нужно поддерживать так же как и остальную часть кода. Часто думают, что тест один раз написал и о нем можно забыть, но намного чаще приходят изменения, которые могут менять логику ожидания какого то поведения, может происходить рефакторинг, который так же может ломать тесты или делать какие то тесты ненужными или требовать новые и т.д. Если будете бояться сломать тесты, то и код перестанет быть гибким к изменениям.
2. Часто по неопытности стараются покрыть чуть ли не все 100% кода, получается избыточность, тесты на очевидные вещи. А это все время, а значит деньги.
3. Есть проекты, у которых срок жизни небольшой, пишется под конкретную одноразовую порцию задач. На них, я считаю, вообще нет смысла писать тесты.

Тесты имеет смысл делать:
1. Когда проект собирается жить долго и счастливо, и придет не одна порция изменений.
2. Над проектом работает не 1-2 человека, надо следить, чтоб кто-то другой не сломал то, что ты написал.
3. Во время разработки иногда удобнее написать тест на какой-то участок кода и запускать код для дебага через тест, чем каждый раз запускать тяжеловесный проект.

от JOIN еще никто не уходил