Довольный Айтишникъ

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

Изучите пожалуйста phpfaq.ru/pdo

Почему в командах , которая занимается разработкой с использованием git , есть определенные правила настройки редактора кода ?

Никогда раньше не слышал, что это связано именно с использованием Git.

Думаю, к конфликтам это никак не относится (напрямую), просто табуляции в разных редакторах выглядят по разному и не редко "4 пробела" и "Таб" - это не одно и то же, даже визуально. Например, в редакторе VI(M) по умолчанию, "Таб" выглядит скорее как 8 пробелов, нежели как 4.

А ещё некоторые языки могут быть зависимы от отступов, Python например, и разные варианты отступов могут давать неожиданное поведение в некоторых случаях...

Вообще, обычно принято использовать "4 пробела" вместо Tab'а... многие редакторы умеют заменять "Таб" на "4 пробела"...

Ну и когда все пишут "в едином стиле", потенциальное количество проблем, в т.ч. в будущем, например при анализе исходного кода машинным способом - значительно сокращается.

это скорее связано не столько с конфликтами гита, как с одним стилем кода на проекте. Каждому разработчику нравится писать код в определенном стиле. Представьте себе, какой ужас будет твориться в файлах, когда команда из 10 разработчиков будет писать код каждый в разном стиле. А если на проекте сотни или тысячи разработчиков?
Это будет ппц. И вот мне пару дней назад достался такой проект на доработку. Единого стиля нет. Кто как хотел так и писал. Поэтому и придумали какие-то стандарты написания кода.

Не отправлять запросы на js/css/jpg в index.php а просить веб-сервер (apache, nginx) сразу отдавать статику с диска

А что помешает хакеру изучить метод шифрования и зашифровать свой запрос?
Всё, что присылает клиент, должно проверяться на сервере, в том числе и условия допустимости запроса.

Пользователь должен указывать телефон в международном формате, Вам достаточно просто удалять все лишние символы при регистрации/авторизации, а проверять телефон можно так (все страны):

function phone_number($phone)
    {
        return (bool)preg_match("/^\+?([87](?!95[4-79]|99[08]|907|94[^0]|336|986)([348]\d|9[0-6789]|7[0247])\d{8}|[1246]\d{9,13}|68\d{7}|5[1-46-9]\d{8,12}|55[1-9]\d{9}|55[12]19\d{8}|500[56]\d{4}|5016\d{6}|5068\d{7}|502[45]\d{7}|5037\d{7}|50[4567]\d{8}|50855\d{4}|509[34]\d{7}|376\d{6}|855\d{8}|856\d{10}|85[0-4789]\d{8,10}|8[68]\d{10,11}|8[14]\d{10}|82\d{9,10}|852\d{8}|90\d{10}|96(0[79]|17[01]|13)\d{6}|96[23]\d{9}|964\d{10}|96(5[69]|89)\d{7}|96(65|77)\d{8}|92[023]\d{9}|91[1879]\d{9}|9[34]7\d{8}|959\d{7}|989\d{9}|97\d{8,12}|99[^4568]\d{7,11}|994\d{9}|9955\d{8}|996[57]\d{8}|9989\d{8}|380[3-79]\d{8}|381\d{9}|385\d{8,9}|375[234]\d{8}|372\d{7,8}|37[0-4]\d{8}|37[6-9]\d{7,11}|30[69]\d{9}|34[67]\d{8}|3[12359]\d{8,12}|36\d{9}|38[1679]\d{8}|382\d{8,9}|46719\d{10})$/", $phone);
    }

Скажите честно, а что вы вообще хотите услышать?
Во-первых, iPhone 8 - первый телефон со встроенной беспроводной зарядкой у Apple, который поступил в продажу только месяц назад, а вы хотите "реальный опыт"? От кого, от таких же, гхм, больших любителей Apple, которые мгновенно бросились покупать новую модель?
Во-вторых, если вы действительно хотите объективных цифр, зачем вы спрашиваете про чей-то частный опыт, который получен в непонятно каких условиях, вместо того, чтобы сесть и посчитать?

Минута поиска дает ответ, что в настоящее время, беспроводная зарядка iPhone 8 способна брать от зарядного устройства не более пяти Ватт мощности. Чего, согласно тестам с проводной зарядкой, достаточно для заряда телефона с нуля до полного при длительности заряда порядка трех с половиной часов. Теперь сравните эту цифру с обратной ситуацией - за сколько ваш телефон сядет со ста процентов заряда до отключения при использовании навигации. Вероятнее всего, скорость разряда все же окажется меньше. А про потерю емкости от перегрева вам никто ничего не скажет - времени с начала продаж еще маловато прошло, а это, как раз, вопрос экспериментального свойства.

= - оператор присваивания
== - оператор равенства
В условии должно быть if(productname==theproduct)

Бекенд должен учесть всех клиентов, чтобы каждому клиенту было удобно с ним работать,
но чтобы могло работать со всеми видами клиентов...

То есть нужно подстраиваться под здравый смысл вам всем :)

А в чем проблема внедрить рекламу на captive portal? Если речь о транспорте, то там он должен быть для идентификации. Иначе незаконно.

Нужно web-приложение, radius-сервер и роутер, который умеет редирект на captive portal. Запускал с год назад в эксплуатацию такую услугу у интернет провайдера. Использовали микротики, у них из коробки такой функционал есть.

2й способ сложнее и больше мороки но ходят слухи что он более выгодный что б не потерять позиции сайта

сомнительно. Этот метод скорее подходит для двух сайтов. А так как Вы второй домен грохните со временем, не думаю что это верный путь. Да и 301 редирект - это именно то, что ожидается поисковиком при переезде.

Всё зависит от архитектуры приложения.

Далеко не всегда сервер обрабатывает всю информацию клиента - это дорого как со стороны серверных ресурсов так и трафика.
Часто сам клиент обрабатывает происходящее а на сервер отсылаются только текущие статусы и задача сервера проверить, на сколько реальные данные ему шлёт клиент.

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

Чем старее игра тем более сложно найти лазейку ибо по большей части, за года, уже позакрывали всё.

Во всех играх отслеживается такая аномалия как "резкое пополнение внутриигровой валютой" - то есть было у вас 10 "монет" стало 100кккк.