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

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

Аватар пользователя Sinkora Sinkora 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
      $items
    ['blog/%node'] = array(...);
     
    ?>
  2. Сделать hook_menu_alter() для <?php $items['node/%node']... ?>. Тут я не совсем уверен.

Вопрос для программистов: как вы решали/решаете подобную задачу. Повторюсь, задача заключается в том, чтобы не использовать зря модуль pathauto для создания алиасов к нодам именно такого типа [type-name]/[nid], иначе на больших сайтах это большой минус в сторону производительности. Скорее всего полностью откажусь от модуля pathauto, когда найду наиболее грамотное альтернативное решение.

Вопрос для сеошников: если сразу заменить на сайте все алиасы (почти 10 тыс. штук), за это поисковики не обидятся на сайт?

Комментарии

Аватар пользователя tolykot tolykot 19 апреля 2010 в 17:32

Sinkora wrote:
если сразу заменить на сайте все алиасы (почти 10 тыс. штук), за это поисковики не обидятся на сайт?
.
Перенастраивал все пути, было на тот момент (4 месяца назад) около 1000. Яша переиндексировал за 2 месяца, а google до этих пор ходит по старым ссылкам, в поиске процентов 10 страниц.

Аватар пользователя Sinkora Sinkora 19 апреля 2010 в 17:42

"tolykot" wrote:
Перенастраивал все пути, было на тот момент (4 месяца назад) около 1000. Яша переиндексировал за 2 месяца, а google до этих пор ходит по старым ссылкам, в поиске процентов 10 страниц.

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

А теперь я окончательно решил изменить алиасы, согласно теме топика. Но вот боюсь, что опять проблемы с поисковиками начнутся.

Наверное, стоит на несколько месяцев включить модуль для редиректа со старых ссылок на новые... Хотя тут я далеко не спец.

Аватар пользователя graker graker 19 апреля 2010 в 17:56

Sinkora wrote:
Наверное, стоит на несколько месяцев включить модуль для редиректа со старых ссылок на новые... Хотя тут я далеко не спец.

Если что, модуль Path redirect умеет автоматически фиксировать изменение алаясов (по крайней мере ручные) и автоматически же делать редирект со старого на новый. И отслеживать, когда в последний раз имела место попытка доступа к старому алаясу (для удаления ненужных). Может пригодиться.

Аватар пользователя Sinkora Sinkora 19 апреля 2010 в 18:15

"xxandeadxx" wrote:
адреса реврайтить с помощью mod_rewrite :)

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

Аватар пользователя PVasili PVasili 19 апреля 2010 в 18:42

1) бред, (варианта: 2 запрет менять и не перезаписывать старые). Какие варианты ещё если вы завязались на заголовки Wink ?
2) Вы каждый раз на каждую страницу вытягиваете 10 000 записей?
3) Вам нужны алиасы (шашечки или ехать...)? Если нет - node/n

Напишите свой триггер и заносить им, при сохранении материала данные в таблицу url_alias.

з.ы. потратьте лишних $5 на более лучший хостинг и это окупит все ваши проблемы и изобретение великов

Аватар пользователя volocuga@drupal.org volocuga@drupal.org 19 апреля 2010 в 22:30

"Sinkora" wrote:
Пользователи частенько меняют названия своих материалов, из-за чего каждый раз меняется алиас урла материала.

А вы настройки pathauto смотрели? там можно выставить, чтобы алиасы не изменялись в дальнейшем при редактировании ноды

"Sinkora" wrote:
Сайт только начинает развиваться, а в таблице алиасов уже почти 10 000 записей. Если так пойдет дальше, то в недалеком будущем это число перевалит за миллион.

Теперь посмотрите,сколько там пустышек вида taxonomy/term

Касательно миллиона, то не думаю, что это случиться так уж скоро Smile

Аватар пользователя Sinkora Sinkora 19 апреля 2010 в 23:19

