Manual testing of Hugo 0.55 (Help Wanted!) #5784
Comments
|
First of all in the latest production deploy of Hugo Themes we have 4 broken theme demos due to errors. When I build the Themes Site locally with Hugo 0.55 DEV with the latest commits especially the gargantuan Make Page An Interface there is a jump to 27 errors from above. Here is a typical ERROR message:
And typically in a template an author has entered And here is the log with most of themes that fail to have demos generated in 0.55 DEV (I have included the ones that have meaningful error messages that point to specific templates) Also the following ERROR is different to the ones above: P.S. Note that I hadn't noticed that the Discource topic was locked when I replied. Sorry for that. |
|
@onedrawingperday thanks for testing these. I will look more closely at these tomorrow, but there are some commons ...
|
|
You're welcome. I just want to say that what you did by changing Page into an Interface has some very tangible benefits. It's 23 themes that broke. If nothing can be done we will handle the breakage as we usually do, (me and @digitalcraftsman ) Have a look at the above but at the end of the day making Hugo better is what counts. |
It was removed in 597e418 -- it's not documented, but it's used in too many real sites on the web. See gohugoio#5784
|
@onedrawingperday I have pushed fixes to the 2 issues you mentioned. Note that the at <.Dir>: error calling Dir: runtime error: invalid memory address or nil pointer dereferenceThis relates to #5781 -- and I have not decided on what to do about that yet. In short:
|
|
Right. So when 0.55 is released we will quote from your post above because frankly we do not have the time to debug such complexities. There is also this other theme that fails in 0.55-DEV because it creates a dictionary with all sorts of variables for an Algolia JSON: https://github.com/zhaohuabing/hugo-theme-cleanwhite/blob/master/layouts/_default/list.algolia.json#L6 And there may be other themes as well... P.S. I will test your fixes later today and get back to you. |
|
Yes -- I think what I'm saying about #5781 is that if the breaks in the wild get too noisy, then we adjust it to reduce work ... Possibly delay the problem for later. |
|
I still get 7 broken theme demos. It depends on what you want to do with #5781 In any case if you want to check out these themes here is the console log: |
|
I have in In the for a homepage that has no However, after I generated the same site with 0.55.0-DEV/extended, I got instead. I'd be more than happy to make a minimized test case tomorrow (March 26 in the Americas) if that'll help. |
|
But the above is not readable in the template (at least I would have to scratch my head for a couple of minutes to figure it out). Why haven't you instead opted for: It works the same and it doesn't break with 0.55-DEV. |
|
It's plenty readable if you're the one who wrote it and have seen it work properly ;) If I wrote it with a with-else block I'd have to write something like this (fair warning: I've never written a with-else block before): Writing it the way I did saves me from having to write out The docs so far have seemed to indicate that |
No. The above is not entirely true. .Title can include .Site.Title it depends on the context. To be honest I think that there was a flaw with that you were doing and I am a bit surprised it used to work. But anyway this GitHub issue is most likely not the place to discuss templates’ logic. Anyway you said what you used to do and what changed in 0.55-DEV If something needs to be reverted it’s not for me to say. |
<title>{{- .Site.Title -}}{{ with .Title }} — {{ . }}{{- end -}}</title> I have not looked at it, but I suspect that this is 1) The home page and 2) You have no content file (with a title) for that page? I guessing that the behavior for "title defaults" have somehow changed, which I will look into ... |
|
Yes, this is the home page. The associated content file, |
|
@adiabatic I tried unsuccessfully to reproduce your issue in bceda1b -- so I suspect that there is something else going, of which I have no idea. |
|
On a separate site, I'm using this partial, called This partial is used on every page of a site. Some of these pages have Upgrading to 0.55 has gotten rid of a bunch of "(0001)"s generated by this (admittedly buggy) partial, which I like. However, it's also getting rid of all the perfectly valid dates as well: I'm not sure what the proper behavior should be, and I don't know if anyone's relying on current behavior, but this is a change. |
Sounds like I should make a test case, then. On it. |
|
Test case made for the .Title change. It's available at https://github.com/adiabatic/shenanigans-title. I'm using repeated runs of |
|
Please use the See https://gist.github.com/ericclemmons/b146fe5da72ca1f706b2ef72a20ac39d Also, there are several date fixes in this release (and we have a billion test cases that passe), so what you see are most likely more correct -- but it would be great if you shouted if you are convinced they're not. |
|
@adiabatic the "title issue" is fixed, I somehow forgot to add |
|
I tried wrapping the listing in a |
|
Even wrapped with a pre or something? It's not a big deal, it's just that threads like this gets very hard to follow after a while |
After sleeping on it, I'm convinced that the current behavior is incorrect. In #5379, you wrote:
Given a template chunk like
I'd expect output like
for pages that have some sort of date associated with them (date, pubdate, lastmod, etc.) and
for pages that don't. Current (in 0.55-DEV, as of five minutes ago) behavior around For what it's worth, Let me review the changes as best as I am able:
I think both category pages and taxonomy pages should have the "dates are inherited from subpages" property or neither should. I weakly favor the "neither should" option. If a template writer wants dates, he shouldn't try to depend on a single "date" function/value with no defined meaning. He should use things like .MostRecentDate, .LeastRecentDate, .MostRecentLastmod, .LeastRecentLastmod, .MostRecentCreated, .LeastRecentCreated, and so on. These things would be defined for categories and taxonomies. This way, he'll be using an interface that has obvious semantics. If our template author comes to assume that |
|
Yes, even wrapped with a |
|
The ERROR in B: Is that new? As in: Does it run fine in 0.54? |
|
Yes. I only report the differences between 0.54 and 0.55DEV
port 1313 already in use, attempting to use an available port
INFO 2019/04/05 16:04:50 Using config file:
Building sites … INFO 2019/04/05 16:04:50 syncing static files to /
INFO 2019/04/05 16:04:50 found taxonomies: map[string]string{"category":"categories", "tag":"tags"}
INFO 2019/04/05 16:04:50 found taxonomies: map[string]string{"category":"categories", "tag":"tags"}
WARN 2019/04/05 16:04:50 Page's .Hugo is deprecated and will be removed in a future release. Use the global hugo function.
+------------------+-----+-----+ Total in 646 ms
port 1313 already in use, attempting to use an available port
INFO 2019/04/05 16:05:42 Using config file:
Building sites … INFO 2019/04/05 16:05:42 syncing static files to /
INFO 2019/04/05 16:05:42 found taxonomies: map[string]string{"tag":"tags", "category":"categories"}
INFO 2019/04/05 16:05:42 found taxonomies: map[string]string{"tag":"tags", "category":"categories"}
INFO 2019/04/05 16:05:42 Alias "blog/une-nouvelle-equipe/" translated to "blog/une-nouvelle-equipe/index.html"
INFO 2019/04/05 16:05:42 Alias "fr" translated to "fr/index.html"
INFO 2019/04/05 16:05:43 Alias "en/a-new-team" translated to "en/a-new-team/index.html"
INFO 2019/04/05 16:05:43 Alias "fr" translated to "fr/index.html"
+------------------+-----+-----+ Total in 227 ms |
|
May be not related but on the 3 sites with "WARN 2019/04/05 14:10:27 Unable to increase number of open files limit invalid argument", the 2 failing are multilingual, and the one going live in server mode is without multilanguage. |
|
Those 3 sites are on GitHub and I can give you access if needed. |
|
A: These warnings are deliberate. B: Is the only one I don't understand, so I assume an upstream change ... somewhere ... It would be great if you could share that repo with me. 2 questions:
|
It was removed in 597e418 -- it's not documented, but it's used in too many real sites on the web. See gohugoio#5784
Note that this fixes some "live reload" issues recently introduced in non-released code. Closes gohugoio#5811 See gohugoio#5784
|
|
@divinerites just to make sure: The site you shared with me was the site you got " too many open files |
|
Yes bep. This site fails (divinerites/lagouille.com). |
|
Chiming in to say I've gotten this warning starting in 0.55-DEV; I just haven't mentioned it because I was busy pinning down other changes ;)
I've gotten this warning (I've been building on macOS Mojave 10.14.4 with go 1.12.1), but not the error. My "normal" hugo is the one provided by homebrew. I suspect my sites are smaller than most, though. For example, I get it in https://github.com/bep/hugo-dates: The output of |
|
I assume it is this massive commit in Go 1.12.1: golang/go@a3b0144#diff-a7c1e05474b922ebf6f2905fc1e88c64 It does not fail for me though (macOS Mojave 10.14.4 with go 1.12.1) ... Will think about it. Could one of you try to build this branch and see if the problem goes away: https://github.com/bep/hugo/tree/ulimit That branch uses golang/sys to do the ulimit changes. |
|
Will try (I'm a noob in Go/compilation tho)... |
|
No obvious change. |
|
@adiabatic curious, but thanks. I will investigate, and @divinerites you can call if your "compile the branch" struggles if you want ... |
|
Seems to be related to this issue: golang/go#30401 |
|
OK, I can reproduce this myself by editing lowering the I will adjust the logic so the WARNING goes away and add some documentation somewhere (with a link in the error log if possible) with info about how to work around the "too many open files" if it still is too low (which in short is to edit |
I confirm this error is gone with the latest DEV (compiled with latest go1.12.2). Thanks Bep. |
|
|
@divinerites I'm about to release this now, so any issue related to that release will need to be handled in separate issues. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
See:
The important bits of that release is now implemented and merged to master.
I have tested this extensively manually myself, but I would really appreciate that you if you know how to compile Hugo from source, can take this for a spin on your site.
It's cool if you also test the "new stuff", but I'm mostly curious about if this somehow breaks anything in your site. And if it somehow breaks for you, access to the source code so I could see how and what would be gold. I'm not looking for more feature requests (as in "it would be cool if that also ...") as this has already been one of the most work-intensive releases.
I would strongly recommend that you build with the latest Go 1.12.1.
The text was updated successfully, but these errors were encountered: