Comments 53
что я сделал первым делом? расшарил линк на эту статью знакомому админу. мол, пусть крутит себе на сайт ;)

за проектом наблюдаю с первой версии, ребята молодцы. я думаю это не конец
» Придумать и сделать: как разделять клиентов на «под-чаты»

а что если бот для каждого зашедшего человека будет создавать якобы груповой чат. и называть его [PM] &USERNAME%
Удивлен, что еще нет чата, в котором можно подключить любой чат для общения со стороны компании: jabber, telegram, vk, slack и т.д.
Да вобщем-то уже есть:
http://manychat.com/
https://chatlio.com/
http://whatshelp.ru/

видел ещё какие-то, т.к. думал создать подобное
UFO landed and left these words here
HTTP уходит в прошлое и это хорошо. Благо, что сейчас можно не генерить самоподписанный, а получить бесплатный сертификат
UFO landed and left these words here
http2 полностью ходит только на ssl. Сравнивать обычный http, а тем более https 1.1 — разница в разы. А уж кэширование ключей и сессий — так сайт открывается даже через сутки быстрее, чем http.
UFO landed and left these words here
А зачем переводить весь сайт? Достаточно сгенерить self-signed для работы с Телеграмом.
braindrain абсолютно верно заметил. Переводить сайт на HTTPS не обязательно, достаточно самому сделать сертификат и настроить сервер (или хостинг). По HTTPS должен быть доступен только один скрипт, к которому обратится сервер Telegram.
Единственная проблема, что на хостингах приходится платить ~90 р/мес за услугу дополнительный IP, без которой поддержку SSL не включат.
по моему Вы просто не уважаете посетителей ваших сайтов. Ведь Http легко прослушивается, а значит вы светите всё, что они делают. Саме неприятное — светить данные форм, типа email адресов.
По https обязательно должен быть доступен только скрипт к который работает с телеграмом, сам сайт может оставаться на http
Может вам стоит задуматься над качеством кода? Нет, я все понимаю, что сделано из хороших убеждений, но то в каком оно виде предоставлено это полный атас. Зачем изобретать велосипед и писать непонятную приблуду в виде «telegram-site-helper-install.php», в котором основной код приложения захардкожен в строки и обернут в base64. Вы серьезно думаете, что это будет удобно дорабатывать? А что со стилем кода, неужели вы до сих пор используете php 4 и эта версия вам не позволяет ввести классы, пространства имен, описать взаимодействия интерфейсами? Может стоит организовать код в виде composer пакета, разделив front и back end части?
И да, напоследок (и такого в коде не мало):
		if(!is_file("telegram-site-helper-config.php")){
			header("location:?act=install");
			exit();
		}else{
			header("location:?act=install");
			exit();
		}

		if(array_key_exists("selfCertPart", $_POST)){
			if($_POST["selfCertPart"]!=null){
				$selfCertPart=$_POST["selfCertPart"];
			}else{
				$selfCertPart=null;
			} 
		}else{
			$selfCertPart=null;
		}
UFO landed and left these words here

Что за бред кодировать скрипты в base64?


Выигрыш нулевой (кэширование, сжатие, слышали?), единственная достойная причина — возможность подсунуть вредоносный код.

По-хорошему сделали бы обычные исходные скрипты, и скрипт-сборщик кода, если уж так хочется в виде одного файла (но зачем? опять-таки раздача статики не лучший кейс для php).

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

Как уже выше отметил тов. zenn — пока проект не оформлен в виде composer пакета (с опциональным дополнением в виде bower пакета со всеми фроненд-компонентами) — использовать его крайне, крайне проблематично не удобно. Должны быть очень сильные аргументы, которые заставят отказаться от:


$ composer require Surzhikov/Telegram-Site-Helper
# some times later
$ composer update

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


Так же поддержу мнение что не стоит всё запихивать в один файл. Весомый плюс из этого подхода видится один — портабельность (но зачем она здесь?), а минусов же — вагон и маленькая тележка. В крайнем случае — есть phar, запустив который из консоли можно выполнить всю магию.


Сам проект потестирую обязательно, но позже. Как только придет composer.

Хотелось бы по человечески попросить разработчиков магазинов — не употребляйте везде где ни попадя и когда не попадя чат помощник. Последнее время это просто какой-то адский ад. Заходишь на сайт-магазин глянуть что там есть нужного, а тебе хлоп перед носом на полэкрана окно чата — дескать я манагер Петя чем могу быть полезен? (и ведь, падла, часто ещё с таким противным булькающим звуком! )) Да ничем, я ещё вообще не разобрался что и за сколько вы продаёте.