"PVasili" wrote:
1) бред, (варианта: 2 запрет менять и не перезаписывать старые). Какие варианты ещё если вы завязались на заголовки Wink ?

Запрещать пользователю менять название статьи нельзя, пользователь должен иметь такое право. Это такое условие. Если не перезаписывать старые алиасы, то название урла не будет соответствовать новому заголовку материала.

"PVasili" wrote:
2) Вы каждый раз на каждую страницу вытягиваете 10 000 записей?

Нет. Зачем? Но есть страницы с несколькими десятками, а иногда и сотнями ссылок, что требует соответствующего количества запросов к БД (если используется pathauto). Зачем мне лишние десятки/сотни запросов на страницу?

"PVasili" wrote:
3) Вам нужны алиасы (шашечки или ехать...)? Если нет - node/n

Как я написал в топике, мне нужны алиасы типа [машинное имя типа узла]/nid. А node/nid не нужны.

"PVasili" wrote:
Напишите свой триггер и заносить им, при сохранении материала данные в таблицу url_alias.

Я не собираюсь использовать таблицу url_alias. Иначе какой смысл тогда отказываться от модуля pathauto, который и так это делает. Задача заключается как раз в том, чтобы полностью отказаться от работы с этой таблицей.

"PVasili" wrote:
з.ы. потратьте лишних $5 на более лучший хостинг и это окупит все ваши проблемы и изобретение великов

А с чего Вы взяли, что у меня плохой хостинг? Я же на это не жаловался. И цифру в $5 откуда взяли? Это разве существенные деньги?

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

Вот возьмите, например, сайт drupal.ru или drupal.org - pathauto не используется или используется очень редко.

Аватар пользователя Sinkora Sinkora 20 апреля 2010 в 12:48

"gorr" wrote:
А еще есть функции custom_url_rewrite_inbound и custom_url_rewrite_outbound для этих целей.

Не совсем то, что нужно было, но тоже неплохо. Только вот custom_url_rewrite_outbound нужно будет в ограниченных количествах применять.

Аватар пользователя Crea Crea 20 апреля 2010 в 12:56

Quote:
Я просто хочу избавиться от лишнего количества запросов к БД, чтобы в будущем, когда на сайте в онлайне будут тысячи залогиненных юзеров, было меньше проблем. Также это мне необходимо для системы кеширования, которая будет на сайте (но это уже другая тема).

Классический случай premature optimization

Аватар пользователя orbisnull orbisnull 6 мая 2010 в 8:58

С развитием сервисов типа bit.ly и т.п., коросткие адреса node/nid начинают казаться очень неплохим вариантом ), кстати, а node можно заменить без алиасов на что-то другое?

Аватар пользователя Crea Crea 6 мая 2010 в 15:37

Quote:
кстати, а node можно заменить без алиасов на что-то другое?

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

Аватар пользователя Sinkora Sinkora 6 мая 2010 в 15:51

"orbisnull" wrote:
кстати, а node можно заменить без алиасов на что-то другое?

Да, как неплохой вариант, в settings.php можно написать такой код:

function custom_url_rewrite_outbound(&$path, &$options, $original_path) {
  if (preg_match('|^node(/.*)|', $path, $matches)) {
    $path = 'id'. $matches[1];
  }
}
function custom_url_rewrite_inbound(&$result, $path, $path_language) {
  if (preg_match('|^id(/.*)|', $path, $matches)) {
    $result = 'node'. $matches[1];
  }
}

В таком случае везде на сайте вместо node/777 будет id/777.
Кстати, функция custom_url_rewrite_outbound() не должна очень часто использоваться на странице...

Аватар пользователя Sinkora Sinkora 6 мая 2010 в 15:56

"Crea" wrote:
Локально - можно создать свой путь в меню который будет вызывать функцию вывода ноды.

Вроде как тоже вариант, не пробовал. Но, по-моему, в таком случае будут проблемы со сторонними модулями, которые будут работать со стандартным меню:) Но это не помеха:)

Аватар пользователя xxandeadxx xxandeadxx 10 мая 2010 в 16:02

