OldWarrior: Комментарии

Главные вкладки

1 июля в 17:30

marassa wrote: То есть Internal Page Cache (не путать с Dynamic Page Cache, который у меня включён и что-то не особо ускоряет) вообще игнорирует контексты. Тогда зачем их добавлять в билд-массив?

Я сейчас смутно припоминаю: году так в 2016, когда D8 был свеж, как утренняя булочка из пекарни, мы вроде как парились на одном проекте с аналогичным вопросом. Вроде что-то кешировалось неуместным образом для гостей в форме на фронте. Не помню точно, как решилось тогда, но кажется, действительно выключили модуль Internal Page Cache.

1 июля в 11:15

PS. Опять же, мы рассматриваем типичный случай, когда build-массив представляет содержимое, отдаваемое контроллером. Но всё вышенаписанное справедливо и для любых других рендер-массивов, например, блоков.

1 июля в 11:05

marassa wrote: То есть в самом начале работы контроллера страницы нужно проверить нет ли уже в кэше страницы с этим адресом И ЭТОЙ КУКОЙ, и если есть, то просто отдать из кэша. А если нет, и дело дошло до рендеринга страницы, то после рендеринга нужно положить свежеотрендеренную страницу в кэш, причем с id, включающим куку.

12 июня в 20:16

Тогда в теории они таки обязаны заняться вашей проблемой. Поскольку MySQL-сервер работает, так сказать, в глобальном контексте - для всех аккаунтов и, следовательно, вы не можете напрямую повлиять на его работу и файлы БД. На shared-хостингах обычно вообще ни на что из окружения невозможно повлиять.

12 июня в 20:11

chei1ahJoh8K wrote: какая база

Указанный автором файл .FRM относится к структуре таблиц MySQL.

chei1ahJoh8K wrote: там же написано - много открытых файлов

Вторую часть сообщения я несколько пропустил. Ну да, много открытых файлов, поэтому открыть semaphore.frm система уже не может. Возможно, имеются какие-то незавершённые процессы, не закрывшие корректно файлы. Тут ребутнуть MySQL бы, но у автора shared-хостинг .

12 июня в 18:16

Ну, строго говоря, пользовательские БД (и стало быть связанные с ними файлы) - это как бы данные пользователя. Т.е. на хостинге-то может быть всё и хорошо, как они говорят: ОС в норме, ресурсы в норме, сервера крутятся-пашут. А вот пользовательские данные - это данные, относящиеся к аккаунту, а не к хостингу. Так что с формальной стороны они могут быть правы, хотя это и не очень чуткий к клиенту подход. )

Но вообще здесь многое зависит от разновидности хостинга. Какой у вас: shared или что-то выделенное?

12 июня в 17:23

Браузер мог также закешировать сопоставление IP - домен. Попробуйте из другого браузера, например.

Кстати (это не прямо относится к проблеме, но упоминаю, раз переносили на другой IP) - стоит посмотреть ещё 'trusted_host_patterns' в settings.php. Бывает, что паттерны там прописывают не по домену, а по IP. В таком случае, тоже могут возникнуть проблемы позднее. Но это уже актуально, когда сайт на Друпале доступен и работает.

12 июня в 17:16

Kublahan wrote: Что такое semaphore.frm?

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.

Иными словами - побилась база на хостинге. Если есть бекап БД, то лучше восстановиться, тут больше ничего не сделаешь.

9 июня в 9:21

Модуль-то (dblog) явно включен, поскольку выполняется процедура записи в ряды этой таблицы. Но самой таблицы уже (или ещё) нет.

Если это происходит именно при обновлении, то что-то делается не так во всей процедуре. Возможно, побили таблицы или забыли выполнить обновление БД (drush updb) после обновления кода.

Тут можно попытаться дать возможность модулю dblog восстановить таблицу, ОТКЛЮЧИВ его и затем повторно включив (drush un dblog, затем drush en dblog). При включении модуль должен заново создать необходимые таблицы в БД.

7 июня в 22:10
1

ИМХО, в случае с shipping на каком-то отдельном проекте не имеет особого значения - костыли или нет. По фэншую может быть слишком/необоснованно долго и замороченно.

6 июня в 15:32

По поводу автопересчёта - тоже были какие-то проблемы. То ли он не работает как надо, то ли работает только на JS-событиях change для каких-то специфических полей. В общем, помню, что с ним тоже была какая-то история. И установка 'auto_recalculate' => TRUE хоть программно, хоть из интерфейса чекаута ничего не давала.

6 июня в 13:46
1

y-vo wrote: проблема в том что при этом не обновляется цена на фронте, не разобрался пока что как именно она обновляется, явно по какому то эвенту или хуку, она например обновляется при переключении способов доставок в виджете. Пробовал вызывать пересчет цены ордера, но не обновляет отрисовку. Может быть кто то знает подробности?

Насколько я помню, в коммерце при активированном shipment есть давнее проклятие: кнопка "Обновить стоимость" или как-то так. Я не смотрел последние версии, не в курсе осталась ли она.

6 июня в 11:35

1) У админа должны быть все права по умолчанию. Однако, вы писали, что у админа тоже нет возможности открыть файл по ссылке. Т.е. для админа никаких спец. манипуляций обычно не требуется.

Кстати, какой именно админ? Самый-самый толстый (uid=1)? Просто я когда-то сталкивался с тем, что админы с НЕ uid=1 порой обрабатывались иначе. Подозреваю, что баг каких-то модулей.

2) Что именно получается не очень? Вроде решаете же проблему.

5 июня в 19:51

1. Я сверился таки с документацией - у вас (вроде бы) верное использование службы 'file.repository', именно она создаёт одновременно и физический файл и его файловую сущность в Друпале. Т.е. тут всё вроде бы верно.

2.

gera8774 wrote: Вообще было бы здорово обойтись php://output но проблема в том, что я генерирую файл на основе шаблона.

5 июня в 19:11

Ну как бы я вам писал выше, что мне показались сомнительными манипуляции с 'file.repository'

По каким ссылкам админ вообще пытается запросить эти файлы? Какой вид/формат имеют URL'ы таких файлов?

5 июня в 18:40

gera8774 wrote: И судя по всему, вот эту часть с сохранением мне надо делать как-то по-другому, чтобы друпал брал этот файл к себе "в подопечные" и заносил в базу
Вместо $_doc->saveAs($PATH); пробую такое:

$fileRepository = \Drupal::service('file.repository');
$fileRepository->writeData($_doc, 'private://mydir/file'. $entity->id().'.docx', FileSystemInterface::EXISTS_REPLACE);

5 июня в 13:36

gera8774 wrote: Например сейчас есть папка 2025-06, в ней лежит файл, загруженный при создании материала. Он доступен по ссылке
Также рядом с этой папкой лежит папка mydir, в ней лежат программно сгенерированные файлы. Они по ссылке выдают 403

3 июня в 19:32

В идеале нужен кастомный модуль, например, реагирующий на хук hook_post_update и/или запускающий батч-процесс по всем сущностям файлов, во время которого бы выполнялся перенос файла в приватную папку + коррекция/обновление URI в таблице файлов.

Но можно попробовать начать с этого: filefield_paths. У него заявляется такая фича как:

Retroactive updates - rename and/or move previously uploaded files.