Алексей Уколов

-VALUES (':notification_type', ':operation_id
+VALUES (:notification_type, :operation_id

и т.д.

https://laravel.com/docs/10.x/routing#view-routes

Route::view('/advokaty', 'lawyers', ['profession' => 1])

Если вы хотите одним контроллером обрабатывать несколько похожих роутов, то определять значение вашей переменной нужно внутри контроллера на основании path. Передавать при описании роутов дополнительные параметры можно только во view, но не в контроллер.

По моим ощущениям в нише малобюджетных и ненагруженных проектов (условно интернет магазины и прочий малый бизнес) PHP сильно опережает ноду.

Node, действительно, конкурирует скорее с PHP, чем с Go. И тогда, когда Нода создавалась, у неё была киллер-фича, которой не было (в удобном и надёжном виде) в PHP - постоянно живущий процесс. Это делало создание websocket-сервера тривиальным делом и в реальных проектах она именно в таком виде и использовалась.
Ну а дальше нарастали уже три других кейса:

• Вам нужно сделать относительно простой сайт, который активно использует websockets - зачем туда тянуть ещё и PHP, когда можно всё сделать на одних технологиях?
  
• Вы уже знаете javascript и по какой-то причине хотите сделать бэкенд самостоятельно.
  
• Вы повелись на маркетинг нового супер инструмента (и вдобавок ещё обмазались NoSQL до кучи).
  

Понятно, что всё, кроме первого сценария - это скорее баловство, чем взвешенный выбор инструмента.

Есть множество дополнительных псевдоклассов, которые можно использовать. Например, :first-child.

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

Давайте для начала переведём это на привычные всем названия.
У вас таблица customers (А) со столбцами id и name, а ещё таблица orders (Б) со столбцами id и customer_id.

Таблица orders имеет внешнюю (по отношению к ней) связь: orders.customer_id -> customers.id. Таблица customers здесь выступает в качестве основной, поскольку именно она отвечает за то, какие id для orders.customer_id будут валидными, а какие нет. Т.е. "родительская" таблица это та, в которой хранятся "условия проверки" корректности значения в "дочерней".

В тексте вопроса же у вас, простите, какой-то винегрет из слов.

но потом подумал что это не правильно, т.к. номер заказа не может быть в родительской таблице

Вот это, например, вообще не имеет смысла, потому что никакого номера заказа тут и нет.

Вот они, красным подсвечены:


Это синтаксис PostgreSQL, а не MySQL - в это главная ошибка.

Постановка вопроса очень расплывчатая. У Битрикса, например, есть своя js-библиотека и определённые стандарты по работе с ней. Но, во-первых, до фреймворка она всё же не дотягивает, по моему мнению, а во-вторых, это во многом побочный продукт и на 95% Битрикс всё же про php, а не про js.

Но костыль это или нет - решать вам. Что скажете?

Скажем, что нам пофиг, что происходит в вашем коде ¯\_(ツ)_/¯

Но есть два точно некостыльных решения: View Composers и Service Injection.

P.S. Мы не теряем надежды, что когда-нибудь вы всё-таки прочитаете документацию по вашему основному рабочему инструменту.

Первый и самый важный шаг вы сделали — идите дальше. Смотрите что у вас в document.getElementById('id').value, потом что в document.getElementById('id'), если в value пусто.
Это называется "отладка" или "дебаг" и это примерно половина работы программиста.

выводит новую форму

Вангую, что в итоге у вас куча одинаковых форм и, соответственно, куча инпутов с id="id", что, естественно, недопустимо.

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

Никак — скриншот делает не браузер.

https://www.yiiframework.com/download
Вы очень-очень-очень плохо искали:

В запросе должен быть заголовок accept: "application/json".

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

Ну кривой у вас какой-то JSON получается. Не видя его мы вам ничем помочь не в состоянии.

.replace("]", "").replace("[", "")

Как минимум тут вы его портите, если внутри есть массивы.

.find((item) => (item.name = this.info)),

Здесь, явно, должно быть сравнение, а не присваивание.

Похоже, вам подойдёт Tampermonkey или Stylebot.