Coder Social home page Coder Social logo

Bigimg paths about beautifulhugo HOT 9 CLOSED

halogenica avatar halogenica commented on June 2, 2024
Bigimg paths

from beautifulhugo.

Comments (9)

halogenica avatar halogenica commented on June 2, 2024 1

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.

eine avatar eine commented on June 2, 2024 1

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.

halogenica avatar halogenica commented on June 2, 2024

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.

eine avatar eine commented on June 2, 2024

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.

halogenica avatar halogenica commented on June 2, 2024

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.

eine avatar eine commented on June 2, 2024

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.

halogenica avatar halogenica commented on June 2, 2024

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.

eine avatar eine commented on June 2, 2024

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
    • /site3
      • /images
        • /s3image.png

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

or

  • root
    • /post
      • /mypost
        • /s1image.png
    • /site2
      • /post
        • /mypost
          • /s2image.png
    • /site3
      • /post
        • /mypost
          • /s3image.png

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.

eine avatar eine commented on June 2, 2024

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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.