Ипатьев

Очень неплохо, но есть замечания.

1. ini_set('display_setup_errors', 1); надо убрать вообще, это бессмысленный карго-культ
   
2. ini_set('error_reporting', E_ALL); и ini_set('display_errors', 1); надо вынести в общий файл, который инклюдится во все остальные. Иначе на бою придется редактировать в каждом файле, чтобы заменить 1 на 0.
   
3. empty после trim надо убрать, проверять на существование заведомо существующее значение не имеет смысла. То есть, переписать так
   

   if(trim($_POST['user_name']) && trim($_POST['user_email']) && trim($_POST['user_password']))

   
   Но и это будет неправильно, поскольку trim не применяется к добавляемым в БД значениям
   То есть, потримать отдельно в переменные, а потом проверить просто
   if($user_name && $user_email && $user_password)
   
   
4. проверка if(isset($_SESSION['user_data'])) явно не на месте. А если форма запрошена не постом? Показывать её уже авторизованному пользователю? Зачем?
   
5. после header('Location: '); всегда должен идти exit. в данном случае не принципиально, но это должно делаться на автомате.
   
6. _once из require_once надо убрать вообще, это бессмысленный карго-культ
   
7. require('database/ChatUser.php'); - это стыдоба. Сделайте простенький автозагрузчик, это три строчки. Например
   

   spl_autoload_register(function ($className) {
       $ds = DIRECTORY_SEPARATOR;
       $className = str_replace('\\', $ds, $className);
       $filename = __DIR__ . "{$ds}..{$ds}database{$ds}$className.php";
       require($filename);
   });

   автозагрузчик тоже кладется в общий подключаемый файл.
   
   
8. проверку if($user->saveData()) надо убрать вообще, это бессмысленный карго-культ, и - вдобавок - ошибка. Если POST запрос был обработан без ошибок, то после него всегда должен быть редирект, без всяких success_message. А "Something went wrong" выводится совсем другим кодом. Я ещё посмотрю в database, но если что, то исправлять надо будет там
   
9. вывод сообщений об ошибках в хтмл части лучше сделать в едином стиле
   

   <? if($errors !== ''): ?>
       <?=htmlspecialchars($errors) ?><br><br>
   <? endif ?>

   
   
10. хорошим тоном считается при ошибке выводить пользователю уже введенные значения (кроме пароля, разумеется)
    

    <input type="text" name="user_name" value="<?= htmlspecialchars($user_name ?? '') ?>">

    
    

Так, в database более серьезные ошибки.
В целом неплохой ActiveRecord, но в конструкторе прям всё очень плохо.

1. В обязательном порядке переделать
   • Во-первых, require в коде класса - это сразу профнепригодность. Всю необходимую информацию класс должен получать только через методы.
     
   • Во-вторых, new DatabaseConnection в каждом конструкторе - это совсем детская ошибка. Давно TOO MANY CONNECTIONS от mysql не получали?
     
   
   Этот класс должен принимать уже созданное соединение, через параметр конструктора.
   
   
2. createAvatar я бы вынес в отдельный класс
   
3. Непонятно, зачем вам вообще понадобился цикл foreach ($params as $key => $value), если проще и удобнее написать $statement->execute($params); Для кого специально этот функционал создатели PDO писали?
   
4. return $user_data; после условия - это логическая ошибка. Будет undefined variable $user_data если условие не выполнится. Но главное, что здесь все неправильно изначально. Никаких проверок быть в принципе быть не должно.
   

DatabaseConnection

Тут две основные ошибки, не буду уж нумеровать

• Во-первых, данные для подключения к БД (как и другие, отличающиеся для разных окружений настройки) пишутся в отдельном файле, который не добавляется в систему контроля версий (пишется в .gitignore). И, соответственно, никаких констант, а обычные параметры конструктора. И в этом контексте становится непонятно, зачем вообще нужен класс DatabaseConnection, если все что он делает - это создает инстанс PDO? Правильно, он становится совершенно не нужен
  
• Во-вторых, и самое главное - в PDO не включен режим информирования программиста об ошибках. Я даже не представляю, у какого инфоцыгана вы брали этот код - уже, вроде бы, даже до самых тупых из них дошло, что оставлять программиста без сообщений об ошибках - это садизм. Поэтому при создании инстанса ПДО надо в обязательном порядке включать режим информирования об ошибках. Для этого добавить еще один параметр в виде массива, [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]; и пока оставить так. А потом, со временем, добавить к проекту централизованный вывод сообщения "что-то пошло не так"
  
  

