Итак, вспомним ещё раз про короткие урлы (в дальнейшем - КУРЛы, © baev), про достоинства и необходимость которых тут уже немало сказано.

Большинство рассмотренных ранее способов их реализации для PostNuke основаны на перезаписи URL с помощью mod_rewrite (методы MTModular, Karateka). Это очень мощный модуль Apache, с помощью которого можно создавать самые замысловатые условия перезаписи; даже краткий обзор его возможностей занял бы значительное время. Но при его использовании есть и некоторые минусы:

• данный модуль не всегда подключен (ограничения хостинга или какие-либо другие причины);
• модуль ресурсоёмкий, может (теоретически) значительно повысить нагрузку на сервер, что актуально при ограничениях у хостера; хотя лично я о таких проблемах не слышал;
• сложные реврайты (RewriteRule) в .htaccess с использованием регулярных выражений требуют очень внимательной настройки, при малейшей ошибке (синтаксис, порядок правил) перезапись урлов будет работать некорректно либо не будет работать вообще (давно вы видели 500 ошибку?)

Поэтому давайте рассмотрим другие, альтернативные способы обработки КУРЛов. Оставим за бортом способ, основанный на обработке 404 ошибки - считаю его совершенно неприменимым, не только по отношению к PN, но и вообще.

Допускаем, что самим движком КУРЛы уже сформированы; обычно для PostNuke они строятся по определённым правилам путём прогонки буферизированного содержимого сгенерированной страницы через функцию замены; при этом время общей генерации страницы может увеличиться почти в 2 раза (по наблюдениям и отзывам). Есть и другие способы, например, когда урлы формируются непосредственно модулем, но этот метод не универсальный, требующий вмешательства в код модулей и ядра, и для повсеместного применения рекомендовать его не могу (хотя сам использую).

Нам требуется по этим КУРЛам получить доступ к страницам, интерпретируя их в понятную для PN форму, т.е. заменить на этом этапе mod_rewrite.

1. Способ первый: не совсем КУРЛы, а «сокращённые», например, такого вида: index.php?article=1234 (для новостей)

При этом не требуется .htaccess, весь разбор полётов происходит в index.php.
После строк:

pnInit();
list($module, $func, $op, $name, $file, $type) = 
  pnVarCleanFromInput('module', 'func', 'op', 'name', 'file', 'type');

пишем:

if (isset($article)) {
  settype($article,"integer");
  $op = "modload";
  $name = "News";
  if ($article > 0) {
    $file = "article";
  } else {
    $file = "index";
  }
  $sid = $article;
}

Получили $sid статьи, дальше всё как обычно.

Достоинства - не зависим от параметров хостинга, не требуется .htaccess, работает быстро, поисковики такие урлы легко проглатывают.

Недостатки: требуется оперативное вмешательство в код PN (index.php и, возможно, модулей).

2. Способ второй, основанный на использовании директивы <FilesMatch>, которая является Apache Core Feature, т.е. не требует подключения дополнительных модулей. В отличие от директивы <Files>, в ней можно использовать регулярные выражения.

Требования: нужен доступ к .htaccess.

Дано: урлы вида article1234.html (для новостей) и doc1234.html (например, страницы модуля Subjects).

Пишем .htaccess:

Action throw /index.php

<FilesMatch "^(article|doc)([1-9][0-9]*).html$">
ForceType throw
</FilesMatch>

Теперь обработка всех подобных урлов передаётся index.php

Если же написать что-то вроде <FilesMatch "^([^\.]+)$"> - тогда вообще все ссылки (кроме содержащих точку - например, картинки) будут передаваться index.php

Правим index.php (вставляем в начало):

// articleXXXX.html
if (ereg("^/article([0-9]+).html$", $REQUEST_URI, $match)) {
  $article = $match[1];
}

Теперь в переменной $article имеем числовой параметр (в данном случае - CID статьи). Аналогично для doc1234.html:

// docXXXX.html
if (ereg("^/doc([0-9]+).html", $REQUEST_URI, $match)) {
  $doc = $match[1];
}

Далее идёт код, рассмотренный в п.1 - формируем значения параметров $name, $op, $file, $sid.

Ограничения: где-то было написано, что для правильной работы ForceType нужно, чтобы PHP был подключен к Apache как модуль; если как CGI - то работать не будет. Такая проблема могла встретиться на windows-платформе, на *nix-хостинге всё работает нормально. Хотя я с подобным не сталкивался - локально под windows на Denver'е всё прекрасно работает.

Достоинства: красивые и легко запоминающиеся урлы, которые очень нравятся поисковикам, быстро работает (во всяком случае, быстрее, чем с mod_rewrite).

Недостатки: требует .htaccess + недостатки п.1.

3. Способ третий: КУРЛы вида index.php/news/1234 (как в Xaraya).
Не требуется .htaccess, обработка урлов происходит в index.php:

// index.php/news/XXXX
if (ereg("^/index.php/news/([0-9]+)$", $REQUEST_URI, $match)) {
  $article = $match[1];
}

Далее - код из п.1.

Достоинства: красивые запоминающиеся урлы; особенно подходят, если в дальнейшем планируется переход на Xaraya.

Недостатки: всё из п.1 + необходимо корректно составленная тема и прописанные абсолютные ссылки, т.к. относительные ссылки в данном случае будут уже не от корня сайта, а от текущей страницы. Возможно лечить указанием в заголовке страницы base href (но в этом случае могут быть проблемы со ссылками внутри страницы). Кому-то может не нравится наличие index.php в урл - его тоже можно убрать, но лучше этого не делать :-)

При всех способах корректно работают ссылки на якоря внутри страницы (вида <a name="anchor"></a>).