ThunderCat

массив в вашем случае будет следующего формата:

$replacers = array(
"title" =>"some title",
"text" =>"some text",
"id" =>"some id"
);

что легко ищется в документации вообще то....
Что касается сохранения - очевидно, что редактируемая новость будет иметь ненулевой id, в случае отсутствия значения в этом поле делаем вывод что это добавление, а не редактирование.
По поводу нагрузки - если вы сможете добавлять хотя бы новость в минуту, и вас (добавляльщиков) будет 50-100, это вообще никак на нагрузке на базу не отразится. 1 запрос в секунду база даже не заметит.

Ваще полный ноль. Попробуйте почитать про ООП сначала. И пару примеров самому написать. Обычно это ставит на место мозг в плане "откуда есть пошли классы, объекты и свойства с методами". Подумайте и почитайте на тему разницы объекта и класса. А так же почему $this вызывается в классе, но не может быть использован в созданном объекте.

"В ответ на агрессию со стороны неизвестно кого США нанесли удар куда попало"
Передавать можно методом пост или гет ).
Если приходит тарабарщина - то и перебирать foreach-ем и записывать как ключ=> значение.

Форма и экшн одна, если передается ид записи - читаем и разбрасываем по полям, если ид отсутствует - значит поля пустые, ждем заполнения, по субмиту в первом случае проверяем ид и делаем апдейт, во втором случае инсерт (в модели в обоих случаях вызывается метод save()).

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

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 в запрос и произвести его из пдо, а при ошибке - попробовать из консоли или из пхпмайадмин запустить запрос, смотрите что скажет сервер, и проверьте правильность полей запроса.

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

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

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

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

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

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