Сделать правильнее сделать 301 Moved Permanently

[musson]

Всем привет))
Перенес сайт с cms написанной на .Net на Typo3.
Все страницы раньше имели путь типа site.ru\contact.aspx ,
сейчас структура сайта такая же только расширение разное, с aspx поменялось на html.
Так как сайту уже год, поисковики уже проиндексировали сайт. Т.е. хочется чтобы при запросе скажем site.ru\contact.aspx typo3 выдавала 301 Moved Permanently и перекидывал на site.ru\contact.html т.е. просто достаточно менять с aspx на html т.к. структура осталась такая же.
Как это лучше реализовать?
К typo3 прикручен realurl.

[musson]

сделал вот так, добавил в index.php

$linkRequest = $_SERVER['REQUEST_URI'];
if(preg_match("/.aspx$/",$linkRequest))
{
$toRedirect = preg_replace("/(.aspx$)/",".html", $linkRequest);
header('HTTP/1.1 301 Moved Permanently');
header('Location: http://www.site.ru'.$toRedirect);
exit();
}


либо


RewriteBase /
RewriteRule ^(.*)\.aspx$ $1.html [R=permanent,L]

[-=UncleByte=-]

Редиректы самого сервера работают быстрее и не надо ничего менять в ядре системы.

[dmartynenko]

Обнаружилась проблема с новым RealURL.
Одинаковый контент выдается как для урлов вида page/ и page.html
Раньше это решалось установкой в конфиге acceptHTMLsuffix = 1, но в последних версиях этот параметрв хоть и объявляется и описан в доке, но реально в коде не учитывается. Похоже что "принятие" урлов с .html зашито в коде, так как другие урлы, например .htm выдают 404 ошибку.

Попробовал в .htaccess такое решение:

RewriteBase /
RewriteRule ^(.*)\.html$ $1/ [R=permanent,L]

Работает - но теперь перестали работать страницы "версия для печати", урл которых конфигом RealURL был задан как .../page.html

Что посоветуете?

Updated: единственное что пока удалось сделать что бы все работало - поменять print.html на print.htm

[-=UncleByte=-]

А если этот самый атрибут print транслировать просто в /адрес_страницы/ptint/ ?

[dmartynenko]

Не получиться в .../print/
Так как RealURL умеет добавлять фиксированные переменные только в начало пути, т.е. /en/... или /print/...
Добавить "в самый конец" можно только опцией fileName.

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

Самое главное, что для SEO плохо что page/ и page.html выдают одно и тоже, а это поведение что называется "из коробки".

[-=UncleByte=-]

Так на самом деле вполне будет логично выглядеть url типа domain.tld/print/page/id/ - и совершенно точно он не будет отзываться ни на какие *.html
Хотя, насколько я помню при использовании .htaccess в мануале к RealURL был комментарий к какой-то строке "при использовании такой настройки filename работать правильно не будут" (это вольный перевод - передача общего смысла фразы). Можеть быть дело в этом?
Потому что у меня работает вроде как вполне адекватно все и при использовании .html и без него.

[dmartynenko]

Так на самом деле вполне будет логично выглядеть url типа domain.tld/print/page/id/ - и совершенно точно он не будет отзываться ни на какие *.html

Судя по тому какое поведение я наблюдаю сейчас на последнем RealURL, то получиться что и в этом случае domain.tld/print/page/id/ и domain.tld/print/page/id.html будут показывать одно и тоже.

РЕШЕНИЕ!

Все оказалось просто, но не очевидно. В новой версии проверка наличия суффикса делается вот так:

protected function decodeSpURL_decodeFileName_checkHtmlSuffix($fileNa me, $segment, $extension, array &$pathParts) {
$handled = false;
if (isset($this->extConf['fileName']['defaultToHTMLsuffixOnPrev'])) {
$suffix = $this->extConf['fileName']['defaultToHTMLsuffixOnPrev'];
$suffix = (!$this->isString($suffix, 'defaultToHTMLsuffixOnPrev') ? '.html' : $suffix);
if ($suffix == '.' . $extension) {
$pathParts[] = rawurlencode($segment);
$this->filePart = '.' . $extension;
}
else {
$this->decodeSpURL_throw404('File "' . $fileName . '" was not found (2)!');
}
$handled = true;
}
return $handled;
}


