Столкнулся с этим сейчас, до сих пор не решено, выбор
Filter to items that share all terms
Filter to items that share any term
не работает, сортирует всегда по последнему (share any term)
Это всё к моему вопросу не относится.
Ладно, т.к. баг в шапке мне исправить помогли, за что спасибо большое,то тему я закрываю как решенную, про другие вопросы отдельно если что создам.
Так это я понимаю, вопрос в том, как сначала проделать друпалом все эти манипуляции, а потом только выполнить проверку на ограничение по весу? Друпал делает всё наоборот - сначала смотрит на вес, если он превышает предел, то друпал отказывается делать что-либо с фалом.
Отличный модуль, поставил себе, спасибо. Мою проблему с публикацией исправило. Единственный минус, при первичной загрузке если изображение обрабатывалось Друпалом, то размер показывается оригинального, а не обработанного (уменьшенного) изображения, что может сбить с толку.
Ну некоторые совсем большие файлы, которые проходят по размеру пикселей, но при этом имеют изначально чрезмерно завышенное качество от пользователей, я не готов хранить на сервере, так что полностью от ограничения не хотелось бы отказываться.
Тоже интересует ответ на данную задачу. PHP не владею, как сделать решение #1 от Goodboy, описанное выше, не понял, тем более у меня Друпал 7 (тут у автора 6). Будет кто так добр, что подскажет, как именно переписать надо
X-GUN (ник не даёт отправить комментарий ), вот это уже полезный совет, спасибо! Собственно я и сам пока только этот вариант и вижу - таким способом вроде таблица до 500 мб за сутки успевает нарости, ну уже в два раза прогресс хотя бы.
Да вы сильно много полезного и не сказали, спасибо за ничего.
Ещё раз повторю, 50% всей моей оплаты идёт просто за место mysql таблицы. ещё 25% это оплата hdd всего сайта. Тогда как все вычисления, все обращения, в том числе и boost-а к кешированным страницам - это оставшиеся 25%. Тут надо университет закончить, чтобы понять, что подобный подход к хранению кеша в самой таблице - непрактичный?
Сдаётся мне, что несколько раз в день обращаться к html страницам на HDD менее трудозатратно, чем перманентно хранить гиг информации в базе и платить за него втридорога, при том что не важно есть ли к нему обращения или нет.
fairrandir, не раз и не два уже написал, речь о том, когда либо все архивные ревизии удалены, либо даже когда удалён материал полностью. Повнимательнее.
Спасибо за ссылку, попробовал (сделав бэкап), размер отдельных таблиц намного уменьшился (кстати как раз пресловутой file_usage), плохо что после окончания операции никаких отчётов модуль не показал, собственно вообще не понятно что он именно делал. Ну да ладно, лишь бы сбоев в работе сайта не было.
Касательно удаления файлов, я как раз разбираясь с моей проблемой наткнулся на такой модуль, Fancy File Delete. Но т.к. revisioning не отвязывает файл от материала, то в базе он считается нужным и от Fancy File Delete толку нет.
Фишка моего наблюдения была в том, что до тех пор, пока не было обращения к модулю revisioning, всё нормально удалялось. Т.е. проблема именно в вышеуказанном модуле. Удаляй ревизии или нет - уже ничего не поможет.
Так дело не в этом, даже если их удалить (да даже если удалить весь материал), модуль revisioning не снимает (не умеет корректно) с файлов метку что они используются, поэтому друпал их не может удалить. Я так понял.
Проверил сайт у себя на денвере - та же беда, так что хостер отпал. Потом заметил, что если удалить файл не создавая ревизию в материале, где ни разу не создавались ревиизии, то он удаляется. Начал копать в сторону revisioning - оказалось, что это давно известная проблема на семёрке https://www.drupal.org/node/2285629 и 8ке https://www.drupal.org/node/1239558 У меня седьмой друпал и там написано, что до сих пор не исправлено. Такие дела.
Предположение хорошее, но я этот вариант проверял - даже с одной опубликованной ревизией (моей) ноды они не удаляются с сервера, хотя в материале я их удалил.
Не очень понял при чём тут кэш. Содержимое представления не меняется же, т.е. например даже если данные обновились, представление как и положено продолжает показывать мне старую версию из кэша (к примеру, у меня раз в сутки обновляется), просто временами пропадает сводка.
Similar By Terms по двум словарям
Кто-нибудь?
Настройка аргумента Views с использованием Entity Reference
Столкнулся с этим сейчас, до сих пор не решено, выбор
Filter to items that share all terms
Filter to items that share any term
не работает, сортирует всегда по последнему (share any term)
Материал публикуется автоматически, когда размер изображения больше допустимого
Это всё к моему вопросу не относится.
Ладно, т.к. баг в шапке мне исправить помогли, за что спасибо большое,то тему я закрываю как решенную, про другие вопросы отдельно если что создам.
Материал публикуется автоматически, когда размер изображения больше допустимого
Так это я понимаю, вопрос в том, как сначала проделать друпалом все эти манипуляции, а потом только выполнить проверку на ограничение по весу? Друпал делает всё наоборот - сначала смотрит на вес, если он превышает предел, то друпал отказывается делать что-либо с фалом.
Материал публикуется автоматически, когда размер изображения больше допустимого
Отличный модуль, поставил себе, спасибо. Мою проблему с публикацией исправило. Единственный минус, при первичной загрузке если изображение обрабатывалось Друпалом, то размер показывается оригинального, а не обработанного (уменьшенного) изображения, что может сбить с толку.
Материал публикуется автоматически, когда размер изображения больше допустимого
Ну некоторые совсем большие файлы, которые проходят по размеру пикселей, но при этом имеют изначально чрезмерно завышенное качество от пользователей, я не готов хранить на сервере, так что полностью от ограничения не хотелось бы отказываться.
Similar By Terms по двум словарям
Тоже интересует ответ на данную задачу. PHP не владею, как сделать решение #1 от Goodboy, описанное выше, не понял, тем более у меня Друпал 7 (тут у автора 6). Будет кто так добр, что подскажет, как именно переписать надо
Слишком большой размер таблицы cache_views_data
X-GUN (ник не даёт отправить комментарий ), вот это уже полезный совет, спасибо! Собственно я и сам пока только этот вариант и вижу - таким способом вроде таблица до 500 мб за сутки успевает нарости, ну уже в два раза прогресс хотя бы.
Слишком большой размер таблицы cache_views_data
Я уже прижился, не хотелось бы. Но как вариант конечно можно рассмотреть смену хостера (или даже попробовать плана).
Слишком большой размер таблицы cache_views_data
Да вы сильно много полезного и не сказали, спасибо за ничего.
Ещё раз повторю, 50% всей моей оплаты идёт просто за место mysql таблицы. ещё 25% это оплата hdd всего сайта. Тогда как все вычисления, все обращения, в том числе и boost-а к кешированным страницам - это оставшиеся 25%. Тут надо университет закончить, чтобы понять, что подобный подход к хранению кеша в самой таблице - непрактичный?
Слишком большой размер таблицы cache_views_data
Сдаётся мне, что несколько раз в день обращаться к html страницам на HDD менее трудозатратно, чем перманентно хранить гиг информации в базе и платить за него втридорога, при том что не важно есть ли к нему обращения или нет.
Слишком большой размер таблицы cache_views_data
«Буст работает только для анонимов»
Да я-то знаю. Нужно подобное решение для views.
На счёт картинки - хотелось бы использовать views
[РЕШЕНО] С сервера не удаляются старые файлы, добавленные через тип поля "Файл"
Проблема решена патчем https://www.drupal.org/node/2285629#comment-12157520 для Drupal 7.
[РЕШЕНО] С сервера не удаляются старые файлы, добавленные через тип поля "Файл"
fairrandir, не раз и не два уже написал, речь о том, когда либо все архивные ревизии удалены, либо даже когда удалён материал полностью. Повнимательнее.
[РЕШЕНО] С сервера не удаляются старые файлы, добавленные через тип поля "Файл"
Спасибо за ссылку, попробовал (сделав бэкап), размер отдельных таблиц намного уменьшился (кстати как раз пресловутой file_usage), плохо что после окончания операции никаких отчётов модуль не показал, собственно вообще не понятно что он именно делал. Ну да ладно, лишь бы сбоев в работе сайта не было.
Касательно удаления файлов, я как раз разбираясь с моей проблемой наткнулся на такой модуль, Fancy File Delete. Но т.к. revisioning не отвязывает файл от материала, то в базе он считается нужным и от Fancy File Delete толку нет.
[РЕШЕНО] С сервера не удаляются старые файлы, добавленные через тип поля "Файл"
Фишка моего наблюдения была в том, что до тех пор, пока не было обращения к модулю revisioning, всё нормально удалялось. Т.е. проблема именно в вышеуказанном модуле. Удаляй ревизии или нет - уже ничего не поможет.
[РЕШЕНО] С сервера не удаляются старые файлы, добавленные через тип поля "Файл"
Так дело не в этом, даже если их удалить (да даже если удалить весь материал), модуль revisioning не снимает (не умеет корректно) с файлов метку что они используются, поэтому друпал их не может удалить. Я так понял.
[РЕШЕНО] С сервера не удаляются старые файлы, добавленные через тип поля "Файл"
Проверил сайт у себя на денвере - та же беда, так что хостер отпал. Потом заметил, что если удалить файл не создавая ревизию в материале, где ни разу не создавались ревиизии, то он удаляется. Начал копать в сторону revisioning - оказалось, что это давно известная проблема на семёрке https://www.drupal.org/node/2285629 и 8ке https://www.drupal.org/node/1239558 У меня седьмой друпал и там написано, что до сих пор не исправлено. Такие дела.
[РЕШЕНО] С сервера не удаляются старые файлы, добавленные через тип поля "Файл"
Очень полезный совет, что он есть что его нет. Базовая функция движка некорректно работает, а я админа буду нанимать.
[РЕШЕНО] С сервера не удаляются старые файлы, добавленные через тип поля "Файл"
Дайте мне идеи!
[РЕШЕНО] С сервера не удаляются старые файлы, добавленные через тип поля "Файл"
C cron проблем не замечал, по крайней мере письма отправляет мне и пользователям регулярно по распорядку.
Кстати, сейчас проверил - картинки тоже не удаляются (даже если удалить материал), а они у меня в общедоступном хранилище, в отличии от файлов.
[РЕШЕНО] С сервера не удаляются старые файлы, добавленные через тип поля "Файл"
Предположение хорошее, но я этот вариант проверял - даже с одной опубликованной ревизией (моей) ноды они не удаляются с сервера, хотя в материале я их удалил.
[РЕШЕНО] С сервера не удаляются старые файлы, добавленные через тип поля "Файл"
Ну есть у кого хоть какие-то идеи?
В Views пропадает "сводка результатов" сама по себе
К сожалению, этот модуль не помог (но он кстати очень полезный, спасибо за наводку).
В Views пропадает "сводка результатов" сама по себе
Не очень понял при чём тут кэш. Содержимое представления не меняется же, т.е. например даже если данные обновились, представление как и положено продолжает показывать мне старую версию из кэша (к примеру, у меня раз в сутки обновляется), просто временами пропадает сводка.