Comments (9)
Thanks for laying out your site for me, it makes it easier for me to understand what you're trying to do :)
If you don't mind, would you please follow up with spf13 on the appropriate convention? I would love to see the response.
What I meant about "sharing images" was that I thought you'd be more interested in cross-referencing the images between sites instead of them being specific to a single site/BaseURL.
If you find that making everything relative to the BaseURL is the established convention, I'd be happy to make that change for bigimg and anything else in the future. I think in this case I'd like to stick with whatever the convention is instead of adding too many parameters to the config file. Especially since the theme is pretty easily customizable in case anyone is trying to do something a little differently :)
from beautifulhugo.
Just in case anyone reaches this issue, this is what I am currently running in a build script to automatically patch the latest version from the repo:
sed -i -r 's/\"\{\{\$img\.src \| absURL \}\}\"/"{{$.Site.BaseURL}}{{$img.src}}"/g' ./themes/beautifulhugo/layouts/partials/header.html
It replaces "{{$img.src | absURL}}"
with "{{$.Site.BaseURL}}{{$img.src}}"
.
from beautifulhugo.
My understanding is the baseURL is the programmable part; and I would naiively expect it to always be set to the base URL of the domain. Can you help me understand why you would want to set the baseURL to a subdirectory and not to the root of a domain?
One more thing to note is that a leading slash makes the image path relative to the baseURL, but I believe no leading slash makes the path relative to the directory of the .md file. In other words, if you had a "posts" directory, and a post named "mypost.md" and the frontmatter described an image at"img/path.jpg", it would expect to find the image at "posts/mypost/img/path.jpg"
If neither of these solve your problem, I don't know what to suggest, or what you'd like to see done that would solve your problem.
from beautifulhugo.
Can you help me understand why you would want to set the baseURL to a subdirectory and not to the root of a domain?
Say I want to deploy three sites to GitHub Pages: a landing page, the documentation of a program and a blog. The three of them have similar colors, but different themes. Hugo lets me set baseURLs to 1138-github.io/myrepo/
, 1138-github.io/doc/
and 1138-github.io/blog/
, then build each of them separately and put all the content in a single directory. Neither vhosts nor redirects are required.
Apart from that, I'd prefer to have all the images in static
, rather than spreading them in subdirs.
If neither of these solve your problem, I don't know what to suggest, or what you'd like to see done that would solve your problem.
I don't know much JavaScript, but I think that it can read content from the HTML. Then, if the baseURL parameter in Hugo is written to a class/field in the header of every page (or at least those with bigimg), JS can read it and add the prefix to the url()
paths. Is this possible?
from beautifulhugo.
I don't think this is a problem specific to the bigimg stuff, right? You would have this same problem with every website where you've changed the baseURL if you want the path not to be relevant to the .md directory or the baseURL directory. I don't know of a standard solution to this; if you know or find one please let me know.
I'm not an expert, but if you want to inspect the DOM with the js, specifically for bigimg's you could search for data-img-src-1="..." (or data-img-src-2="...", etc) and modify this path. I don't believe that's something appropriate to add to the theme itself, so I'll close this issue.
from beautifulhugo.
I don't think this is a problem specific to the bigimg stuff, right? You would have this same problem with every website where you've changed the baseURL if you want the path not to be relevant to the .md directory or the baseURL directory. I don't know of a standard solution to this; if you know or find one please let me know.
Indeed, I want the path to be relevant to '$.Site.BaseURL'. Now, it depends on the domain '/', not baseURL. There are some explicit examples of what I mean here:
https://github.com/yoshiharuyamashita/blackburn/blob/43b2c9346694de8cfb1b7db52e28f5e1cb16c82a/layouts/partials/footer.html
https://github.com/yoshiharuyamashita/blackburn/blob/43b2c9346694de8cfb1b7db52e28f5e1cb16c82a/layouts/partials/head.html#L49-L52
A specific commit was pushed to this other theme on 2015-09-19, to support this feature:
https://github.com/crakjie/hugo-base-theme/commits/master
I don't believe that's something appropriate to add to the theme itself, so I'll close this issue.
I did only see problems with bigimgs, but I believe this should be considered a theme issue, since the behaviour is not coherent to other 'oficial' themes.
I don't mind checking the partials to improve it, and make a PR (keeping it as a branch, if you prefer so). However, could you tell me whether any other JS part needs to be modified, apart from bigimgs?
from beautifulhugo.
First let me say I would love to do whatever the standard convention is, but I don't really know the convention or how it solves your problem. I'm sorry, I keep misunderstanding what you want. Earlier it sounded like you were asking for a way to build sites independently, but then copy them to the same parent directory and have a single static directory that isn't spread between the subdirectories. To me this means, images that you might conceivably want shared or accessible between sites should not use BaseURL, while css, js, and images specific to a site (or specific to the theme) should use the baseURL so that the site can be compiled without some kind of external dependency. To my understanding, that's what you could do with this theme as it is today.
In your most recent post you're asking to make all the bigimgs relative to the BaseURL, which from your earlier explanation I would think means that you'd have to copy those images to separate theme's subdirectories (blog, doc, myrepo) if you wanted to cross reference them. Since I expect the bigimgs to be pictures defined by the user of the theme and not an intrinsic part of the theme, I would expect that if anything you'd want to share them?
I also don't quite understand the established convention, even from the links you sent me. For example the lines 49-52 you're referencing here seem to allow someone to customize the theme by specifying their own CSS/JS relavent to the theme's BaseURL, but line 24 is relative to the domain. Perhaps this was an oversight?
https://github.com/yoshiharuyamashita/blackburn/blob/43b2c9346694de8cfb1b7db52e28f5e1cb16c82a/layouts/partials/head.html
And in the hugo base theme, the theme's CSS was changed to be relevant to the BaseURL (which I think is a good change) but favicon and apple-touch-icon.png are still relative to the domain (not sure if that's good or bad). I just checked a couple more themes and this seems to be standard for those themes as well.
https://github.com/crakjie/hugo-base-theme/blob/master/layouts/partials/header.html
Perhaps what supports your argument about BaseURL being standard is that the hugo-base-theme seems to use the BaseURL for the mainicon which is similar in functionality to the bigimg. But why is this different from the favicon and apple-touch-icon in the same theme, and wouldn't one of these break the model you're looking for?
https://github.com/crakjie/hugo-base-theme/blob/master/layouts/partials/top-block.html
I don't think you need to modify any JS for bigimg, Just change "{{$img.src}}" to "{{.Site.BaseURL}}{{$img.src}}" in the index.html, head.html, and header_wp.html layouts/partials. I don't know if you have other javascript you need to modify for your use case because unfortunately I don't understand your use case.
I feel terrible that I still don't understand what you're after, and I'm happy to follow whatever the established standard is, but as I said the standard isn't clear to me yet and I don't understand why things like how favicon or apple-touch-icon wouldn't also cause you headache.
from beautifulhugo.
First let me say I would love to do whatever the standard convention is, but I don't really know the convention or how it solves your problem. I'm sorry, I keep misunderstanding what you want.
I think I should have thought better about it, before opening this issue. This topic is deeper than I thought. I believe you are understanding pretty well. It's me who isn't giving proper explanations. So, please, forgive me for it, and let's get it clear ;)
Earlier it sounded like you were asking for a way to build sites independently, but then copy them to the same parent directory and have a single static directory that isn't spread between the subdirectories.
I meant to have a single static directory for each site:
- root
- /images
- /s1image.png
- /site2
- /images
- /s2image.png
- /images
- /site3
- /images
- /s3image.png
- /images
- /images
where site1's baseURL is domain
, site2's is domain/site2
and site3's domain/site3
.
This is different from your first two alternatives, which I understood being either
- root
- /images
- /s1image.png
- /images
- /s2image.png
- /images
- /s3image.png
- /images
or
- root
- /post
- /mypost
- /s1image.png
- /mypost
- /site2
- /post
- /mypost
- /s2image.png
- /mypost
- /post
- /site3
- /post
- /mypost
- /s3image.png
- /mypost
- /post
- /post
To me this means, images that you might conceivably want shared or accessible between sites should not use BaseURL, while css, js, and images specific to a site (or specific to the theme) should use the baseURL so that the site can be compiled without some kind of external dependency. To my understanding, that's what you could do with this theme as it is today.
Then, it is just that the theme expects bigimgs to be accesible between sites and I expected it to treat them just as CSS and JS files, isn't it? If so, it is clear to me now, and I don't expect any change to the theme. However, a comment in the README might be helpful so that it is made clear which content is relative and which is absolute.
In your most recent post you're asking to make all the bigimgs relative to the BaseURL, which from your earlier explanation I would think means that you'd have to copy those images to separate theme's subdirectories (blog, doc, myrepo) if you wanted to cross reference them. Since I expect the bigimgs to be pictures defined by the user of the theme and not an intrinsic part of the theme, I would expect that if anything you'd want to share them?
There are a couple of things I don't completely get:
- Since sites are independent, I expect to cross-reference them with their absolute path. Therefore, I think I don't have to copy images to separate theme's. I think I understand that you mean cross-referencing using relative paths, which is a much portable solution. However, since I consider those sites independent, I treat cross-references as if I was referencing any other external site (say wikipedia).
- If I wanted to improve portability, I think the way to go would be to add shortcodes, such as external links in Sphinx.
- I would expect that if anything you'd want to share them? I don't understand this question. Can you, please, reword it?
I also don't quite understand the established convention
After your detailed analysis, I don't neither. Specially because of the favicons thing you pointed, since I'd expect them to be relative too.
Shall we ask about it at github.com/spf13/hugoThemes ? Do you want to handle it, or should i?
I don't think you need to modify any JS for bigimg, Just change "{{$img.src}}" to "{{.Site.BaseURL}}{{$img.src}}" in the index.html, head.html, and header_wp.html layouts/partials. I don't know if you have other javascript you need to modify for your use case because unfortunately I don't understand your use case.
Well... in the end it was as simple as this. Sorry again for making it longer because I couln't explain myself properly.
Would you find useful a PR which makes this optional as a parameter in the config file? If so, I'll test on top of the latest version, instead of my local copy.
from beautifulhugo.
Well, I opened a thread in the forums: https://discuss.gohugo.io/t/is-there-any-baseurl-usage-convention-for-themes/5797/3
@bep, which is the main contributor now, replied:
My recommendation is to always use the template funcs relURL and friends.
Therefore, I think there is no convention here, just a 'strong' recommendation.
from beautifulhugo.
Related Issues (20)
- KaTeX table rendered as literal string HOT 2
- Copyright Year in Footer Shows As "© 0001" HOT 2
- Support for multiple authors and author profiles
- Bigimg displays as empty div with Javascript disabled HOT 3
- Position attribute documented in exampleSite config.toml doesn't do anything
- Mastodon HOT 1
- Code blocks are unreadable in dark mode when using missing or unknown language tag HOT 2
- Nonstandard method used for deriving twitter card image
- How to write the inline math formulas
- Some problems of inline formulas
- I am getting an error when trying out the example site HOT 1
- CSS not rendering correctly HOT 1
- why the static resource doesnt not use the baseurl
- Hugo v0.120.1: depecation warnings HOT 1
- modify css, ideally change menu colors but other colors as well.
- Menu broken on Chrome HOT 2
- Social link for mastodon is slightly malformed. HOT 2
- side column examples
- The navbar drop downs aren't keyboard-accessible
- The navbar drop downs aren't great with screen readers
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from beautifulhugo.