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

[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]

Сообщение от -=UncleByte=-

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

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

РЕШЕНИЕ!

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

PHP код:

protected function decodeSpURL_decodeFileName_checkHtmlSuffix($fileName, $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

PHP код:

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


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

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

PHP код:

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


[-=UncleByte=-]

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

[dmartynenko]

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