Xveeder

А вы не видели обновление awesomium? Оттуда выпилили поддержку .Net. Впрочем, её обещают вернуть. лНо поскольку сама обнова у них заняла год, а всё это время они просто были оффлайн, то, кажется мне, c# вернут не скоро.

... where `id` in (2, 4, 17, 74)

А чего ты ждал когда называл метод validate?
Обрати внимание, у тебя метод контроллера называется также как метод валидации в контроллере, который ты кстати вдобавок ко всему вызываешь из своего метода
Замени
public function validate
на другое название, должно быть либо store либо update
Ах да, и еще ты не наследуешь свой контроллер от базового, в этом тоже беда

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

Ну примерно так

var TemplateRow = (function() {
	var $container;
	var $containerImages;
	var $containerSongs;
	var $containerText;

	this.create = function() {
		$container = $("<div/>").addClass("single");
		$containerText = $("<div/>").addClass("text");
		$containerImages = $("<div/>").addClass("image");
		$containerSongs = $("<div/>").addClass("doc");

		$container.append($containerImages)
			.append($containerText)
			.append($containerSongs);

		return this;
	};

	this.setTextAsHtml = function(value) {
		$containerText.html(value);
		return this;
	};

	this.addImage = function(url, title, alt) {
		var $block = $("<div/>").addClass("postimage");
		var $image = $("<img/>")
			.attr("src", url)
			.attr("title", title)
			.attr("alt", alt);

		$block.html($image);
		$containerImages.append($block);
		return this;
	};

	this.addSong = function(id, name) {
		var $block = $("<div/>").addClass("song");
		var $blockId = $("<div/>").addClass("numsong").text(id);
		var $blockName = $("<div/>").addClass("namesong").text(name);

		$block.append($blockId).append($blockName);
		$containerSongs.append($block);
		return this;
	};

	this.getContainer = function() {
		return $container;
	};

	return this;
});

$.each(data, function(index, element) {
	var container = new TemplateRow;
	container.create().setTextAsHtml(element.text);

	$.each(element.image, function(imageIndex, imageUrl) {
		container.addImage(imageUrl, "", "");
	});

	$.each(element.song, function(songIndex, song) {
		container.addSong(song.id, song.name);
	});

	container.getContainer().appendTo("#articles #innerarticles");
});

Первую часть вопроса удалось понять по комментам, вторую не допер

Добрый вечер!
Вы также должны заботиться об уникальности ваших slug ссылок, если вы собираетесь по ним доставать записи из таблиц и лучше бы вы посмотрели в сторону готовых библиотек для этих нужд, например: eloquent-sluggable, laravel-sluggable

Почему в мутаторе обращение к $this->title? В документации разве так написано?
Лучше читайте про события моделей и обсерверы.

По вопросу №1: настоятельно рекомендую разобраться в основах Composer'а и PSR-4, ибо это базовые понятия в современной PHP-разработке.

Чтобы автоматически подрубалось всё что нужно

А что нужно?

По вопросу №2: что за класс Response? Судя по названию, это представление ответа на запрос, тогда не понятно, почему вы куда-то хотите его передать и откуда в нём какие-то данные, которые куда-то надо загрузить.

P.S. Возьмите за правило: один топик на Тостере — один вопрос.

Первое: интерфейсы принадлежат не уровню реализации, а уровню использования.
Что значит?
У вас есть проект самолета.
Есть транспортная компания перевозящая грузы.
Есть пассажирская - соответственно перевозящая пассажиров.
у транспортной есть некий шаблон под названием транспортное средство. Все что подпадает под этот шаблон может компанией использоваться.
У пассажирской - все что подпадает под шаблон "средство перевозки пассажиров"
Т.е. по большему счету им не важно что будет самолет или автобус.
Вы хотите, что бы ваши самолеты использовались. Вам нужно реализовать интерфейс (шаблон использования) грузоперевозчик. Для одной компании. Для пассажирской вы можете реализовать шаблон пассажироперевозчик.
Т.е. интерфейс это некая договоренность, способ использования. И он лежит не на уровне библиотеки (т.е. на уровне реализации класса), а на уровне более высокой логики. (транспортное средство)
Интерфейс становиться неким шаблоном между двумя частями системы. Он достаточно стабилен. Из этого мы получаем разделение большой системы на две части. и соответственно мы можем разрабатывать раздельно эти части, не боясь что-то нарушить в другой части.
По части использования. Интерфейсы очень широко применяются. Даже в небольших проектах. Они разбивают на части систему, что очень полезно для построения прозрачных моделей. Также это дает возможность работать нескольким людям над одним проектом (или одному. Над частями проекта)
Это дает возможность Сосредотачиваться на логике проекта, оставляя реализация на "позже" - делая простые затычки для тестирования.
В примере с животными. Есть зоопарк где животные. По большей части они работают с интерфейсом животные (кормят, ограждают и т.е.) И все что подпадает под интерфейс животное легко там содержится. Если им привезти новое животное, они его посадят в клетку, будут кормить и показывать детям. Т.е. Животное - это скорее договоренность, а не сущность. (для зоопарка)

Приведу самый часто встречаемый случай в моей практике, где нужны интерфейсы.
Есть база пользователей, и у пользователя есть адрес, который состоит из нескольких полей (страна, регион, город, улица, дом, квартира, этаж и т.д.). Адреса хранятся в отдельных таблицах, но привязаны в конкретному пользователю, кстати адресов у пользователя может быть более одного, например, адрес прописки, фактический адрес проживания или адрес доставки и т.д.
Также у пользователя есть телефоны, которые тоже хранятся в отдельной базе данных, там хранится какой телефон основной, какой оператор, какая страна, есть ли подписка на рассылку SMS.
А еще у пользователя может быть должность, которая тоже состоит из нескольких полей, но зависит типа должности.
Таким образом когда создаем нового пользователя, тогда используем интерфейсы адресов, телефонов, должностей.

Две последние буквы SOLID для вас ( https://en.wikipedia.org/wiki/SOLID_(object-orient... ). Вообще рекомендую прочитать всю эту статью, она очень дельная (+ все ссылки из секции Design and development principles). Использование этих принципов позволят писать относительно неплохой код даже без понимания (которое приходит с опытом обычно). Кстати, в этих статьях должны быть ссылки на книги по ОО-проектированию (ну в любом случае они неплохо гуглятся).
Необходимость в интерфейсах и абстрактных классах возникает в основном в больших коммерческих проектах. Использование интерфейсов позволяет понизить связанность компонентов системы (их уровень знания друг о друге), что, в свою очередь, позволяет легче модифицировать систему, работая в команде. Например пишет один программист какой-то класс для запуска задач и делает у него метод, который принимает интерфейс IRunnable (возможно с одним методом run()) и описывает контракт (правила, как метод run() должен себя вести). После этого, любому другому программисту достаточно будет реализовать интерфейс по контракту и он сможет пользоваться классом для запуска задач. При этом, класс для запуска задач вообще понятия не имеет о том что он запускает, ему важно знать, что это можно запустить, и любому другому классу нет необходимости знать, как его запускают, достаточно просто реализовать метод.

laravel 5 - оптимальное сочетание быстроты входа и более-менее правильной архитектуры. Плюс наибольшее количество материалов для обучения и активное сообщество. Я бы рекомендовал его.
yii2 сейчас морально устарел, можно потыкать если хочется что-то быстро cделать и вы почему то против laravel.
symfony 4/zend expressive - можно смотреть если вы уже сделали пару блогов (поработали 3+ месяца с laravel/yii), они имеют чуть больший порог входа.
Рекоммедовал бы так же материалы из https://habrahabr.ru/company/zfort/blog/345462/ "Пишем PSR-7 фреймворк".
Это именно то, что бы я дал новичку чтобы он понял какие идеи сейчас лежат в фреймворках

CodeIgniter лучше изучить для начала, у него низкий порог вхождения - самое то новичку.
Поймешь, что такое MVC.

Лично я брал бы сразу 3 - Yii, Symfony, Laravel. Все 3 во многом похожи, у всех 3 есть существенные и даже принципиальные различия, плюс и минусы. Да, это немного замедлит начальный этап. Но польза будет огромная.

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

Нам понадобится LINQ
Ход мысли такой:

1. Берем список ссылок
   
2. Кастуем каждую к типу Uri
   
3. Забираем у каждой левую часть
   
4. Делаем Distinct колеекции
   

var urls = new List<string>() {"https://mysite1.com/", "https://mysite2.com/",
                                           "https://mysite3.com/", "https://mysite4.com/",
                                           "https://mysite1.com/test", "https://mysite2.com/test",
                                          "https://mysite5.com/", "https://mysite5.com/234234/23434/sdfas"};
            
 List<String> uris = urls.Select(x => new Uri(x).GetLeftPart(UriPartial.Authority)).Distinct().ToList();
 uris.ForEach(x => Console.WriteLine(x));

Список большой?

Вот адская регулярка, которая выбирает вообще любые ссылки из любого текста.
Вам нужны группы с 1-й по 6-ю.

((https?|ftp):\/\/)?([a-z0-9+!*(),;?&=.-]+(:[a-z0-9+!*(),;?&=.-]+)?@)?([a-z0-9\-\.]*)\.(([a-z]{2,4})|([0-9]{1,3}\.([0-9]{1,3})\.([0-9]{1,3})))(:[0-9]{2,5})?(\/([a-z0-9+%-]\.?)+)*\/?(\?[a-z+&$_.-][a-z0-9;:@&%=+/.-]*)?(#[a-z_.-][a-z0-9+$%_.-]*)?

Тесты здесь

.

Не знаю какая у вас бизнес-задача, но я бы реализовал примерно так - последовательно перебирал элементы списка и проверял на наличие в массиве уникальных. если элемент есть - идем дальше, если нету - добавляем. Проблема в том что при больших объемах данных такой алгоритм сильно тормозит. на поздних итерациях поисковые операции будут занимать много времени. Это решаемо конечно, но уже более сложными алгоритмами построения массива уникальных записей.
Как вариант - сделать через LINQ - GroupBy по тексту.