ant4 wrote: Можно скачать по отдельности архивы ядра и модулей распаковать и сравнить каждый по отдельности Smile
Вариант вполне нормальный, даже если там 50 папок и придется вручную качать нужные версии модулей, это не так уж прям много времени потребует, если не возиться с композером.
Еще вариант - просто удалить все htaccess внутри модулей (не вручную), там их быть не должно нигде, если только какие-то кастомные модули.
В 10ке есть встроенная миграция контента с 6/7 версии, можно ее попробовать для начала, дальше уже исходя из результатов, и насколько много останется того, что не смогло перенестись в 10ку.
Если все плохо с этим встроенным вариантом получится, то может проще будет из 6ки выгрузить контент в каком-то формате, а потом в 10ку его загрузить. Или же на 10ке сразу свои миграции писать.
Залезть в код и дописать передачу того, что нужно.
Если поддержки у модуля все-равно нет, а его обновлений с большой вероятностью тоже можно уже не ждать, то это проще всего.
Страница могут быть сделана на модулях, типа panels, context, тогда искать в них.
Блок может программно подменяться, генерироваться, формироваться - тогда искать в используемой теме или модулях.
Страница может быть собрана разными способами, а не видя сайта, точный ответ дать трудно.
Для разовой редактуры проще обратиться к тому, кто в этом понимает, чем самостоятельно разбираться.
Если скрипт выполняется 1 раз, то при листании чего-то на ajax он выполняться второй, третий, n-ный раз не будет, и соответственно, элемент удален следующие разы не будет. Если при каждом ajax запросе это удаление должно происходить, то скрипт нужно каждый раз выполнять, а не один раз.
Про document.find уже писал, если вдруг обычный выбор элемента не работает.
Попробуйте вынести в функцию удаления за пределы кода, который 1 раз выполняется, чтобы при каждом ajax он срабатывал.
По ссылке для друпал 10, а для 9ки, если весь депенденс приводить, то скорее всего, будет как-то так:
dependencies:
- core/jquery
- core/jquery.once
- core/drupal
Порядок следования регионов и через css можно поменять, если структура следования позволяет - через order в flexbox. Или для мобил отдельное меню сделать и его показывать только мобилам.
Верно подметили, так никак не выбрать именно неделю, месяц.
Тогда что если добавить просто поле списка или таксономии, в котором выбирать неделя или месяц, дальше в зависимости от выбранного считать от даты публикации срок.
Вариант вполне нормальный, даже если там 50 папок и придется вручную качать нужные версии модулей, это не так уж прям много времени потребует, если не возиться с композером.
Еще вариант - просто удалить все htaccess внутри модулей (не вручную), там их быть не должно нигде, если только какие-то кастомные модули.
В 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 или стилями бордер добавить, то это работает? Элемент на странице находится или нет?
Да так, только лишние пробелы убрать нужно, чтобы лесенки не было.
Нужен ли 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, срок жизни - поле типа дата, потом по нему снимать с публикации.