автор, к чему в итоге пришёл? custom_url_rewrite_inbound+custom_url_rewrite_outbound? есть тесты производительности до и после? я вот тоже решил заняться этой темой Smile

Аватар пользователя Sinkora Sinkora 10 мая 2010 в 16:46

"xxandeadxx" wrote:
автор, к чему в итоге пришёл? custom_url_rewrite_inbound+custom_url_rewrite_outbound? есть тесты производительности до и после? я вот тоже решил заняться этой темой :)

Да, через custom_url_rewrite_inbound+custom_url_rewrite_outbound. Я сделал так:

function custom_url_rewrite_outbound(&$path, &$options, $original_path) {
  if (preg_match('|^node(/.*)|', $path, $matches)) {
    $path = 'p'. $matches[1];
  }
}
function custom_url_rewrite_inbound(&$result, $path, $path_language) {
  if (preg_match('|^p(/.*)|', $path, $matches)) {
    $result = 'node'. $matches[1];
  }
}

где вместо "p" - любое название: "article", "page"...
Только custom_url_rewrite_outbound - желательно использовать на одной странице не очень часто. Т.к. если все ссылки пропускать через функцию l(), то это лишние затраты при большом количестве ссылок. Я функцию l() почти не использую на сайте.

Насчет производительности, с custom_url_rewrite_inbound проблем нет, а вот с custom_url_rewrite_outbound нужно осторожно, т.к. она может часто использоваться на странице (но у меня это исключено, т.к. я за этим слежу).

Аватар пользователя xxandeadxx xxandeadxx 10 мая 2010 в 17:24

вместо preg_match можно использовать substr, работать будет раза в полтора быстрее

<?php
function custom_url_rewrite_outbound(&$path, &$options$original_path) {
  if (
substr($path05) == 'node/') {
    
$path 'p' substr($path5strlen($path) - 5);
  }
}
?>
Аватар пользователя Sinkora Sinkora 10 мая 2010 в 18:24

"xxandeadxx" wrote:
вместо preg_match можно использовать substr, работать будет раза в полтора быстрее

Да, я знаю. Как раз собирался исправить:)

Аватар пользователя Sinkora Sinkora 10 мая 2010 в 21:07

"orbisnull" wrote:
на глаз тут str_replace вроде-бы можно использовать?
ну вообшем уже написали из той-же серии )

На досуге, ради интереса, протестирую разные варианты на скорость...

Аватар пользователя volocuga@drupal.org volocuga@drupal.org 11 мая 2010 в 0:25

Sinkora: т.е предложенное решение полностью валидно? Что с выигрышем в производительности, есть ли конкретные цифры?

Меня уже тоже напрягает pathauto, а "node" как-то не кошерно

Аватар пользователя Sinkora Sinkora 11 мая 2010 в 4:36

"<a href="mailto:volocuga@drupal.org">volocuga@drupal.org</a>" wrote:
т.е предложенное решение полностью валидно? Что с выигрышем в производительности, есть ли конкретные цифры?

Ничего невалидного тут нет. Все гуд.

Цифры не измерял. В моем случае нет смысла.

custom_url_rewrite_inbound - никаких проблем с производительностью.

custom_url_rewrite_outbound - эта функция вызывается в url, которая вызывается в l. А так как функция url вызывает drupal_get_path_alias, который вызывает drupal_lookup_path, где есть такое:
$alias = db_result(db_query("SELECT dst FROM {url_alias} WHERE src = '%s' AND language IN('%s', '') ORDER BY language DESC", $path, $path_language));
То получается, что если на странице сайта 200 ссылок пропускается через функцию l, то это вызовет 200 лишних запросов к БД и 200 вызовов функции custom_url_rewrite_outbound.
Вообще, без custom_url_rewrite_outbound можно почти обойтись, если не использовать l, а строить ссылки самостоятельно. Согласитесь, что чтобы построить ссылку <a href="id/777">Название ссылки</a> нет смысла вызывать функцию l($node->title, 'node/'. $node->id), которая будет дергать базу всякий раз и использовать custom_url_rewrite_outbound. Можно в коде писать и так:
'<a href="id/'. $node->id .'">'. check_plain($node->title) .'</a>', или написать свою упрощенную функцию темизации для ссылок.

Т.е. у меня проблем с производительностью от этих функций не возникло, т.к. они используются у меня по минимуму.

Аватар пользователя orbisnull orbisnull 11 мая 2010 в 7:16

"Sinkora" wrote:
Больше всего напрягает вот что: на страницах листингов материалов СЛИШКОМ много запросов типа "SELECT dst FROM url_alias WHERE ..." при использовании функции l()! Различные хаки делать не вижу смысла.

Кстати, а почему не хотите хакнуть, понятно что метод не рекомендуемый, но иногда дозированный яд является лекарством? Вот например кэш в памяти(сессии): http://drupal.org/node/102311, а вот в базе: все пути и постранично, или простой вариант постраничного кэша.

Аватар пользователя kyky kyky 11 мая 2010 в 10:49

Я, кстати, давно задаюсь вопросом, когда же разработчикам станет понятно, что [node-type]/[nid] гораздо лучше, чем node/[nid]. Ставлю pathauto, по сути, только для этого нехитрого преобразования.

Аватар пользователя PVasili PVasili 11 мая 2010 в 12:08

"kyky" wrote:
Я, кстати, давно задаюсь вопросом, когда же разработчикам станет понятно, что [node-type]/[nid] гораздо лучше, чем node/[nid].
особенно им понятны ваши фантазии при смене типа материала Wink

Аватар пользователя kyky kyky 12 мая 2010 в 2:10

2 PVasili, penexe
Как часто вы меняете тип материала?
Отвечу за себя: еще ни разу не приходилось. Лучше потратить 3 дня на продумывание архитектуры, чем перекраивать уже в процессе.
Так что сарказм мне не понятен. И можно было бы избежать установки громоздкого модуля.

Аватар пользователя PVasili PVasili 12 мая 2010 в 11:28

"kyky" wrote:
Лучше потратить 3 дня на продумывание архитектуры, чем перекраивать уже в процессе.
вот поэтому архитектуру Drupal грамотно и продумали, и думали не 3 дня и "непродуманные хотелки" не используются...

Аватар пользователя Sinkora Sinkora 12 мая 2010 в 21:00

"orbisnull" wrote:
Кстати, а почему не хотите хакнуть, понятно что метод не рекомендуемый, но иногда дозированный яд является лекарством? Вот например кэш в памяти(сессии): http://drupal.org/node/102311, а вот в базе: все пути и постранично, или простой вариант постраничного кэша.

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

А если сайт представляет из себя активное коммьюнити, то от модулей path, pathauto лучше отказаться. Ведь Друпал позволяет создавать собственные адреса (hook_menu), а также custom_url_rewrite_inbound и custom_url_rewrite_outbound. А хаки в таком случае не оправдывают себя.

Вообще, когда в таблице url_alias есть хоть одна запись, то Друпал дергает эту таблицу даже для ссылок типа /comment/edit/8511 (несмотря на то, что алиаса для этого адреса в url_alias нет и в помине). Т.е. помимо отключения модуля алиасов, нужно еще очистить эту таблицу.

Помимо path, pathauto, я также отказался от locale. Но несмотря на то, что локализацию я отключил, на сайте нигде нет слов на английском языке! Все переводы стандартного интерфейса сделал через hook_menu_alter)

В итоге, без хаков, без path, pathauto, locale можно запросто обойтись, но тем самым добиться того, чтобы на странице было не больше 40 запросов к БД, а не 400-700...

Аватар пользователя Siegfrid@drupal.org Siegfrid@drupal.org 12 мая 2010 в 21:11

Sinkora wrote:

