Андрей

покажите схему DB.
ну и использовать mysql_* - моветон.

Как-то уже показывал тут, но напишу еще раз.

Настраиваем path OpenServer


Добавляем закладку на PhpStorm


Запускаем PhpStorm через OpenServer


Используем встроенную в PhpStorm консоль и получаем удовольствие от работы

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

1. docker-окружение
(в 90% случаев для веб-разработки достаточно php -S 0.0.0.0:8000)
виртуальные машину становятся нужны:
- когда надоест переустанавливать хост-систему из-за обилия хлама
- когда работаешь с несколькими проектами имеющие специфические (разные) настройки окружения(php, web-сервер, база)
- когда надоест решать проблемы в команде из-за того что по разному настроено окружение

2. git - система контроля версий
Помнить что ты и когда изменял, должен не человек, а машина.
Это необходимо:
- чтобы не испортить всю работы за прошедший год нажав del
- чтобы определить кто из команды злодей и все испортил
- чтобы не думать как перенести свежую версию проекта с одной машины на другую

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

4. behat + phpspec
Тесты нужны:
- когда хочется почувствовать себя безопасности и для сладко спать ночь, забыв о кошмарах о сломанном коде
- когда в production все снова сломалось
- когда ты написал одну новую фичу, а сломал три

5. zsh
Хорошей консолью приятно пользоваться, работа идет быстрее.
Консоль есть жизнь, жизнь есть shell.

6. tmux
Мало одно окошка в консоли, тогда tmux идет к вам.
В качестве бонуса получите возможность парного программирования совершенно бесплатно

7. tmuxinator
Надоело каждый раз открывать кучу окон для tmux, попробуйте его )
8. vim
- Потянуло на что-нибудь необычное?
- Хочется эффективнее писать код ?
Ну что открыли vim? В первый раз? Поздравляю закрыть вы его не сможете )
Вызывает зависимость при частом потреблении

9. continuous integration сервер
Вообще ci сервер это одушевленная машина. Это твой тамагочи, ты кормишь его хорошим кодом, он радуется и ты видишь приятный зеленый огонек. Если ты дал с код от скажет что не вкусно. Ну а если ты ему, что гнилое он будет долго на тебя орать плохими словами. Со временем он растет и учится делать более серьезные вещи, и начнет помогать тебе:
Его скилы:
- он может сам выполнить 10 минутные тесты
- подготовить и опубликовать проект
- рассказать о твоем коде, даже то что ты не знаешь
Он легко обучается и ты легко сможешь научить его удивительным вещам.

10. куча линтеров на pre commit hook
Чтобы ci не кормить плохими продуктами, хорошо бы проверять что ты сделал до отправки на сервер. Что бы не забыть это сделать git сам работу.

11. gulp
gulp - это еще один твой помощник.
как если использовать, как watcher файлов + livepreview, можно забыть о F5 в браузере

12. bower
Тоже что и composer но для управления ассетами. Это я о всяких jQuery и Bootstrap

666. Линукс
Даже если не хочется ставить как хост-систему, его все равно надо знать. Ваш код будет работать на нем )

Как не смешно звучит, сам я эти книжки не читал, но, когда собирал подобную же вашей коллекцию, заметил, что их во многих местах рекомендовали безотносительно языка:
The-Art-Unit-Testing-examples
xUnit-Test-Patterns-Refactoring-Code
ActiveRecord нормально тестируется с помощью частичных моков. Даже запросы нормально тестируются, если их выносить в отдельный класс, а ActiveRecord::find() использовать только как фасад для получения инстанса нужно класса с запросами.
П.С. Поделитесь потом что нашли и что реально оказалось полезным.
П.П.С. А вот еще книжка хорошая The Clean Architecture in PHP. Она вроде бы не сложная, но очень хорошо описывает как можно IoC использовать, а это прямой путь к хорошим тестам.

UserModel::public function register($name, $email, $password);

Регистрирование нового пользователя это ну никак не метод UserModel. Методы моделей - это действия, производимые с объектом модели. Если бы он был статическим, это ещё куда ни шло.

Вообще странно у вас всё устроено. Вроде бы пользователь только регистрируется, т. е. объект UserModel должен создаваться по окончанию процедуры регистрации, а у вас $user приходит на вход postRegisterUser(..., UserModel $user). А ещё потом это $user->find($request->get('id')). Что ещё за id? Если пользователя только собираетесь регистрировать, у него ещё не должно быть id, или я что-то не понимаю? Ну это так, к слову...

В документации к различным фреймворкам, я вижу что-то вроде $form->isValid() и ни слова о том, что происходит далее.

Чтобы понять, что происходит дальше, нужно понять, что же собой представляет $form. Это класс формы, хранящий внутри себя список названий полей ввода (в вашем случае 'name', 'email', 'password'), а также все необходимые фильтры и валидаторы для этих полей. Форма, строго говоря, ничего не знает ни о контроллерах, ни даже о UserModel, её задача - принять, отфильтровать, проверить данные, вернуть список ошибок, если данные не корректны. Для каждой html формы создаётся и конфигурируется свой класс формы. В итоге получаем что-то вроде:

public function postRegisterUser(Request $request)
{
    $form = $this->getRegisterForm();
    // Передаём данные $_POST. Ключи не перечисляем - форма сама разберётся, что взять
    $form->setData($request->getPost());
    if ($form->isValid()) {
        // Получаем уже отфильтрованные данные
        $data = $form->getData();

        // Регистрируем нового пользователя
        $user = UserModel::register($data['name'], $data['email'], $data['password']);
    }
}

static public function register($name, $email, $password) 
{
    // Регистрируем нового пользователя
}

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

Вне зависимости от выбранного языка или фреймворка, принципы остаются примерно те же. С Symfony мы можем говорить о гексагональной архитектуре, луковой архитектуре, data mapper и т.д. С nodejs мы тоже можем обо всем этом говорить но там не особо развиты идеи data mapper (на данный момент). Приходится жить с active record или dbal. Ну и опять же управление зависимостями в js и в php по разному организованы, хотя суть (dependency inversion) остается той же.

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

Я напишу в целом, т.к. это подойдет для любого языка

Алгоритм работы парсера довольно прост, и по большей части делится на 3и этапа:
1) Получить данные
2) Разобрать данные
3) Сохранить данные

1) Для того чтобы получить данные, надо изучить стек функций для работы с сетью. Можно гуглить по такому запросу "Как скачать веб-страницу" + твой ЯП (PHP, Java, Python и т.д.). Тут ты должен написать функцию которой на вход передашь url, а на выход получишь данные (html, json, xml и т.д.)

2) Разобрать данные можно либо с помощью готовых библиотек под нужный формат, либо с помощью регулярных выражений, либо с помощью строковых функций. Тут на помощь придет запрос "Строковые функции" + твой ЯП или "регулярные выражения" + твой ЯП. На этом этапе ты должен написать функцию, которой на вход поступают данные, а на выходе получаешь заранее утвержденную структуру.

3) Сохранять данные в необходимой структуре можно в файлы или в БД. Опять в гугл с запросом "Работа с бд " + твой ЯП, либо "Работа с файлами" + твой ЯП. Тут твоя задача написать функцию, на вход которой приходит заранее утвержденная структура, а на выходе ты получаешь результат "сохраненные данные"

Ну, собственно и всё. Идешь в гугл, изучаешь матчасть и пишешь парсер.

Если же тебя в большей степени интересуют алгоритмы разбора, тогда советую посмотреть код "калькуляторов" на твоем ЯП, погуглить можно по запросу "калькулятор со скобками", "Разбор и вычисление выражений". Это классическая задача, разбор твоего куска будет очень похож.

Размер файла ещё не говорит о том, что в нём что-то не правильно.

Контроллер содержит бизнес логику. Проверку введенных данных и т.д.

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

Может разбить контроллер на несколько частей?

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

echo '<pre>';
var_dump($var);
echo '</pre>';

И таки да, это print_r :)

codereview.stackexchange.com

$release->{"country-code"} или $release->{"@country"}

country-code и @country - это свойства объекта, но написать $release->country-code или $release->@country нельзя, это не переварится интерпретатором. Поэтому и используется такой способ.
Подробнее можно прочитать, разумеется, в документации.

return "{$this->product}"
А вот это - дурацкий хак. Насколько я понимаю, это сделано для того, чтобы возвращать строковое представление объекта product. Но гораздо нагляднее делать $this->product->__toString().
Вот пример такой системы:

class Product {
	public function __toString() {
		return 'foo';
	}
}

class Thing {
	private $product;
	
	public function __construct() {
		$this->product = new Product;
	}
	
	public function bar() {
		// Писать меньше и можно гордиться своим крутым маневром
		// Но через месяц надо вспоминать, зачем это кавычки вокруг свойства
		return "$this->product";

		// Наглядно и понятно, никакой магии
		return $this->product->__toString();
	}
}

$thing = new Thing();
var_dump($thing->bar());

https://bitbucket.org/

скрипт выводит только строку title в таблице news

SELECT title FROM news

"Действительно, в чем же причина такого странного поведения?" - спросил Алексей Уколов с явным сарказмом в голосе.