Закрываю окно чата. Перехожу на следующую страницу — и опять, хрясь на полэкрана… я манагер Петя… В общем — не злоупотребляйте. Активируйте чат хотя бы нажатию на кнопку. Я хочу сам решать когда мне спрашивать совета у манагера. Иначе получается как в реальном магазине порой — манагер назойливо стоит у вас под локтем и внимательно смотрит что вы там смотрите. Не крадёте ли чего случаем… :)
Это конечно сугубо мое мнение, но тут скорее всего проблема в настройке чата. Многие на магазин ставят чат потому что есть у других но не понимая как именно он должен работать.
Например было бы полезнее показывать чат если человек просмотрел 5-7 товаров из одной рубрики, тут можно предположит что посетитель не может выбрать товар и ему нужна помощь. Т.е. чат должен быть плотно завязан на статистике. А еще лучше что-бы сайт менялся под потребности посетителя, а не пихать ему чат где нужно и не нужно.
тут можно предположит что посетитель не может выбрать товар и ему нужна помощь.

По уму, я бы предложил ничего не предполагать за посетителя. А просто аккуратно и неназойливо написать в правом нижнем углу, что если у вас есть вопросы, то менеджер прямо сейчас доступен в чате. Нажмите кнопку для начала беседы. Всё.
И в дополнение хотелось бы попросить еще — не употребляйте чат-помощник, если не собираетесь его использовать. А то бывает, дозреешь до вопроса, напишешь его в в тот самый чат-помощник, а тебе приходит автоответ: «Этот вопрос легче прояснить в личном разговоре, оставьте телефон, и мы вам перезвоним». И вот уже в квест выбора товара интровертом добавляется невыполнимый пункт «телефонный разговор с продавцом».
Есть Intercom, но он 50$ в месяц стоит. Хотя он не только как чат, но и CRM и множество других плюшек.
Я, конечно, понимаю, что считается очень usersfriendly подходом сразу же на четверть экрана (а на мобильных устройствах и на весь) открывать чат, но это реально мешает. Многие сайты в рунете внезапно этим заболели. При чем даже если закроешь его или свернешь, то при каждом новом переходе по ссылке-снова вылетает. Спокойной посерфить по разным товарам в интернет магазине становится невозможно. Кто сказал, что это увеличит конверсию?
Одной и той же ложкой можно есть суп, мешать чай, а можно варить героин.
Многие сайты в рунете устанавливают JivoSite и отмечают в настройках все галочки, которые призваны увеличить конверсию.
Эт понятно, что можно. Именно потому люди и намекают, что ещё же и самому думать нужно.
Ещё есть над чем работать.
На будущее не плохо было бы добавить возможность прикреплять не только изображения, но и обычные файлы документов: pdf, odt, txt и др.
Уже при первом использовании столкнулся с тем, что не работала авторизация менеджера. Пришлось заменить в вебхуке msgText,6 на msgText,7 — помогло. Pull отправил, хоть и дико не удобно из-за этого base64.
Спасибо за Pull. Я учту всю критику касательно кода.
P. S. Можно аттачить любые типы файлов.
Действительно любые.
Проверял mp3 изначально, для него видимо нужна отдельная обработка.

Скрытый текст
Да, MP3 приходит не как Document, а как Audio.
Я просто не успел доделать эту часть. Теперь вот Composer сижу изучаю
Придумать и сделать: как разделять клиентов на «под-чаты»

Скорее всего это в ботах должна поддержка такая появиться.
Как вариант сделать приложение под телефон, который будет иметь в настройках собственный ИД, и слушать некий порт.
Сам написал тестовый подобный твоему.
Придумать и сделать: как разделять клиентов на «под-чаты»

Очевидно, что нужен сабпротокол поверх протокола телеграма, где часть сообщения будет являться заголовком. Само собой, для этого понадобится реализация своего клиента с преферансом и маркитантками.

Если понадобится делать собственный клиент, то какой остается смысл использования Telegram? Просто хранить там данные?
Очень интересно, посматривал давно как реализовать ЧатОпс (управление сервером через чат) — нужно попробовать и вправду телеграм под это дело — может что дельное получится :)
Кто нибудь может внятно объяснить преимущество Web Hook против Long Poll?

Я использую демон на Go, так что со стабильностью демона и его перезапуском никаких проблем нет.
На PHP (в реалиях современных хостингов) весьма сложно сделать стабильно и постоянно работающего демона; а технология WebHook реализует идею «PHP создан, чтобы умирать»: шлет запрос, PHP обрабатывает его и умирает.
Если речь о Go, или NodeJS или скажем Python — думаю, LongPoll ничем не хуже.
Написал уже в issues на гитхабе.

Сначала установка затыкалась на проверке https. Хотя весь сайт работает через https. Сервер сам работает через апач+nginx. Последний и подсовывает сертификат. Пришлось прописать настройки виртуального хоста в httpd.conf строку «SetEnvIf X-Forwarded-Proto https HTTPS=on» тогда установка прошла успешно, но бот молчит на команду /login pass. Как быть? Что не так?

Привет автору!
Могу ли я использовать этот чат в паре со своей "кнопкой заказать звонок", которую бесплатно предлагаю своим клиентам?
По нажатию на кнопку выпадает моя панель с просьбой ввести номер, хочу добавить туда вызов чата, если посетитель так захочет.

У меня есть SSL сертификат на сайте. Всё делаю по гайду, всё равно выдаёт → Checking HTTPS available… Error.

Что делать?
Only those users with full accounts are able to leave comments. Log in, please.