Маршрутизация во фреймворках: CUrlManager в Yii

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

Первая часть: Маршрутизация во фреймворках: Управление адресами URL

Маршрутизация в Yii Framework

Читателя, освоившего первую часть, можно поздравить с тем, что он теперь знает принцип работы маршрутизации в Yii. Да-да, достаточно немного улучшить «придуманный» нами код, и мы получим классы CUrlManager и CUrlRule этого фреймворка.

Компонент Yii::app()->urlManager по умолчанию является экземпляром класса CUrlManager и описывается как и другие компоненты в конфигурационном файле. После создания приложения командой yiic webapp секция этого компонента в конфигурационном файле имеет вид:

return array(
    ...
    'components'=>array(
        ...
 
        'urlManager'=>array(
            'urlFormat' => 'path',
            'rules'=>array(
                '<controller:\w+>/<id:\d+>' => '<controller>/view',
                '<controller:\w+>/<action:\w+>/<id:\d+>' => '<controller>/<action>',
                '<controller:\w+>/<action:\w+>' => '<controller>/<action>',
            ),
        ),
 
        ...
    ),
);

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

Если вообще убрать имеющиеся правила, то маршрут post/view подставится в первозданном виде и параметр id просто передастся в GET строке:

http://site.com/index.php/post/view?id=52

А если не убирать, то сгенерированный адрес для маршрута post/view в соответствие с первым правилом будет выглядеть так:

http://site.com/index.php/post/52

Если же поменять значение 'urlFormat'=>'path' на 'urlFormat'=>'get', то адресация будет производиться простыми GET параметрами:

http://site.com/index.php?r=post&id=52

Для передачи маршрута в обычном GET запросе в Yii по умолчанию используется параметр r.

Настройка человекопонятных адресов в Yii

Чтобы наиболее эффективно воспользоваться преобразованиями адресов мы выберем вариант с 'urlFormat'=>'path', но уберём index.php из адреса.

Сначала нужно настроить соответствующим образом наш сервер на перенаправление всех запросов в файл index.php, как мы делали это вначале:

Конфигурация Apache (.htaccess):

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php

Конфигурация Nginx:

server {
    ...
    location / {
        index index.html index.php;
        try_files $uri $uri/ /index.php?$args;
    }
}

Теперь можем убрать имя файла index.php из адреса, указав 'showScriptName'=>false:

'urlManager'=>array(
    'urlFormat' => 'path',
    'showScriptName'=>false,
    'urlSuffix' => '',
    'rules'=>array(
        'feed.xml' => array('post/feed', 'urlSuffix' => ''),
        '<controller:\w+>/<id:\d+>' => '<controller>/view',
        '<controller:\w+>/<action:\w+>/<id:\d+>' => '<controller>/<action>',
        '<controller:\w+>/<action:\w+>' => '<controller>/<action>',
    ),
),

Теперь если мы зайдём по адресу

http://site.com/post/update/1

то согласно третьему правилу выполнится действие post/update и GET-параметру id присвоится значение 1. Для удобства в Yii сделано так, что параметры для подстановки можно указывать как аргументы метода действия:

class PostController extends Controller
{
    public function actionUpdate($id) {
        echo $id; // выведет '1'
    }
}

Заодно мы попробовали добавить правило для обработки feed.xml:

'feed.xml' => array('post/feed', 'urlSuffix' => ''),

Почему же мы сделали это таким способом? Мы же могли это сделать так:

'feed.xml' => 'post/feed',

Параметр urlSuffix, который мы уже упоминали, позволяет задать дополнение к адресу. Но этот параметр есть как у отдельных правил, так и у самого менеджера.

Для всего менеджера можно указать, например, значение .html, и всюду добавится этот суффикс. Например, страница авторизации и запись блога будет открываться теперь по адресу:

http://site.com/site/login.html
http://site.com/post/52.html

А теперь представим, что мы вписали в шаблон правила непосредственно feed.xml и захотели добавить глобальный суффикс .html:

'urlManager'=>array(
    ...
    'urlSuffix' => '.html',
    'rules'=>array(
        'feed.xml' => 'post/feed',
    ),
),

Не обнули мы суффикс для нашего правила, система сгенерировала бы адрес:

