Aetae

Конкретизировать на что именно он вешает обработчики.
Не $('.button').click(...) который повесит на все .button на странице - и старые и новые, а $(container).find('.button').click(...), где container - родительский элемент нового добавляемого блока.

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

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

Для решения подобных задач два варианта:
1. require.context - который соберёт все файлы по предоставленному шаблону на этапе компиляции, и на этапе исполнения будет их подставлять. Этот вариант подходит если в папке img уже сейчас лежат все нужные изображения.
2. Если изображения на этапе компиляции отсутствуют, а появляются каким-то сторонним образом в паке потом, то require тебе тут не нужен(и не поможет), просто динамически подставляй пути к ним как в твоём первом варианте.
Путь от корня, если что, можно получить из __webpack_public_path__:
root: __webpack_public_path__,

<img :src="root + 'img/' + message.filename" :alt="message.filename"/>

Если changeTab не может примать async функцию(функцию возвращающую Promise) то никак. Ожидание действия пользователя - асинхронная операция. Тебе надо изменить логику поведения.

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

const result = await modal({
  title: ...,
  type: 'confirm',
  acceptText: 'Подтвердить',
  ...
})

Но если что-то колхозить, то условно так:

showPopup() {
  this.isDialogShown = true;
  this.pending = new Promise((resolve) => {
    this.discardChanges = () => resolve(false);
    this.saveChanges = () => resolve(true);
  });
},
async changeTab() {
  ...
  return await this.pending;
}

Ну или прямо так:

changeTab() {
  return new Promise((resolve) => {
    this.discardChanges = () => resolve(false);
    this.saveChanges = () => resolve(true);
  });
}

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

prettier - это одно, eslint - это другое, если у тебя prettier подключается через eslint, то настройки для него указываются скопом, условно так:

rules: {
    'prettier/prettier': ['warn', {
      semi: false,
      ...
      singleQuote: true,
      vueIndentScriptAndStyle: true,
      arrowParens: 'avoid',
      trailingComma: 'none',
      quoteProps: 'consistent',
    }],

Вот что тебе не понятно в ошибке?
Он тебе пишет "не могу прочитать appendChild у null".
Включаем голову и глаза на ней: откуда он хочет прочитать appendChild в данном месте?
Из document.body, так?
В каком случае document.body === null?
Очевидно, когда никакого body нет на странице.
Когда body нет на странице?
В тот момент когда кусок разметки с body ещё не прочитан.
Когда такое возможно?
Когда скрипт выполняется в head и не ждёт загрузки документа.

Из этого можно сделать вывод, что раньше ты пихал скрипт внутрь body и всё работало, а сейчас wp подключает его в head, как принято.
Соответственно, тебе либо надо найти как пихать скрипт в body в wp, либо, что лучше, дожидаться в скрипте загрузки документа(DOMContentLoaded).

https://vitejs.dev/config/server-options.html#serv...
Буквально первый параметр сервера в vite.

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

По-хорошему - делаешь ещё один массив(через usememo) с уже разложенным как надо значениями и уже с ним работаешь.
Но в целом substring каждый рендер даёт пренебрежимо мизерные накладные расходы, а вся идея React: "хреначь сейчас, оптимизируй потом(никогда)", так что делай как хочешь.)

У тебя в тегах вебпак, а значит тебе нужны именно его алиасы.

Если ты используешь cra, то придётся костылить, через craco или подобное.

В первом случае ты сортируешь уже отсортированный массив повторно(при каждой сортировке начальное состояние разное), во втором ты сортируешь каждый раз новый(начальное состояние одно и то же).

Использование Math.random в sort в любом случае не даст нормального распределения, т.к. под капотом используется определённый оптимизированный алгоритм сортировки, к тому же браузерозаивисимый и разный для разных случаев.
Как это всё влияет на конечный результат - одному богу известно (или дотошному математику, который засядет с сырцами браузера и распишет километровые формулы, да).
Если нормальное распределение получилось на практике - это совпадение, а не гарантия, что так и будет впредь.

Факт в том, что не надо использовать метод sort ни для чего, кроме его предназначения - детерминированной сортировки.

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

о какой рендер функции идет речь?

render-function

Это более низкоуровневый вариант работы с vue, вместо использования <template>.(под капотом <template> компилируется в render-функцию)

Render-функцию можно возвращать из setup, можно класть в свойство render.
При script setup, можно сделать так:

<template>
  <div>
    <render/>
  </div>
</template>

<script setup lang="ts">
  import { h, useSlots } from 'vue'

  const slots = useSlots();
  const render = () => {
    return h('div', slots.default());
  };
</script>

Но не нужно в подавляющем большинстве случаев. Мешать всё в одну кучу - весьма опасно.

Одинаковая структура при разных реализациях - это больно и малореально. Существуют css\html-only дизайн системы, которые можно брать и реализовывать на любом фреймворке, но это тот ещё геморрой без особого выхлопа.

Мне кажется вам стоит решить чего вы будете-придерживаться впредь, а что легаси, и вынести таки все компоненты одной актуальной версии(vue2 или vue3) в библиотеку, скомпилировав её в режиме web-components. Веб компоненты вы сможете подключать куда угодно, ценой лишних 100кб на непрофильный vue-runtime в случае несовпадения.

Никаких setTimeout точно.
Просто при каждом поступающем сообщении создаёте задачу на временную метку(можно с помощью совета Станислав Макаров) если такой ещё нет, которая в указанное время запросит все записи с такой меткой и выполнит с ними нужное действие.
Метку и, соответственно, запрос можно создавать с округлением в размере допуска.
В базе естественно всё это дело надо индексировать и складывать для удобства таких запросов.

Не надо ничего никуда вставлять.
eval(res.data.notification.FRONT_SCRIPT)

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

Во-первых: не работайте с html через регулярки.
Во-вторых: см. во-первых.
В-третьих: `(?<=>)(${letter})(?=<)`

Ошибка в том что файл у вас читается как js, а не как ts. Разберитесь с конфигами.

Ещёб чужие функции мне поток останавливали.)
Нет, низя. И слава богу.

Не используйте localStorage напрямую, напишите минимальюную обёртку-hook, положите в context или используйте одну из 100500 готовых библиотек для store в react.

type Extensions = {
  Category: typeof LayoutMenuCategory;
  Item: typeof LayoutMenuItem;
};

Иначе оно для ts может быть также и undefined, а undefined - то, что написано в ошибке.