Daria Motorina

В коде много ошибок
1) в ajax не добавляется get-параметр, выходит просто /events?9, а не /events?id=9
2) wildcards в роутинге ларавеля не действует на обычные гет параметры, поэтому нет смысла указывать айди как /events?{id}, или формировать урл как /events/9, тогда wildcard будет иметь смысл.
3) следуя из п. 2, никакой id не будет автоматически передан в экшен, нужно его самому достать из объекта запроса. Объект запроса можно автоматически инжектить в аргументы экшена

https://laravel.com/docs/8.x/blade#layouts-using-t...
extends для header, footer и других блоков это нелогично - достаточно создать основной шаблон, экстендить его и через section дополнять контентом

Скорее всего она под капотом тянется здесь

$sub_task = Task_1st_kind::where('sub_task', $sub_id)->first();

Потому что вытягивает объект со всеми полями.
Причины:
1) в базе нет колонки id
2) id это не primary key в таблице
3) у таблицы нестандартный primary key, это нужно указать в классе модели

Смотрите, сейчас у Вас уже написан вывод результатов в шаблон admin/test.blade.php в контроллере

public  function  search(Request $request)
    {
        $name = $request->input('Name');
        $item = DB::connection('555')->table('Shop_Goods')->where('name', 'LIKE', '%' . $name . '%')->get();


        return view('adminka.test')->with($name, $item);
    }

Тут нужно только создать этот шаблон, добавить в него инклуд секций и базового лейаута и вывести $name и $item в шаблоне.

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

Нет. Фреймворк тут играет последнюю роль. 10000 человек в день это немного, меньше одного запроса в секунду в среднем, надо смотреть на нагрузку в пике. В любом случае надо анализировать слабые места - запросы к базе, количество веб серверов для обработки запросов, возможность кеширования и асинхронной обработки...
UPD. У Вас в вопросе написано и пиковая нагрузка 10000, и 10000 за день, что в итоге?))
Все равно результат нужно сводить к предварительному профилированию и только потом к тюнингу серверов или рефакторингу

Правильно нормализуйте базу данных, а следом за ней и управление файлами:
1) таблица users, таблица files с привязкой к юзеру, в files - id, user_id, original_name, extension(необязательно), abs_path. Имя файла нужно хранить по какому-то правилу, чтобы не было конфликтов.
2) На стороне приложения нужно иметь экшены CRUD файла (read на свойства файла в таблице и отдельно read как просмотр файла или отдача на скачивание).
3) Не нужно удалять все файлы, нужно на фронтенде выводить элементы управления на все файлы пользователя, которые будут вызывать экшены удаления файлов (условно список кнопок, нажатие которых вызывает экшен удаления конкретного файла).
Часть из это у Вас уже есть, просто действительно сумбурно написано, надо отрефакторить так чтобы каждая вещь отвечала за свою логику, а не вперемешку, как сейчас

Базовая таблица "документ" + таблица "свойства документов". Валидация свойств на уровне класса модели. Работа с конкретными документами - через model scope.

Нет, через blade нельзя, создайте отдельный экшен для получения услуг по id заказчика, делайте на него запрос ajax'ом и в респонсе на стороне фронта рендерите селект с новым набором услуг

Storage это фасад для Filesystem, в Filesystem метод put описан так, получается это обертка для file_put_contents, $contents это просто данные, которые надо записать в файл)

Посмотрире решения из этого issue на гитхабе
https://github.com/JeffreyWay/laravel-mix/issues/2206

Фронтенд, личный кабинет и админка - разные по логике модули, для независимого развития кода больше всего подходит пункт 1. Общую логику всегда можно вынести в сервисы/хелперы и через DI передавать контроллерам

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

Модель это не универсальный фасад для доступа к базе, подход "одна модель - одна таблица" в большинстве случаев правильный, если разные таблицы связанны отношениями one-to-one, one-to-many, many-to-many, то для этого у ларавел тоже есть средства для получения связанных данных