marassa wrote: То есть Internal Page Cache (не путать с Dynamic Page Cache, который у меня включён и что-то не особо ускоряет) вообще игнорирует контексты. Тогда зачем их добавлять в билд-массив?
Я сейчас смутно припоминаю: году так в 2016, когда D8 был свеж, как утренняя булочка из пекарни, мы вроде как парились на одном проекте с аналогичным вопросом. Вроде что-то кешировалось неуместным образом для гостей в форме на фронте. Не помню точно, как решилось тогда, но кажется, действительно выключили модуль Internal Page Cache.
PS. Опять же, мы рассматриваем типичный случай, когда build-массив представляет содержимое, отдаваемое контроллером. Но всё вышенаписанное справедливо и для любых других рендер-массивов, например, блоков.
marassa wrote: То есть в самом начале работы контроллера страницы нужно проверить нет ли уже в кэше страницы с этим адресом И ЭТОЙ КУКОЙ, и если есть, то просто отдать из кэша. А если нет, и дело дошло до рендеринга страницы, то после рендеринга нужно положить свежеотрендеренную страницу в кэш, причем с id, включающим куку.
Тогда в теории они таки обязаны заняться вашей проблемой. Поскольку MySQL-сервер работает, так сказать, в глобальном контексте - для всех аккаунтов и, следовательно, вы не можете напрямую повлиять на его работу и файлы БД. На shared-хостингах обычно вообще ни на что из окружения невозможно повлиять.
Указанный автором файл .FRM относится к структуре таблиц MySQL.
chei1ahJoh8K wrote: там же написано - много открытых файлов
Вторую часть сообщения я несколько пропустил. Ну да, много открытых файлов, поэтому открыть semaphore.frm система уже не может. Возможно, имеются какие-то незавершённые процессы, не закрывшие корректно файлы. Тут ребутнуть MySQL бы, но у автора shared-хостинг .
Ну, строго говоря, пользовательские БД (и стало быть связанные с ними файлы) - это как бы данные пользователя. Т.е. на хостинге-то может быть всё и хорошо, как они говорят: ОС в норме, ресурсы в норме, сервера крутятся-пашут. А вот пользовательские данные - это данные, относящиеся к аккаунту, а не к хостингу. Так что с формальной стороны они могут быть правы, хотя это и не очень чуткий к клиенту подход. )
Но вообще здесь многое зависит от разновидности хостинга. Какой у вас: shared или что-то выделенное?
Браузер мог также закешировать сопоставление IP - домен. Попробуйте из другого браузера, например.
Кстати (это не прямо относится к проблеме, но упоминаю, раз переносили на другой IP) - стоит посмотреть ещё 'trusted_host_patterns' в settings.php. Бывает, что паттерны там прописывают не по домену, а по IP. В таком случае, тоже могут возникнуть проблемы позднее. Но это уже актуально, когда сайт на Друпале доступен и работает.
FRM files are used to define the format of a table used with MySQL. MySQL is a cross-platform relational database . FRM files will have the same name as the table they reference, but with a . FRM extension.
Иными словами - побилась база на хостинге. Если есть бекап БД, то лучше восстановиться, тут больше ничего не сделаешь.
Модуль-то (dblog) явно включен, поскольку выполняется процедура записи в ряды этой таблицы. Но самой таблицы уже (или ещё) нет.
Если это происходит именно при обновлении, то что-то делается не так во всей процедуре. Возможно, побили таблицы или забыли выполнить обновление БД (drush updb) после обновления кода.
Тут можно попытаться дать возможность модулю dblog восстановить таблицу, ОТКЛЮЧИВ его и затем повторно включив (drush un dblog, затем drush en dblog). При включении модуль должен заново создать необходимые таблицы в БД.
ИМХО, в случае с shipping на каком-то отдельном проекте не имеет особого значения - костыли или нет. По фэншую может быть слишком/необоснованно долго и замороченно.
По поводу автопересчёта - тоже были какие-то проблемы. То ли он не работает как надо, то ли работает только на JS-событиях change для каких-то специфических полей. В общем, помню, что с ним тоже была какая-то история. И установка 'auto_recalculate' => TRUE хоть программно, хоть из интерфейса чекаута ничего не давала.
y-vo wrote: проблема в том что при этом не обновляется цена на фронте, не разобрался пока что как именно она обновляется, явно по какому то эвенту или хуку, она например обновляется при переключении способов доставок в виджете. Пробовал вызывать пересчет цены ордера, но не обновляет отрисовку. Может быть кто то знает подробности?
Насколько я помню, в коммерце при активированном shipment есть давнее проклятие: кнопка "Обновить стоимость" или как-то так. Я не смотрел последние версии, не в курсе осталась ли она.
1) У админа должны быть все права по умолчанию. Однако, вы писали, что у админа тоже нет возможности открыть файл по ссылке. Т.е. для админа никаких спец. манипуляций обычно не требуется.
Кстати, какой именно админ? Самый-самый толстый (uid=1)? Просто я когда-то сталкивался с тем, что админы с НЕ uid=1 порой обрабатывались иначе. Подозреваю, что баг каких-то модулей.
2) Что именно получается не очень? Вроде решаете же проблему.
1. Я сверился таки с документацией - у вас (вроде бы) верное использование службы 'file.repository', именно она создаёт одновременно и физический файл и его файловую сущность в Друпале. Т.е. тут всё вроде бы верно.
2.
gera8774 wrote: Вообще было бы здорово обойтись php://output но проблема в том, что я генерирую файл на основе шаблона.
gera8774 wrote: И судя по всему, вот эту часть с сохранением мне надо делать как-то по-другому, чтобы друпал брал этот файл к себе "в подопечные" и заносил в базу
Вместо $_doc->saveAs($PATH); пробую такое:
gera8774 wrote: Например сейчас есть папка 2025-06, в ней лежит файл, загруженный при создании материала. Он доступен по ссылке
Также рядом с этой папкой лежит папка mydir, в ней лежат программно сгенерированные файлы. Они по ссылке выдают 403
В идеале нужен кастомный модуль, например, реагирующий на хук hook_post_update и/или запускающий батч-процесс по всем сущностям файлов, во время которого бы выполнялся перенос файла в приватную папку + коррекция/обновление URI в таблице файлов.
Но можно попробовать начать с этого: filefield_paths. У него заявляется такая фича как:
Вопрос продвинутым знатокам Cache API
Я сейчас смутно припоминаю: году так в 2016, когда D8 был свеж, как утренняя булочка из пекарни, мы вроде как парились на одном проекте с аналогичным вопросом. Вроде что-то кешировалось неуместным образом для гостей в форме на фронте. Не помню точно, как решилось тогда, но кажется, действительно выключили модуль Internal Page Cache.
Вопрос продвинутым знатокам Cache API
PS. Опять же, мы рассматриваем типичный случай, когда build-массив представляет содержимое, отдаваемое контроллером. Но всё вышенаписанное справедливо и для любых других рендер-массивов, например, блоков.
Вопрос продвинутым знатокам Cache API
Вопрос продвинутым знатокам Cache API
Ключевое слово тут
$build
. Т.е. этот элемент добавляется просто к любому возвращаемому из какого-то контроллера (страницы или формы) рендер-массиву.Ошибка в процессе обновления
Дальше - всё даже проще, можно для админа сразу поставить пароль из драша:
drush user:password admin '12345'
https://www.drush.org/12.x/commands/user_password/
Ошибка в процессе обновления
Значит, установить.
https://www.drupal.org/docs/develop/development-tools/drush#s-installation
Ошибка в процессе обновления
drush установлен? С помощью драша можно принудительно залогинить любого пользователя. А там уже можно установить новый пароль.
С чем связана проблема на сайте?
Тогда в теории они таки обязаны заняться вашей проблемой. Поскольку MySQL-сервер работает, так сказать, в глобальном контексте - для всех аккаунтов и, следовательно, вы не можете напрямую повлиять на его работу и файлы БД. На shared-хостингах обычно вообще ни на что из окружения невозможно повлиять.
С чем связана проблема на сайте?
Указанный автором файл .FRM относится к структуре таблиц MySQL.
Вторую часть сообщения я несколько пропустил. Ну да, много открытых файлов, поэтому открыть semaphore.frm система уже не может. Возможно, имеются какие-то незавершённые процессы, не закрывшие корректно файлы. Тут ребутнуть MySQL бы, но у автора shared-хостинг .
С чем связана проблема на сайте?
Ну, строго говоря, пользовательские БД (и стало быть связанные с ними файлы) - это как бы данные пользователя. Т.е. на хостинге-то может быть всё и хорошо, как они говорят: ОС в норме, ресурсы в норме, сервера крутятся-пашут. А вот пользовательские данные - это данные, относящиеся к аккаунту, а не к хостингу. Так что с формальной стороны они могут быть правы, хотя это и не очень чуткий к клиенту подход. )
Но вообще здесь многое зависит от разновидности хостинга. Какой у вас: shared или что-то выделенное?
Смена ip сайта на хостинге
PS. Ещё можно сбросить кеш DNS на локальной машине. В винде, например:
ipconfig /flushdns
Смена ip сайта на хостинге
Браузер мог также закешировать сопоставление IP - домен. Попробуйте из другого браузера, например.
Кстати (это не прямо относится к проблеме, но упоминаю, раз переносили на другой IP) - стоит посмотреть ещё 'trusted_host_patterns' в settings.php. Бывает, что паттерны там прописывают не по домену, а по IP. В таком случае, тоже могут возникнуть проблемы позднее. Но это уже актуально, когда сайт на Друпале доступен и работает.
С чем связана проблема на сайте?
Иными словами - побилась база на хостинге. Если есть бекап БД, то лучше восстановиться, тут больше ничего не сделаешь.
Ошибка в процессе обновления
Модуль-то (dblog) явно включен, поскольку выполняется процедура записи в ряды этой таблицы. Но самой таблицы уже (или ещё) нет.
Если это происходит именно при обновлении, то что-то делается не так во всей процедуре. Возможно, побили таблицы или забыли выполнить обновление БД (drush updb) после обновления кода.
Тут можно попытаться дать возможность модулю dblog восстановить таблицу, ОТКЛЮЧИВ его и затем повторно включив (drush un dblog, затем drush en dblog). При включении модуль должен заново создать необходимые таблицы в БД.
Отрисовка изменения стоимости заказа после addAdjustment
ИМХО, в случае с shipping на каком-то отдельном проекте не имеет особого значения - костыли или нет. По фэншую может быть слишком/необоснованно долго и замороченно.
Отрисовка изменения стоимости заказа после addAdjustment
По поводу автопересчёта - тоже были какие-то проблемы. То ли он не работает как надо, то ли работает только на JS-событиях change для каких-то специфических полей. В общем, помню, что с ним тоже была какая-то история. И установка 'auto_recalculate' => TRUE хоть программно, хоть из интерфейса чекаута ничего не давала.
Отрисовка изменения стоимости заказа после addAdjustment
Насколько я помню, в коммерце при активированном shipment есть давнее проклятие: кнопка "Обновить стоимость" или как-то так. Я не смотрел последние версии, не в курсе осталась ли она.
Права доступа к default/files
1) У админа должны быть все права по умолчанию. Однако, вы писали, что у админа тоже нет возможности открыть файл по ссылке. Т.е. для админа никаких спец. манипуляций обычно не требуется.
Кстати, какой именно админ? Самый-самый толстый (uid=1)? Просто я когда-то сталкивался с тем, что админы с НЕ uid=1 порой обрабатывались иначе. Подозреваю, что баг каких-то модулей.
2) Что именно получается не очень? Вроде решаете же проблему.
Права доступа к default/files
1. Я сверился таки с документацией - у вас (вроде бы) верное использование службы 'file.repository', именно она создаёт одновременно и физический файл и его файловую сущность в Друпале. Т.е. тут всё вроде бы верно.
2.
Права доступа к default/files
Ну как бы я вам писал выше, что мне показались сомнительными манипуляции с 'file.repository'
По каким ссылкам админ вообще пытается запросить эти файлы? Какой вид/формат имеют URL'ы таких файлов?
Права доступа к default/files
Права доступа к default/files
Права доступа к default/files
В идеале нужен кастомный модуль, например, реагирующий на хук hook_post_update и/или запускающий батч-процесс по всем сущностям файлов, во время которого бы выполнялся перенос файла в приватную папку + коррекция/обновление URI в таблице файлов.
Но можно попробовать начать с этого: filefield_paths. У него заявляется такая фича как:
Права доступа к default/files
А приватный метод загрузки включили?
Под рукой только настроенная под приватные файлы девятка. Там так:
Скачивать файл в Ноду по ссылке. Как?
Так этож победа, не?