Задавайте вопросы про Drupal - 2

Почти уверен, что проблема не в Drupal, а в настройках PHP. Там есть опция max_input_vars в php.ini. Она по умолчанию равна одной тысяче. Нужно изменить на большее значение. PHP обрабатывает только первую тысячу переменных (полей), а остальные игнорирует. Я недавно сталкивался с этой проблемой при редактировании меню.

Drupal 6.28

Пробелма с таксономией.

1. Как прописать мета теги для таксономии?

В настройках самого термина пишу - после сохранения все пропадает, как будто не вводил ничего. На странице термина так же пусто

Через модуль nodewords сохраняется, однако на самой странице термина не отображается.

2. Описание термина.

Описание выводится на странице термина, в мета-теге description, а так же в атрибуте title="" во всех ссылках на страницу этого термина (то есть при наведении на ссылку отображается описание). Это ваще бред.

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

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

Когда обратился к специалисту по Друпалу, он мне тоже посоветовал увеличить max_input_vars в php.ini, что и сделала поддержка хостинга по моей просьбе. Но почему-то ничего не изменилось, как привязывалось не более тысячи терминов, так и осталось. Больше вариантов у специалиста небыло.

Потом обратился к другому специалисту. Сначала он установил модуль, который отмечал термины при редактировании ноды, с помощью аякса. Это должно было уменьшить нагрузку. Но вариант тоже не сработал. Словарь вообще перестал открываться.

Сейчас он реализовывает интерфейс добавления городов чтобы можно было каждый термин сохранять в БД из редактирования ноды. Это должно облегчить нагрузку на БД. Надеюсь этот вариант сработает, а то эти тысячу с копейками городов уже заколебали меня:) Не думал, что реализовать классификацию по городам на Друпал будет так сложно..

Помогите прописать rel="nofollow" ко всем ссылкам меню на всех страницах, кроме морды.

big boy, вот это вроде должно помочь http://drupal.org/project/menu_attributes

Хранить в сессии таблицу в 50 строк и 3 столбца - это нормально для модуля? Ну в смысле сильно ли влияет на нагрузку сервера такая таблица?

Для каждого нового пользователя таблица новая.

Да, он работает, но ставит атрибуты глобально на весь сайт. То есть нельзя выделить на каких страницах. А было бы круто применять атрибуты по аналогии, как настраивается отображение блоков - со списком страниц.

Может кто-нибудь допилит?

Если модуль тянет поля из профиля например иль... - это нормально

Засада ИМХО ::: когда некоторые модули воротят свои таблицы со стандартными данными (которые уже есть - типа дублируют) и не дают ими манипулировать отдельно иль связать со штатным функционалом.

Если модуль в сессии плодит таблицу в которой 90% дублей, вместо того чтоб ссылаццо на уже имеющееся - в топку принципиально такие модули. Посещалка увеличиццо и настанет полный абзац... дата-центр покупать придёццо... ))

зачем гемороиться с подобным? думаете как-то повлияет в плане seo? неа..

Ну делается этот коловорот только с 1 целью - передача данных между 2 страницами. GET и POST запросы такого вида - Это перебор. Хотя можно поместить Если использовать уникальную конфигурацию сервера... Модуль должен быть универсален на то он и модуль. Вот отсюда все беды. В сессии можно засунуть очень много данных, чем я и пользуюсь. Хотя кошки таки скребут на душе.

Нет 90% не дубли. Таблица такого рода: index, url, name. Для разных результатов поиска выдаются разные таблицы. То есть 1 пользователь ищет одно, другой - естессно другое. Дублей нет практически. Опять же при вбивании нового запроса таблица обновляется. То есть больше 50 записей на 1 пользователя не будет ибо сие невозможно.

Можно пойти другим путем:

-Модуль при установке создает в Mysql таблицу с перечисленными выше полями.

Потом просто каждому новому пользователю дается кукиз с его порядковым номером. Порядковый номер равен столбцу index в таблице. Теперь при вбивании в поле поискоого запроса данные будут загоняться не в сессии а в таблицу бд.

А на другой странице эти данные будут уже браться не из сессий а из таблицы.

Минусы очевидны: чем больше посетителей тем больше в бд записей. Рано или поздно ваша база данных будет переполнена...(хотя я ее по крону очищаю, о тоже не всегда правильно - вдруг в момент очистки базы на сайте есть пользователи у которых кукисы еще действуют. Записи удалены а куки есть - баг эррор труба!)