Nikolino

Потому, что выходит за область видимости цикла v-for. Там нет переменной perfume) Переменная perfume доступна только внутри тега <li>, к которому применена директива v-for. При чем на любом уровне вложенности внутри , но не вне.

Для задания шаблона поиска вы используете двойные кавычки. В этом случае, в строке заменяются все служебные последовательности. Одной из таковых (не известных мне) является \1, доказательство:

php > var_dump("\1", '\1', "\g1", '\g1', "\\1");
string(1) ""
string(2) "\1"
string(3) "\g1"
string(3) "\g1"
string(2) "\1"

Как решение:
- дважды экранировать (\\1);
- использовать одинарные кавычки.

Поиск там достаточно умный:

В чем недостатки такого решения?

Помимо отсутствия транзакционности в коде (о чём уже упоминали выше):

1) Нет ключа на thread_id (желательно foreign)
2) Типы в INT, вместо UNSIGNED INT
Т.к. это MySQL, судя по вопросу, то:
3) Нет указания на collation таблицы (желательно utf8mb4)
4) Нет указания на движок таблицы (транзакции есть только в InnoDB и их нет в ISAM, MyISAM, Archive, Memory, etc.)
5) Нет уникальности голосов (т.е. votes), как следствие - таблица денормализованная и подсчитывать так голоса - крайне глупо. В нормальном мире это делается отдельной таблицей с привязкой по comment_id и уникальным ключом на comment_id + user_id.
6) Так как это комментарии, то использование varchar(255) для поля text - глупо. Нужен TEXT или LONGTEXT.
7) Отсутствуют поля даты создания и редактирования, что в будущем не позволит строить статистические данные или расширять функционал (разрешать менять текст комментария только в течении 5ти минут, например). На это надо закладываться заранее.

Это что касается структуры таблицы. Теперь по коду:
8) Сервис-локация (класс App), вместо нормального DI - это жесть. Скрытые зависимости говорят о невозможности тестирования такого кода.
9) "Магическая" константа 'comment' говорит о том, что потом такой код нормально не отрефакторить. Т.е. переименовываешь внутри что-то, а потом получаешь кучу ошибок и придётся лазать по коду и везде выгребать этот "get('comment')". И не дай бог где-то они получаются как-то иначе. Работы ещё на пол дня.
10) Метод getById говорит о том, что сущность должна возвращаться всегда. Однако, может так случиться, что её по указанному id просто не найдётся. Как следствие - нет нормальной обработки ошибок.
11) Мутабельное поле votes у comment (т.е. имеется прямой доступ к нему). Это говорит о том, что сущность очень сильно связана с БД, а значит любой рефакторинг таблицы ведёт к полному перелопачиванию всего кода.
12) Нет обработки ошибок во время сохранения сущности.
13) Метод vote - не лучшее название. Оно переводится и как глагол "голосовать" и как существительное "голос", что может запутать. Я бы переименовал в addVote. Хотя и так тоже норм.

Это всё, что касается вопроса "в чём недостатки такого решения". Ответ - почти на каждой строчке косяк.

Если есть вопросы - задавай, могу чуть поподробнее расписать что-либо.

Но вторая и последующие очереди не добавляются в jobs

Вот тут я мозг сломал. Обычно джобы в очередь ставят, а не очереди в джобы...

https://github.com/laravel/framework/blob/5.7/src/...

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

Это значит если вы осилили один то достаточно легко сможете писать на другом