Daria Motorina

1) установить вывод ошибок в индексном файле/единой точке входа:

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

2) читать ошибки во вкладке нетворк.

1) Не надо называть контроллером то, что им не является.
2) Если у вас 2 дб - не надо в одном объекте их инициализировать, нужно создать 2 объекта (по 1 на дб) со своими настройками.
3) WHERE id - просто шикарное условие.
4) $_POST, $_GET и вообще сырые данные приходящие с фронтенда в запросы вставлять категорически нельзя. Во первых их надо хотя бы базово валидировать, во вторых для этого есть prepared statements.
5) Чем вообще обусловлено разделение данных на 2 базы? Похоже что вы что-то не так делаете изначально, на уровне проектирования структуры данных.

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

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

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

Сам не захочет, не начнет. Программирование это ад для обычного человека.

Во-первых: начните изучать архитектурную часть программирования, изучите паттерны проектирования, изучите SOLID, DRY, KISS и остальные модные словечки, постарайтесь всё это осознать, или, на крайняк - зазубрить. Всё придет с опытом, изначально все не понимали зачем всё так сложно, но эта сложность обусловлена неисчислимыми литрами слёз и потраченных нервов, всё не просто так.

Судя по всему это тестовое или учебное задание. От вас требовалось отоверинжинирить простую задачу. Давайте попробуем:

Суть задачи - есть файл с определенной структурой хранения данных, структура строковая. Требуется этот файл преобразовать в другую структуру данных и вывести эту структуру в json формате. Задача ясна.

Разобъем задачу на отдельные независимые этапы:
1) Преобразование одной структуры данных (текстового файла) в другую (объект, понятный PHP, к примеру)
2) Преобразование этой структуры данных в Json формат.
Первый вопрос, который может возникнуть - почему сразу не преобразовать в json? Ответ - при расширении системы в будущем - нам понадобится вывести данные в виде массива, или в виде XML, или даже в виде готового файла Excel. Нам будет сложно дополнять логику изначального класса, ничего при этом не сломав и не затронув уже существующий функционал. Также ответом на этот вопрос может являться каждая буква из SOLID принципов, подробнее отвечу дальше, когда буду пояснять за реализацию, см. ниже

Теперь рассмотрим эту задачу с точки зрения ООП, начнем думать не от конкретной реализации, а от интерфейса и абстракции (мы не парсим конкретный файл, мы парсим просто файл, мы не переводим его в конкретное представление json, мы переводим его просто в представление):
Нам понадобится 2 класса - непосредственно класс, читающий файл и преобразующий его в простейший тип данных (например PHP array). Второй класс - преобразователь простейшего типа данных парсера в какой-то определенный тип:

1. LogFileReaded implements/extends FileReaderContract(интерфейс, возможно абстрактный класс, если понадобится предустановленная логика)
   
   Непосредственно наш преобразователь (не забываем, что передавать путь к файлу и все настройки нужно из вне, к примеру, в конструктор. Нельзя, как вы - хардкодить всё внутрь файла, на крайний случай - можно использовать конфигурацию), на ввод получает файл определенного типа с определенной известной структурой, на выходе выдает информацию из файла, преобразованную в базовый тип (массив, в нашем случае). Если нам когда-то понадобится парсить другой тип данных или структура данных будет изменена - мы сможем написать отдельный класс для этой логики, а не рушить целостность уже работающего кода, добавляя туда новую логику. Запомните - нужно стремиться не менять, а дополнять.
   
   
2. JsonPresenter implements/extends DataTypePresenterContract
   
   Абстракция содержит контракт на метод output(), а в конструкторе принимются исходные данные. В конкретной реализации JsonPresenter в output() будет банальный json_encode() (да, это нормально, нет, класс не лишний и нет, json_encode() нельзя пихать в сам парсер) А теперь к вопросу - почему не следует просто запихать это всё в парсер и вместо массива отдать json: в будущем, когда система будет расширяться - нам понадобится представить данные в виде XML - что тогда будем делать - переписывать весь код парсера ради добавления switch case "json" и т.д.? А если что-то сломается во всей системе? А если вариантов представления станет настолько много, что файл будет просто не читаем? А при данном подходе достаточно будет просто написать новый класс XMLPresenter, или даже ExcelPresenter, который на выводе не строку будет выдавать, а целый файл (опустим типизацию output пока)). Также этот класс можно реализовать в виде декоратора (паттерн), да и много еще как.
   
   

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

К примеру: в итоге, если вас уже повысили, и вы вместо парсинга стали заниматься более высшими материями - новому программисту, чтобы дописать логику преобразования данных в Excel не нужно знать как конкретно вы преобразовывали когда-то эти данные в json, ему не нужно дебажить ваш код, ему достаточно посмотреть на интерфейс - отнаследоваться от него и написать свой собственный метод преобразования и дальше использовать его в нужном месте.