А если сайт представляет из себя активное коммьюнити, то от модулей path, pathauto лучше отказаться. Ведь Друпал позволяет создавать собственные адреса (hook_menu), а также custom_url_rewrite_inbound и custom_url_rewrite_outbound. А хаки в таком случае не оправдывают себя.

Я бы пошел иным путем. сделал бы небольшой хак и анализировал бы посещаемость страниц. Для популярных страниц я бы загружал алиасы пачкой в кеш и хранил его там бы минут так по 15ть, тогда мне не пришлось бы делать скажем сто запросов, а м.б. сделать 1 и вытащить срузу 100 наиболее популярных. места они съели бы наверное что то около 10k байт - не так уж и много...

Sinkora wrote:

Помимо path, pathauto, я также отказался от locale. Но несмотря на то, что локализацию я отключил, на сайте нигде нет слов на английском языке! Все переводы стандартного интерфейса сделал через hook_menu_alter)

Совсем фиговая идея... Есть стандартное средство - вынести перевод в settings.php и не париться. Выносится только то, что нужно, т.е. админка оставляют не локализованной, чтобы не раздувать settings.php

Аватар пользователя Sinkora Sinkora 12 мая 2010 в 21:39

"<a href="mailto:Siegfrid@drupal.org">Siegfrid@drupal.org</a>" wrote:
Я бы пошел иным путем. сделал бы небольшой хак и анализировал бы посещаемость страниц. Для популярных страниц я бы загружал алиасы пачкой в кеш и хранил его там бы минут так по 15ть, тогда мне не пришлось бы делать скажем сто запросов, а м.б. сделать 1 и вытащить срузу 100 наиболее популярных. места они съели бы наверное что то около 10k байт - не так уж и много...

Я бы так не делал. Ибо во время загрузки в кеш все равно придется гонять кучу запросов. Причем кеш часто обновлялся бы. Т.е. вы предлагаете "заплатку на проблему", взамен полного решения проблемы.
"<a href="mailto:Siegfrid@drupal.org">Siegfrid@drupal.org</a>" wrote:
Совсем фиговая идея... Есть стандартное средство - вынести перевод в settings.php и не париться. Выносится только то, что нужно, т.е. админка оставляют не локализованной, чтобы не раздувать settings.php

Можно поподробнее? Но скорее всего (с моей точки зрения) это еще более фиговая идея. Если сайт не будет использовать другой язык, кроме русского, то переводы - это вообще бред! Их не должно быть на одноязычном сайте!!!

Аватар пользователя Siegfrid@drupal.org Siegfrid@drupal.org 12 мая 2010 в 22:10

Sinkora wrote:
это еще более фиговая идея. Если сайт не будет использовать другой язык, кроме русского, то переводы - это вообще бред! Их не должно быть на одноязычном сайте!!!

Эта еще более фиговая идея заложена в ядро drupal для случая, когда включать local не хочется, а локализация нужна. Я так понимаю, что через hook_menu_alter вы изобрели заново велосипед и нам пытаетесь теперь рассказать, какой вы умный. Но дело то в том, что над этой CMS работали и продолжают работать очень много не менее умных и талантливых людей, не даром google собирается инвестировать в drupal 500 000 зеленных человесков Smile

Аватар пользователя Siegfrid@drupal.org Siegfrid@drupal.org 12 мая 2010 в 22:00

penexe wrote:
зачем вам друпал, если всю гибкость рубите на корню?

+1, может стоит подумать о своей "правильной" CMS, чем обтачивать напильником этот "тормознутый" drupal...

Аватар пользователя Sinkora Sinkora 12 мая 2010 в 21:58

"penexe" wrote:
зачем вам друпал, если всю гибкость рубите на корню?

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

Аватар пользователя orbisnull orbisnull 12 мая 2010 в 22:18

у меня пока запросов 40 и есть в среднем, пути включу с патчем (мне нужно 10-20 алиасов для разделов, это в apc прекрасно поживет)... И вообще сотни запросов выглядят странно (views+cck использую всегда)... А вот сторонние модули иногда вызывают кучу лишних запросов - тут нужно проверять после установки...(+ снипеты, блоки)