http://site.com/feed.xml.html

что не очень хорошо.

Так что эти способы правильны и равнозначны:

'feed.xml' => array('post/feed', 'urlSuffix' => ''),
'feed' => array('post/feed', 'urlSuffix' => '.xml'),
array('template' => 'feed', 'route' => 'post/feed', 'urlSuffix' => '.xml'),
array('template' => 'feed.xml', 'route' => 'post/feed', 'urlSuffix' => ''),

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

Дабы посмотреть все возможные настройки откройте файлы CUrlManager и CUrlRule. Посмотрите имеющиеся у них публичные поля. Любое из них можно настраивать подобным образом. Некоторые параметры мы рассмотрим ниже.

В любом случае, в правиле должен быть указан целевой маршрут в формате контроллер/действие или модуль/контроллер/действие и шаблон в формате, к которому мы пришли в первой части.

Расположение методов createUrl и createAbsoluteUrl

Как видно из настроек компонента, менеджер адресов доступен в приложение как компонент

Yii::app()->urlManager

Метод parseUrl нам вряд ли понадобится вызывать. Его приложение вызывает само для определения того, какое действие какого контроллера нужно выполнить. Метод createUrl есть как в самом менеджере, так и в классах правил. Методы правил мы вручную не вызываем (этим занимается менеджер, обходя по очереди все правила). Соответственно, нам понадобится только метод createUrl менеджера маршрутизации.

Его мы можем вызвать прямо у компонента парой способов:

echo Yii::app()->urlManager->createUrl('post/feed');
echo Yii::app()->getUrlManager()->createUrl('post/feed');

Для удобства использования аналогичный вспомогательный метод есть в классе самого приложения:

class CApplication
{
    ...
    public function createUrl($route, $params=array(), $ampersand='&')
    {
        return $this->getUrlManager()->createUrl($route, $params, $ampersand);
    }
    ...
}

Он позволяет записывать обращение короче:

<?php
<a href="<?php echo Yii::app()->createUrl('post/feed'); ?>">RSS</a>

Это правило сгенерирует относительный адрес от корня сайта:

<?php
<a href="/feed.xml">RSS</a>

По соседству в менеджере присутствует метод createAbsoluteUrl, который достраивает адрес до абсолютного:

<?php
<a href="<?php echo Yii::app()->createAbsoluteUrl('post/feed'); ?>">RSS</a>

Это правило сгенерирует абсолютный адрес:

<?php
<a href="http://site.com/feed.xml">RSS</a>

Указание полного адреса бывает полезно для построения карты сайта, адресов в RSS и для встраивания кнопок «Мне нравится» социальных сетей.

Третий способ немного отличается от первых двух. Его мы рассмотрим подробнее.

Метод createUrl контроллера

Третьим способом генерации ссылок является вызов одноимённого вспомогательного метода в контроллере:

class CController
{
    ...
    public function createUrl($route,$params=array(),$ampersand='&')
    {
        if($route==='')
            $route=$this->getId().'/'.$this->getAction()->getId();
        elseif(strpos($route,'/')===false)
            $route=$this->getId().'/'.$route;
        if($route[0]!=='/' && ($module=$this->getModule())!==null)
            $route=$module->getId().'/'.$route;
        return Yii::app()->createUrl(trim($route,'/'),$params,$ampersand);
    }
}

Пока не будем обращать внимания на его содержимое.

Его мы можем вызывать от от контроллера, то есть от указателя $this в контроллере или в представлении:

<?php
<a href="<?php echo $this->createUrl('/post/feed'); ?>">RSS</a>

В других компонентах (например, в виджетах) нужно сначала получить сам контроллер, который хранится в Yii::app()->controller, и вызвать метод у него:

<?php
<a href="<?php echo Yii::app()->controller->createUrl('/post/feed'); ?>">RSS</a>

или воспользоваться вызовом Yii::app()->createUrl(...).

Теперь рассмотрим назначение добавленного в метод CController::createUrl функционала.

Если ваше приложение использует модули, то можно указать маршруты по умолчанию для них:

