Тимофей

$this->belongsToMany(Categories::class, 'category_post','category_id','post_id');

Во вторым аргументе указывается название таблицы связи. Или вы неправильно её написали в методе, или в вопросе (category_post или post_categories?). А последние 2 аргумента можно вообще опустить - ларавел сам додумается в данном случае (то есть просто возьмёт название класса + '_id').

public function category() { ... }

Стоит назвать categories, а то потом сами запутаетесь. Связь же многие-ко-многим, а название метода в ед. числе.
В остальном связи правильно прописаны.

А вот в контроллере проблема - метод findOrNew нужен не для того, чтобы в зависимости от наличия аргумента отдавать новую или существующую запись. Его задача в том, чтобы попытаться найти запись с переданным ID, и если найти таковую не удалось - вернуть свежий экземпляр. То есть совершенно логично, что он ругается на отсутствующий аргумент, так как он ему необходим для работы :)

Ещё момент - вы пытаетесь вызвать sync, хотя на момент вызова пост ещё может быть не создан. По причине того, что у свежесозданной записи ещё нет идентификатора, sync, очевидно, тоже упадёт с ошибкой, то есть предварительно нужно вызвать $post->save(). А ещё лучше saveOrFail(), который сразу кинет исключение, если не удалось сохранить запись.

Ну и Александр тут уже написал, что хорошая мысль разделить на 2 метода создание и редактирование элемента. По остальным вопросам, как, опять же, уже упоминалось, нужно читать документацию. У ларавел она очень понятная и хорошо структурированная (хотя и многого не охватывает, но для начала вполне достаточно информации).

include как бы намекает, что можно вставлять куски конфигов из отдельных файлов. Создаешь файл с тем, что нужно, и просто пишешь include my-awsome-config-file.

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

Потому что при наследовании нельзя изменять доступность функции. Если нужен синглтон, то ты по определению не сможешь унаследоваться от класса с открытым конструктором. А сделано это для того, чтобы объект любого класса, унаследованного от данного, гарантированно обладал всеми функциями родителя, в частности и возможностью создания новых объектов. Иначе теряется смысл наследования.

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

trait ClosureConfigurable {
    public function configureWith(Closure $closure) {
        $closure($this);
    }
}

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

Если есть возможность писать функции без классов, то почему бы и нет? Это ж не Java или C#, где просто физически такой возможности нет, поэтому, очевидно, там так никто не делает, а все используют классы-обертки.

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

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

Лично я вижу только одну проблему в функциях - возможные конфликты имен. Но и эта проблема легко решается с помощью namespace'ов.

По поводу передачи параметров по ссылке - если смущает запоминание порядка передачи, то можно передавать ассоциативный массив, значения в котором будут записаны по ссылке типа такого:

$filter -> fire(array('arg1' => &$arg1, 'arg2' => &$arg2));

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

Тут важный момент есть: некоторые соцсети не дают доступа к мылу (например, VK). Да и может быть ситуация, когда разное мыло на соцсети и на сайте, но пользователь один. Лучше после того, как была произведена авторизация у провайдера, спрашивать e-mail (а лучше и пароль тоже) явно, но если провайдер предоставил e-mail, то просто подставлять его в соответствующее поле в форме. Если пытаешься использовать существующее мыло, то выдавать ошибку и предлагать сначала войти, а потом привязать аккаунт в личном кабинете (типа как на хабре).
Ну а в базе хранить пары провайдер-UID либо прямо в поле у пользователя, либо в отдельной таблице.

Можно, короче, по пацану сделать, вот так

$result = array_reduce($input, function($acc, $i) {
	if (isset($acc[$i['id']])) $acc[$i['id']]['num'] += $i['num'];
	else $acc[$i['id']] = $i;
	return $acc;
}, array());

// если нужен неассоциативный массив
$result = array_values($result);

В классе, реализующем ArrayAccess, в методе offsetSet отщепляешь левую часть ключа до точки, далее:
- Если у ключа не осталось правой части (то есть нет точек) - просто задаешь значение по ключу у $this -> collection (ну или как у тебя поле со значениями обозвано)
- Если осталась - при отсутствии значения по ключу инициализируешь его как new static
- Задаешь значение в дочерней коллекции по оставшемуся "хвосту" ключа

Ну и как offsetGet при этом реализовать, думаю, понятно.

Вообще лучше сделать это через __set, __get, чтобы не было некрасивых записей типа $obj -> set/getName, а просто обращаться к name так, как будто это поле объекта. Ну а sanitize нужно вызывать как static::sanitize. Только добавь к методу sanitize static. А, ну и обязательно нужно сделать PRIVATE $name, а то смысл инкапсулирования теряется.

Ну, если необходимость использования БД возникла на сайтах, которые написаны на PHP, то учи PHP)
Аналогично можно сказать про любой другой язык. БД сама по себе никаким образом не связана с языком программирования. Почти у каждого языка есть библиотеки, которые позволяют работать с БД. Да и сами эти БД бывают разные.

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

аще по*й
Сам тормознул на руби. Не спрашивайте, почему. Я сам не знаю. Очень долго выбирал, так как выбор равнозначный - есть и там, и там свои плюсы, свои минусы, но в итоге, как я и сказал выше: аще по*й.

Да зачем тут CMS! Тем более с админкой, подобной монстроподобному битриксу. Лендинг слишком прост для любой CMS. Тут можно обойтись легкой самописной админкой с http авторизацией. Для редактирования разметки, если это необходимо, можно взять какой-нибудь CKEditor. Сами тексты хранить в файлике, написать пару функции для внедрения этих текстов в нужных местах и все. Картинки - тупо файловым input, с ресайзом на сервере, если необходимо (ресайз картинок легко гуглится, его ручками писать нкобходимости нет), пути к картинам - в том же файле. Если админку покрасивше сделать хочется - Bootstrap.

Это не php в чистом виде, а какой-то шаблонизатор. Не уверен, что в нем можно добавить код для того, чтобы увидеть индекс товара. Можно попробовать заменить
{foreach $product->features as $f}
на
{foreach $product->features as $i => $f}
Но это может не сработать, если массив $product -> features индексирован не подряд, а, например, идентификаторами. С другой стороны индекс может оказаться информативным и можно будет написать что-то типа

{if $i == 'feature_with_link'}
<span><a href="">{$f->value}</a></span>
{else}
<span>{$f->value}</span>
{endif}

Вообще, чтобы что-то более конкретное подсказать, нужно более подробное объяснение. Выведи структуру массива $product -> features на экран через print_r (или var_dump).

Любая CMS общего назначения умеет все это. Возможно, с модулями, но тем не менее.