P.S. В данной реализации опускаются и упрощаются некоторые моменты для понятности

Если регистрация с email адресом, то по возможности вытаскивать email из соц сетей и автоматически привязывать у пользователя эту соц сеть. Если соц сеть не дает email, то при первом входе насильно требовать завершения регистрации через указания email, далее проверяется есть ли этот пользователь уже в базе - тогда говорим нужно авторизоваться и после логина привязываем соц сеть, если такого email нет, то регистрируем нового пользователя с записью этого email в качестве основного + привязка соц сети + пароль(уже по желанию).

array_splice($password, count($password), 0, 'e');

Подозреваю что на выходе , после цикла
while($row = mysqli_fetch_array($res))
Result set - $res становится ПУСТЫМ! поэтому второй while его не отрабывает.
и либо
- его необходимо наполнить заново, повторно выполнив запрос
$res = mysqli_query($dbc, $query);

либо, что более корректно:

1) заполнить из result set некий массив, далее по коду уже работать с массивом.

2) на каждом номере класса выполнять запрос

SELECT * FROM `pupils` WHERE class = 'НОМЕРКЛАССА' -- я допустил что колонка у вас называется class

и далее делать вывод анологично.

3) что еще более правильное:
получить из базы список классов, например

SELECT DISTINCT class FROM `pupils` -- я допустил что колонка у вас называется class

далее цикл по резалтсету
выводим

<div class="cl">
      <h3>НОМЕРКЛАССА</h3>

делаем запрос вида

SELECT * FROM `pupils` WHERE class = 'НОМЕРКЛАССА' -- я допустил что колонка у вас называется class

далее цикл по резалтсету
выводим
<h4>ФИО</h4>
конец вложенного цикла

выводим закрывающий тэг </div>

конец первого цикла.

как-то так... ну код сами напишете ;)

Сочетайте все три способа вместе!

1. На подстраховку задайте в css размеры изображений и чтобы он их обрезал.
2. Сохраняйте оригинал файла. А уже от этого оригинала генерируйте обрезанные копии для разных частей сайта:

- Для корзины надо 50х50px
- Для админки 100х100px
- Для списка товаров 300х400px
- Для просмотра товара 1000х1000px и ещё с водяным знаком.

В таком случае вы папки изображений разделяете на две:
- original (оригинальные фалы)
- cache (сгенерированные из оригинала под нужные размеры).

В дальнейшем можно удалить просто папку cache и сгенерировать новые по нужным размерам из оригиналов папки original без опаски удаление оригинала и опаски потерять оригинал совершив ошибку при обрезке.

Сохранение оригинала ещё поможет в будущем... Например, если изменится вёрстка и нужно будет пересоздать файлы под другие размеры.

На Yii для этого есть замечательная библиотека, которая реализует такой подход

Пример настройки:

public function behaviors(): array
    {
        return [
            [
                'class' => ImageUploadBehavior::className(),
                'attribute' => 'photo',
                'createThumbsOnRequest' => true, //Создавать при запросе (если файлы из cache удалить, то они снова сгенерируются под новым размерам указаных ниже)
                'filePath' => '@staticRoot/origin/posts/[[id]].[[extension]]',
                'fileUrl' => '@static/origin/posts/[[id]].[[extension]]',
                'thumbPath' => '@staticRoot/cache/posts/[[profile]]_[[id]].[[extension]]',
                'thumbUrl' => '@static/cache/posts/[[profile]]_[[id]].[[extension]]',
                'thumbs' => [
                    'admin' => ['width' => 100, 'height' => 70],
                    'thumb' => ['width' => 640, 'height' => 480],
                    'blog_list' => ['width' => 1000, 'height' => 150],
                    'widget_list' => ['width' => 228, 'height' => 228],
                    'origin' => ['processor' => [new WaterMarker(1024, 768, '@frontend/web/image/logo.png'), 'process']],
                ],
            ],
        ];
    }

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

3. Лучше не предупреждать что будет обрезано, а в момент загрузке на js показать как будет выглядеть изображение на всех видах верстки. Но можно и просто написать.

Вообще это идеальный вариант. Вы можете использовать самый простой вариант и работать с простой и удобной библиотекой. Или любой другой популярной написанной на чистом php. Решать вам)

Напишите на любом php фреймворке. Нет такой админки, которая бы всем угодила.
Laravel работает на любом хостинге. Нет там ничего тяжелого.

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

что-то вроде:

CompanyName\YourBundle\Controller\Admin\UsersController;
CompanyName\YourBundle\Controller\Admin\NewsController;

(для админки)

CompanyName\YourBundle\Controller\Public\UsersController;
CompanyName\YourBundle\Controller\Public\NewsController;

(для публичного раздела)