遷移到 TYPO3 后繼續重定向舊的 realurl 9+

Question

我想使用過期 url 的 realurl memory 為升級到 TYPO3 9+ 的站點生成 301 並避免 404。

比如TYPO3 9之前，抓取/my-old-page重定向到/my-new-page ，因為/my-old-page還在realurl數據庫表中。 現在，由於遷移到 TYPO3 9，獲取/my-old-page會拋出 404。

TYPO3 9 發布了一個升級向導，它將 realurl 頁面路徑/別名轉換為 slugs，但不會將 realurl 的過期頁面路徑/別名轉換為sys_redirect 。

保持 realurl memory 重定向的最佳策略是什么：

• 將所有過期的 url/別名遷移到 sys_redirect？ 這會導致一個很大的 sys_redirect 表，出現性能問題
• 在搜索過期的 url 的 RedirectHandler 之后運行一個中間件，如果找到則觸發 301？ 這將為每個請求進行額外的數據庫查詢。
• 創建一個 PageNotFoundHandler，如果找不到頁面，它會搜索過期的 url？ TYPO3 每個狀態碼只允許一個 ErrorHandler，所以這可能是個問題
• 列出 .htaccess 中的重定向

我所說的“最佳策略”是指：

• 性能可能很重要（我有超過 10,000 個過期的網址）
• 如果可能，重定向應該由編輯器維護（如 sys_redirect）

感謝您的見解！

Answer 1

我的第二個解決方案（我正在使用 - 稍微修改 - 在生產中）是 TYPO3：

• 基於PageErrorHandlerInterface為 404 創建頁面錯誤處理程序。檢查 URL 的 realurl 表。如果命中，則重定向到新的 URL。
• 如果沒有命中，則退回到您通常會做的事情，例如顯示錯誤頁面。

這有以下優點（到 TYPO3 重定向擴展）：

• 它只在 404 上觸發，而不是在每個頁面上觸發。
• 此外，您不必將重定向遷移到 sys_redirects，您可以按原樣使用舊的 realurl 表。

存儲庫\路徑映射存儲庫：

  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;
  }

Answer 2

對於以下內容，我假設您使用 Apache 網絡服務器，並且可以訪問 /etc/apache2 下的網絡服務器配置，例如。

---

我沒有任何數字，但我假設您在網絡服務器中處理的重定向比啟動 PHP 和 TYPO3 更有效。缺點是重定向也會針對 static 資產進行評估（除非在其他地方處理，例如 cdn）。 此外，這不能由編輯維護。 但是，如果您從 realurl 遷移，例如，您可以通過 Apache 使用此解決方案作為臨時解決方案，並在一段時間后將其取下。

但是，如果您有很多重定向，這可能會變得難以維護並且非常難看。

我見過的網站多年來經常積累重定向，經常愉快地混合使用 RewriteRule、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” 。