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

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

23 декабря 2018 в 1:59

Столкнулся с этим сейчас, до сих пор не решено, выбор
Filter to items that share all terms
Filter to items that share any term
не работает, сортирует всегда по последнему (share any term)

12 декабря 2018 в 0:10

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

11 декабря 2018 в 23:40

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

11 декабря 2018 в 20:54

Отличный модуль, поставил себе, спасибо. Мою проблему с публикацией исправило. Единственный минус, при первичной загрузке если изображение обрабатывалось Друпалом, то размер показывается оригинального, а не обработанного (уменьшенного) изображения, что может сбить с толку.

10 декабря 2018 в 21:49

Ну некоторые совсем большие файлы, которые проходят по размеру пикселей, но при этом имеют изначально чрезмерно завышенное качество от пользователей, я не готов хранить на сервере, так что полностью от ограничения не хотелось бы отказываться.

23 января 2018 в 12:37

Тоже интересует ответ на данную задачу. PHP не владею, как сделать решение #1 от Goodboy, описанное выше, не понял, тем более у меня Друпал 7 (тут у автора 6). Будет кто так добр, что подскажет, как именно переписать надо

8 сентября 2017 в 23:47

X-GUN (ник не даёт отправить комментарий Smile ), вот это уже полезный совет, спасибо! Собственно я и сам пока только этот вариант и вижу - таким способом вроде таблица до 500 мб за сутки успевает нарости, ну уже в два раза прогресс хотя бы.

8 сентября 2017 в 18:30
1

Да вы сильно много полезного и не сказали, спасибо за ничего.
Ещё раз повторю, 50% всей моей оплаты идёт просто за место mysql таблицы. ещё 25% это оплата hdd всего сайта. Тогда как все вычисления, все обращения, в том числе и boost-а к кешированным страницам - это оставшиеся 25%. Тут надо университет закончить, чтобы понять, что подобный подход к хранению кеша в самой таблице - непрактичный?

8 сентября 2017 в 13:37

Сдаётся мне, что несколько раз в день обращаться к html страницам на HDD менее трудозатратно, чем перманентно хранить гиг информации в базе и платить за него втридорога, при том что не важно есть ли к нему обращения или нет.

7 июля 2017 в 2:00

fairrandir, не раз и не два уже написал, речь о том, когда либо все архивные ревизии удалены, либо даже когда удалён материал полностью. Повнимательнее.

6 июля 2017 в 20:05

Спасибо за ссылку, попробовал (сделав бэкап), размер отдельных таблиц намного уменьшился (кстати как раз пресловутой file_usage), плохо что после окончания операции никаких отчётов модуль не показал, собственно вообще не понятно что он именно делал. Ну да ладно, лишь бы сбоев в работе сайта не было.

Касательно удаления файлов, я как раз разбираясь с моей проблемой наткнулся на такой модуль, Fancy File Delete. Но т.к. revisioning не отвязывает файл от материала, то в базе он считается нужным и от Fancy File Delete толку нет.

6 июля 2017 в 19:34

Фишка моего наблюдения была в том, что до тех пор, пока не было обращения к модулю revisioning, всё нормально удалялось. Т.е. проблема именно в вышеуказанном модуле. Удаляй ревизии или нет - уже ничего не поможет.

6 июля 2017 в 19:30

Так дело не в этом, даже если их удалить (да даже если удалить весь материал), модуль revisioning не снимает (не умеет корректно) с файлов метку что они используются, поэтому друпал их не может удалить. Я так понял.

6 июля 2017 в 19:10

Проверил сайт у себя на денвере - та же беда, так что хостер отпал. Потом заметил, что если удалить файл не создавая ревизию в материале, где ни разу не создавались ревиизии, то он удаляется. Начал копать в сторону revisioning - оказалось, что это давно известная проблема на семёрке https://www.drupal.org/node/2285629 и 8ке https://www.drupal.org/node/1239558 У меня седьмой друпал и там написано, что до сих пор не исправлено. Такие дела.

6 июля 2017 в 16:57

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

5 июля 2017 в 0:46

C cron проблем не замечал, по крайней мере письма отправляет мне и пользователям регулярно по распорядку.

Кстати, сейчас проверил - картинки тоже не удаляются (даже если удалить материал), а они у меня в общедоступном хранилище, в отличии от файлов.

4 июля 2017 в 22:30

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

6 мая 2017 в 18:16

Не очень понял при чём тут кэш. Содержимое представления не меняется же, т.е. например даже если данные обновились, представление как и положено продолжает показывать мне старую версию из кэша (к примеру, у меня раз в сутки обновляется), просто временами пропадает сводка.