Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

css() and js() helper memoizing interacts badly with relative_links and local css/js files #5261

Closed
5 tasks done
JoshuaGrams opened this issue Aug 2, 2023 · 2 comments
Closed
5 tasks done

Comments

@JoshuaGrams
Copy link

Check List

Please check followings before submitting a new issue.

  • I have already read Docs page & Troubleshooting page
  • I have already searched existing issues and they are not help to me
    • Well, I tried searching but "css" and "js" aren't very useful search terms. But I tried "helpers" and a bunch of things, and I looked through all 61 open issues, so I don't think this has been reported...
  • I examined error or warning messages and it's difficult to solve
  • Using the latest version of Hexo (run hexo version to check)
  • Node.js is higher than minimum required version

Expected behavior

Given:

  • A local css file: /blog/root/style.css, for example.
  • relative_links: true

Then:

  • In /blog/root/index.html you want css(style.css) to return style.css
  • In /blog/root/archive/index.html you want css(style.css) to give ../style.css
  • In /blog/root/yyyy/mm/dd/title/index.html you want it to give ../../../../style.css

Actual behavior

Both of these call e.g. moize(cssHelper, ...) (here and here) so the functions are evaluated once and the result will be correct for only one particular level of nesting. Worse, the result may change semi-randomly based on which file is rendered first (i.e. it might be different on different incremental builds).

So if relative_links is set and these helpers are given a local path, the memoization needs to take into account not only the argument to the function but also the page it's being rendered for.

@stevenjoezhang
Copy link
Member

It should have been fixed by #5217

@JoshuaGrams
Copy link
Author

Ah, so it is. Ugh, how did I not find that before I spent three hours chasing it down? Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants