Эдуард

очень вероятно что одна строка написана в блокноте с выбранным UTF8-BOM, а вторая написана на сервере или на чьём-то ноутбуке где было выбрано Windows-1251, а потом просто скопировано или вставлено в базу как было

ну и как ты сам нашел в комментах - __debugInfo магический метод может менять вывод var_dump.

File -> Settings -> IDE Settings -> File types -> PHP files
Добавляете в список нужное расширение файла по аналогии.

Недавно была задача, анализировать и подменить трафик(TLS) windows приложения.
1. Составил список доменов(использовал wireshark) к которым идут запросы через TLS.
2. Добавил домены в hosts с локальным ip.
3. Создал самоподписанные сертификаты на каждый домен.
4. Добавил сертификаты в доверенные корневые сертификаты.
5. Поднял вебсервер(nginx) с сертификатами как прокси и вел логи всех запросов.
6. Поменял некоторые данные отдаваемые вебсервером.

По теме: sslstrip, sslsniff

string date ( string $format [, int $timestamp = time() ] )

Поскольку вы неправильно используете функцию date(), сравниваются просто строки. Строки сравниваются посимвольно. Ноль меньше, чем два, поэтому сравнение немедленно возвращает true.

Правильно сравнивать даты так:

$first = DateTime::createFromFormat('d.m.Y', '01.01.2016');
$second = DateTime::createFromFormat('d.m.Y', '25.12.2015');
var_dump($first < $second);

Или так:

var_dump(strtotime('01.01.2016') < strtotime('25.12.2015'));

Немного банальностей:
1. Бизнес не даст ресурсов на переписывание проекта с 0: время и большие риски
2. Бизнесу как правило все-равно какое говно там крутится, лишь бы деньги приносило.
3. Если более-менее адекватное руководство - нужно донести идею постепенного рефакторинга кода по мере необходимости в процессе фикса багов и разработки новых фич и тем самым аргументировать что на разработку новых фич/фикс багов нужно больше времени.

Как я бы делал:
1. Тесты на существующие функции (если возможно, видел методы в контроллерах с мешаниной вызовов методов моделей, созданием DTO и сохранением их через репозиторий, прямых http-запросов и запросов в бд на 1000+ строк, покрыть такое тестами - невозможно)
2. Составить план рефакторинга, где отметить что и где надо сделать, коротко, в основном для команды разработчиков.
3. Постепенно рефакторить старый код по мере взаимодействия с ним.
4. Новый код - писать сразу правильно, для взаимодействия со старым кодом где нет возможности/времени его переделать - делать какие-то адаптеры, что бы не распространять токсичный код.
5. Как оперативная мера защиты от SQL иньекций можно поставить что-то вроде этого https://github.com/nbs-system/naxsi
6. Мониторинг кода, который не используется - pinba.org , по мере обнаружения такого кода - удалять безвозвратно (в крайнем случае есть VCS, я надеюсь). Начать с более высокоуровнего кода - контроллеры, напримерю. Плюс IDE в этом могут помочь и grep.
7. Как вариант - новые фичи можно пилить в отдельном проекте (v2), крутить оба и постепенно переходить на новый, со временем старый (v1) выкинуть (и начать делать новый - v3 :-) )

1. Любой язык в который умеете
2. После выбора языка можно загуглить библиотеки для телеграмма или воспользоваться чисто их api (у них там все подробно написано)
3. читать документацию и учиться программировать

Как-то уже показывал тут, но напишу еще раз.

Настраиваем path OpenServer


Добавляем закладку на PhpStorm


Запускаем PhpStorm через OpenServer


Используем встроенную в PhpStorm консоль и получаем удовольствие от работы

Любое поле, которое может быть введено, а может и не быть должно иметь значением по умолчанию null.

Использовать NULL.