Продолжайте перенаправлять старые URL-адреса realurl после перехода на TYPO3 9+

Мое второе решение (которое я использую - немного измененное - в производстве) - это TYPO3:

• создайте обработчик ошибок страницы на основе PageErrorHandlerInterface для 404. Проверьте таблицу realurl на предмет URL. Если у вас есть обращение, перенаправьте на новый URL.
• если нет попадания, вернитесь к тому, что вы обычно делаете, например отобразить страницу ошибки.

Это имеет следующие преимущества (расширение перенаправления TYPO3):

• Он запускается только на 404, а не на каждой странице.
• Кроме того, вам не нужно переносить свои перенаправления на sys_redirects, вы можете использовать старую таблицу realurl как есть.

Репозиторий \ PathMappingRepository:

  public function findPageidForPathFromRealurl(string $path, int $languageId) : int
  {
        $path = ltrim($path, '/');

        $queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)->getQueryBuilderForTable('tx_realurl_pathdata');
        $uid = $queryBuilder->select('tx_realurl_pathdata.page_id')
            ->from('tx_realurl_pathdata')
            ->join(
                'tx_realurl_pathdata',
                'pages',
                'p',
                $queryBuilder->expr()->eq('tx_realurl_pathdata.page_id',$queryBuilder->quoteIdentifier('p.uid'))
            )
            ->where(
                $queryBuilder->expr()->like('tx_realurl_pathdata.pagepath', $queryBuilder->createNamedParameter($path)),
                $queryBuilder->expr()->eq('tx_realurl_pathdata.language_id', $queryBuilder->createNamedParameter($languageId, \PDO::PARAM_INT)),
                $queryBuilder->expr()->eq('p.sys_language_uid', $queryBuilder->createNamedParameter($languageId, \PDO::PARAM_INT))
            )
            ->orderBy('tx_realurl_pathdata.uid', 'DESC')
            ->execute()
            ->fetchColumn(0);
        $this->logger->debug("findPageidForPathFromRealurl: path=$path language=$languageId returns $uid");
        return (int)$uid;
  }

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

У меня нет цифр, но я предполагаю, что перенаправления, которые вы обрабатываете на веб-сервере, более эффективны, чем запуск PHP и TYPO3. Недостатком является то, что перенаправления оцениваются также для статических активов (если они не обрабатываются где-либо еще, например, cdn). Кроме того, это не может поддерживаться редакторами. Но если вы, например, переходите с realurl, вы можете использовать это решение через Apache в качестве временного решения и через некоторое время отключить его.

Однако это может стать неудобным и некрасивым, если у вас много перенаправлений.

На сайтах, которые я видел, часто накапливались перенаправления на протяжении многих лет, часто с радостью смешивая RewriteRule, Redirect (или redirect), RedirectMatch и RewriteCond, добавленные для хорошей меры. Чтобы сохранить это красивым и чистым, у меня есть 2 предложения (оба были использованы на сайтах, которые я поддерживал):

1. Поддерживайте перенаправления в системе управления конфигурацией (например, angular, SiteStack). Не пишите там операторы перенаправления, а просто добавьте URL-адреса и позвольте вашим состояниям (или тому, что CM их называет) записать их за вас.

2. Используйте RewriteMap и файл, состоящий из URL-адресов.

Для обоих решений у вас обычно есть перенаправления (как минимум) двух типов:

• точные переадресации, например вы хотите перенаправить / abc / def на / new / def, но не, например, / abc / def / subpage
• регулярное выражение или подстановочный знак перенаправление, например вы хотите перенаправить / abc / * на / new / *

И то, и другое можно обрабатывать с помощью соответствующих операторов RewriteRule, но они выглядят по-разному. Для решений 1 и 2 вам нужно обрабатывать их отдельно.

Пример 1 (перенаправление регулярного выражения):

RewriteRule /?abc/(.*)? /new$1 [R=307,L]

Пример 2 RewriteMap:

/etc/apache2/sites-available/mysite.conf

RewriteEngine on
RewriteMap exactredirects "txt:/etc/apache2/redirects/exactredirects.txt"
RewriteRule "^(.*)$" "${exactredirects:$1|/404}" [R=307,L]

/etc/apache2/redirects/exactredirects.txt:

/abc.txt /def.txt

Рекомендации:

• поместите конфигурацию Apache и файлы перенаправления в систему контроля версий
• будьте осторожны с 301 (постоянным). Постоянное перенаправление означает постоянное. Поскольку это обрабатывается в клиенте, вы не можете отменить это. Если уверены, используйте только 301.
• Вы часто видите рекомендации использовать .htaccess. Вы можете использовать это вместо того, чтобы помещать его в конфигурацию Apache. Но если у вас есть полный контроль над конфигурацией Apache, вам не нужен .htaccess, а документация рекомендует вообще не использовать .htaccess, если он вам не нужен. Есть большой недостаток (помимо соображений производительности): если вы сделаете ошибку в .htaccess, вы можете отключить сервер. Если вы внесете изменения в конфигурацию Apache, вы можете выполнить service apache2 reload (который прерывается при ошибке) или apachectl configtest. (Или, что еще лучше, ваш CM сделает это за вас до того, как состояния будут выполнены).
• об использовании RewriteRule против Redirect: вы можете многое сделать с обоими и или его вариантами, такими как RedirectMatch, но RewriteRule, как правило, мощнее, а другой может быть быстрее. В идеале используйте одно или другое. См. Также Когда не использовать mod_rewrite.