IvanIF

Вопрос легко гуглится, в чём проблема поискать: "общепринятые размеры баннеров"?
Вот мой список, чаще всего используемых баннеров:
300 х 250
320 х 50
320 х 100
250 х 250
200 х 200
336 х 280
728 х 90
300 х 600
160 х 600
970 х 90
468 х 60

Тоже не понял юмора от Kirill Makarov

Только что сделал у себя так (Laravel)

модель UserMessage

user_id // отправитель
notifiable_id // получатель
message_class // класс нотификации или мейл-класс
message // текст мейл-письма или уведомления
created_at

Перед тем как отправить делаешь нужную проверку (для каждого класса индивидуально или по шаблону)

// Проверяем есть ли такое сообщение в указанном периоде
return UserMessage::where('notifiable_id', $notifiableId)
    ->where('user_id', $user->id)
    ->where('message', $message)
    ->where('message_class', $messageClass)
    ->where('created_at', '>', now()->subMinute())
    ->exists();

Только у меня через hasMany отношение у модели юзер. Плюс еще в том что записывается сообщение в бд, которые юзеры отправляют по емейл, давно хотел сделать) А записи для нотификаций очищаются кроном раз в день. Написал несколько тестов на спам - все ок. Возможно есть изъяны и можно улучшить, я сильно не вникал в проблему и написал по быстрому.

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

2. Кто-то оценил публикацию пользователя
3. Кто-то оценил комментарий пользователя
4. Кто-то написал комментарий к публикации пользователя

Т.е.: кто-то оценил, а потом снял свой лайк (случайно или по умыслу). По первому событию отправляется уведомление с некоторой задержкой (1-5 минут). Если именно по этому событию происходит событие-отрицание, то отзыв уведомления. То же справедливо для остальных типов уведомлений.

А про настройки я не просто так - можно дать юзеру возможность (если есть такая фантазия и ресурсы позволяют) выставлять доп. параметры в группе параметров уведомлений. Например:
– Оценка Ваших публикаций
–– Кто-то оценил Вашу публикацию
–– Кто-то отменил оценку Вашей публикации

И т.д. с остальными.
На мой взгляд - это была бы идеальная система именно со стороны пользователя.

Кластеризация: уникальное уведомление (текст и событие) и его каунтер при повторах.
Отдельно: детализацию всех уведомлений (если нужно).

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

Большинство складывателей букв на РНР об этом не задумываются вообще, и очень хорошо что тебе пришел в голову этот вопрос. А ответ на него очень простой:

Проверять обращения к БД не нужно вообще

(за исключением нескольких специальных случаев, когда есть определенный сецнарий обработки ошибки)
Если же такого сценария нет, то никак проверять не нужно. Просто потому, что обращения к БД ничем не отличаются от любого другого кода.
И поскольку ты не проверяешь каждый include или там оператор деления, то не нужно и проверять запросы к БД. Их надо оставить в покое. И первый, и каждый по отдельности, и все 5 разом.

А вот что нужно сделать - это договориться с РНР, чтобы он сам сообщал тебе об ошибках в запросах. Для mysqli надо написать перед коннектом

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

Для ПДО при соединении выставить в настройках соединения

PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION

Всё. Больше ничего для обращений к БД делать не надо.

А вот обработчик ошибок, общий для всего кода, а не только для работы с БД, настроить желательно.
Чтобы AJAX-скрипт подписки получал соответствующий НТТР статус при любой ошибке, которая может возникнуть на сервере.
Ну и разумеется AJAX-скрипт подписки должен проверять НТТР статус, и обрабатывать ответ только если статус= 200
Пример обработчика можно посмотреть здесь

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

*На самом деле в транзакцию имеет смысл заключать только запросы, изменяющие данные. То есть все, кроме первого.

Соотсветственно, если ПДО настроен на выброс исключений, то при ошибке запроса
- пдо выбросит ислючение
- которое будет поймано обработчиком ошибок
- который выведет код ошибки и завершит работу РНР скрипта
- при завершении скрипта РНР закроет соединение с БД
- БД при закрытии соединения автоматически откатит незавершенную транзакцию

причем без обработчика ошибок будет всё то же самое, только клиенту уйдет код не 500 а 200

то есть для того чтобы убедиться в том что все запросы выполнились корректно, надо

1. выставить для ПДО режим исключений
2. перед первым запросом написать $pdo->begin();
3. после последнего запроса написать $pdo->commit();

Что-то вы не то читали. 2 байта для TEXT и 3 байта для MEDIUMTEXT выделяется для хранения длины текста. Для каждого символа текста выделяется от 1 до 4 байт, в зависимости от используемой кодировки.

не позволять занимать повторно ники и делать редирект. "этот пользователь сменил ник на .ххххх... перейти >". таких случаев будет очень мало.

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

Плюс желательно переменовывать файл целиком, потому что к примеру веб-сервер апач может принять за расширение файла то, что им не является.

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

Попробуй сделать collation utf8_bin для колонки user_nickname

ALTER TABLE `tablename` MODIFY
`user_nickname` VARCHAR(100) 
CHARACTER SET utf8
COLLATE utf8_bin

phpMorphy нормально работает под современным пыхом за одним исключением: конструкторы классов названы по-старому, именем класса. Их нужно переименовать в __construct именно в тех строчках, в которых вам выдает ошибку. Десять минут на все исправления.

Используйте DOMPurify

Куки хранятся в браузере если не указать ssl?

Куки храняться в браузере, что-бы вы не указывали.

Сессии на сервере ну почему у меня PHPSESSID в браузере?

Сессии храняться на стороне сервера. PHPSESSID - Эту кука, в которой записан идентификатор сессии SESSion IDentifier (кстати, ее можно переименовать как угодно).

Время жизни пока не закрыт браузер

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

Может ли сес ид передаваться по url?

Может.

Советы в целом норм, кроме совета про ip. Пришел домой, подключился к wi-fi, ip сменился, и пора логиниться заново?

Помогите плиз 2 год бьюсь(

Удивительно, что за два года вы даже не прочитали что такое сессии и как хранить пароли.

А sodium - это вообще криптография, а не хеширование.

$('selector').attr('data-title', 'value');

SELECT a.id,a.phone,b.device,b.address FROM users as a,devices as b WHERE a.id = b.user_id;

Абсолютно верно. PHP хранит сериализованные данные сессии в файле на сервере. Между страницами передаётся только идентификатор сессии и передаётся он как раз с помощью cookies. Теоретически можно украсть идентификатор сессии тем самым получив доступ к данным сессии с другого устройства, но довольно просто можно сделать дополнительную защиту привязав сессию к IP например (хранить в сессии и каждый раз проверять, при изменении IP клиента - сбрасывать сессию) или же используйте SSL на своём сайте если на нём имеется достаточно важная информация, в остальных случаях я думаю можно не заморачиватся, но всё же следите за тем что вы делаете - безпосными ваши скрипты делаете вы сами, а не PHP.