Нашел "штучку-дрючку", которая прибавляла к времени генерации страницы почти целую секунду:
это скрин фрагмента настройки поля ubercart_price (Цена продажи) в VIEWS (работа с полями).
Если стоит как "Ubercart price", то работает медленнее, чем "Числовая".
Глубина может быть разной, в одной ветке может быть глубина 2, а в другой 5.
Принудительно давать глубину - не выход, именно нужна проверка на самый глубокий (последний) термин.
смысл с том, что бы выводимые в блоке ноды соответствовали термину таксономии каталога.
Например: фотоаппараты -> зеркальные [вверху ноды со статьями по выбору зеркалок, а снизу соответственно идет каталог фотиков]
Я бы не делал это во views, а сделал бы настройку дисплея можно использовать модуль https://drupal.org/project/entity_view_mode можно добавить нужный дисплей и темизировать его целиком а не каждое поле через views, опять таки в другом месте понадобиться - не надо будет опять настраивать.
0. Код - все запросы к БД оптимизированы, большинство операций с node так же оптимизированы, views, таксономия и др. - аналогично
1. eAccelerator, кэширование средствами Друпала
2. Gzip, Boost - отдает сгенерированные html версии страниц
3. CSS, JS - сжатие включено
4. Сайт завершен, из оптимизации осталось только убрать все лишнее из html на выходе
Ну надо же чем-то процессор занять. А то что он будет просто так простаивать =)
Ну да, это первоочередная задача. Про уменьшение веса страницы не слышали? Польза от минимизации кода кажется вам только лишней загрузкой ресурсов сервера... печально.
Хочется закрыть уязвимость конкретно по открытой информации т.е. да, в случае, если у кого то не нужного появится доступ по SSH -> MySQL (и можно читать всю инфу прямо из базы).
Доступ к инфе есть у юзеров, которые логинятся с 2-мя уровнями верификации (по SMS паролям).
Данные есть общие и личные (с этим проблем и вопросов нет, все разграничения сделаны успешно).
Нашел "штучку-дрючку", которая прибавляла к времени генерации страницы почти целую секунду:
это скрин фрагмента настройки поля ubercart_price (Цена продажи) в VIEWS (работа с полями).
Если стоит как "Ubercart price", то работает медленнее, чем "Числовая".
Глубина может быть разной, в одной ветке может быть глубина 2, а в другой 5.
Принудительно давать глубину - не выход, именно нужна проверка на самый глубокий (последний) термин.
Решено: http://drupal.stackexchange.com/questions/49031/show-related-terms-block...
Это тоже пробовал: https://drupal.org/node/65375 хз почему не пошло...
Вот как это сделать правильно? Аргументы в views крутил всячески - безрезультатно.
смысл с том, что бы выводимые в блоке ноды соответствовали термину таксономии каталога.
Например: фотоаппараты -> зеркальные [вверху ноды со статьями по выбору зеркалок, а снизу соответственно идет каталог фотиков]
Думал на счет нагрузки к БД в случае использования модуля View Entity Mode.
Да, точно! Спасибо, у меня уже мозг "замылился", разумеется $item, я же это определил в foreach
Кажется теперь застрял на шаге цикла в шаблоне:
В node--webform--test.tpl.php пишу:
Рекомендую ощутить эффект удивления от чтения http://www.drupal.ru/comment/reply/106615/592905 где уже было указано, что gzip включен.
0. Код - все запросы к БД оптимизированы, большинство операций с node так же оптимизированы, views, таксономия и др. - аналогично
1. eAccelerator, кэширование средствами Друпала
2. Gzip, Boost - отдает сгенерированные html версии страниц
3. CSS, JS - сжатие включено
4. Сайт завершен, из оптимизации осталось только убрать все лишнее из html на выходе
Ну да, это первоочередная задача. Про уменьшение веса страницы не слышали? Польза от минимизации кода кажется вам только лишней загрузкой ресурсов сервера... печально.
Спасибо капитан
Большое спасибо!!!
Да, на счет ssh вы абсолютно правы.
Хочется закрыть уязвимость конкретно по открытой информации т.е. да, в случае, если у кого то не нужного появится доступ по SSH -> MySQL (и можно читать всю инфу прямо из базы).
Доступ к инфе есть у юзеров, которые логинятся с 2-мя уровнями верификации (по SMS паролям).
Данные есть общие и личные (с этим проблем и вопросов нет, все разграничения сделаны успешно).
Не, не помогло. К тому же мне нужно обратное, не ключ (key), а подпись (label).
На выходе html хочется получить label т.е. слова: один, два или три (в зависимости от выбранного).
Проблема оказалась в том, что entity tokens не работают с множественным выбором терминов таксономии, от чего легче не стало.
Нет, дело именно в :parents:join-path который друпалом не воспринимается.
Спасибо за наводку! Буду смотреть, пробовать!
Да, согласен, что можно и так, но не во всех ситуациях это гибкое решение.
И теперь зимняя тема:
