Иван Корюков

А вот и буду кидаться палками, ловите сразу 4 =)
1) Вы хотите отправить ajax запрос, но вы делаете форму и работающую (button type="submit") кнопку отправки. Не надо так. Либо форма, либо ajax.
2) JS код, который вешает обработчик на кнопку располагается выше самой кнопки и не обёрнут в $(document).ready. Т.е. в тот момент когда исполняется этот код, самой кнопки ещё нет, и обработчик нажатия не вешается.
3) обработчик отправки формы реагирует на isset($_POST['button-reg']), однако когда вы делаете ajax запрос, вы не передаёте параметр "button-reg".
4) расширение php, которое позволяет вызывать функции mysql_*** устарело. Используйте mysqli или PDO

Чем вас не устраивает первый вариант и в чём плюсы второго?
Логика подсказывает, что дублировать пост для каждого юзера, который на него подписан это абсурд.
Хотите сказать, что если я делаю пост в группу в которой 100к подписчиков, то я сразу создаю 100к записей в базе?
Количество постов в таблице постов будет больше чем в первом варианте на несколько порядков и это только замедлит выборку.

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

select * from posts join subscribe sub on(...) where sub.user_id=123

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

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

Надо добавить маркеры начала и окончания строки. Вот так:

preg_match("/^update\/[0-9]+\/[a-z]+$/", $input_line, $output_array);

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

Всё просто - не надо в функции проверки прав печатать ответ.
Более того, функция проверки прав не должна ничего знать про то - под аяксом она запускается или нет. Она должна просто проверять и возвращать результат (bool, текст ошибки, код ошибки, что угодно), а уже где-то в контроллере (это такое место, где вы получаете данные http запроса, решаете что делать и формируете http ответ) вы должны превращать результат в ответ.

Важно понимать, что сначала отрабатывает PHP, который формирует и отдаёт html, а уже потом. Браузер, приняв этот html, рендерит его, ну и если у чего-то там display:none, то не показывает этого.
Вам надо сразу не генерировать этот div. Как это сделать зависит от того кода который у вас уже есть.

Нади использовать не запятые, а точки с запятой.

Сделайте перенаправление не с любого адреса на coming-soon.php, а только с адресов, заканчивающихся на .php

Используя ...$arr вы не получите ключи в массиве. Поэтому почему бы не сделать третий агрумент обычным агрументом, и не передавать туда массив, который без изменений будет передаваться в execute?

public function query($sql, $class, $params){ // $params = [":age"=>20]
        $sth = $this->dbh->prepare($sql);
        $res = $sth->execute($params); // <----
        if (false !== $res) {
            return $sth->fetchAll(\PDO::FETCH_CLASS, $class);
        }
        return [];
    }

$day_orders = $db->query("SELECT COUNT(*) as cnt FROM 'oc_order' WHERE 'date_add' >= CURDATE() ");
echo $day_orders['cnt'];

Просто используйте постраничную навигацию:

SELECT *, something FROM `news`
WHERE (некое условие для фильтрации по категориям) AND  date < "time of page hit"
ORDER BY `something` ASC
LIMIT 20, 20

Я добавил в этот запрос всего два маленьких изменения. Первое - задал смещение для LIMIT, его надо высчитывать на PHP и вставлять в запрос. Первая цифра это просто номер страницы минус один, умноженное на количество постов на странице (page_num-1)*page_size. Вторая цифра - как обычно, количество постов на странице.
Второе измененеие - добавил в where дополнительное условие: выбирать только те новости, которые уже были в базе, пользователь открыл страницу. Это необходимо, т.к. если в процессе подгрузки новостей добавится ещё одна, то страницы поедут (вы могли замечать это, когда листаете хабр и на следующей странице первым виден последний пост с предыдущей) и какая-то новость задублируется в общем списке на клиенте. Time of page hit должно храниться на клиенте и передаваться на сервер при подгрузке каждой следующей порции данных.

Этот метод не зависит от того как вы сортируете новости - по дате, рейтингу, любому другому полю... главное чтобы первая подргузка и все последующие сортировались одинаково.

Пример не очень хороший. Тут очень сильно зависит от предметной области. Если вы разрабатываете систему управления всякими вокрфловами, в которых могут участвовать разные сущности, то наверное да, однако тут можно зайти с другой стороны - что если выделить класс сущностей, которые могут использоваться в управлении воркфлоу как отдельную сущность, которая может нести разную полезную нагрузку в зависимости от типа? Тогда статус будет атрибутом этой сущности, а полезная нагрузка уже будет выносится в компоненты той же самой Стратегии...
Если же, как в примере, вы просто заметили схожесть процессов работы с разными сущностями, то скорее всего не стоит париться. Можно конечно унифицировать, но когда сущности действительно разные, рано или поздно появятся различия, ради поддержки которых придётся хакать свою же систему.

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