yes in linux , with snap, the upgrade has been for 2 years in auto
I do not care: I just type “hugo server” and the new version is loaded and starts
render.com does not allow you to easily specify the version to use when building your site. That’s a huge problem. If I were you I would use a different provider.
That looks kind of like raw HTML to me, also known as, issues bringing in assets like css files and images.
It would be helpful to right click and then click view source, compare both versions. I’d concentrate on the src and href attributes of your assets.
When using third-party renderers, sometimes the assets get mixed up. Had it happen with my sites using Github Pages and such. I’ve had tons better luck with rendering it on my own computer, then just rsyncing it to the webhost.
To clarify, the OP can’t update their site to be compatible with v0.164.0 or later because render.com uses an earlier Hugo version, and they don’t provide a simple way to use any version.
Hi, (I do not understand “OP” , and 0.164 version)
I removed Hugo snap version and installed pre-built binaries of v 0.145 : all works well .
So the cause is the new version (snap was still on 0.146.3)
my site is not on a public repo and has a tailwind css , but yes I can give you a collaborator access @jmooring ( Productivix site-prx-hugo ) i made a special branch named “0.146” - thanks
OP is an acronym for Original Poster, for example: the person who started a thread.
Snaps automatically update a few times a day. Which can be a good or bad thing, I guess a bad thing in your case, at least for this one instance.
I think jmooring may have had a typo, and switched the 6 and 4 around. It is the 146 version(s).
There was a bit of a rough spot in the releases lately, as can happen for any software package. 146.0 was the primary release. 146.1-4 was mainly to correct some of the issues with layout lookups, there may have/be other issues about too.
render dot com maybe waiting for code contributors to ride out some of the issues in the release before migrating to 146. Either way, it’ll likely be more time efficient for you to match their version instead of trying to upgrade it on their end.
hi, thks for explanations. I develop on React JS / Native and for that I prefer to master the versions I have in dev and prod . No I will not go over the Render version and push mine .
The problem I mention is only on index page, not on the others that have more simple templates.
The main thing is that we do not have any error messages at all to help to point out the difference.
thanks for your help all , with some commands , I have been able to switch from 0.145 and 0.146.4 : and I found that a file home.html under theme/layout/default was unused and putting the mess in 0.146 (and not in 0.145) .
I think the lookup order of templates changed a bit in 0.146.x.
One of the things I wish there was (unless I’m just not finding it in Docs) was a field that could be put in baseof to print out what template a page is using. Would be very helpful in diagnosing issues like this.
Well… a page most likely uses many templates, for example:
layouts/baseof.html -> layouts/home.html -> layouts/_partials/footer.html -> etc.
You are probably interested in either template boundaries (enter/leave) or the template call stack. You can do both with the new templates.Current function. See examples.
I played around with it some. It’s more useful to put it in the actual template files you’re trying to identify vs using it to figure out which templates are in the chain of each page.
Maybe a command line switch or build flag to list each page generated and its template chain would work better for this sort of thing. I may look at Hugo’s code, maybe it’s something I can figure out and contribute. But, at least currently, I’m more familiar with Python than Go.