Алексей Горбунов

При создании экземпляра DatBase у вас не вызывается родительский конструктор и, соответственно, свойство chat_id остаётся неинициализированным.

SELECT `name` 
FROM `example`
WHERE `status` = 'free'
ORDER BY `date`ASC
LIMIT 1;

Не?

Господи, опять очередные страдания, "люди добрые памажите решить чем мне заниматься, мы сами не местные пять семей по вокзалам". У вас у всех прямо гамлетовские страдания, "быть или не быть". Вопрос века, ошибка смерти подобна - "в какой области я больше бабла получу???!!!111" Да ни в какой. Никому ты не нужен, такой беспомощный нытик. Ни в вебе, ни в энтерпрайзе.

В любой области ценятся самостоятельные разработчики, те, которым можно поставить задачу, и они сами исследуют проблему, разработают решение и будут его внедрять. А не те, которым надо всё разжевать и в рот положить. А потом еще проверять за ними, все ли сделано правильно.
Если ты не можешь самостоятельно решить несложную организационную задачу - промониторить вакансии, походить по собеседованиям, составить собственную картину и принять самостоятельное решение, то как разработчик ты тоже полный ноль и неважно, 1 год ты тему изучал, или 20.

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

НИ В КАКОЙ. В прошлом веке кончились те времена, когда ты выбирал себе профессию на всю жизнь. Сейчас мир меняется если не за 2 года, то за 10 лет неузнаваемо. Важны способности, а не навыки. Важно понимать общие принципы построения программных систем, а не конкретный синтаксис одного языка. Да, возможно через 5 лет разработчики БД будут совсем не нужны (на самом деле нет). Но я тебе точно говорю что и через 5, и через 50 лет будут нарасхват люди с мозгами и руками. И надо не затачивать свои руки под один конкретный инструмент, а разивать мозги, учить теорию, учиться самостоятельности, пытаться стать исследователем, а не мелким лавочником.

Ну вообще-то в сообщении об ошибке всё сказано. C bindParam можно использовать только переменные. Потому что биндинг идёт по ссылке (by reference). А на строку, вписанную прямо в коде, ссылку не поставишь. В этом случае надо использовать другой метод

$b=$pdo->prepare(" INSERT INTO `main` SET tel=:tel");
$b->bindValue(":tel", '79998887766');

или вообще передавать данные сразу в execute():

$pdo->prepare(" INSERT INTO `main` SET tel=:tel")->execute(["tel" => '79998887766']);

и всё будет работать

Он не долго обрабатывается, он бесконечный.
12 всегда больше единицы, и while(true) длится вечно. (или пока движок его по таймауту не вырубит)

Алгоритм называется "используй циклы"
https://www.php.net/manual/ru/language.control-str...

while
do-​while
for
foreach

$sum = 0;
$arr = [1, 2, 3, 4, 5];

foreach($arr as $val) {
    $sum += $val;
}

var_dump($sum);

Отвечу всё же на заданный вопрос:

Откуда это берется вообще? /*!40001 SQL_NO_CACHE */ и как это убрать?

Это - комментарий с фрагментом запроса, специфичным для MySQL.

Помещается в тело запроса (в т.ч. в дамп) для того, чтобы запрос, использующий какую-либо специфичную для MySQL конструкцию, мог быть выполнен в другом SQL-диалекте без внесения изменений в текст запроса. Т.е. MySQL обрабатывает содержимое такого комментария так, словно этот фрагмент не закомментирован, тогда как другие СУБД проигнорируют этот фрагмент как комментарий.

Опциональное пятизначное число указывает минимальную версию MySQL, начиная с которой содержимое комментария должно обрабатываться (в показанном фрагменте - это версия 4.00.01), на более младшей версии комментарий останется комментарием. При его отсутствии (используется только /*!) - код из комментария обрабатывается любой версией.

Убрать - в случае дампа никак. Да и не нужно это - эти комментарии специально добавляются для того, чтобы можно было корректно развернуть дамп на более младшей версии MySQL. Впрочем, далеко не все специфичные конструкции так комментируются - скажем, если в теле хранимой процедуры имеется обращение к функции, отсутствующей в младшей версии, то это обращение не комментируется и при разворачивании на младшей версии приведёт к ошибке. Но тут уж, как говорится, на каждый чих не наздравствуешься...

man mysqldump

--where='where_condition', -w 'where_condition'

Dump only rows selected by the given WHERE condition.
Quotes around the condition are mandatory if it contains spaces or other characters that are special to your command interpreter.

А ты в WHERE подставил SELECT

mysqldump -u root database table \
--where "article='263203A001' or article='OP570' or article='OC90'" \
> dump.sql

https://lnav.org/

удобный,простой интерфейс.

LINUX

Поздравляю, вы успешно поделили на ноль.

Инструмент называется xdotool и вызывается из консольки:
xdotool mousemove 100 100 click 3

Потому что нельзя быть на свете красивой такой:

// @ , также известный как оператор подавления ошибок -- сразу на мороз.
ini_set( 'upload_max_size' , '400M' ); // -- на мороз. Правильное написание: upload_max_filesize ; переопределяется только через .htaccess (в случае Apache, и если разрешены изменения в .htaccess) или через настройки сервера (PHP_INI_PERDIR), или в php.ini
ini_set( 'post_max_size', '400M'); // -- на мороз. Только через (см. выше.)
ini_set( 'max_execution_time', '300' ); // и это если хватит 300 секунд на обработку потока

Посмотрите Shop-Script — там вроде бы всё есть, что вы описали. Насчёт интересных шаблонов дизайна — это дело вкуса, смотрите темы дизайна в официальном каталоге.

Никак
При клике запрос делается браузером пользователя и значит скрыть ничего не получится
И скрывать эти данные не имеет смысла. Если не хотите чтобы пользователь видел какие-то данные - не отдавайте ему их никогда.

https://yandex.ru/search/?text=php%20Очистка%20POST
https://www.cyberforum.ru/php-beginners/thread1697...

Первый пришедший в голову вариант:

SELECT user_id
FROM some_table 
WHERE num IN (878, 925, 242)
GROUP BY user_id
HAVING COUNT(DISTINCT num) = 3 -- 3 количество вариантов
;

MySQL fiddle

Вариант с JOIN:

SELECT some_table.user_id
FROM some_table 
JOIN some_table st1 ON st1.user_id = some_table.user_id AND st1.num = 925
JOIN some_table st2 ON st2.user_id = some_table.user_id AND st2.num = 242
WHERE some_table.num = 878
;

MariaDB fiddle

Вариант с GROUP_CONCAT (номера должны быть отсортированы):

SELECT user_id, GROUP_CONCAT(DISTINCT num ORDER BY num)
FROM some_table 
WHERE num IN (878,925,242)
GROUP BY user_id
HAVING GROUP_CONCAT(DISTINCT num) = '242,878,925'
;

MySQL 8.0 Fiddle

Пользователь САМ должен придумать пароль, а ВЫ должны хранить хеш от него, но не САМ пароль. Разумеется в целях большей безопасности НЕ нужно отправлять пароль на почту, вот совсем-вообще. Единственный тонкий момент - на этапе ввода юзером его пароля, проверяйте, чтобы юзер выбрал достаточно надежный пароль.