Т.е. даже если defaultToHTMLsuffixOnPrev установлен в ноль в конфиге, то это означает что .html суффиксы будут приняты!

Причем этот конфиг предлагается по умолчанию как в примерах, так и в autoconf, вот кусок из class.tx_realurl_autoconfgen.php

'fileName' => array(
'defaultToHTMLsuffixOnPrev' => 0,
'acceptHTMLsuffix' => 1,
)

Поэтому, что бы суффиксы .html давали 404 ошибку, строку с defaultToHTMLsuffixOnPrev из конфига нужно убрать совсем!

PS: Скорее это просто баг, на это указывает то что при генерации этот параметр учитывается простой проверкой, а не isset()

elseif ($url != '') {
$suffix = $this->extConf['fileName']['defaultToHTMLsuffixOnPrev'];
if ($suffix) {

[-=UncleByte=-]

Скорее надо выставить acceptHTMLsuffix в 0 - тогда RealURL не будет его воспринимать как еще один вариант именования страницы. Насколько помню это сделано для упрощения миграции со статичных сайтов на динамические.

[dmartynenko]

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

[-=UncleByte=-]

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

[dmartynenko]

Либо документация не поспевает, либо код переработан и этот параметр просто "забыли".
Тот код, что я видел в исходниках RealURL полгода назад, сильно отличается от того что есть сейчас.
Проверить acceptHTMLsuffix легко - берете название параметра и ищите по исходникам где он встречается.

Мой конфиг - самый что ни есть типовой:

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['realurl'][$site_name] = array (
'init' => array (
'enableCHashCache' => true,
'appendMissingSlash' => 'ifNotFile,redirect',
'adminJumpToBackend' => true,
'enableUrlDecodeCache' => true,
'enableUrlEncodeCache' => true,
'emptyUrlReturnValue' => '/',
),
'pagePath' => array (
'type' => 'user',
'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main',
'spaceCharacter' => '-',
'languageGetVar' => 'L',
'segTitleFieldList' => 'tx_realurl_pathsegment,alias,nav_title,title',
'rootpage_id' => 1,
),
'fileName' => array (
// 'defaultToHTMLsuffixOnPrev' => 0,
// 'acceptHTMLsuffix' => 0,
'index' => array (
'print.htm' => array (
'keyValues' => array ('type' => 98),
),
),
)

[-=UncleByte=-]

Я когда столкнулся с глюками при переходе на новую версию RealURL выработал "стратегию" перехода: включить автоконфиг несериализованный, сгенерить его, использовать как болванку для своего. Потому что на самом деле довольно много изменений вносится и не всегда работает ожидаемым образом, в результате изменение настроек лучше всего показывает именно автоконфиг.
Кстати, а внутренние редиректы RealURL выдают 301 код или нет?

[dmartynenko]

Мой конфиг по основным параметрам (исключения то что в ветке выше) идентичен тому, что предлагает autoconfig


/**
* Creates common configuration template.
*
* @return array Template
*/
protected function getTemplate() {
$confTemplate = array(
'init' => array(
'enableCHashCache' => true,
'appendMissingSlash' => 'ifNotFile,redirect',
'adminJumpToBackend' => true,
'enableUrlDecodeCache' => true,
'enableUrlEncodeCache' => true,
'emptyUrlReturnValue' => t3lib_div::getIndpEnv('TYPO3_SITE_PATH')
),
'pagePath' => array(
'type' => 'user',
'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main',
'spaceCharacter' => '-',
'languageGetVar' => 'L',
),
'fileName' => array(
'defaultToHTMLsuffixOnPrev' => 0,
'acceptHTMLsuffix' => 1,
)
);

[-=UncleByte=-]

Проверил на паре сайтов. Везде обновился до последних версий всех плагинов и переводов.
Результаты:

Сайт сконфигурированный на использование суффикса - www.rzhevrealty.ru
На самом деле адрес воспринимается и с суффиксом и без и адрес приводит к одной и той же странице.

Сайт сконфигурированный на использование без суффикса - www.jawaclub.ru
При использовании суффикса выдается 404-я ошибка и страница этой ошибки.

[dmartynenko]

Можете выложить конфиг для RealURL второго сайта (только его начало)?

У вас там кстати есть SEO-недоработка, урл со слэшем в конце и без него выдают одно и тоже:
http://www.jawaclub.ru/prosmotr-novosti
http://www.jawaclub.ru/prosmotr-novosti/

[-=UncleByte=-]

Этот конфиг стопроцентно не мой собственный, брал его вроде бы из wiki.typo3.org давным давно и с тех пор если и менял, то крайне незначительно:

<?php
$TYPO3_CONF_VARS['EXTCONF']['realurl'] = array(
'_DEFAULT' => array(
'init' => array(
'enableCHashCache' => 1,
'appendMissingSlash' => 'ifNotFile',
'enableUrlDecodeCache' => 1,
'enableUrlEncodeCache' => 1,
),
'redirects' => array(),
'preVars' => array(
array(
'GETvar' => 'no_cache',
'valueMap' => array(
'nc' => 1,
),
'noMatch' => 'bypass',
),
array(
'GETvar' => 'L',
'valueMap' => array(
'en' => '2',
'ru' => '1',
),
'noMatch' => 'bypass',
),
),
'pagePath' => array(
'type' => 'user',
'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main',
'spaceCharacter' => '-',
'languageGetVar' => 'L',
'expireDays' => 7,
'rootpage_id' => 2,
),
'fixedPostVars' => array(),
'postVarSets' => array(
'_DEFAULT' => array(
// news archive parameters
'archive' => array(
array(
'GETvar' => 'tx_ttnews[year]' ,
),
array(
'GETvar' => 'tx_ttnews[month]' ,
'valueMap' => array(
'january' => '01',
'february' => '02',
'march' => '03',
'april' => '04',
'may' => '05',
'june' => '06',
'july' => '07',
'august' => '08',
'september' => '09',
'october' => '10',
'november' => '11',
'december' => '12',
)
),
),
// news pagebrowser
'browse' => array(
array(
'GETvar' => 'tx_ttnews[pointer]',
),
),
// news categories
'select_category' => array (
array(
'GETvar' => 'tx_ttnews[cat]',
),
),
// news articles and searchwords
'article' => array(
array(
'GETvar' => 'tx_ttnews[tt_news]',
'lookUpTable' => array(
'table' => 'tt_news',
'id_field' => 'uid',
'alias_field' => 'title',
'addWhereClause' => ' AND NOT deleted',
'useUniqueCache' => 1,
'useUniqueCache_conf' => array(
'strtolower' => 1,
'spaceCharacter' => '-',
),
),
),
array(
'GETvar' => 'tx_ttnews[swords]',
),
),
),
),
// configure filenames for different pagetypes
'fileName' => array(
'index' => array(
'rss.xml' => array(
'keyValues' => array(
'type' => 100,
),
),
'rss091.xml' => array(
'keyValues' => array(
'type' => 101,
),
),
'rdf.xml' => array(
'keyValues' => array(
'type' => 102,
),
),
'atom.xml' => array(
'keyValues' => array(
'type' => 103,
),
),
),
),
),
);?>

А для SEO недоработок такого вида есть sitemap.xml, в котором и указаны все правильные адреса и сам sitemap.xml прописан и в robots.txt и добавлен в поисковики вручную.
Ну и заодно следует учитывать специфику использования только nginx без apache :)

[dmartynenko]

Ваш конфиг является подтверждением моей догадки, у вас нет этой строки: 'defaultToHTMLsuffixOnPrev' => 0
Поэтому .html ваш сайт не принимает!

Если бы вы создали конфигурацию как autoconf и внесли в нее свои правки, то вероятнее всего строка с 'defaultToHTMLsuffixOnPrev' => 0 у вас осталась бы.

А запрет ссылок без "/" на конце делается вот так: 'appendMissingSlash' => 'ifNotFile,redirect'

Keyword: "redirect"
This keyword will force RealURL to redirect to the location with appended slash. This will ensure that pages do not appear doubled in the Google index (and therefore page rank does not suffer).

[-=UncleByte=-]

В том и дело что это не мной написанный конфиг, 5 лет назад я еще не очень подробно разбирался с RealURL и конфиги брал готовые с wiki.typo3.org правя в них исключительно rootpageid.
Добавлять отсутствующий слэш на конце гораздо лучше умеет вебсервер, в том же htaccess приложенном в доке по RealURL одна из строк именно этим и занимается.
В nginx это тоже можно делать, но в nginx нет такой фичи как перенаправление по завершающим слэшам как в Апаче и поэтому в принципе не нужно заморачиваться на такие мелочи, достаточно чтобы страница была верно указана в sitemap.xml.

[dmartynenko]

Добавлять отсутствующий слэш на конце гораздо лучше умеет вебсервер, в том же htaccess приложенном в доке по RealURL одна из строк именно этим и занимается.

Соглашусь, перенаправление как page.html на page/, так и page на page/ лучше делать в .htaccess
Но, скажем так, RealURL в дефолтном конфиге тоже должен препятствовать дублям страниц по разным адресам, в независимости от настройки .htaccess

Во вторых не все вещи можно сделать в .htaccess с учетом "виртуальности" практически всех url в TYPO3. Мануал об этом и говорит (Note that it...):
To force this you simply append a '/' to the url if it is not a file:

RewriteRule (.*[^/])$ http://%{HTTP_HOST}/$1/ [L,R]

This works by redirecting the browser from www.example.com/project-name to www.example.com/project-name/.
Note that it will break rss.xml and similar mappings in the fileName section of the configuration.

В nginx это тоже можно делать, но в nginx нет такой фичи как перенаправление по завершающим слэшам как в Апаче и поэтому в принципе не нужно заморачиваться на такие мелочи, достаточно чтобы страница была верно указана в sitemap.xml.

Я следую рекомендациям SEO-шников. Никто не гарантирует что другие сайты на вас не сделают ссылки как example.com/page вместо example.com/page/. Тут то поисковики и обнаружат что по двум адресам одинаковый контент, что не есть хорошо.

[-=UncleByte=-]

В nginx весь этот непомерного объема htaccess решается парой строк:


location / {
try_files $uri $uri/ /index.php;
}

И все. Поэтому городить огород еще и с завершающими слэшами, которые в общем-то поисковикам никоим образом не мешают, считаю излишним.

[dmartynenko]

Я не спрециалист по SEO, поэтому только выполняю рекомендации. SEO-шники говорят что ссылки .../page/ и .../page будут дублями для поисковиков.

Эту строку "непомерного объема" можно записать и короче (у вас вообще 3 строки :) ). Кроме того, nginx стоит не везде, конфиг nginx более сложен для понимания и не доступен для редактирования без рутовских прав. А .htaccess могут редактировать и обычные пользователи shared-хостинга.

PS: Дмитрий Дулепов согласился со мной что то, что обсуждалось выше, это баг RealURL и пофиксит в следующей 1.10.3 версии http://bugs.typo3.org/view.php?id=18081

[-=UncleByte=-]

Конфиг nginx яснее ясного, но это уже вопрос предпочтений.
Про невозможность редактирования конфига nginx пользователями shared'ов советую посмотреть как это устроено на nic.ru - и, заметьте, работает как часы.
А про баг, что это недоработка это понятно, хорошо что Дулепов пофиксит это.