Sinkora: Блог

Главные вкладки

Когда не стоит использовать Друпал

7 сентября 2010 в 0:30

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

Что делать, когда база данных очень большая?

4 сентября 2010 в 17:38

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

Внимание: фильтр работает неправильно!

22 августа 2010 в 19:41

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

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

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

Без хакинга никак. Часть 1

14 августа 2010 в 19:13

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

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

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

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

function my_hacks_menu_alter(&$items) {
  $items['node/%node']['access callback'] = 'my_hacks_node_access';
}
function my_hacks_node_access($op, $node) {
  global $user;
  if (node_access($op, $node) || ($op == 'view' && $user->uid)) {
    return TRUE;
  }
  else {
    return FALSE;
  }
}

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

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

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

31 июля 2010 в 19:30

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

Интересное наблюдение за кешированием страниц

3 июня 2010 в 18:11

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

Например, у нас есть сайт 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 очень быстро разрастется до огромных разделов.

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

Скрытие в браузере удаленных кешированных на сервере картинок. Как правильнее делать?

24 апреля 2010 в 17:48

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

Ищем альтернативу pathauto

19 апреля 2010 в 16:44

В общем, до сегодняшнего дня активно использовал на одном сайте 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?>

О кешировании на drupal.ru

13 апреля 2010 в 2:44

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

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

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

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

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

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

Большие тексты в нодах

17 февраля 2010 в 22:57

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

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