Вот, так если приходится прописывать, какие изображения соответствуют тем или иным нодам, то может проще их вручную закачивать (через форму). А так - конечно можно сформировать поля, а потом залить сами изображения (сразу все). Изображения реализуются с помощью cck-поля imagefield, так что тут Уберкарт не при чем.

В общем, набирайте в поиске модулей "import" и смотрите.

Поставьте нормальный полноценный сервак, а не денвер. Это не так сложно, как кажется.

Только Pathauto ИМХО лучше не использовать. Лучше custom_url_rewrite_inbound()/inbound, тогда алиасов будет мало, и можно будет все подгрузить за один раз.

В БД копайте таблицу menu_router... Смотрите отработку index.php - на каком этапе затык. Можете попробовать сбросить кэши - тоже ручками в БД.

Да, тоже интересно. В чем разница идеологий?

1. Проанализируйте таблицу "user" - может что не так.

Остальные пункты - стандартные при любых проблемах:

2. Почистите все кэши на сайте, лучше вручную в БД (почистить все таблицы "cache_*" и таблицу "sessions"). А также в браузере. Попробуйте другой браузер.

3. Думайте, что делали с сайтом перед возникновением проблем.

4. Последовательно смотрите (с помощью echo) отработку index.php, чтобы понять, на каком этапе проблема.

Действительно, как бы это объединить логины вида name и name@drupal.org? У меня та же фигня, что и у ingumsky@drupal.org

term_node_count дает кол-во нод непосредственно в данном терме, без учета нод в "детях".

Quote:

Очевидно можно.А кто его будет потом поддерживать,баги ловить?Что делать,если надо там ссылочку убрать,а там поставить?Лезть на сервак за файлами и править вручную?Можно написать что-то универсальное конечно,но это будут те же вьюсы,только хуже.

Никакие это не понты. Кастомным модулем можно получить лучшую производительность, чем с использованием views. А если еще сделать простенькое кэширование, то вообще отлично будет.

Ваши рассуждения о том, что Друпалу нужно хорошее железо, в данном случае неуместны, потому что 15 секунд - это нереально много. Впрочем, как и 1000 запросов

Самый простой метод "в лоб". Отключите все модули кроме Devel, затем включайте поочереди. Таким образом определите, что дает такие тормоза.

P.S. Друпал, конечно, прожорливый, но если постараться - оптимизировать реально.

Ну вместо views делать свой модуль это конечно долго. Это уже потом.

1. Навскидку могу предложить посмотреть кэширование блоков (я так понимаю, вьюсы у вас - в виде блоков): [module=blockcache_alter], http://drupal.ru/node/25398 .

2. И вы, я так понял, генерите свой path для каждого товара (судя по тому, что стоит ubercart & pathauto)? Это тоже может тормозить. Возможно, вообще лучше отказаться от path (ну и pathauto ес-но).

Хостинг - это конечно хорошо, но вы уверены, что все оптимизировали по максимуму?

Посмотрите HTML-код страниц для начала (правильные ли href у ссылок).

Добавлю, что неплохо еще заюзать нормальное кэширование блоков: [module=blockcache_alter] http://drupal.ru/node/25398 Заодно может и не надо будет трогать вьюсы, отображаемые как блоки.

И вьюсы, отображаемые в виде страниц, реализовать своим модулем. Вообще views на посещаемых проектах нужно стараться использовать по минимуму - тормозной он.

Да, в ядре D7 теперь есть API, чтобы цеплять поля к различным сущностям. А модуль CCK для семерки - просто UI для этого API.

Но, кстати, сделали они не совсем гибко. Любое поле связано сразу с двумя сущностями: bundle (article, story ...) и entity (node, taxonomy_term, user ...) Было бы круто оставить просто объекты, к которым можно подцепить любые поля...

Но хоть сделали "корзину", т.е. любое поле может быть отмечено как удаленное, но физически остается в БД. И может быть успеют до заморозки добавить централизованную загрузку entities.

Я думаю, что получить полностью готовый объект ноды из базы все же быстрее, чем вызов node_load(). Т.е. грубо говоря, простой select по nid.

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

Кэширование объектов нод, и даже темизированной ноды - очень даже имеет смысл, даже не смотря на то, что они зависят от юзера. Если я, например, знаю, что какие-то ноды всегда одинаковы, почему я не могу включить принудительное кэширование именно этих нод?

Или, как тут уже писали, сделать кэширование по ролям/юзерам (более реально, наверное, первое).

Кстати, я это принудительное кэширование уже предлагал на drupal.org, но они FieldsAPI доводят до ума, и этот вопрос отложили до лучших времен.

penexe wrote:

shp, block уже не в ядре

Принципиально это ничего не меняет Хорошо, можно назвать эти модули "стандартными"

Эта тема - на самом деле - хорошая идея, потому что за всем не уследишь, и можно много интересного пропустить. Меня, например, больше интересуют нововведения с точки зрения программиста, и особенно производительность.

Да, можно выводить ноды своим active_handler. Кстати, спасибо за hook_menu_alter, раньше я его как-то не замечал Я имел в виду - неплохо было бы, чтобы дошло дело до изменения "ядерных" модулей block и node.

В Друпале-7 на основе drupal_render() теперь сделана и генерация страницы.

krf wrote:

Как это посмотреть?

В начале участка кода засекаете время, в конце - высчитываете разницу. Получение точного времени - см. ф-ию microtime().

Отключайте поочередно модули. Если шарите в PHP, смотрите, какие участки кода жрут больше ресурсов.

Поиск рулит: это неоднократно обсуждалось.

Но вообще нужно включить отображение ошибок в PHP. Тогда сразу увидите, что за проблемы. Может и memory_limit.