我有一个非常小的Hugo站点,我正试图将其部署到Netlify.当我构建站点时,我得到了一个意外的无限循环,尽管它似乎可以在使用hugo serve --ignoreCache --disableFastRender --noHTTPCache -D
的dev中工作.
该网站由两个页面组成:
-
/
个 -
/contact/
个
在联系页面方面,它直接在content
文件夹中,如下所示:
---
title: "Contact"
draft: false
date: "2020-02-25"
type: "page"
layout: "page"
aliases:
- /contact.html
- /blog/contact/
- /blog/contact.html
---
{{< contactformwide >}}
然后我有themes/MYTHEME/layouts/shortcodes/contactformwide.html
的联系人表格.
我有一个非常奇怪的错误,当我用hugo serve --ignoreCache --disableFastRender --noHTTPCache -D
构建网站时,它工作得很好.当我try 部署它以使其网络化或使用hugo
在本地构建它时,/contact/
个页面陷入了无限循环.在构建时没有抛出错误,它似乎只是反复try 加载页面,但都无济于事.
我试着将config.yaml
中的baseURL
调整到适合生产的域,但无济于事.
在/contact/
个处呈现(以及重新呈现,再重新呈现)的页面的HTML如下所示(这是Netlify的版本,因此是mellifluous-marzipan
):
<!DOCTYPE html>
<html>
<head>
<title>https://mellifluous-marzipan-3893e2.netlify.app/contact/</title>
<link rel="canonical" href="https://mellifluous-marzipan-3893e2.netlify.app/contact/"/>
<meta name="robots" content="noindex">
<meta charset="utf-8" />
<meta http-equiv="refresh" content="0; url=https://mellifluous-marzipan-3893e2.netlify.app/contact/" />
</head>
</html>
除了前四行之外,这个HTML基本上与我期望呈现的内容没有任何关系.
我假设问题是这<meta http-equiv="refresh" ...
,但这是从哪里来的?为什么它不出现在dev中?我通常的head
中只有以下两个http-equiv
,并且主站点(使用相同的head
)现在是up(已修复EDIT:错误),所以您可以看到head
是什么样子的:
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
EDIT:我刚刚注意到我想要的页面(在我的开发环境中我得到的是webaddress/contact
,在构建中存储在public/contact/contact.html
.
无论我是点击/
个中的链接(这很好用),还是手动转到/contact/
个,结果都是一样的.
有人能帮我破解这个吗?我可以提供回购等访问,但也许答案显而易见,我只是太新手看不到它?也许这与/contact/
个页的别名有关?
如果有帮助的话,当我将base URL设置为另一个URL时,我只是从我被重定向到的baseURL/contact/
中获得了404,而不是这个无限循环.
EDIT:我发现正确的页面位于netlify站点此处(EDIT:错误已修复).它被放在/public/contact/index.html
号房里.
这也证明了,当我把url: contact
放在layouts/contact.md
的前面时,public/contact.html
在网站建成时就不复存在了,只剩下public/contact/index.html
.
EDIT:当我将以下内容放在标题中时,我得到public/contact.html
(具有正确的内容/页面),而相同的页面ALSO在public/contact/index.html
中.
结果发现,在/contact
、/contact/
个和contact/
之间存在一些混淆.我原本是链接到/contact/
个的,而修复程序似乎只是简单地将我的链接更改为/contact
.不知道为什么这会导致无限重定向,但它现在起作用了.