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

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

Поискал репозитории для debian, действительно 6.х не видать - 5.9-1 последний нашёл. Можно свой пакет собрать, в принципе. Это всё же правильнее будет, чем ставить через pear.

С одной стороны, оно конечно так... А вот с другой, установка нестандартными методами софта в пакетных дистрибутивах и гонка за последними версиями софта на продакшен серверах, обычно, плохо заканчивается.
Так что лучше так не делать, если это не является жизненно необходимым. Да и в этом случае, лучше поискать репозиторий со свежими версиями drush для вашего дистрибутива.

Такие вещи должны реализовываться на уровне темизации.

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

"zzia" wrote:

Защита на стороне сервера
1. Обычная друпал аутентификация (видимо уже используется) - достаточна для большинства целей
2. Переход на https - существенно повысит защищенность
3. Перевод сервера и всех клиентов в VPN еще более повысит защищенность
Защита на стороне клиента
1. Если все работают со стационарных компьютеров настроить на сервере фильтрацию по IP

Такую систему на Drupal сделать вполне можно, и это вполне нормальное решение.

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

Если надо иметь доступ из разных мест, например филиалов, или отдельного склада, то всё это реализуется, как выше правильно написали, расширением внутренней сети предприятия на основе VPN.

По Питерским есть отчёты на http://drupalspb.org/.

"Bezlepkin" wrote:

А почему полностью не перейдешь на YII?

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

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

Yii.

Для описанной вами ситуации, наверное, лучше сделать модуль, который реализует соответствующий блок, с возможностью кеширования конечного результата. Более простой но менее правильный способ, используя функции API, получить подменю и передать как переменную в MYTHEME_preprocess_node(), если в другой теме это не используется.
Но вообще, лучше в слое темизации управлять только тем, как отображаются данные, а не самими данными.
И уж конечно, никаких mysql запросов в теме быть не должно...

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

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

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

"Anton1" wrote:

А большинство агитирующих за дру думает поставлю ядро+views и буду в шоколаде. ага ага... а то что кучи модулей на д.орге написаны просто отвратительно + не держат нагрузку про это все как то забывают...

Если я правильно понял что вам нужно, то вам поможет views_data_export.

Проверьте владельца sites/default/files, sites/default/files/tur, и права заодно.

Обратиться к хостеру, и попросить увеличить лимит памяти процесса php, например, до 128МБ.

Меняйте хостинг. Это не ddos, это превышение квот на нагрузку.

Могу зайти и покопаться.
skype: boris.syomov

А вообще, как же вы живёте без админа на сервере, не имея знаний в администирировании?

А почему у вас возникает такой вопрос? Перенести надо все таблицы... Возможно, перед переносом, очистить cache*.

Да, такое теоретически возможно.
Бекапы делались?

"3746598" wrote:

Им даже не нужен доступ к файлам в папках друпала. Это такой обзорный курс по CMS. Просто чтобы могли устанавливать модули.

В том-то и дело, что какой-то доступ нужен, иначе как же они установят модули...

В вашем случае, видимо, придётся предустановить им с запасом модули в /sites/all/modules, чтобы студенты могли нужные включить на своих сайтах, раз нельзя им давать доступ...

А каким образом студентам предлагается работать с файлами в своих папках? Т.е. как это сейчас происходит?

Это ужасная и нечитаемая стена текста, но тем не менее кое-что полезное она содержит.