Можно ли настроить запросы к php через вебсокет и http одновременно?

Виктор Кожухарь, например?

Можно ли настроить запросы к php через вебсокет и http одновременно?

Shurik, я ж вроде несколько раз повторил - ни nginx, ни php-fpm не имеют к вебсокету никакого отношения :)
Их надо оставить в покое и вообще не трогать.

Независимо от них поставить вебсокет сервер и работать с ним напрямую с клиента.

В теории, можно конечно настроить прокси в nginx на определённый локейшен, чтобы обращение шло по 443 порту, которое потом тупо проксируется на вебсокет сервер, но мне это кажется лишним. По крайней мере для теста точно не нужно добавлять лишнюю точку отказа. Потом, когда всё заработает, можно будет добавить такое проксирование, чтобы не настраивать SSL отдельно для вебсокета. Хотя это не такая уж и сложность.

Как развивать логику в программировании?

Сами комменты я читал, но конкретно ваш про бублики - разумеется нет, поскольку вы его написали за две минуты до того, как написали этот. Теперь ваши проблемы с логикой становятся куда понятнее. Ну что ж, удачи вам в обучении. Её вам понадобится много раз уж с логикой не сложилось.

MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

Я бы не рассматривал эту проблему как некий баг 11 версии.
А считаю, что это такой стандартный взбрык оптимизатора. Просто вот он вылез именно на этом запросе после апгрейда. Так совпало.

MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

при тех же настройках my.cfg...

Хм. Кстати, а что за настройки-то?
Ну и традиционно - в первую очередь размер innodb_buffer_pool_size?
Может быть, 11-ке тупо требуется больше памяти, индекс не влезает в оперативку и она срывается в построчное чтение? Может, я конечно глупость говорю, но лишний раз проверить буфер innodb всё равно не помешает.

MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

Я думаю, имеет смысл написать куда-нибудь в группу поддержки MariaDB. Приложив результаты show index from table для всех таблиц.

MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

Сам недавно столкнулся с точно таким же поведением. Мария (впрочем, когда работал с Му, то же самое случалось) точно так же перекособочила порядок таблиц в запросе и получила какое-то дикое время выполнения. Заставил использовать мой порядок джойнов через STRAIGHT_JOIN, и всё залетало. Но вот как это лечить на системном уровне - и сам не знаю. Принимаю такие закидоны как данность и лечу вот хинтами.

Причём у меня БД не менялась, это новый запрос на старых данных.

Не работает авторизация через телеграмм для определенного домена, может кто сталкивался с этим?

Ну значит дело не в домене

Не работает авторизация через телеграмм для определенного домена, может кто сталкивался с этим?

это шелл на том же хосте, где и живой домен, правильно?

Symfony 6.4 php 8.4 много сыплется deprecated, есть ли пути решения?

А последняя цифра версии-то какая?

Не работает авторизация через телеграмм для определенного домена, может кто сталкивался с этим?

Ох уж эти пользователи библиотек
Если сказал "А", говори уж и "Б": смысл просто пинговать апи курлом? Тогда уж надо и тестовое сообщение отправлять

curl https://api.telegram.org/bot<BOT ID>:<TOKEN>/sendMessage?chat_id=<CHAT ID>&text=test

что возвращает?

Не работает авторизация через телеграмм для определенного домена, может кто сталкивался с этим?

curl https://api.telegram.org возвращает 302

А куда перенаправляет-то хоть?

Возможно ли сделать такие запросы-замены в таблице?

Насколько проще и как это будет обработано php?

Вы так спрашиваете, как будто у вас есть готовое решение на SQL и вы типа сомневаетесь, стоит ли его менять на непонятное пхпе

Как называется такая вложенность в php?

Для двух дней нормально, можно продолжать баловаться. На шаблонизатор надо переходить когда (если) поймешь недостатки этого способа.

Почему возникает ошибка (T_VARIBLE)?

Это понятно.
Непонятно, почему не писать все запросы одинаково, и не забивать себе голову вопросом, безопасные ли эти данные, или нет. Ну допустим здесь такой ключ. А в другом месте будет другой ключ, который в силу отсутствия знаний и опыта, будет принят за "безопасный".

Почему возникает ошибка (T_VARIBLE)?

function api_key_generator($length = 8){
    return bin2hex(random_bytes(ceil($length/2)));
}

а не вот этот вот ужас

Почему возникает ошибка (T_VARIBLE)?

У меня ещё свой вопрос есть. Что, по-вашему, делает функция parse_str, если вы её вдруг решили здесь написать?

Почему возникает ошибка (T_VARIBLE)?

Это сейчас не может. А потом логика поменяется, и вдруг сможет.
Зачем вообще писать небезопасные запросы? Какая проблема написать

$sql = "UPDATE `Users` SET `api_key`=? WHERE id=?";
$conn->execute_query($sql, [$new_api_key, $row["id"]]);

Так и код аккуратнее, и не надо сидеть думать над каждой переменной, может её пользователь изменить, или нет.

Есть ли в PHP оптимизация при передаче массива по значению?

И не только массива. Большая строка (при условии только чтения) точно так же память не съест

Помощь в PHP проверка данных из файла только выбранные значения?

// Удаляем пустые строки

Точно удаляем?

// Проверяем значение

Как именно проверяем?

Вам, часом, не ИИ этот код писал?