ThunderCat

вместо свитч/кейс лучше использовать массив по типу ключ-значение, это и наращивать программно проще(роутинг на 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 умеет по клику менять попапы, ничего не мешает по клику в нем открывать другой магнифик(первый закроется автоматически) и по субмиту формы вызвать нужный попап снова.
пример

в 2 параметр topRatio задавал позицию от центра, выраженную в десятичной дроби, попробуйте topRatio: 0.5 - по центру должно быть.

На будущее: PHP при вызове из крона(и из консоли вообще) использует настройки, отличные от пхп настроенного "наружу" через Апач.
По этому:
1) Все пути должны быть абсолютные, как к скрипту, так и внутри него
2) Такие глобальные переменные как $_SERVER, $_GET, $_POST и прочие скорее всего будут пустыми.
3) Для отладки норм будет ">> somepath/log.txt 2>&1", но если скрипт не выполнится ничего естественно туда не запишется(не забываем что и здесь нужно указать полный абсолютный путь).
4) Ничего не мешает использовать вполне вменяемое мвц и объекты, достаточно сделать настроечный файл с инициализацией глобальных переменных "вручную" и, в некоторых случаях, подправить автозагрузку. Для такого у меня используется отдельный clibootstrap и cliController, в который можно только из консоли )

чета мало кода, ну да смысл примерно понятен...

Хинт: инпут вида

<input type='text' name='username[]' value='somename'>

вставленный многократно, на стороне сервера будет интерпретирован как массив, который можно перебрать и получить весь список из ваших 100 строк. Если форма методом post, то соответственно на сервере будет $_POST['username'][0] = 'somename';

Если у вас 2 и более заголовка h1 - гугл считает это ошибкой, т.к. хэ1 это заголовок страницы, далее все должно быть подзаголовками.

в общем случае никак, нужно передать объект(читай ссылку) $data1 в метод класса 2.
типа такого:

$data1  = new Class1();
$data2 = new Class2()
$data2->funct1($data1);

На сайте довольно сложная клиентская часть, думаю будет сложно написать подобный функционал на чистом js.

да

Многие считают, что jquery сегодня устаревшая технология, так ли это?

нет

В таком случае какой фреймворк больше всего подходит под данную задачу?

vue, react вполне подойдут. Jquery для другого немного, хотя на нем можно написать подобное, но это будет дольше, неудобнее и в целом сложнее.

полезности

1) CI, Laravel - низкий порог, простая архитектура, однако располагает к "небрежному" и "неклассическому" коду.
Yii, Symphony, Zend - сложнее, хорошо структурированы, достаточно "чистый" код, более строгий подход к коду и архитектуре.

Нужно быстро стартануть и устроиться - учите 1(лучше ларавель, свежее и популярнее), хотите роста и сложных задач вкупе с привычкой к качеству кода выше среднего - выбирайте из 2.