Finsh

Распечатайте dd($request) это не массив и не коллекция. Чтобы получить содержимое $request, надо обратиться к его методу all(). Очень велика вероятноть, что вы не совсем правильно передаете данные, вангую, что там не массив.

В body вы выводите ячейку контента, который будет доступен для всех страниц, Вам нет необходимости добавлять метки для всех страниц
Чтобы получить доступ к other_news, поступите так же как и с news, но так делать не стоит. Обычно эту ячейку называют content и используют её для всех страниц

@extends('layouts.app')
@section('news')
Новости
@endsection
@section('other_news')
Другие новости
@endsection

В том, что Ваш подход не знает слов гибкость, сопровождение, да и много других он тоже не знает. За последние пару лет работал на 3-х проектах, ни один проект не имел только одной бд. Данные хранились в 2-3х бд, тянулись по апи из сторонних сервисов, в общем бд никогда не ставилась во главу стола. Представьте себе ситуацию, вот вы пилите 2-3 года проект, и тут вам заказчик сообщает, что ему кровь из носу надо переехать на другую бд или надо дополнительно тянуть данные и обрабатывать из иного хранилища, поставить поисковый движок. Вы будите дублировать всю логику? Да и потом, в больших проектах, обычно бд является первым узким местом, наваливая на бд ещё и логику Вы делаете это место ещё более узким. Сейчас более интересен подход не данные ферст и уж тем более никак не бд. Лучше посмотрите на DDD подход, Эрик Эванс вам в этом в помощь.

Взять Symfony.
Только вот серьёзно, зачем делать из отвертки дрель, когда она уже есть. Вы думаете, что это будет быстрее? Вы думаете что это будет дешевле? Laravel прекрасен для своих, средних, задач, для "enterprise" берите Symfony.

любой хостинг с PHP 5.6

Пилим CRM на Angular2, Ionic2. Всем довольны.

Разбейте проект по модулям(в зависимости от симантики сущностей), в каждом модуле пусть будет своя папка с сервисами. Так будет больше порядка и удобнее работать. На взаимоотношения с одной сущностью создавайте один сервис.

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

это не уникальная разработка, она не создает ничего принципиально нового.

И что же вы собрались патентовать, интерфейсики?

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class IndexController extends Controller
{
    public function index(){

    	$namesite = 'МУЦА';
    	//$descsite = 'Данная информация должна быть заменена.';


    	//return view('index')->with(['namesite'=>$namesite,'descsite'=>$descsite]);

    	return view('index',['namesite' => $namesite])->with('namesite',$namesite);
    }	
}

Во вьюхе выводите

{{ $namesite }}

В Kernel надо прописать Ваши команды No scheduled commands are ready to run.

Vendor трогать запрещено федеральными и региональными законами всего сущего!
Если мне не изменяет память, то в 5.3 для разворачивания AdminLTE надо опубликовать фаилы пакета.
php artisan publish

Докуметация
Курсы от разработчиков
И бонусом - подобный вопрос на тостере

SELECT * FROM forc LEFT JOIN prod ON prod.id = forc.id