Аватар пользователя Sinkora Sinkora 12 мая 2010 в 23:10

"<a href="mailto:Siegfrid@drupal.org">Siegfrid@drupal.org</a>" wrote:
Но дело то в том, что над этой CMS работали и продолжают работать очень много не менее умных и талантливых людей, не даром google собирается инвестировать в drupal 500 000 зеленных человесков :)

1. Дело не в Друпале, а в сторонних модулях.

2. Дело даже не в том, что Друпал плохая или хорошая система. Дело в универсальности Друпала, которая дорого обходится в плане производительности.

3. Если бы Друпал был производительным, то на нем бы делали такие сайты как vkontakte.ru:)

Аватар пользователя Siegfrid@drupal.org Siegfrid@drupal.org 13 мая 2010 в 1:00

Sinkora wrote:
"<a href="mailto:Siegfrid@drupal.org">Siegfrid@drupal.org</a>" wrote:
Но дело то в том, что над этой CMS работали и продолжают работать очень много не менее умных и талантливых людей, не даром google собирается инвестировать в drupal 500 000 зеленных человесков :)

3. Если бы Друпал был производительным, то на нем бы делали такие сайты как vkontakte.ru:)

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

Кстати, вКонтакте не так давно наконец то "ожил", а до этого у него тоже было весьма и весьма много вопросов к коду и производительности. Как я слышал, Дуров спер где то на Германщине прототип "своей" CMS, вплоть до дизайна... После чего он с сотоварищами ооооочень долго выгребали косяки, закрывали дыры и т.д. и т.п.... Так что не приводите такие примеры, они как минимум не корректны!

Аватар пользователя Sinkora Sinkora 12 мая 2010 в 23:17

"orbisnull" wrote:
И вообще сотни запросов выглядят странно

Такое бывает, если на странице 400-500 ссылок, и все они прогоняются через проверку на алиас...
"orbisnull" wrote:
А вот сторонние модули иногда вызывают кучу лишних запросов

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

Аватар пользователя Sinkora Sinkora 13 мая 2010 в 1:53

"<a href="mailto:Siegfrid@drupal.org">Siegfrid@drupal.org</a>" wrote:

Ладно, проехали:)

"<a href="mailto:Siegfrid@drupal.org">Siegfrid@drupal.org</a>" wrote:
Совсем фиговая идея... Есть стандартное средство - вынести перевод в settings.php и не париться. Выносится только то, что нужно, т.е. админка оставляют не локализованной, чтобы не раздувать settings.php

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

Аватар пользователя Siegfrid@drupal.org Siegfrid@drupal.org 13 мая 2010 в 10:20

Sinkora wrote:
"<a href="mailto:Siegfrid@drupal.org">Siegfrid@drupal.org</a>" wrote:

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

Tip Using string overrides in settings.php is highly performant (for small sets of strings only) because
no database call is needed; the replacement string is simply looked up in an array. You don’t even have to
have the locale module enabled for string overrides to work. See also the string overrides module at
http://drupal.org/project/stringoverrides.

Взято из Pro Drupal Development 2 стр 412.

Вот сам пример:
String Overrides in settings.php

Find your settings.php file (typically at sites/default/settings.php). You may need to make
the file writable before making changes, as Drupal tries its best to keep this file read-only.
Scroll to the end of settings.php.We’ll add the following custom string array:
/**
* String overrides:
*
* To override specific strings on your site with or without enabling locale
* module, add an entry to this list. This functionality allows you to change
* a small number of your site's default English language interface strings.
*
* Remove the leading hash signs to enable.
*/
# $conf['locale_custom_strings_en'] = array(
# 'forum' => 'Discussion board',
# 'count min' => 'count minutes',
# );
$conf['locale_custom_strings_en'] = array(
'Home' => 'Sweet Home',
);
If you visit your site, you’ll notice that in the breadcrumb trail, Home has been changed to
Sweet Home, as shown in Figure 18-2.
Now that you know how to do string overrides, let’s go ahead and replace the word Blog
with the word Journal:
$conf['locale_custom_strings_en'] = array(
'Blog' => 'Journal',
);

