Избавляемся от modules в адресе

[ZlydenGL]

Yrich, а зачем его трогать-то? Ведь "старые" ссылки точно так же остаются функционирующими и доступными Мне вообще помимо описанных выше модификаций делать не пришлось - а там, как видишь, упоминаний о модуле news вообще нету

[ZlydenGL]

Еще забыл про один момент - после данного хака надо обязательно поправить файл robots.txt - все запреты в нем, прописанные через modules, становятся невалидными Я сделал следующим образом: в конец списка disallow добавил следующие секции:

Disallow: /*submit.php
Disallow: /*visit.php
Disallow: /*post.php
Disallow: /*reply.php
Disallow: /*rate*.php
Disallow: /*broken*.php

Получились универсальные запреты для большинства штатных модулей (по крайней мере для news, myarticles, mylinks, mydownloads, newbb_plus). Как говорится, краткость - сестра таланта Проверил инструментами от Яндекса/Гугля - такие конструкции прокатывают на ура.

Осталась только одна часть, которую масками не выкинешь - это Disallow: /*mod*.php (если поставить такую инструкцию, то все ссылки через modules станут невалидными), ее надо делать для каждого из использующих файлы mod*.php модулей.

[ZlydenGL]

К конце концов я все-таки перетащил сайтик жены на nginx, и сразу выяснилась презабавнейшая штука. В свое время, еще когда этот сайтик жил на виртуальном хостинге, начались проблемы после увеличения аудитории до 1000 уников в сутки, а работать с включенным оптимизатором статического контента (так мастерхостовцы хитро обозвали nginx) не получалось - rewrute для статического контента, расположенного в папках модулей, не отрабатывался, в результате на выходе получался mess.

Каким же я был болваном, поверившим в байки "спецов" мастерхоста, и верившим до недавнего времени, что подобную схему реврута будет построить сложно вообще и невозможно для виртуального ТП! А все оказалось до безумия просто: чтобы работала схема данного реврута, надо всего лишь в секцию-обработчик статического контента сайта добавить ОДНУ строку:

PHP код:

try_files $uri /modules/$uri; 


Если в этом случае возникают проблемы с генерацией миниатюр в момент обращения к файлу миниатюры, достаточно добавить третий параметр

PHP код:

try_files $uri /modules/$uri @toapache; 


и создать дополнительную секцию

PHP код:

section @toapache {
proxy_pass path_to_proxy;
} 


И все! Эх, были бы у меня эти знания - просидел бы на виртуальном хостинге как минимум до 1500 уников ИМХО.

[ZlydenGL]

И еще одна заметка "в копилку мастера".

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

Решение для newbb_plus элементарное: в файле /modules/newbb_plus/config.php нужно строку

PHP код:

$bbCookie['path'] = str_replace(basename($_SERVER['PHP_SELF']),"",$_SERVER['PHP_SELF']); 


заменить на

PHP код:

$bbCookie['path'] = str_replace("/modules/","/",str_replace(basename($_SERVER['PHP_SELF']),"",$_SERVER['PHP_SELF'])); 


И все начинает работать!