3

我想使用过期 url 的 realurl 内存为升级到 TYPO3 9+ 的站点生成 301 并避免 404。

例如，在 TYPO3 9 之前，fetching/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）

感谢您的见解！

4

2 回答 2

2

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

  • 基于PageErrorHandlerInterface404 创建页面错误处理程序。在 realurl 表中检查 URL。如果您有命中，请重定向到新 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;
  }
于 2020-09-22T09:34:06.100 回答
1

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

我没有任何数字，但我认为您在网络服务器中处理的重定向比启动 PHP 和 TYPO3 更有效。缺点是重定向也被评估为静态资产（除非在其他地方处理，例如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 重写映射：

/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 配置中进行更改，您可以执行 a service apache2 reload（错误中止）或apachectl configtest. （或者更好的是您的 CM 在执行状态之前为您执行此操作）。
  • 关于使用RewriteRulevs. Redirect：您可以同时使用和或其变体（例如 RedirectMatch）做很多事情，但 RewriteRule 通常更强大，而另一个可能更快。理想情况下使用其中一种。另请参阅“何时不使用 mod_rewrite”。
于 2020-09-22T09:25:42.650 回答