VoidVolker, нормальный сервер и нормальный браузер сами по себе нормальный уникод в подоконные кракозябры не превратят. Скорее всего, там какой-нибудь ОпенСервер, требующий настройки, а страница вообще ни при чем. Или уже существующий сайт на 1251, в который ТС влез со своей кодировкой.
CityCat4, я там видел еще что-то про ограничение записи при проседании напряжения - в ожидании, что щас придется скидывать кэш, диск уже не дает в него писать. Может выйти неожиданным боком в реальных условиях, особенно без выравнивания линии UPS-ом. Или при хреновом БП. В общем, оно делается не под условия рабочей станции, а больше под всякую встройку.
Это тяжелое наследие древних версий РНР. В новых этот костыль просто выкинут за ненадобностью, поскольку есть анонимные функции.
Заменяешь create_function('first', 'second') на function(first) { second } - можно даже регуляркой попробовать...
Маркетинг и жажда власти уже породили термин Power Loss Protection, которым производители SSD хвалятся на своих дорогих моделях. А пытаться какими-то настройками спасать дешманские, похоже, просто бесполезно.
Saboteur, для интерактивного бота можно реализовать схему:
- юзер нажимает кнопочку в боте, телега отправляет сообщение от этого юзера боту
- бот разбирает сообщение, получая chat_id, и возвращает юзеру ссылку на сайт, в параметрах которой этот самый chat_id
- юзер переходит на сайт, сайт сопоставляет chat_id и ID юзера на сайте.
Минус в том, что по той же ссылке теоретически может зайти другой юзер... но почвы для злоупотреблений пока не представляю. Разве что проблемы, если он начнет этой ссылкой делиться ;)
Использовать в одном проекте decimal(10,2) и decimal(10,0), причем и то и другое - для денег... it smells a lot.
Ну, и насчет нужности целого поля PLUS/SUB вместо того, чтобы тупо писать сумму со знаком - тоже подозрительно.
Дмитрий, токен вы и формируете, и разбираете сами, так что содержание произвольное.
Простейший бот отправляет сообщения и принимает их. Вы его точно дописали? ;)
Принимает либо через вебхук, но для этого нужен HTTPS на сайте, либо периодическими запросами.
Если бот должен делать, скажем, ежедневную рассылку - достаточно периодических запросов.
Вообще-то довольно странно, что "работает тоже отлично". У меня тут завалялась ХРюшка, на которой SMB1, включил ее в сеть - а она этой сети не видит вообще. А Десяточки, наоборот, не желают видеть той ХР. На SMB-серверах давно поднята версия именно из-за того, что первая уже создает неизбежные проблемы даже в Убунтах.
ffshow16, этот простейший код будет работать только после того, как на странице появились пункты меню.
Воткните его в хедер до их вывода - и он не сделает ровно ничего, даже если подключен jQuery - элементов с таким классом еще нет в DOM.
Поэтому любой подобный код обязательно заворачивается в ready.
Если сайт на хостинге - есть еще нетривиальная опасность: настроить более широкие ограничения по адресу, чем у почтового сервера провайдера, через который будут отправляться письма.
Для практической задачи, имхо, не стоит искать того, что "где-то можно найти".
Если не страшно пожертвовать 0,001% пользователей, которые завели себе настолько фильдеперсовую почту, что имеют с ней проблемы по всему остальному интернету, прогибаться под них на своем сайте смысла нет.
My1Name, например, у меня сейчас на столе лежит письмо (бумажное) от потенциального пользователя, который не смог зарегистрироваться на сайте только потому, что указывал почту через & вместо @. Человеку 76 годиков, он путает. Запрещать - имхо, неверно сказано. Стоит указывать, что такого символа в почте не должно быть.
photosho, можно записывать числа строго в 6, 7 или, если вы большой оптимист, 8 цифр.
Тогда глубину можно будет определять простым сравнением длин строк, даже прямо в БД.