ant4 wrote: Можно скачать по отдельности архивы ядра и модулей распаковать и сравнить каждый по отдельности Smile

Вариант вполне нормальный, даже если там 50 папок и придется вручную качать нужные версии модулей, это не так уж прям много времени потребует, если не возиться с композером.
Еще вариант - просто удалить все htaccess внутри модулей (не вручную), там их быть не должно нигде, если только какие-то кастомные модули.

• Views+контекстный фильтр по nid и в нужном формате выводить результат.
• Кастомным модулем, так же, как в первом варианте принимать nid, выдавать результат

В 10ке есть встроенная миграция контента с 6/7 версии, можно ее попробовать для начала, дальше уже исходя из результатов, и насколько много останется того, что не смогло перенестись в 10ку.

Если все плохо с этим встроенным вариантом получится, то может проще будет из 6ки выгрузить контент в каком-то формате, а потом в 10ку его загрузить. Или же на 10ке сразу свои миграции писать.

Тему, модули, понятное дело, с нуля делать нужно.

max_input_vars

Открывать лог, смотреть конкретную причину 500 ошибки, исправлять, пробовать снова.

Можно по этой схеме сбросить, без почты - https://www.drupal.org/node/2778219

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

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

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

Если скрипт выполняется 1 раз, то при листании чего-то на ajax он выполняться второй, третий, n-ный раз не будет, и соответственно, элемент удален следующие разы не будет. Если при каждом ajax запросе это удаление должно происходить, то скрипт нужно каждый раз выполнять, а не один раз.
Про document.find уже писал, если вдруг обычный выбор элемента не работает.

Попробуйте вынести в функцию удаления за пределы кода, который 1 раз выполняется, чтобы при каждом ajax он срабатывал.

А если вместо .remove что-то другое делать - скрывать .hide или стилями бордер добавить, то это работает? Элемент на странице находится или нет?

VasyOK wrote: Так (?):

Да так, только лишние пробелы убрать нужно, чтобы лесенки не было.

Нужен ли once в js в конце - я не уверен, но и без него работает, вот полный вариант, можно попробовать через клонирование элемента:

По ссылке для друпал 10, а для 9ки, если весь депенденс приводить, то скорее всего, будет как-то так:
dependencies:
- core/jquery
- core/jquery.once
- core/drupal

Сам js, из реального проекта пример:

Использовать once в js.
В dependencies core/jquery.once нужен будет.

Во вьюсе группировку полей, для начала, можно попробовать применить.
Либо двумя вьюсами выводить.

Почему-бы не писать значение в базу, в куки, в сессию? Смотря где и сколько потом значение должно использоваться.

hook_form_FORM_ID_alter

А чем программный способ не подходит, если все-равно php в рулзах используется?

https://github.com/Bahlaouane-Hamza/I-Miss-You

В $commerce_order uid юзера вроде должен быть, дальше загрузить его, взять нужные поля, вывести.

Я бы context использовал в таком случае.

Порядок следования регионов и через css можно поменять, если структура следования позволяет - через order в flexbox. Или для мобил отдельное меню сделать и его показывать только мобилам.

Через theme_preprocess_html(&$variables) класс добавить можно, получить данные вьюса, например, так можно.

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

rules, срок жизни - поле типа дата, потом по нему снимать с публикации.