迁移到 TYPO3 9+ 后继续重定向旧的 realurl url

Posted 2023-02-16

【中文标题】迁移到 TYPO3 9+ 后继续重定向旧的 realurl url

【英文标题】：Keep redirecting old realurl urls after migrating to TYPO3 9+

【发布时间】：2021-01-08 08:42:14

【问题描述】：

我想使用过期url的realurl内存为升级到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 页面路径/别名转换为 slug，但不会将 realurl 过期的页面路径/别名转换为 sys_redirect。

保留重定向的 realurl 内存的最佳策略是什么：

将所有过期的 url/别名迁移到 sys_redirect？这可能会导致 sys_redirect 表变大，出现性能问题 在搜索过期 url 并触发 301 的 RedirectHandler 之后运行中间件？这将为每个请求进行额外的数据库查询。 创建一个PageNotFoundHandler，如果找不到页面，它会搜索过期的url？ TYPO3 每个状态码只允许一个 ErrorHandler，所以这可能是一个问题 在 .htaccess 中列出重定向

“最佳策略”是指：

性能可能很重要（我有超过 10,000 个过期网址） 如果可能的话，重定向应该由编辑器维护（如 sys_redirect）

感谢您的见解！

【参考方案1】：

我的第二个解决方案（我正在使用 - 稍作修改 - 在生产中）使用 TYPO3：

为 404 创建基于 PageErrorHandlerInterface 的页面错误处理程序。检查 URL 的 realurl 表。如果您有点击，请重定向到新网址。 如果没有命中，请退回到您通常会做的事情，例如显示错误页面。

这有以下优点（对 TYPO3 重定向扩展）：

它只在 404 上启动，而不是在每个页面上。

另外，您不必将重定向迁移到 sys_redirects，您可以按原样使用旧的 realurl 表。

Repository\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;
  

【讨论】：

我喜欢只在 404 上而不是在每个请求上使用 realurl 缓存的想法。

我接受这个答案，因为这是我在项目中实施的答案。但是，我将 PageErrorHandler 基于 tx_realurl_urldata 而不是 tx_realurl_pathdata。这样，我还可以重定向记录的 url（不仅是页面）。我还处理了其他查询参数（如 utm_、fbclid）。代码在此处公开：gist.github.com/dogawaf/fc0982880c8d39cc185964607955e93a

【参考方案2】：

对于以下内容，我假设您使用 Apache Webserver 并可以访问 /etc/apache2 下的 webserver 配置，例如。

---

我没有任何数字，但我认为您在网络服务器中处理的重定向比启动 php 和 TYPO3 更有效。缺点是重定向也会针对静态资产进行评估（除非在其他地方处理，例如 cdn）。此外，这不能由编辑维护。但是，如果您从 realurl 迁移，例如，您可以通过 Apache 使用此解决方案作为临时解决方案，并在一段时间后将其删除。

但是，如果您有很多重定向，这可能会变得无法维护并且非常丑陋。

多年来，我看到的网站经常积累重定向，通常很高兴地将 RewriteRule、Redirect（或重定向）、RedirectMatch 和 RewriteCond 混合使用以达到很好的效果。为了保持整洁，我有 2 条建议（在我维护的网站中都使用过）：

在配置管理系统（例如 Angular、SiteStack）中维护重定向。不要在那里编写重定向语句，而只需添加 URL 并让您的状态（或 CM 调用它们的任何内容）为您编写它们

使用 RewriteMap 和一个由 URL 组成的文件。

对于这两种解决方案，您通常有（至少）两种类型的重定向：

exact

重定向，例如您想将 /abc/def 重定向到 /new/def，但不是例如 /abc/def/subpage

正则表达式或通配符

重定向，例如您想将 /abc/* 重定向到 /new/*

两者都可以使用适当的 RewriteRule 语句来处理，但它们看起来不同。对于解决方案 1 和 2，您需要分别处理它们。

示例 1（正则表达式重定向）：

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

示例 2 重写映射：

/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 通常更强大，而另一个可能更快。理想情况下使用其中一种。另见"When not to use mod_rewrite"。

【讨论】：

很抱歉这个冗长的答案，甚至写了 2 个答案。我不是想问这个问题。我希望我的回答是有用的，并希望得到反馈。我也会对其他答案感兴趣。让我知道我是否应该减少它，我会尝试。