AUser0

А что, $stmt->errno/$stmt->error уже запретили?

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

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

Так там дальше по тексту все в виде примеров и расписано. В частности разница между * и именем конкретного столбца f1. А ещё добавка DISTINCT.

Напишите малюсенький скрипт на любом языке, пусть читает построчно, суммирует как вздумается, и заносит результат в новую таблицу. Всё!

Поменяйте запрос к виду:

'SELECT post.id, post.title, post.user_id, post.cat_id,  users.username, category.name
FROM post
LEFT JOIN category ON category.id=post.cat_id
LEFT JOIN users ON users.id=post.user_id
ORDER BY post.id DESC LIMIT 25'

и удивитесь, как поменялся var_dump().

preg_replace("/ 00:00:00$/", "", $date_str);

Ivan_pmk, а если...?

self.cursor.execute("SELECT `user_id` FROM `users` WHERE `user_id` = %s", (user_id,))
result = self.cursor.fetchall()
self.cursor.close()

P.S. Я вообще не понимаю в этом Python, но первый же пример из Интернета...

Исправлять отправку сообщений, что бы они все-таки отправлялись.

Сотрите в <form> параметр action, или сделайте его пустым. Тогда GET-запрос придёт на тот-же URL, на котором отображается форма. И прийдётся делать обработку запроса в самом генераторе формы.

Ну или AJAX, но это сложнее.

Когда вам нужно посчитать КОЛИЧЕСТВО монет у вас кармане - вы НЕ суммируете их номинал SUM(все_монеты) = 5 р. + 2 р. + 1 р. + 1 р. = 9 р., а считаете именно их количество COUNT(все_монеты) = 1 монета + 1 монета + 1 монета + 1 монета = 4 монеты.
Теперь чувствуете разницу?

P.S. А в запросе лучше сделать COUNT(place), потому что на пассажира с ребёнком (один паспорт, один passenger) должно быть зарегистрировано два места.

А зачем тут вообще JOIN таблицы самой на себя? Достаточно:
SELECT num, num2 FROM tmp WHERE num<>num2;

P.S. Ну и рекомендовал бы изучать SQL не по вопросам-ответам, а по какой-нибудь книжке, ну или по примерам запросов, в конце концов...

SELECT * FROM Resources AS Models
LEFT JOIN Resources AS Designs ON (Designs.parent_id = Models.id AND Designs.template_id = id шаблона дизайна модели)
LEFT JOIN Resources AS Batches ON (Batches.parent_id = Designs.id AND Batches.template_id = id шаблона серии дизайна)
WHERE Models.parent_id IS NULL
AND Designs.id IS NOT NULL
AND Batches.id IS NOT NULL

Теперь приклеивайте к этому запросу JOIN-ы из переменных.

Потому что в результате по максимуму могут быть такие наборы строк:
A1+B1, A1+B2, A1+B3, A1+B4
A2+B1, A2+B2, A2+B3, A2+B4
A3+B1, A3+B2, A3+B3, A3+B4
A4+B1, A4+B2, A4+B3, A4+B4

Сразу вспомнился PhpMyAdmin с его парсером прямиком в браузерном JS,
и вот надо-же, существует библиотека на GitHub...

Правда такой запрос вернёт 3 записи, с разными type_id.
И общее кол-во нужно будет суммировать самостоятельно из этих 3-х записей.

SELECT COUNT(*) AS cnt, type_id
FROM example
WHERE user_id = 53 AND status = 1
GROUP BY type_id

Как-то нелогично использование -1/+1, ведь дата начала означает, что в момент начала аудитория УЖЕ недоступна (занята).

Select * From date d where d.id not in(
SELECT d.id FROM date d, reservation r WHERE d.id BETWEEN r.datestart_id and r.dateend_id)

Вот так выдаёт действительно незанятые временные промежутки.

SELECT drop.name, MIN(drop_sell.price) AS min_price, MAX(drop_buy.price) AS max_price
FROM drop
LEFT JOIN drop_sell ON (drop_sell.drop_id=drop.id)
LEFT JOIN drop_buy ON (drop_buy.drop_id=drop.id)
WHERE drop.name='name'
GROUP BY drop.id

И никакой проверки на валидность строки в $_SESSION['id']? И нет защиты от иньекции при выполнении SQL-запроса с INSERT-ом?