ThunderCat

я не в курсе кто такой gtag, но возможно не хватает preventDefault и форма делает и субмит и код.

смотрите .htaccess, скорее всего в нем не прописаны исключения для реврайта на файлы изображений.

В mysql есть реализация системы прав пользователей с гибкой настройкой доступа к данным. При регистрации пользователя на сайте, ему присваиваются данные права, т.е. используются именно эти возможности mysql?

Нет, это пользователи чисто бд, для этого в веб приложениях они не используются.

Информация об авторизации фиксируется не чьей стороне? При переходах со страницы на страницу каждый раз происходит переконнект к БД, а значит теряется информация о предыдущей сессии?

Не надо путать авторизацию пользователя на сайте и авторизацию скрипта при доступе к бд. Скрипт имеет единые настройки для подключения к бд, а пользователь взаимодействует со скриптом через вебсервер, напрямую к бд пользователь никак не может обратиться. При авторизации цепочка действий примерно следующая:
- вводим данные авторизации(браузер) и отправляем на сервер
- сервер принимает данные, создает соединение к бд, и проверяет запросом правильные ли данные ввел пользователь.
- Если все ок, создается запись в сессии(читайте про механизм сессий в пхп), и в дальнейшем проверяется при каждом запросе к серверу, есть ли соответствующий ключ в сессии. Если есть - значит пользователь авторизирован.

Если казино не шарага в подвале, то ни о каких заранее выигрышных для казино стратегиях речи быть не может, особенно если это сертифицированное заведение. Простая математика говорит нам о том, что если шанс у игрока хотя бы на 0,1% меньше шанса казино, в перспективе казино заберет все деньги игрока. Так что им не надо придумывать себе какие-то "особые" алгоритмы. Более того, все электронные казино ОБЯЗАНЫ иметь генератор случайных чисел с высокой долей приближения к "реальному" случайному распределению, и эти генераторы все имеют сертификацию государственного контроля. Ну и все игры в казино имеют "перекос" по шансам от ~51% до ~60%, в пользу казино разумеется.

Все очень просто - если это дата и/или время - использовать формат datetime, во всех остальных случаях соответствующие хранимым данным типы. Int для timestamp вообще непотребство в чистом виде.

Дату/время рождения - это DATETIME

У вас хранится время рождения? Тут можно использовать DATE, но я бы не скупился и поставил DATETIME из соображений единообразности работы с датой и временем.

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

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

вместо свитч/кейс лучше использовать массив по типу ключ-значение, это и наращивать программно проще(роутинг на 20 путей свитчем будет так себе решением), и обрабатывать можно по всякому, т.к. это данные, а не условие. А в целом вам верно подсказали - смотрите готовые решения, их много, от простеньких до очень навороченных.

Вроде ?autoplay=1 не зависит от устройства...

<iframe width="420" height="345" src="http://www.youtube.com/embed/somevideocode?autoplay=1" frameborder="0" allowfullscreen></iframe>

Я правильно понял что лучше сделать разные таблица до разного товара

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

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

Как я понимаю, результат будет возвращаться в элемент с id=input_area.

$.ajax({
   url: 'actions.php?show',
   success: function(data){ // <-- сюда вернутся данные из скрипта php, попав в data
          $('#input_area').html(data); // здесь они будут вставлены в соответствующий DOM элемент
   }
});

PS: так как у вас пропущена кавычка, работать у вас скорее всего скрипт не будет

1) Снять уникальность с поля, если есть возможность добавить ТАКОЕ ЖЕ имя под другим id то это нарушает логику работы. Если есть необходимость соблюсти активное состояние уникальным - проверяйте программно перед добавлением новой записи.
2) Это вполне нормальная практика, частая задача, например для записи логинов. Уникальность проще проверить перед вставкой чем искать причины ошибок при дублировании ключей.

ЕМНИП контент срендеренный через js не очень хорошо индексируется. Но это было раньше, как поисковики сейчас смотрят на контент точно сказать не могу. Еще нюанс - тащить каждый раз словарь на клиент не очень хорошая идея. Еще вопрос с урл - для разных языков он должен быть разным, то есть хранить текущий язык в куке или локалстораже - плохая идея.
UPD: имхо лучший вариант - отдавать с сервера уже локализованный контент.

Я так понимаю вы хотите набор аргументов в пользу ваших утверждений?
ну тогда ...
1. Html сайт без движка
преимущества: быстро, дешево, ... все.
недостатки: Замена контента - либо обращение к разработчикам, либо попаболь с изучением основ верстки/хостинга/етц.
2. Дизайн на готовом шаблоне Wordpress
преимущества: быстро, относительно дешево, весь контент можно поменять из админки, включая расположение модулей.
недостатки: подходит лишь для небольших проектов, не требующих особого стиля фронтенда и высокой производительности бэкенда, новые плюшки разрабатывать сложнее чем на нормальном фреймворке. Однако для сайта-визитки важнее отсутствие индивидуальности и "фишки" в дизайне.
3. Дизайн на шаблоне-конструкторе
преимущества - см. пункт 2, я лично не вижу особой разницы.
недостатки аналогично.
4. Уникальный дизайн, psd макет, натяжка на Wordpress
Если ваш дизайнер реально тащит, то отличить стандартный шаблон с монстертемплейта от штучной работы сможет любой человек с хотя бы одним рабочим глазом. Если нет - нафига он нужен? Предложите клиенту вариант 2-3 и скажите что дизайнер разработал. Разницу положите в карман.

MP умеет по клику менять попапы, ничего не мешает по клику в нем открывать другой магнифик(первый закроется автоматически) и по субмиту формы вызвать нужный попап снова.
пример