'urlManager'=>array(
    'urlFormat' => 'path',
    'showScriptName'=>false,
    'urlSuffix' => '',
    'rules'=>array(
 
        ''=>array('site/index', 'urlSuffix' => ''),
        '<action:login|logout|register>' => 'site/<action>',
        'feed.xml'=>array('blog/post/feed', 'urlSuffix' => ''),
        '<module:\w+>/<controller:\w+>/<id:\d+>' => '<module>/<controller>/view',
        '<module:\w+>/<controller:\w+>/<action:\w+>/<id:\d+>' => '<module>/<controller>/<action>',
        '<module:\w+>/<controller:\w+>/<action:\w+>' => '<module>/<controller>/<action>',
 
    ),
),

Обратите внимание на первое правило. По умолчанию при входе на главную страницу сайта сработает действие по умолчанию index контроллера, указанного в параметре defaultController приложения (по умолчанию это site). Чтобы изменить домашнюю страницу сайта можно либо указать другое значение параметру defaultController в конфигурациооном файле, либо добавить указанное первое правило и указать там свой маршрут.

Метод Yii::app()->createUrl всегда генерирует независимую ссылку по переданному ему маршруту.

Представим, что мы используем модули и у нас есть модуль blog.

Тогда вызов:

echo Yii::app()->createUrl('blog/post/update', array('id'=>1));

сгенерирует ссылку от корневого адреса приложения:

/blog/post/update/1

А метод $this->createUrl(...) находится в контроллере и обучен производить относительную адресацию от текущего модуля, контроллера и действия.

Если вы находитесь в blog/post/index, то, например, запись:

echo $this->createUrl('blog/post/update', array('id'=>1));

сгенерирует то же самое:

/blog/post/update/1

Теперь попробуем поэкспериментировать, убрав часть blog/ и оставив только post/update:

echo $this->createUrl('post/update', array('id'=>1));

Даже в этом случае мы получим такой же адрес.

Продолжим эксперимент:

echo $this->createUrl('update', array('id'=>1));

И сейчас адрес не изменился, хотя мы и оставили только имя действия.

Но поробуем запустить этот же код в действии actionIndex контроллера ProductController модуля ShopModule:

echo $this->createUrl('update', array('id'=>1)) . PHP_EOL; // (1)
echo $this->createUrl('post/update', array('id'=>1)) . PHP_EOL; // (2)
echo $this->createUrl('blog/post/update', array('id'=>1)) . PHP_EOL; // (3)
echo $this->createUrl('', array('id'=>1)) . PHP_EOL; // (4)
echo $this->createUrl('site/login') . PHP_EOL; // (5)
echo $this->createUrl('/site/login') . PHP_EOL; // (6)

Вот такие адреса мы увидим на экране:

/shop/product/update/1
/shop/post/update/1
/blog/post/update/1
/blog/product/index/1
/shop/site/login
/login

Метод CController::createUrl генерирует ссылку относительно текущего действия. Случай (1) сохранил текущий контроллер и модуль и построил новый адрес /shop/product/update/1 (вроде относительной адресации в консоли cd ../update). Случай (2) поднялся от текущего действия на два уровня вверх (как cd ../../post/update) и сохранил только текущий модуль. Соответственно, пустой $this->createUrl('') в случае (3) по принципам относительной адресации сгенерирует ссылку на тот же маршрут shop/product/index.

Относительная маршрутизация удобна для упрощения копировании кода CRUD одного модуля в другой, так как в маршрутах можно не указывать имя модуля. Вызов $this->createUrl('index') будет правильно ссылаться на actionIndex того контроллера, в котором он производится. Кнопки CButtonColumn виджета CGridView, например, используют контекст контроллера:

Yii::app()->controller->createUrl('update', array('id'=>$data->primaryKey));

Это позволяет им по умолчанию ссылаться на действие actionUpdate в любом текущем контроллере любого модуля.

Соответственно, нужно быть осторожным при использовании $this, так как относительная от текущего модуля ссылка $this->createUrl('site/login') в случае (5) может вас из модуля магазина нечаянно завести на несуществующий адрес /shop/site/login. Так что ссылаясь из одного модуля в другой нужно либо использовать беспристрастный Yii::app()->createUrl('site/login'), либо не забыть заставить маршрутизатор генерировать адрес от корня, добавив слэш вначале: $this->createUrl('/site/login'). Как в случае (6) вкупе со вторым правилом маршрутизации:

