"Вопрошающий оперирует ложной моделью Вселенной" (с) Ответчик.
Довольно обычное для начала изучения РНР по учебникам "для чайников" непонимание его роли.
РНР получает запрос от пользователя, формирует текст страницы и отдает его. Все. Больше никакого интерактива.
Нужно что-то получить после загрузки страницы, или по нажатию на кнопку, или по ссылке без перезагрузки страницы - используйте JS, отправляйте AJAX-запрос другому РНР-скрипту и пристраивайте в браузере его ответ, куда надо.
Вне зависимости от капч и прочих технических средств определения живого пользователя - стоит подумать головой, чем отличается то, что вам реально может написать клиент, от того, что пришлет спам-бот.
Например, если в тексте клиента крайне маловероятен фрагмент "http" - можно обойтись и вовсе без капчи... а боты пусть радостно шлют свой шлак в /dev/null.
Авторские права неотчуждаемы, их нельзя нарушить.
А вот лицензия на код, как правило, говорит не только о распространении, но и о модификации. И ваш патч ее условия, вполне возможно, таки нарушит.
Вообще-то сервис прямо запрещает дублировать вопросы.
Тем более, что это бессмысленно.
А у этого вопроса - вдвойне.
Никто тебе через астрал не скажет, какая конкретно у тебя в БД кодировка.
А РНР тут вообще ни при чем.
Стоит начать с корректной формулировки, что есть "активность от пользователя на сайте".
Например, JS может худо-бедно определить, является ли вкладка со страницей активной.
Вариант с колбэком требует от того, кто будет пользоваться классом, слишком всерьез разбираться с ним.
Три разных метода логичны, поскольку они выполняют три разные действия и это естественная, ожидаемая логика.
А вот их общую низкоуровневую логику можно вынести в четвертый метод, приватный.
В РНР - никак.
Этот код один раз отрабатывает на сервере, когда браузер запрашивает страницу, после чего никак на то, что отображается в браузере, уже не влияет.
А кто, по-вашему, сможет собрать эту "какую доля"? Владелец сайта никому не отчитывается, на чем он написан.
По косвенным признакам можно определить многие CMS, но и только. Первое попавшееся исследование (с первой страницы выдачи Гугля, между прочим), смогло это сделать только для четверти опрошенных сайтов. Для остальных же не всегда можно даже определить использованный язык.
Кастомный лог имеет смысл делать в файлах с именем, содержащим дату, в папке, на которую можно натравить logrotate. Тогда вас не особенно будут волновать такие нюансы - не накопите же вы гигабайты лога за день.
Боты - это не возможность спамить кого попало.
Это возможность осмысленно ответить тому, кто сам спросил.
Вот ID этого самого чата, созданного пользователем при обращении к вашему боту, и обрабатывается.
Собственно, из документации:
Боты не могут сами начать общение с пользователем. Пользователь должен либо добавить робота в группу, либо первым начать с ним диалог
Это чей-то чужой товар?
Так-то у WB есть API, и для своего товара это решается куда более вменяемыми методами.
Тем более, что информация "этот товар купили ... раз(а)" обновляется с задержкой, зависящей от фазы луны, и никогда не бывает актуальной.
Если вам нужны только суммы транзакций, зачем в массиве остальные поля?
Соберите отдельный массив, каждое значение которого - сумма транзакции, тогда к нему действительно можно будет применять array_sum.
Кроме того, строка "-$1,002.53" - это не число, и приведена к числу она быть не может. Нужно удалить из строки символы доллара и запятой.
Написать функцию сравнения, которая сначала сравнивает позиции валют в предопределенном списке, а при их равенстве - второе значение.
И использовать штатную функцию сортировки массива с пользовательской функцией.
Никакой "отзеркаленный" текст вам не нужен. Вам нужен повернутый на 180 градусов.
mPDF, например, это умеет. Если будут проблемы с поворотом картинки - ее-то вы можете заготовить перевернутой отдельно.
