Daria Motorina

Через PHP никак, это ведь серверный язык который обработается еще до показа странички. Только через JS мб

т.к. с Coockie я раньше не работал

ну так может загуглить php cookie?
Много ума не нужно, просто перезаписать куку с нужной вам датой

Трудно сказать, поскольку код мягко говоря не очень. Включите вывод ошибок в php и смотрите в лог.
Может быть не работает $('#nones').load("get.php"), посмотрите oncomplete либо втыкайте в консоль.

У кого какие секреты по поддержанию "боевой" формы котелка? Что едите и пьете для более эффективной интеллектуальной работы?

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

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

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

а лучше все выше перечисленное

Чем это хуже подхода - когда вся логика распологается в сервисах, и в целом чем плох такой подход?

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

Сервис или какая-то иная часть приложения - это часть именно конкретного (вашего) приложения, то есть что-то, что написано и предназначено конкретно для данного приложения, а не для универсального решения общих задач. Пакет - логическая противоположенность этому.

Не стоит забывать, что чем более универсальным является какое-то решение (аки "швецарский нож") - тем хуже оно решает конкретную задачу. Это же полностью применимо и к тому, что описываете Вы. Если Вы будете делать некие универсальные решения и складывать их в пакеты:
1. Потеряете выраженность решений
2. Потеряете производительность
3. Получите на обслуживание много приложений (пакетов) вместо одного конкретного

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

"Не гадить в код" - это искусство и опыт, которые никакой "пакет" не заменит.

https://github.com/barryvdh/laravel-ide-helper

судя по распечатке массива, где-то ошибка: функция предполагает, что в неё передаётся хэш ( то есть массив, у которого ключи - значимы), а у вас приведён список ( ключи не несут информации ).
Может, поэтому и непонятен результат работы функции. $arr должен быть таким:

$arr = [685 => [
    'id' => 685,
    'title' => 'Комплектующие к Apple',
    'parent' => 0
  ],
  691 => [
    'id' => 691,
    'title' => 'Запчасти к iPad',
    'parent' => 685
  ],
  692 => [
    'id' => 692,
    'title' => 'Запчатси к iPhone',
    'parent' => 681
  ]
];

Плюс в последнем элементе подозрительное значение у ключа parent ( больше подходит 685 ).

- метод контролера один, но используется GET переменная «json», скажем. Добавляем блок if, если переменная присутствует, то отдаем json, иначе отдаем view. Но тоже, как-то не кошерно смотрится…

Это по тому что это должны быть разные контроллеры, один для вебморды, один для API/app.

Вторую — самая понятная и простая для новичка.

Сейчас есть фактически 4 энтепрайз платформы (связки систем):

1. Java платформа (Java/Scala/Kotlin). Это не просто язык, это целая экосистема на которой строят проекты. Главным образом используется в финтехе, логистики и телекомуникациях (90% всех вакансий будет туда). Тут в любом случае начинаешь с Java, а остальное учишь по необходимости
   
2. .Net платформа (.net/.net core). Платформа от майкрософт, где главный рабочий язык c# (но есть и visual basic). Сейчас активно развивается, но кто его знает, что с ней в итоге будет (т.е. стрельнет и отберет долю Java или останется так, как сейчас). Госкомпании, реальный сектор, автоматизация производства
   
3. Php (Главным образом Symfony). Чаще всего это компании, которые начинали с каких-то небольших проектов, но потом выстрелили и стали зарабатывать хорошие деньги (JivoSite/Скайенг/PetShop итд, ну понимаешь впринципе размер компаний и их профиль). Так как изначально все было на PHP, то и стали переходить со всяких самописов систем (а некоторые так и не перешли типа Байду) и Zend Framework на Symfony. Это больше про Россию и Европу, в США это не признают.
   
4. Ruby/Python системы, где ключевые элементы переписываются на c++/go. Чаще всего практикуется такое у буржуев. У нас такое разве, что у yandex/mail/rambler/wargaming. Если планируешь работать в РФ, то это наименее перспективный стек в плане карьеры. Стоящих предложений на этот стек реально мало