Непонятно что здесь непонятно и почему стоит сложность высокая.
"Скопировать данные ответа программы" это стандартно OTVET=$(programma)
"взять часть его" - это grep или там cut

Сам по себе вопрос бессмысленный, поскольку вообще ничего не сказано ни о данных, ни об их структуре. Ни о проблемах, которые вызывают необходимость такой "оптимизации".
Так что на него можно ответить только так же абстрактно.
Превращать JSON в EAV глупо.
Так что вопрос здесь не в том, размазывать ли JSON по строкам, а в том, нужен ли он здесь вообще.

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

Кроме того, никакого "login" в качестве идентификатора быть не должно, а должен быть первичный ключ.

копать в сторону гугля вестимо
ssh socks proxy
делается одной строчкой на никсах или настройкой путти в венде.
собственно от удаленного сервера ничего не нужно кроме доступа по ssh

Запретить, разумеется, ничего нельзя. Но можно ограничить количество введенных символов ( -n), проверять введенное значение, и выводить запрос повторно, если оно не соответствует контрольным.

Причем в данном конкретном случае можно проверить только на у, а любой другой ввод расценивать, как "нет".

К сожалению, плохих статей в интернете куда больше чем хороших.
Вот эта, например, вводит совершенно ненужную конструкцию, завязывая зачем-то внутреннюю структуру приложения на структуру НТТР запроса. Хотя разумеется они вообще никак не связаны.
Вам надо просто уйти от этой дурацкой схемы имя/действие/операнд. В реальности так никто не делает.
Если бы адресация любого приложения могла вписываться в эту схему, то отдельный роутинг был бы просто не нужен. Да, для некоторых контроллеров это годится. Для других - нет. И при этом внутренняя структура приложения может вообще ничего общего не иметь с порядком ключевых слов в НТТР запросе.

В данном случае notebooks_and_computers/notebooks - это просто SEO мусор, который вообще не нужен для отображения товара. Для которого нужен только айди товара. Ну вот и запускается контроллер витрины с экшеном отображения карточки товара.

https://php.net/md5_file

Для начала надо выучить русский язык и узнать, что означает слово "сортировка"
Потом надо выучить SQL, чтобы узнать, каким образом можно ограничить выборку по условию.
Потом надо выучить HTML чтобы узнать, как можно передать выбор пользователя на сервер
Потом надо выучить РНР чтобы узнать, как можно взять переданное из HTML значение и подставить его в SQL запрос, выполнить этот запрос, и вывести результат.

Никак.

Причем в данном конкретном случае это еще и бессмысленно.
Админу не нужна картинка, чтобы отредактировать пост. Она уже загружена, и заново ее загружать просто не имеет смысла.

Так и не смог разобраться в чем проблема, может я тупой

Да нет, дело не в умственных способностях. Просто всё поколение такое. Не умеет пользоваться интернетом. Только тикток смотреть в телефоне.

Вот, я погуглил за вас: Не добавляются данные в таблицу

Соответственно, после исправления ошибки надо будет ещё переписать кусок после bind_param, убрав бессмысленную проверку и оставив только

$stmt->execute();
return [
    'error' => false,
    'message' => 'Дело успешно добавлено'
];

Как правильно написали выше, общепринятой практики нет.
С натяжкой общепринятой можно назвать практику, когда часть свойств пишется в JSON поле, но как раз для описанного в вопросе случая она не должна применяться. Здесь однозначно подходит стандартная реляционная структура. Нет гарантии? Пишем null. Нет пробега? Пишем 0 км.

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

Да, но не на джунской вакансии.

Сам по себе современный пых как раз очень сильно покусан явой.
И если писать на пхп, используя современные подходы в ООП, то при переходе на яву увидишь очень много общего. Собственно, пхпшники всю жизнь учили паттерны проектирования по книжкам для Явы.

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

Но сначала надо научиться формулировать вопросы. Без этого умения ни в пхп ни в яве толку не будет

Непонятно, что именно здесь может быть непонятно
PhpMyAdmin - тупейшая программа, которая на веб странице показывает результат запроса, с разбивкой на страницы.
Если запрос вида SELECT * FROM table, то показывает все содержимое таблицы
Если запрос вида SELECT * FROM table WHERE col=value, то показывает только те строки, в которых выполняется условие поиска.

Если вопрос в том, как PhpMyAdmin запоминает условие поиска между страницами - точно так же, как запоминает всё остальное, включая авторизованного пользователя - в сессии.

Можно.
Это называется eager loading.

Не только можно, но и нужно.
Всегда надо использовать только абсолютные пути.