'<action:login|logout|register>' => 'site/<action>',

Помошник CHtml::link

Для генерации той же ссылки на действие редактирования записи post/update из действия post/admin можно воспользоваться как непосредственным вызовом метода createUrl:

<?php
<a href="<?php echo Yii::app()->createUrl('post/update', array('id'=>1)); ?>">Редактировать</a>
<a href="<?php echo $this->createUrl('update', array('id'=>1)); ?>">Редактировать</a>

Так и воспользовавшись помощником CHtml::link:

<?php
<?php echo CHtml::link('Редактировать', $this->createUrl('update', array('id'=>1))); ?>
<?php echo CHtml::link('Редактировать', array('update', 'id'=>1)); ?>

В первой строке мы сами сгенерировали адрес и передали этому методу для построения тега <a href="...">...</a>, а во второй мы передали всё необходимое для построения адреса самому помошнику. Это можно сделать в форме массива:

<?php
<?php echo CHtml::link('Редактировать', array('update', 'id'=>$model->id)); ?>
<?php echo CHtml::link('Все записи', array('index')); ?>

Рассмотрим код меню из шаблона официального демо-блога:

<?php
<div id="mainmenu">
    <?php $this->widget('zii.widgets.CMenu',array(
        'items'=>array(
            array('label'=>'Home', 'url'=>array('post/index')),
            array('label'=>'About', 'url'=>array('site/page', 'view'=>'about')),
            array('label'=>'Contact', 'url'=>array('site/contact')),
            ...
        ),
    )); ?>
</div><!-- mainmenu -->

Мы можем заметить, что адреса элементов для виджетов CMenu (и CBreadcrumbs тоже) передаются аналогично в виде массива. Внутри этих виджетов для построения ссылок вызывается тот же помошник CHtml::link.

Если изучить исходный код метода CHtml::link, то можно увидеть, что по умолчанию он использует контекст контроллера. Если ему вместо адреса передаётся массив

array('site/page', 'view'=>'about')

то он извлекает первый элемент и использует его как маршрут при вызове метода createUrl контроллера:

Yii::app()->getController()->createUrl('site/page', array('view'=>'about'))

Способы построения адресов и ссылок мы рассмотрели. Перейдём к обзору некоторых дополнительный возможностей.

Дополнительные параметры маршрутизатора CUrlManager

Дополнительные опции маршрутизатора можно найти в самом классе CUrlManager. Рассмотрим здесь некоторые из них.

Предположим, что мы сделали наше приложение и прописали правила маршрутизации. Нас сразу же поджидают некоторые неприятности.

Во-первых, мы можем прописывать в адресной строке любой регистр:

http://site.com/blog/post/1
http://site.com/BLOg/POst/1

На это можно и не обращать внимания, но можно включить строгую слежку за регистром, добавив в параметры компонента urlManager значение 'caseSensitive'=>true.

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

http://site.com/blog/post/1
http://site.com/blog/post/view?id=1
http://site.com/index.php/blog/post/1
http://site.com/index.php?r=/blog/post/1
http://site.com/index.php?r=/blog/post/view?id=1

Также главную страницу сайта можно открыть несколькими способами:

http://site.com/
http://site.com/site
http://site.com/site/index
http://site.com/index.php/site
http://site.com/index.php/site/index
http://site.com/index.php?r=/site
http://site.com/index.php?r=/site/index

Конечно же на самом сайте таких ссылок не будет, так как они у нас будут генерироваться по правилам, но наш сосед (который знает, что мы сделали сайт на Yii) может нарочно надобавлять десятки таких ссылок в свои сообщения на форумах и в Twitter. В итоге в индексе поисковых систем вместо ста страниц сайта будут тысячи копий одних и тех же текстов, что может расцениваться поисковиками как спам.

Чтобы избежать дублирования контента можно заставить менеджер маршрутизации работать только по правилам опцией 'useStrictParsing'=>true.

Если у нас есть правила по умолчанию в таком виде:

'<module:\w+>' => '<module>/default/index',
'<module:\w+>/<controller:\w+>' => '<module>/<controller>/index',
'<module:\w+>/<controller:\w+>/<id:\d+>' => '<module>/<controller>/view',
'<module:\w+>/<controller:\w+>/<action:\w+>/<id:\d+>' => '<module>/<controller>/<action>',
'<module:\w+>/<controller:\w+>/<action:\w+>' => '<module>/<controller>/<action>',