Аватар пользователя Sinkora Sinkora 13 мая 2010 в 4:51

"xxandeadxx" wrote:

function custom_url_rewrite_outbound(&$path&$options$original_path) {
  if (substr($path05) == 'node/') {
    $path = 'p' . substr($path5strlen($path) - 5);
  }
}

Кстати, я что-то сомневаюсь, что 3 вызова функций substr, substr и strlen быстрее чем один вызов preg_match. Может все наоборот?о_О

$path = 'p/' . substr($path5strlen($path) - 5); - добавил слеш.

Аватар пользователя Sinkora Sinkora 13 мая 2010 в 4:56

"xxandeadxx" wrote:
preg_match очень прожорливая функция

Это понятно, что substr быстрее чем preg_match.
Но вопрос, что быстрее - preg_match или три последовательно вызванные функции substr, substr и strlen?..

Аватар пользователя xxandeadxx xxandeadxx 13 мая 2010 в 5:27
<?php
function custom_url_rewrite_outbound(&$path, &$options$original_path) {
  if (
preg_match('|^node(/.*)|'$path$matches)) {
    
$path 'p' $matches[1];
  }
}

function 

custom_url_rewrite_outbound2(&$path, &$options$original_path) {
  if (
substr($path05) == 'node/') {
    
$path 'p' substr($path5strlen($path) - 5);
  }
}

$timestart microtime(true);
for (
$i 0$i 1000$i++) {
  
$path $i%'node/' $i 'taxonomy/' $i;
  
custom_url_rewrite_outbound($path$options'');
}
echo 
round(microtime(true) - $timestart5) . ' sec.<br />';

$timestart microtime(true);
for (
$i 0$i 1000$i++) {
  
$path $i%'node/' $i 'taxonomy/' $i;
  
custom_url_rewrite_outbound2($path$options'');
}
echo 
round(microtime(true) - $timestart5) . ' sec.<br />';
?>
Аватар пользователя Siegfrid@drupal.org Siegfrid@drupal.org 13 мая 2010 в 10:27

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

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

Аватар пользователя Siegfrid@drupal.org Siegfrid@drupal.org 13 мая 2010 в 10:56

PVasili wrote:
В 10 раз: - лишние $5 на нормальный хостинг обойдутся дешевле, чем все извращения и возможные глюки

В случае с 5$ - да, а когда речь будет идти о 150$, то что тогда? Тогда начнешь задумываться об альтернативных вариантах...

Аватар пользователя PVasili PVasili 13 мая 2010 в 11:09

"<a href="mailto:Siegfrid@drupal.org">Siegfrid@drupal.org</a>" wrote:
а когда речь будет идти о 150$
Если цена вопроса хостинга будет такой (при соответствующем количестве посетителей), уж поверьте: узкие места будут в другой части ;). Насколько в вас проблемно открыть: http://drupaler.ru/module? (оставлено чисто для эксперимента).
Сколько там ссылок? А сколько будет у вас на среднестатистической? А сколько в кеше? А сколько поисковик будет считать за ссылки?

А в чём смысл обсуждать как улучшить комфорт и скорость феррари имея 3-х колесный детский велосипед и потенциально только присматриваться к 2-х колесному?

Аватар пользователя Sinkora Sinkora 13 мая 2010 в 16:08

"PVasili" wrote:
Насколько в вас проблемно открыть: http://drupaler.ru/module?[/quote]
Так эта страница скорее всего полностью берется из кеша:) Вопрос: как долго эта страница генерируется перед попаданием в кеш?

Аватар пользователя Paldru Paldru 19 мая 2010 в 3:47

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

Аватар пользователя Shift-Web Shift-Web 19 мая 2010 в 5:35

