index0h

exec() вам в помощь, это если кратко.

В самом низу README там написано как:

$validatedData = $validation->getValidatedData();
// [
//     'title' => 'Lorem Ipsum',
//     'body' => 'Lorem ipsum dolor sit amet ...',
//     'published' => '1' // notice this
//     'something' => '-invalid-'
// ]

$validData = $validation->getValidData();
// [
//     'title' => 'Lorem Ipsum',
//     'body' => 'Lorem ipsum dolor sit amet ...',
//     'published' => '1'
// ]

$invalidData = $validation->getInvalidData();
// [
//     'something' => '-invalid-'
// ]

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

sprintf: s - строка, print - печать, f - форматированный режим; форматированная печать в строку.
fprintf: f - файл; форматированная печать в файл.
printf: форматированная печать в стандартное расположение, обычно в консоль.

На мой взгляд их лучше не использовать вообще.

1. Эта идея была взята из Hibernate. Но, Java позволяет в последствии сделать дозагрузку данных которые не были загружены изначально. Т.е. использование partial objects не может привести к ошибке. В PHP у объектов нет API аналогичного Java. У меня есть подозрение, что именно поэтому partial objects будут убраны из Doctrine 3, как это стало с поддержой операций detach/merge.

2. Реализация partial objects в Doctrine противоречит принципу "Модель всегда должна быть валидна"

Кстати, вы забыли про вариант с использование легковесного DTO (см. паттерн Flyweight), вместо массивов. См. https://www.doctrine-project.org/projects/doctrine...

Когда можно использовать массивы?

Массивы легко сериализуются, например, с ними можно быстро сделать API:

public function api(EntityManagerInterface $entityManager): Response
{
    $posts = $entityManager->createQuery('SELECT p FROM App\Entity\Post p')->getArrayResult();

    return new JsonResponse($posts);
}

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

$newArr = array();
foreach ($cName as $cat) {
  if (!isset(newArr[$cat['category_parent_id']])) {
    newArr[$cat['category_parent_id']] = array();
  }
  $newArr[$cat['category_parent_id']][] = $cat;
}

Любой процесс может выставить статус "блокирован", обычно когда обращается к диску или другое IO, ядро это учитвает при расчете loadAverage, в итоге если какое-то приложение выставило этот статус и оставило его висеть, то loadAverage будет расти.
Поищите процессы со статусом D (например через ps aux), в теории у вас должно быть не менее 7 таких процессов.

Во-первых: начните изучать архитектурную часть программирования, изучите паттерны проектирования, изучите 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. В данной реализации опускаются и упрощаются некоторые моменты для понятности

Нет

Вопрос этот задается раз в неделю стабильно. Поиском научитесь пользоваться для начала, этот навык вам точно пригодится.
Если по существу, курсы это трата времени. Есть мануалы и техдокументация.
Если хотите с чего-то начать, пройдите базу на htmlacademy, потом перечитайте webref.
И главное, как тут кто-то сказал - 20% теории и 80% практики.

Странный совет, если рассматриваеть его категорично.
Скажу тривиальную мысль: версионировать нужно то, что является предметом версионирования.
То есть, если конкретная картинка является неотъемлемой частью самого проекта, а не внешней зависимостью или внешним ресурсом, то она должна быть в репозитории.

Сходу нашёл пример в Github: https://github.com/rancher/ui/tree/master/public/a...

Единственно только нужно понимать, что версионирование бинарников обычно сопровождается большими накладными расходами и есть проблемы со слиянием, поэтому если есть возможность исключить картинки из [версионируемого части] проекта, ею стоит воспользоваться. То же касается базы данных: не комильфо держать дамп базы в том же репозитории, что и сам код, поскольку слишком дорогой становится история.

Если Вы спрашиваете правильных разработчиков, то:
1. Они строят и продумывают архитектуру
2. Читают официальную документацию
3. Оптимизируют стыки, логику, алгоритмы
4. Они отвечают на Тостере

Если про всех остальных, то:
1. Они спрашивают на Тостере
2. Пытаются найти исходники или статьи, похожие на их задачу
3. Пытаются найти тех, кому перепродать проект.