ThunderCat

Медиа запросы - это способ прописать стили с привязкой к:
1) Размеру вьюпорта
2) Ориентации
3) Устройству
4) возможне еще чему-то, но не суть
то есть задать некоторые дополнительные условия в которых будут применены/переопределены специфические стили. Важно что все медиа запросы в описании стилей должны идти после основных стилей, в порядке приоритета, где самые "главные" в конце (более нижние переопределяют более верхние).

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

<button name="buy" type="submit">buy me now!</button>

there can be only one auto column and it must be defined as a key - что конкретно не понятно в этой фразе?

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

Цикл не закэшируешь, конечно, а результат можно, нарпимер используя serialize(), если там действительно объект.

Для cli и веб окружения обычно разные php.ini используются, достаточно посмотреть phpinfo() из веба и из консоли, чтобы увидеть разницу в настройках.

Как вариант дергать скрипт кроном через wget. Получится как через веб

Если не ограничить запросы на этот урл по ип/ключу/порту или как то иначе, рискуете получить дыру для ддос.

гугл, как и яндекс, вполне понимают /en /ru, но ДЛЯ КАЖДОЙ ВЕРСИИ НУЖНО УКАЗАТЬ ЯЗЫК. В том числе и в заголовках и метатегах.

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