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

Что делать, когда переполнены записями такие, например, таблицы БД как "node", "comments" и т.д.?

Вот пример неправильно работающего фильтра.

Начало.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  Конец.

Как видим, фильтр не всегда вырезает лишние пробелы. Надо искать ошибку.

Необходимо сделать на сайте возможность для авторизованных пользователей просматривать материалы со статусом 0.

Самый простой способ - это заменить в функции node_access() следующую строчку:
if ($op == 'view' && $account->uid == $node->uid && $account->uid != 0) {

на:
if ($op == 'view' && $account->uid) {

Но можно сделать подобные хуки:

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

Т.е. вывод один: без хакинга никак.

Почему в Друпале отступы принято делать двумя пробелами, а не табуляцией?

Раньше не обращал внимание. Но вчера заметил, что при стандартном кешировании Друпал сохраняет в кеш несуществующие страницы.

Например, у нас есть сайт example.com, на котором имеются следующие страницы:

example.com/catalog
example.com/catalog?page=1
example.com/catalog?page=2
...
example.com/catalog?page=1000

Т.е. Друпал кеширует эти страницы через cache_set($base_root . request_uri(), $data, 'cache_page', CACHE_TEMPORARY, drupal_get_headers());. Но проверку на существование страницы request_uri() не делает...

И если мы будем запрашивать несуществующие страницы, например:

example.com/catalog?page=1001
example.com/catalog?page=1002
...
и так до бесконечности,

то Друпал будет сохранять в таблицу cache_page весь этот хлам. В качестве сохраняемых данных будет браться запись из последней существующей страницы (example.com/catalog?page=1000).

В итоге, если запустить на такой сайт бота, который будет делать подобные запросы, таблица cache_page очень быстро разрастется до огромных разделов.

Таких примеров можно привести очень много.

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

В общем, до сегодняшнего дня активно использовал на одном сайте pathauto.
Ссылки нод строились примерно так: [vocab-raw]/[termpath-raw]/[author-name-raw]/[title-raw] и т.п. Но со временем мне такая красота разонравилась по следующим причинам:

1. Пользователи частенько меняют названия своих материалов, из-за чего каждый раз меняется алиас урла материала.
2. Сайт только начинает развиваться, а в таблице алиасов уже почти 10 000 записей. Если так пойдет дальше, то в недалеком будущем это число перевалит за миллион. Но это еще ничего, смотрим следующий пункт.
3. Больше всего напрягает вот что: на страницах листингов материалов СЛИШКОМ много запросов типа "SELECT dst FROM url_alias WHERE ..." при использовании функции l()! Различные хаки делать не вижу смысла.

Решил я сделать пути к материалам по схеме [type-name]/[nid], а вариант без алиасов node/[nid] не хочется использовать. В таком случае проблемные пункты 1 и 3 отпадают, т.к. алиасы будут неизменными всегда, а функцию l() уже можно будет не использовать, что избавит от десятков лишних запросов к БД.

Но какой смысл мне растить таблицу алиасов, при использовании записей типа "blog/1123", "blog/1124" и т.п., если это можно решить и без модуля pathauto?

Решения пока вижу такие:

1. Создавать каждый тип материала в отдельном модуле, где и указывать в меню правила на формирование адресов. Например, что-то типа такого:
   <?php?>

Я сделал следующее:

1. В первом браузере открыл "под гостем" страницу своего профиля. Там была моя аватарка.
2. Во втором браузере "под авторизацией" удалил свою аватарку.
3. Обновил страницу в первом браузере - увидел "битую" картинку. И только через 3 минуты картинка появилась.

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

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

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

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

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

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