То теперь главная страница блога может открываться только тремя вариантами по первому, второму и пятому правилу:

http://site.com/blog
http://site.com/blog/default
http://site.com/blog/default/index

Чтобы избежать такого дублирования следует отказаться от правил по умолчанию вовсе и прописывать все возможные варианты вручную:

'blog' => 'blog/default/index',
'blog/category/<id:\d+>' => 'blog/default/category',
'blog/tag/<tag:[\w-]+>' => 'blog/default/tag',
'blog/<action:update|delete>/<id:\d+>' => 'blog/post/<action>',
'blog/<action:create>' => 'blog/post/<action>',
'blog/<id:\d+>' => 'blog/post/view',

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

Итак, чтобы избежать дублирования страниц необходимо прописать все возможные варианты адресов вручную и установить 'useStrictParsing'=>true. Может получиться так:

'urlManager'=>array(
    'urlFormat' => 'path',
    'showScriptName' => false,
    'useStrictParsing' => true,
    'caseSensitive' => true,
    'urlSuffix' => '',
    'rules'=>array(
        ...
    ),
),

Прописывание всех правил и включение useStrictParsing – это надёжный, но не единственный вариант. Можно пойти весьма элегантным путём, перенаправляя пользователя со всех неправильных адресов на единственный правильный:

ksort($_GET);
$url = $this->createUrl('', $_GET);
if (Yii::app()->request->getUrl() != $url) {
    $this->redirect($url, 301);
}

Здесь мы собираем правильный адрес (он будет собираться всегда одинаково) и сравниваем его с текущим. Если адреса не совпадают, то делаем редирект на наш правильный.

Дополнительные параметры правила CUrlRule

Из первой части мы помним, что правила можно задавать несколькими способами:

'feed.xml' => 'post/feed',
'feed' => array('post/feed', 'urlSuffix' => '.xml'),
array('template' => 'feed', 'route' => 'post/feed', 'urlSuffix' => '.xml'),

При обработке этих правил менеджер для каждого создаёт экземпляр класса CUrlRule и присваивает его открытым полям urlSuffix, caseSensitive, defaultParams, matchValue, verb, parsingOnly указанные значения.

Мы уже ознакомились с параметрами urlSuffix и caseSensitive менеджера. Внутри правила они работают таким же образом.

Ещё из полей класса CUrlRule в специфических задачах порой используют параметр verb. Он служит для указания метода HTTP-запроса, с которым это правило должно работать.

Это применимо для приобретающей популярность архитектуры REST. Суть её в том, что вместо повсеместного использования форм с method="post" c передачей данных на сервер методом POST воскресают и используются по их исконному прямому назначению все методы GET, PUT, DELETE и POST. При этом они могут ссылаться на один и тот же адрес, но сервером должны обрабатываться в зависимости от типа запроса.

Соответственно, для реализации REST-архитектуры необходимо добавить группу правил для каждого типа запроса:

array('template' => 'blog/posts', 'route' => 'blog/default/index', 'verb' => 'GET'),
array('template' => 'blog/posts/<id:\d+>', 'route' => 'blog/post/view', 'verb' => 'GET'),
array('template' => 'blog/posts/<id:\d+>', 'route' => 'blog/post/update', 'verb' => 'PUT'),
array('template' => 'blog/posts/<id:\d+>', 'route' => 'blog/post/delete', 'verb' => 'DELETE'),
array('template' => 'blog/posts', 'route' => 'blog/post/create', 'verb' => 'POST'),

Теперь в зависимости от метода сработает подходящее ему правило. При необходимости чтобы не копировать одно и то же правило мы можем указывать несколько типов запроса через запятую: 'verb'=>'GET,POST'.

Другие опции используются реже.

Создание своих классов правил

В первой части мы создавали своё правило для маршрутизации статических страниц:

http://site.com/about
http://site.com/services
http://site.com/delivery-information

в виде своего класса. Аналогично мы можем сделать и в Yii. Немного изменятся лишь сигнатуры методов и работа с базой данных:

