Недавно, - если быть точным - 3 года назад, я начал делать чат на PHP для собственных нужд. Буквально на днях я доработал пару функций и решил его всё-таки выпустить в мир. Технология, которую использует данная система, уже считается устаревшей: PHP (ООП, MVC), AJAX (XMLHttpRequest), HTML5, MYSQLI, CSS3. На одном из каналов Telegram кто-то пошутил и назвал чат ламповым, по аналогии с ламповыми телевизорами. Что тут скажешь?! Метафорически точно и остроумно подмечено! Изначально система задумывалась для замены чата на файлах в движке одной браузерной игры. Основная задача была: сделать максимально простую систему.
В 2022 году считается, что чаты на Ajax уже не делают, но почему-то продолжают делать системы комментариев к блогам, новостям и доскам объявлений. В моем представлении системы, которые называют message board и chat, в целом имеют схожую схему работы, а порой вообще отличаются только названием. Система, которая получилась у меня, - что-то среднее между доской сообщений и чатом.
Особенности
1) Система не хранит все сообщения, количество сообщений в базе данных всегда 50 (количество настраивается администратором).
2) Поскольку чат работает без перезагрузки страницы (Ajax), то история сообщений хранится у пользователей. Каждые 30 минут окно перезагружается и стирает историю. Это часть концепции чата: забота о хранении истории перекладывается на пользователя.
3) Чат многоканальный. Есть возможность создавать закрытые каналы. На главной странице отображается только 15 открытых каналов. Для работы с закрытым каналом требуется указать пароль (общий) и имя канала. Есть переключение между каналами с помощью мыши.
4) Ссылки в чате конвертируются. Также отображаются в чате изображения (конвертация ссылок на изображения).
5) Присутствует система выделения текста, а также возможность отправить приватеное сообщение пользователю через alert.
6) Система открытая и не имеет панели управления. Редактировать базу данных предлагается через phpmyadmin. Только каналы можно создавать на лету.
Где может пригодиться подобная система?
1) На системах, где нет необходимости создавать специальные учётные записи пользователей (небольшие офисы в одном здании).
2) На системах, где нет необходимости или возможности использовать интернет-мессенджеры и чаты.
3) Если нужно быстро развернуть сервер для общения и дать доступ десятку-двум пользователям через браузер.
Система протестирована и корректно работает с последними версиями браузеров Firefox и Chrome. Для установки требуется иметь навык работы с phpmyadmin и начальные навыки редактирования кода. Описание системы и установки находятся в сопроводительном файле.
Пример работы чата можно посмотреть здесь: http://comb.org.ru/chat/index.php
Последнюю версию чата можно скачать здесь: https://gitflic.ru/project/dcc0/open
Или здесь: https://github.com/dcc0/OpenChatPhp/tree/OpenChatPhp-1.1-2022
Обложка: отечественный телеграф. Фото из Интернета.
Данная система является открытым ПО, разработанным в России.
На правах рекламы: чат полностью написан в редакторе Geany.
Комментарии (42)
pewpew
18.10.2022 14:24Ого. В далёком 2000 году делал похожий проект. Точнее это была первая попытка сделать что-то на PHP. О базах данных тогда знал весьма туманно и сделал на текстовых файлах, хранящихся на сервере. А для коллизий при записи реализовал файл-флаг записи, при наличии которого писать в основной файл с чатом было нельзя.
В чате даже были роли, а модерация и администрирование работала через команды.
Ух! Ностальгия!
Ilusha
18.10.2022 14:35+7Шел 2022. Чаты на WebSockets уже делают ученики на курсах от всяких инфоцыган, а разворачиваются запуском пары команд (поставить nodejs, запустить скрипт).
Но зачем делать легко и просто, правда?)
Areso
18.10.2022 14:38+2Первый файл в репе при попытке открыть падает с ошибкой 500. Ну, это не к вам претензия, а к GitFlic, но возможно, там какая-то дичь и он это не может запроцессить.
Readme.txt надо бы переименовать в md. Тогда описание вашей репы начнет индексироваться поисковиками, а люди смогут сразу увидеть описание проекта, без необходимости проваливаться внутрь.
Держать ЗИП файлы в репе это моветон. Для этого есть раздел релизы
открытое ПО предусматривает соответствующую лицензию. Будьте любезны, потрудитесь выбрать одну из доступных и подгрузить её в репо
donpadlo
18.10.2022 16:21Не уверен что эта статья в формате Хабра. В личном бложике, но уж не здесь.. Ведь есть вероятность, что начинающие будут смотреть, читать и использовать сиё...
FSA
18.10.2022 19:31+5Из-за финального абзаца («Данная система является открытым ПО, разработанным в России.») больше похоже на стёб. Понятно, что код рабочий или может быть рабочим. Но такое огромное количество ошибок начинающих: код не имеет стилевого оформления, используются устаревшие возможности браузеров для которых есть современная замена работающая с лохматых версий, сохранение реквизитов соединения с базой данных в репозитории, куча require вместо автозагрузки классов... Я устал искать. Не делайте так в 2022 году.
dcc0 Автор
18.10.2022 19:59-1Нет это не стёб, но я все равно не последую Вашему совету.
Спасибо за комментарий.
kuber
18.10.2022 22:27+1Вы же понимаете, что весь код, который вы пишите сейчас на всех этих свеженьких сегодня технологиях и практиках через лет 10 будет в таком же положении, как и у автора.
lair
19.10.2022 00:46-1Если его не трогать — да, будет. Но зачем его через 10 лет таким кому-то показывать? (ну, кроме археологического интереса)
kuber
19.10.2022 07:25-1Непрерывно переписывать все проекты на все самое современное это очень дорогое удовольствие. При этом проект может прекрасно выполнять все свои функции и нуждаться лишь в поддержке и некоторых доработках.
dcc0 Автор
19.10.2022 08:15Согласен. Но этому есть объяснение: программисты хотят кушать тоже, а опубликованное ПО вообще может не приносить заработка.
Вдобавок есть постоянное движение (конкуренция) в сфере, по принципу всё течет, всё изменяется.kuber
19.10.2022 08:30Безусловно. Я сам стараюсь использовать все самые современные техники и технологии. Но у бизнеса другое мнение. Нужно привести очень весомые аргументы, чтобы он захотел потратить много времени и денег на переписывание успешно работающего проекта на все новенькое.
dcc0 Автор
19.10.2022 12:59Снова соглашусь. Но так везде: не только в айти. Любое изменение схемы работы чего-либо обычно должно быть как-то обосновано.
lair
19.10.2022 14:05-1На этапе "некоторые доработки" может внезапно выясниться, что аккуратно поддерживать проект разумно современным было дешевле, чем делать доработку к технологиям, которые больше никем не поддерживаются.
Так, конечно, не всегда бывает, и это решение, которое каждый для себя принимает сам. Но к публикации это все отношения не имеет.
Dier_Sergio_Great
19.10.2022 21:31Поддержку "Server-Sent Events" будет?
А какие бывают другиетехнологии кроме ajax и SSE?
lair
19.10.2022 23:51Вебсокеты бывают. Long-polling бывает.
(а еще бывают абстракции, которые прячут выбор между WS/SSE/лонг-поллингом, основываясь на способностях клиента и сервера)
dcc0 Автор
20.10.2022 12:18-1По поводу устаревания технологий: мне думается, что это не про Ajax на ближайшую перспективу. Как мне кажется, эту технологию можно отнести к "прижившейся" технологии.
space2pacman
Отправка сообщений через get запрос? Почему не post?
dcc0 Автор
Чтобы лимитировать длину сообщения. Расчёт был — заменить файловый чат в игре (в которой много флуда и баловства от игроков).
Этот чат можно рассматривать как некую вспомогательную систему для локальной сети.
Но мне интересны отзывы, если кто-то будет пользоваться. Мне так и не удалось потестировать этот чат, допсутим с тремя десятками пользователей.
space2pacman
Лимитировать можно и post запросы на бэке
kuber
Лимитировать можно и POST запросы на фронте.
Areso
До первого скрипт кидди, умеющего в DevTools
kuber
Не понял. И как вы это реализуете если будет проверка и на фронте и на бэке?
Areso
А смысл лимитировать дважды? Сделали на бэке, все, задача выполнена.
Делать одну и ту же задачу дважды - раздувать кодовую базу и ловить потом баги.
kuber
т.е. вы видите смысл в том, чтобы отправлять заведомо невалидные данные на сервер? Странно. Ну, ок.
Areso
Потом фронт и бэк разъедутся в части правил валидации и начнется хождение по мукам.
Реальный опыт, впрочем, у всех может быть разным. У меня - негативный.
kuber
Так они могут разъехаться по любому вопросу если неправильно выстроено взаимодействие.
Giperoglif
обычно фронт и валидируется правилами бэка. в любом нормальном фрэймворке.
lair
Что мешает это в
POSTсделать?dcc0 Автор
В общем ни что не мешает.
Когда я начинал писать, то мне показось проще ипользовать GET.
Можно переделать, если это кому-нибудь вообще нужно.
Посмотрел вот эту тему:
stackoverflow.com/questions/1872965/get-vs-post-in-ajax
Тут пишут, что GET кешируется и что через него не рекмендуют отправлять персональные данные.
Но чат открытый и авторизации не предполагает.
А про кеширование у меня самого вопрос: на что это может влиять?!
lair
Например, на то, что повторно отправленный
GETможет не достичь сервера вообще.dcc0 Автор
Если текст запроса не изменился!
Но в случае с чатом хорошо это или плохо — под вопросом!
В случае нахождения в чате товарищей с гипеактивностью, посылающих по 20 одинаковых сообщений, то, может быть, хорошо.
lair
Плохо то, что вы это никак не контролируете. Если вам нужен тротлинг — его нужно делать осознанно и специально. А полагаться на неизвестное поведение неизвестного числа посредников — плохое решение.
Ну и да, то, что человек каждый день приходит и пишет "привет", а со второго дня эти сообщения никому не доходят (а он думает, что доходят) — это тоже так себе решение.
kuber
Смотрите. Вы отправили сообщение GET запросом и браузер старательно сохранил это в истории. Через час опять зашли в чат, а браузер подставил сохранённый URL и то же сообщение отправлено повторно.
Ещё проблема, что в разных браузерах количество допустимых символов у GET разное и использовать его для этой цели просто неправильно.