ThunderCat

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

В данном случае копать в сторону понимания связи пхп и хтмл, а так же в сторону элементарно логики. Неплохо было бы объяснить задачу чуть шире, т.к. явно Вы пытаетесь ехать на лыжах по асфальту. Кроме того что тэгов h1 в тексте может быть гораздо больше одного, но еще и вопрос "каким образом данные попадают в нужный тег?" тоже мог бы Вам сильно помочь. В смысле ответ на него )

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

$query_views =mysql_fetch_array($query_views); //будет работать, но это кривое решение

Внимательней читайте код, внимательно читайте доки, ОЧЕНЬ внимательно читайте советы опытных людей. Вам написали - функция mysql_fetch_array депрекатед, это раз, и второе - вы ее неверно используете.
Используйте функции вывода переменных (хотя бы) для отлова багов var_dump, print_r;

Патамушта.

Что за каша вообще?
1) начнем с date('D' ... - получаем стоку, имя дня недели.
2) В итоге $full_count у вас хз что за значение, а не массив, ну да ладно, может вы там массив храните
3) форичем мы получаем непонятно что, т.к. проверили на true $full_count, который вообще неизвестного типа, если массив, то логичнее проверять на is_array(), а если еще и пустой - и на !empty.
4) Раз ругается на несовместимость типов значит там явно не числовой массив
И что должны получить?

как извращенный вариант - прописать лайфтайм сессионной куки покороче.

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

https://technet.microsoft.com/ru-ru/library/ms1890...
Поясню если не очень понятно - в вашем случае надо выбрать всех с дисциплиной 5 и исключить их из выборки

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

В идеале - отдельная таблица ключ-значение, но мы же не живем в идеальном мире )

Я понимаю что "задача такова и решаем как можем", но в идеале нужно разнести такие значения в отдельную таблицу с отношением многие ко многим, ибо like не самая быстрая команда, даже в выражении like ...%, про like %..% вообще молчу. А так - сплошные извращения наподобие `numbers` like %2% and `numbers` like %3% и так до конца, я молчу о проблемах с числами более 9, где надо определить 12 или 1,2.

Так как у вас проверять неправильно.

<?php
if($_SERVER["REQUEST_METHOD"]=="POST"]){
        print_r($_POST);
        if (!empty($_POST["name"]) && !empty($_POST["email"])){
             doSomeMagic($_POST);
        }    
        else {
             echo "Поля name или email не заполнены!";
        }
}
else {
     echo "Метод передачи данных не является POST-запросом!";
}
?>

Если у вас проходит до проверки и выдает пустой массив - то где то явно не хватает нехилого куска кода. Иначе до принт_р не дошло бы и выдавало бы "Поля name или email не заполнены!".

1) Не мешайте чистый жаваскрипт с жквери. Вы еще не так круты в программировании чтобы так изголяться.
2) Скорее всего жквери не подключен, либо $ не переопределен для короткого алиаса. Попробуйте $.ajax => jQuery.ajax

Вариантов много, 2 очевидных -
1)

пользователь может создать заказ, использовать промо-код, но оплату не произвести. При этом использование (счетчик -1) засчитывается.

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

Транзакции, пачками по 300-500-1000, надо подбирать лучшее значение перебором, другого вроде ничего не придумали пока. И что за апдейты которые на 200к занимают час? Нормальный запрос выполняется 0,001 сек, на 1000 уйдет секунда, значит на 60к нужно минуту времени. 150к максимум 3 минуты. Возможно что с базой что-то не так, проверьте скорость работы update, сделайте explain, посмотрите какие индексы нужно добавить.

Обычно есть отдельные классы проверки типов переменных, их либо выносят в хелперы, либо суют в логику модели(что имхо весьма коряво). По экранированию - если у вас строка предполагает наличие спецсимволов, что в принципе нормально, использование препаред статмент спасает ситуацию полюбому.

А чего вы ожидаете? False будет в случае неудачного запроса, у вас же запрос прошел нормально, вернуло 0 строк. Учитесь читать расшифровки, думайте головой.