> ua_courses_insert() - конфликт с hook_insert($node)

Да и вообще эта функция не нужна. В общем-то и реализация хук_крон не нужна. И своя таблица в БД не нужна. И своя ф-я темизации тоже не нужна (есть же theme_item_list).

"anzebra" wrote:

то вот такой error:

Не знаю че там в 7-ке происходит, но 1-е что приходит на ум, так это запрос DELETE FROM sessions WHERE uid = 0, если сайт на локалхосте.

Соовщения drupal_set_message() хранятся в сессии. Друпал имеет свой обработчик сессий, все данные о сессиях хранятся в БД. Если в таблице {users} нет записи для uid = 0, то для анонимов не получится загрузить сессию. Но почему у кого-то эта запись для uid = 0 пропадает, для меня загадка.

А это я затупил, думал в своём модуле выводите

В таблице users есть запись для uid = 0?

Для таких отношений достаточно создать табличку с полями uid и puid. В форме добавления связей вам нужны будут иерархические селекты, я бы использовал не hierarchcal select, а ctools_dependent - тупо проще. Ну а чтоб совсем красиво сделать, можно tabledrag добавить в админке, тут можно просто посмотреть модуль menu, как там это реализовано.

Ну а самое сложное наоборот - отрисовка, моё мнение такое.

Ваша правда
Там как оказалось есть справа кнопочка Use aggregation

Сомневаюсь, что вьюс это может. Тут простой запрос нужен:

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

Зачем здесь variable_get()? Вы понимаете, что это за функция?

Вам нужно:

А я туды не заходил, как-то скачал посмотрел и усё.

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

Ну а про запросы, я скачивал модуль из этой темы, не из репозитария. Там при обновлении аккаунта есть нечто вроде:

for ($i = $min; $i < $max; $i++) {
'SELECT COUNT() ...
}

Капитан очевидность шепнул мне на ушко, что если диапазон номеров будет 100-15000, то соответственно и запросов будет 14900 штук.

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

1. Нет индексов по полям uid и promonumber
2. Нет механизма удаления промокодов
3. Бредовый алгоритм присвоения случайного номера. Вы хотите до 15 тысяч раз выполнять запрос к базе, чтобы получить свободные номера? Бугога.

"Ch" wrote:

почти весь функционал в уберкаталоге оформлен в виде theme функций.

В Ubercart, как и в любом _нормальном_ Друпал-модуле, theme функции отвечают за представление контента и всё. Обработка данных происходит раньше.

"Ch" wrote:

На производительность это мало влияет.

RXB, предлагаю вам открыть, к примеру, content.module, пролистать до content_nodeapi и добавить там drupal_set_message($op . $nid); а потом открыть ноду и посмотреть на результат.

Crea, Разумеется необязан, это так, поток сознания, накипело-с.

Сейчас приходится разбираться с этим чудом инжИнерной мысли. Даже зарегистрировался специально, сил нет никаких. Автор, если кратко - НЕ УМЕШЬ НЕ БЕРИСЬ.

Если аргументированно, то основные претензии следующие:

1) Смутное представление автора об архитектуре Друпал в частности и о программировании в целом.
2) Полнейшее его безразличие к производительности системы. По 300-380 запросов на страницу с 1 нодой - это блин умудриться надо.
Пример:
phptemplate_uc_catalog_browse() @ template.php