lolrofl01

Вредонос:
1. Выполняет все операции и сразу удаляется из dom.
2. Чекает переменную wsjwa573 (на нее много чего завязано, хз зачем, нет времени вычислять).
3. Проверяет, если ли в браузере посетителя pushmanager, notification и fetch apis.
4. Редиректит на вредоносный сайт по условию.
5. Ставит обработчик ontouchstart по клику и условию.
Итп.

Прошерстил все файлы проекта - не нашел никаких подключений. Ни по одному из ключевых слов не находится ничего подобного.

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

Livewire https://livewire.laravel.com/

Как у него с SEO?

Отлично. Как в обычном html

только ajax запросы по каждому пуку появляются

При первой загрузке страницы она отдается в чистом html. Аякс запрос будут уже потом идти. Так что поисковик всегда будет получать чистый html.

На бэке возвращать отрендеренный шаблон и вставлять его на клиентской части вместо текущего.

Получится тот же самый Livewire, только хуже.

App\Http\Middleware\VerifyCsrfToken
там добаьте в except

например, protected $except = [
'mobile/*',
'news/articles',
];

/* Правило для li, у которых атрибут style НЕ содержит подстроки list-style-type */
li:not([style*="list-style-type"]) {
  /* свои стили */
}

Заменить на $request['content']

Вообще мне не понятно, для чего сделан объектный доступ к переменным запроса. Возможно это используется внутри, или наследие прошлого. Но использовать его в приложении - так себе идея. Есть методы get(), input(), реализован ArrayAccess.

$txt = preg_replace("#<a href=\"([^\"<>]+)\">\1</a>|(https://[^<>]+)#", "<script .... /script>", $txt);

Да пожалуйста

для слов достаточно банального [A-Z]+
для фраз чутка сложнее.

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

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

А уж как подгорает от криптовалют....

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

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

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

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

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

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

Цену в долларах на момент оплаты по курсу "продажа" (покупка для вас) у Сбера

Вы учтите, что ваш контрагент тоже не знает, куда рухнет рубль в ближайшее время, и нежданчик в +150% ему может быть просто не по карману, так что от жесткой привязки к баксу, например, он может просто отказаться и пойти искать более сговорчивого исполнителя.
Туроператоры, например, которые жестко зависят от валют в своей работе, во времена высокой волатильности предусматривали пункты типа "стоимость услуг может быть пересмотрена при росте курса доллара свыше 5% от курса на момент заключения договора".

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

Согласно описанию формата, порядок элементов внутри объекта не существует (вернее, не определён), и его поддержание не гарантируется. В отличие от массива.
Так что если порядок важен, то каждая запись должна быть преобразована в отдельный объект, а все они - сложены в массив в нужном порядке, т.е. JSON должен выглядеть, например, так:
'[{"a":1}, {"b":2}, {"c":3}]'

Я его превращаю в json (json_encode), и кладу в бд.

Покажите точно, как выглядит этот JSON.
Покажите точный CREATE TABLE таблицы, в которую кладёте.
Покажите, как точно выглядит в таблице положенное туда JSON значение.
Покажите точно это же JSON значение после обратного извлечения.

Да, всё это - для одного и того же JSON.

Мое имхо.
Продвижение по регионам штука сложная.
Для начала нужно решить, что именно будет являться контентом для продвижения по региону.
Это может быть:

а) при выборе региона показываются все те же страницы что и на основном сайте, но добавляются динамически: url, заголовки и тексты, метатеги, alt в картинках, телефоны если нужно и другой контент. Фактически, выбрал из списка городов "Казань" - перешел на site.ru/kazan и там уже свой контент, оптимизированный под Казань. При перемещении по сайту структура url отталкивается от региона "/kazan/odegda". Этот вариант позволяет продвигаться по низкочастотным запросам, и в целом по большому числу запросов, но сложный в реализации, больше подходит для самописных проектов, плодит кучу ссылок, сложнее отслеживать и управлять проектом. Пример в реализации https://bamper.by/zchbu/gorod_brest/

б) просто отдельные странички типа "купить джинсы в казани", "купить джинсы в самаре" и т.п.
оптимизируются по частотным запросам, представляют собой обычный текст.
Это простой вариант, его делают очень многие, в том числе сами сео студии лепят вроде "продвижение сайта в минске," продвижение сайта в борисове" и т.п. И это тоже работает, причем примитивно в реализации. Но ограничено число запросов. Мне этот вариант нравится, рабочий.

в) нечто среднее.
например, чтобы не заморачиваться с программированием, создаются обычные категории товаров в CMS в виде регионов, типа "Казань", "Самара" и т.п. В общем каталоге не выводятся, чтобы не отвлекать людей. Имеют свой URL, товары, тексты и теги. То есть получается не просто страничка, а целая категория с товарами, но заточенная под запросы из региона. Причем сделанная штатными средствами того же Opencart без привлечения программиста. Тоже имхо нормальный вариант.

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