"подход" с кастомной таблицей вкорне не правилен.
Простейший вариант - создать специальный тип ноды с нужными полями, и работать с ним стандартно. (вывести данные при помощи модуля views и т.п.)

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

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

Полностью согласен с предыдущим оратором..
Если ТС уверенно работает с линуксом на удаленном сервере, почему на десктопе до сих пор маздай?-)
Разрабатывать софт, который работает в линукс-окружении на виндовсе, мягко говоря извращение..-)
Как минимум постаить ubuntu на виртуалку..

блин.. отстал я от жизни.. все по старинке.. IDE, drush, drupal-консоль..
ТС, Вы бы лучше описали причину, из-за которой Вам приходтся так извращаться..
Вам бы 3 кучи советов бы навалили, как все это делать продуктивнее..

Загляните в "Отчет о состоянии" (Меню "Отчеты")
Может там что-то прояснит ситуацию..

Если надо без особых заморочек "ускорить" сайт, с относительно небольшой посещаемостью (чуть пониже новостного портала с 100000 поситителями в месяц) - redis, отличное решение.
Поставил и забыл.
Проверял на "коленке" (в devtools chrome), после сброса кэша, загрузка какого нибудь навороченого вьюса второй раз (в первый он попадает в кэш) быстрее раз в 5-8..
Но для redis нужна свободная оперативнакя память, ибо его суть: хранилище кэша в виде ключ-значение в оперативной памяти..
Из-за этого и ощутимый прирост производительности.

Хм.. проблему придумали.. наши предки 1000 лет назад, а скорее всего еще много раньше знали: пока гром не грянет, мужик не перекрестится.

Успокойтесь, примите удобную позу для ожидания..
Все случиться, когда придет срок-))
Китайцы же тоже не дураки-)

Хранить данные в Excel - даже не прошлый, позапрошлый век..
Drupal почти из коробки может предоставить функционал, на пару порядков проще и удобнее чем Excel.
Импортировать некий готовый набор данных из Excel - ничего сложного..
Далее про Excel лучше забыть, т.к. это лишняя "прослойка" при обработке-хранении информации, плюс, как писал выше, Drupal под эти функции заточен лучше..
Это почти как щи хлебать лопатой: тоже можно, но ложкой проще и удобнее..

mbaev wrote:

прекрасно себя зарекомендовавшую.

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

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

кто согласен, как говорят в однокласниках - ставте лайк-)

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

1.Запросил ноду из кэша,
если нет ее там,
запросил из базы, положил в кэш, пока нода не измениться.

2.Изменил ноду, почистил ее кэш.
При первом же запросе в кэш попадет ее актуальное состояние.(п.1)

Если в базе drupal 7 поставили "U" в начале пароля, то теперь никто не сможет зайти на сайт под любым паролем, т.к. drupal 7 хранит не пароли, а их хэши..

По миграции пользователей с drupal 6 на drupal 7 должён помочь модуль Migrate.
Т.к. тема (перенос пользователей), достаточно востребована, в интернетах вообще и на ютубах в частности должно быть не мало освещений подробных руководств, как это сделать..

Самостоятельно c модулем Migrate разобраться не побуйте, ознакомьтесь сначала с руководствами по решению таких или подобных задач..

Если города и их клубы сделать иерархическим словарем таксономии с двумя уровнями.
уровень 1 - Города
уровень 2 - Клубы
...
то проблема просто решается модулем SHS (Simple hierarchical select )

Если я праильно понимаю, у Вас список РАЗНЫХ нод (с разными идентификаторами (nid)) c "одинаковыми" заголовками..
А Вам надо сгрупировать их по "заголовку"?
Тут неправильный подход к организации структуры данных..
Групировка по введенному вручную заголовку штука совсем не надежная (ошибка, лишний пробел, разный по "росту" буквы и т.п.)..
1.Добавте словать таксономии для хранения "общих признаков" нод.
Термин словаря и будет содержать этот "заголовок" по которому Вы хотите группировать ноды.

Еще вариант.. пометьте "некативные" строким css-классом и скройте чекбоксы css-ом..

если задача не решается, или решается слишком сложно, ее надо разбить на задачки по проще и решать поотдельности..
Например будем рассуждать логически, какой смысл в чекбоксе, который нельзя почекбоксить? Я тоже не понимаю..
Разделите таблицу на 2:
1.В первой доступное для выбора
2.Во второй - то что не доступно(просто инфа без чекбоксов)

Просто как предположение.. кто-то завладел кучей мыл в полное пользование и пытается собрать админ-аккаунты, зарегистрированные на эти мыла.. имхо, конечно тупо..
Еще возможно, бот пытается куда-то ввести свое мыло.. а вдруг на него вышлют доступ к админ-аккаунту..
А есть ли это поле для мыла, бот не проверяет..
...
А вообще, проблема просто решается например на выделенном сервере..
У друпал есть некоторый список "легитимных" запросов на просмотр контента (кроме администрирования)..

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

хм.. а самую главную дыру указать забыли..
Про клаву и спинку стула шутить не буду-)
Пароли могут утекать и с компов, с которых админят сайт.

Использовать для отзывов комментарии, самый безгеморойный вариант.. С наступающим..

Если вьюс у Вас выводит не поля, а содержимое с режимом просмотра Анонс, то посмотрите еще ролики про "Режимы отображения материалов" и "Настройку отображения материалов"
Я серьезно..
Это действительно, как писали выше - очень просто.. Надо просто один раз посмотреть.

хмм.. допустим у исходной ноды 5 тегов..
Наиболее релевантны ей будут ноды, содержащие те же 5 тегов..
Следующий уровень релевантности: ноды содержащие 4 тега.
Вариантов комбинаций этих тегов: 5
выборка по ним будет примерно в 5 раз больше предыдущего уровня..
Если их не особенно большое кол-во, чем необходимо пользователю, которому они выводятся, польза от выборки еще есть..
А если их слишком много, их как-то тоже надо сортировать, иначе большого смысла в них не будет..

Да.. готовые сборки "хороши" как примеры, если эти примеры "хороши"(правильно реализованы)..
...
и составьте 2 плана
1.План минимум
Только необходимый и достаточный функционал
2.План оптимум.
Конечная версия на данном этапе.
..
до полной реализации плана-минимум ни в коем случае не переходите к следующему.

А вот если бы за каждый свой косяк, им приходилось бы отвечать, они б так не беспредельничали.
А подобным отношением наоборот, Вы их поощряете..
А ведь еще куча народу с подобными претензиями.. Эх жаль, что людей так трудно объединять..

Кстати да.. сейчас глянул сколько стоит продление моего на reg.2domains.ru .. в 4 раза дороже чем стоит сейчас мой прошлогодний.. и он свободен-))
Да мы и не гордые, возьмем прошлогодний, нам просто имя надо..