class PageUrlRule extends CBaseUrlRule
{
    public function parseUrl($manager, $request, $pathInfo, $rawPathInfo)
    {
        if (preg_match('#^([\w-]+)#i', $pathInfo, $matches)) {
            $page = Page::model()->find(array(
                'condition' => 'alias = :alias',
                'params' => array('alias'=>$matches[1]),
            ));
            if ($page !== null) {
                $_GET['id'] = $page->getPrimaryKey();
                return 'page/default/view';
            }
        }
        return false;
    }
 
    public function createUrl($manager, $route, $params, $ampersand)
    {
        if ($route == 'page/default/view') {
            if (!empty($params['id'])) {
                if ($page = Page::model()->findByPk($params['id'])) {
                    return $page->alias;
                }
            }
        }
        return false;
    }
}

Теперь добавим наше правило с указанием класса перед правилами по умолчанию:

<?php
...
array('class'=>'PageUrlRule'),
'<module:\w+>' => '<module>/default/index',

Это правило сработает только для существующих страницы /about и пропустит мимо себя запрос модуля /blog.

При создании правила мы отнаследовались от класса CBaseUrlRule вместо CUrlRule, поэтому никакие опции вроде urlSuffix и verb у в нашем правиле работать не будут, так как их в нашем классе нет. При желании мы можем самостоятельно добавить любые параметры в свой класс:

class PageUrlRule extends CBaseUrlRule
{
    public $urlSuffix = '';
    public $verb = '';
    ....
}

и реализовать их поддержку вручную в методах parseUrl и createUrl. Например, если urlSuffix не указан, то его по умолчанию можно взять равным значению Yii::app()->urlManager->urlSuffix.

Работа с поддоменами

В шаблонах правил маршрутизации именованные параметры можно использовать в каком угодно месте. Даже при необходимости можно указывать их на месте поддомена сайта. Это может пригодиться, например, если вы захотите разместить профили пользователей на поддоменах:

'http://<username:\w+>.site.com/profile' => 'user/profile',

Так сделано на многих блог-платформах, например LiveJournal.com. Достаточно лишь настроить сервер так, чтобы запросы ко всем поддоменам ссылались на одну директорию с нашим файлом index.php на сервере.

Но как быть с остальными правилами? Ведь если мы перейдём на поддомен пользователя, то с нашими правилами:

''=>array('site/index', 'urlSuffix' => ''),
'<action:login|logout|register>' => 'site/<action>',
 
'blog' => 'blog/default/index',
'blog/<action:update|delete>/<id:\d+>' => 'blog/post/<action>',
'blog/<action:create>' => 'blog/post/<action>',
'blog/<id:\d+>' => 'blog/post/view',
 
'http://<username:\w+>.site.com/profile' => 'user/profile',

мы сможем прочитать блог этого пользователя, но не сможем вернуться обратно на главный поддомен, например на страницу http://www.site.com/login. Чтобы это было возможно нам необходимо будет явно указать основной поддомен www.site.com у необходимых правил:

'http://www.site.com/' => 'site/index',
'http://www.site.com/<action:login|logout|register>' => 'site/<action>',
 
'blog' => 'blog/default/index',
'blog/<action:update|delete>/<id:\d+>' => 'blog/post/<action>',
'blog/<action:create>' => 'blog/post/<action>',
'blog/<id:\d+>' => 'blog/post/view',
 
'http://<username:\w+>.site.com/profile' => 'user/profile',

Теперь на каком бы поддомене мы ни находились, пункт меню

<?php
<a href="<?php echo Yii::app()->createUrl('site/register'); ?>">Регистрация</a>

всегда будет вести на основной сайт:

<?php
<a href="http://www.site.com/register">Регистрация</a>

Ресурсы по теме

Здесь мы рассмотрели только основные моменты работы с маршрутами в Yii. Дополнительную информацию можно получить из статьи Управление URL официального руководства Yii.

Также могут быть полезными другие материалы на этом сайте:

• Генерация URL для вложенных категорий (со слэшами)
• Загрузка правил маршрутизации из модулей
• Беседа о маршрутизации в Yii и Yii2

В любом случае эта тема достаточно обширная. Многие общие и специфические моменты также описаны в книгах по Yii Framework.