«Вопрос для сеошников: если сразу заменить на сайте все алиасы (почти 10 тыс. штук), за это поисковики не обидятся на сайт?»

Обидятся, но временно ))) Если в материалах хэндлерная перелинковка, то еще и вы припотеете

«Меня уже тоже напрягает pathauto, а "node" как-то не кошерно»

Я вот тоже топчусь и не знаю за что схватится покошернее ))) Ноды стрёмно, а пасавто - говнец.

«+1, может стоит подумать о своей "правильной" CMS, чем обтачивать напильником этот "тормознутый" drupal...»

Предложите ))))
Инкубаторный ВП с вообще нулевой гибкостью?
Друшлак-джумла, где напильником махать дольше и потливее без результатов?
DLE с ублюдочной инлайновстью и дрочерной модульно-тимплейтной системой AJAX?
MODx?
Vbullenin + VBAdvanced = смерть в сексе с шаблонами через админку?
Дохлый MaxSite?
мамонт Bitrix и лям в придачу на расширение?
Уж лучше тогда SMARTY+PEAR xD

А еще лучше всё таки заниматься сексом с друпалом )))) Тут хоть какой-то унисон просматривается )

«В 10 раз: - лишние $5 на нормальный хостинг обойдутся дешевле, чем все извращения и возможные глюки»

Ыыыыыы ))) Что такое нормальный хостинг? Панельки, рюшечки, кнопочки ))) У меня хостинг стоит 780 рублей в год вместе с адресом, при этом памяти 256 сейчас(сначала на 64 извращался для оценки, вчера таки залез в сеттингс и включил - эффект прироста не ошущаю) )))

Хостинги ... Видели мы хостинги ))) Человек получает удобство, в 2 клика разворачивает профильный конфиг движка, в котором даже права на файлы не сконфигурированы, а дальше трындец )))) Вот лично я как-то уже насмотрелся на панельки ... Нахрен они не нужны )

Аватар пользователя Shift-Web Shift-Web 19 мая 2010 в 5:37

В друпале секса не меньше, но все эти наработки делаются один раз. Теоретически можно получить то что надо для себя, то, с чем будет приятно и удобно работать себе.

Аватар пользователя Shift-Web Shift-Web 19 мая 2010 в 5:43
function custom_url_rewrite_outbound(&$path, &$options, $original_path) {
  if (preg_match('|^node(/.*)|', $path, $matches)) {
    $path = 'id'. $matches[1];
  }
}
function custom_url_rewrite_inbound(&$result, $path, $path_language) {
  if (preg_match('|^id(/.*)|', $path, $matches)) {
    $result = 'node'. $matches[1];
  }
}

На глаз понравилось, спасибо буду пробовать.

«Совсем фиговая идея... Есть стандартное средство - вынести перевод в settings.php и не париться. Выносится только то, что нужно, т.е. админка оставляют не локализованной, чтобы не раздувать settings.php»

Надо попробовать...

Аватар пользователя Sinkora Sinkora 19 мая 2010 в 10:59

"Paldru" wrote:
Тут на форуме както обсуждался модуль кеширования алиасов. Некисло увеличивалась производительность сайта. Но модуль сырой, были баги, сейчас его насколько я знаю никто не развивает.

Я знаю, я читал ту статью. Но мне не понравилась сама идея кеширования алиасов, по сравнению с возможностью отключения модулей path, pathauto, очистки таблицы url_alias и использования hook_menu для создания своих адресов.

Более правильно, как мне кажется, строить адреса динамически, а не хранить каждый алиас в базе. Т.е. вместо тысячи алиасов типа article/1, article/2, ... article/1000 лучше хранить одну запись article/% в таблице menu_router.

Аватар пользователя Shift-Web Shift-Web 19 мая 2010 в 20:09

"xxandeadxx" wrote:
2Shift-Web, научишь наконец оформлять чужие цитаты — [_quote_][/_quote_]

Можно пимпу покруптее? ))) Вечно забываю где она ))))