Load custom files from outside the theme [solved] about hexo-theme-next

[ivan-nginx]

Explain, why u need it?

[wafer-li]

OK, for now, if you need to custom the theme, you need to make a fork, since the custom files are everywhere.

When you need to update the theme from the original upstream, you need to deal with hundreds of conflicts since this theme is still maintained and under development.

And while you use Rebase Merge and GPG Signing, it will be more painful to sign hundreds of git commits.

---

But, if the theme could load custom files from given paths, it will make life easier.

[ivan-nginx]

hundreds of conflicts

For example, which conflicts? Can u not use abstract words and say concrete, what u want or what is bad?

And while you use Rebase Merge and GPG Signing, it will be more painful to sign hundreds of git commits.

Here i repeat read message. When repeat and repeat reading again. And can i ask u a question:
What is difference between Rebase, Merge and GPG Signing of commits?

And what mean «hundreds of git commits»? U want on same theme only 10 commits, but at same time this theme must be cool, without bugs and, of course, best Hexo theme? I just trying to understand u logic and if anyone can update to the latest commit in anytime, what's the difference between hundrends and millions commits?

But, if the theme could load custom files from given paths, it will make life easier.

It already will. Make. Life easier. U know something about .gitignore? U can just add there all custom files u want, and, viola! — it will make your life easier. Easy. For free. Without create a wheels.

[wafer-li]

First of all, sorry for my tone above.
I am really sorry that making you so mad.

---

What I really want is «the theme could load custom files from given paths».

After a seriously and carefully consideration, I notice that it could be done through some scripts.

Sorry for bothering you and your org again.

---

Here is my reply to some of your words, if you are interested in it, it might explain my thought further:

What is difference between Rebase, Merge and GPG Signing of commits?

The term Rebase Merge comes from GitHub, it is just rebase.
When using the rebase, since I enable the commit.gpgsign option globally in git config,

I need to use the GPG Key to sign every commit of the incoming upstream updates to make the rebase process done.

It is too painful to sign about 500 commits when I reopen my site after a long preparation of an important exam.

U want on same theme only 10 commits, but at same time this theme must be cool, without bugs and, of course, best Hexo theme?

No, I understood that a well-maintained project comes with lots of commit and recently updates.

I just trying to understand u logic and if anyone can update to the latest commit in anytime, what's the difference between hundrends and millions commits?

That's right, but the custom files isn't a part of the theme actually.

Those files are specified by theme's user and as an input of the theme, they are not maintained by the developer of the theme.

Therefore, it doesn't bother about the difference between commits pushed by the developer.

And in my opinion, those files should be separated from the theme

U know something about .gitignore? U can just add there all custom files u want, and, viola!

Since I use CI, those files should not add to .gitignore as a local file.

[ivan-nginx]

I need to use the GPG Key to sign every commit of the incoming upstream updates to make the rebase process done.

I no need. Use soft at least past of 3 years, any GUI, for example. If u still use console from 2000x, ok. please, sign your commits one by one. It's your problem, not problem NexT, Github and all maintainers, ok? So, notice about «Rebase Merge and GPG Signing» is not relevant, i think. BTW, i no once no do Rebase, only Merge always, if u understand what i'm talking about. But i think Signing is just your appearance, sign not do your code for u and if your commits not signed, that's not mean u noob or other things; this just meaning u don't care about it. U can use GPG or can not use, isn't it?

It is too painful to sign about 500 commits when I reopen my site after a long preparation of an important exam.

I don't understand u, go again: u must to sign every commit, right? With console, right? With sample git command, right? Just, help me, or i will guess to infinity. U not explain your problem, and then u just walk around because nobody help u. But how to help u if u just say «i want custom styles in one place, that's all i want»? In this case impossible to help, try to understand.

Since I use CI, those files should not add to .gitignore as a local file.

Yeah, dude from another issue think the same, but problem was solved and all worked fine.

After a seriously and carefully consideration, I notice that it could be done through some scripts.

Wow! Maybe will be better to remake a wheel? No? Script? I wondering, how it may be!? Never heard about scripts.

---

How i pull/push NexT: i not use for now any GPG sign, never use rebase and work easy in several branch with NexT and other repos in desktop CentOS with Git GUI. U can try to find any GUI for any OS, there is thousands of GUI.

---

I just don't understand: guys, u liked simple take my time for nothing or what? If u suggest something, be kind, take your hands and your head and focus on this suggest to try to take a wave and explain what, how and where u want, step by step. Something like «i want what NexT will be cool and all plugins and configs will in one place and i just push 1 button and money from the sky poured out to me» — not accepted. It's at least waste of time.

---

P.S. Please, in next time suggest your problem more accurately and, desirable, step by step for understanding what u what and mb what u doing not right in your steps. Thank's!

[wafer-li]

Please, in next time suggest your problem more accurately and, desirable, step by step for understanding what u what and mb what u doing not right in your steps. Thank's!

OK, I will keep it in mind.

Wow! Maybe will be better to remake a wheel? No? Script? I wondering, how it may be!? Never heard about scripts.

Just like this:

cat custom/css/custom.styl >| themes/next-reloaded/source/css/_custom/custom.styl

Therefore, the custom css could be loaded from custom/css/custom.styl which locates in the root dir

[ivan-nginx]

Therefore, the custom css could be loaded from custom/css/custom.styl which locates in the root dir

U must understand what css styles is not the same as config based on javascript, it's different things. But, yes, it can be merged in one config if try to hard work. I don't see how to easy implemet it for now. But your thinking is right, it is not usable to keep configs in different files and directories across the troubles with git/deploy will be always appear.

cat custom/css/custom.styl >| themes/next-reloaded/source/css/_custom/custom.styl

This is semi-auto decision. But work? Work. Well, we can live with this for now, because there are many other important things wait to implement they.

[wafer-li]

I am so appreciate that you finally understand my thoughts.

I think we should document that

Where are the custom CSS, layout etc.
Or how do I write a custom CSS and so forth.

[ivan-nginx]

Styles inherited from main SCSS variables. For example, base.styl is defined in ../main.styl by $variables = base $scheme custom; string. So, it's defined other and other variables to infinity. But root of this that — main SCSS engine, which do implement only for browsers. And hexo can generate and unite any swig, ejs or any other renderers with most of current styles, SCSS (SASS) too. But, it's can't be merged because there is different syntax, because hexo (swig) have JS syntax, and SCSS — CSS syntax. It can be in rare cases used by variables from SCSS to JS or vice versa, but not always and need to try hard for this. There is no complete compatibility with this 2 structures, but! If made something like mini-engine, which will interpreter from one language to another, we can use both syntax & source in 1 place and render it how 1 structured language. But i repeat: it's a little difficult.

[wafer-li]

Em....... It might be some misinterpretation here.

For now, Next has lots of custom files located in different places:

For example, the custom CSS is located in source/css/_custom/custom.styl, the custom <head> is located in layout/_particial/head/custom-head.swig etc.

What I really want and suggest is let us make that files out of theme, not to combine them into one file.

Let's say, a custom dir which located in the root of hexo:

Currently, I could use some cat cmds to workaround it:

cat custom/css/custom.styl >| themes/next-reloaded/source/css/_custom/custom.styl
cat custom/head/custom-head.swig >| themes/next-reloaded/layout/_particials/head/custom-head.swig
cat custom/layout/header.swig >| themes/next-reloaded/layout/_custom/header.swig

If it can be achieved in theme, then will come with a config:

custom_file_path:
  header: custom/head/custom-head.swig
  head: custom/layout/header.swig
  css: custom/css/custom.styl

And the theme just loads that custom files from the path in above.

Since the config file is already extracted from theme into source/_data/next.yml.
Then the user could just update the theme easily and don't need to copy and paste files which describe in UPDATE-FROM-5.1.X

[ivan-nginx]

Oh, now i see. Well, it's easy to implement.

[ivan-nginx]

Added this feature. How to use see NexT config descriptions:

# Redefine custom file pathes. Introduced in NexT v6.0.2.
# If commented, will be used default custom file pathes.
# For example, you want to put your custom styles file
# outside theme directory in root `source/_data`, set
# `styles: ../../../../../source/_data/styles.styl`
custom_file_path:
  head: ../../../../../source/_data/head.swig
  #header: ../../../../source/_data/header.swig
  #sidebar: ../../../../source/_data/sidebar.swig

  styles: ../../../../../source/_data/styles.styl
  #mixins: ../../../../../source/_data/mixins.styl
  variables: ../../../../../source/_data/variables.styl

---

Fixed source path to default: 12fe131

[wafer-li]

Emm..

What is source-lang?

[ivan-nginx]

It's just my directory for tests, fixed on default source which defined in Hexo source_dir.

[ivan-nginx]

@wafer-li so, are u happy for now? 😃

[wafer-li]

Maybe some docs is needed about what is the ../../../../../

And to alert them not to touch it, just append the path after it.

[ivan-nginx]

Yes, that's right.

[wafer-li]

Or, what about just use one more config _hexo_dir, and it will look like this:

custom_file_path:
  _hexo_dir: ../../../../../ # DO NOT CHANGE IT
  head: source/_data/head.swig
  #header: source/_data/header.swig
  #sidebar: source/_data/sidebar.swig

  styles: source/_data/styles.styl
  #mixins: source/_data/mixins.styl
  variables: source/_data/variables.styl

Just as the vendors:

vendors:
  # Internal path prefix. Please do not edit it.
  _internal: lib

  # Internal version: 2.1.3
  jquery:

  # Internal version: 2.1.5
  # See: http://fancyapps.com/fancybox/
  fancybox:
  fancybox_css:

[ivan-nginx]

I think about this, but if u see on this paths, there is diffs in count of ../ because files placed in different places and it's just relative paths.

Only if we can somehow to get main hexo dir from styles file, then it can be implemented by global hexo variable + custom user paths. But for now in styles only hexo-config option from hexo-renderer-stylus which only preserve theme settings (not inherit hexo settings). See here for details.

[ivan-nginx]

But i have another idea how to remove this dotes. I'll try it now.

[ivan-nginx]

How about that? 1cb4d08

# Redefine custom file paths. Introduced in NexT v6.0.2.
# If commented, will be used default custom file paths.

# For example, you want to put your custom styles file
# outside theme directory in root `source/_data`, set
# `styles: source/_data/styles.styl`
custom_file_path:
  #head: source/_data/head.swig
  header: source/_data/header.swig
  #sidebar: source/_data/sidebar.swig

  styles: source/_data/styles.styl
  #mixins: source/_data/mixins.styl
  variables: source/_data/variables.styl

[wafer-li]

Yes, that approach comes to my mind at some point, but I soon forgot about it!

In this way, just need to notify the user the dir is relative to his/her hexo's root.

[ivan-nginx]

Yeah, in main docs it will be. And if user is not too noob, he's will understand what it's hexo root relative pathes and comments talk about it.

So, issue can be closed, i think.

[wafer-li]

OK.

[wafer-li]

But you seem to comment out the config:

#custom_file_path:
  #head: source/_data/head.swig
  #header: source/_data/header.swig
  #sidebar: source/_data/sidebar.swig

  #styles: source/_data/styles.styl
  #mixins: source/_data/mixins.styl
  #variables: source/_data/variables.styl

---

Fix it and this issue could be closed.

[ivan-nginx]

So? Read comments above this option:

If commented, will be used default custom file paths.

So, there are no breaking changes.

[wafer-li]

@ivan-nginx
Sorry, my mistake.

Goodbye to this issue.

[sli1989]

I' m sorry to disturb you with this question.
if i want to change the font-size-base and Global link color in custom.styl (source/css/_variables/custom.styl), what did i do in custom_file_path:?
if i want to change other custom styles in custom.styl (source/css/_custom/custom.styl), i just copy the content to the variables: source/_data/variables.styl ?

[ivan-nginx]

U are right, this must be documented and will be later. For now i can give short explain like this:

# Redefine custom file paths. Introduced in NexT v6.0.2.
# If commented, will be used default custom file paths.

# For example, you want to put your custom styles file
# outside theme directory in root `source/_data`, set
# `styles: source/_data/styles.styl`
custom_file_path:
  head: source/_data/head.swig — layout/_custom/head.swig
  header: source/_data/header.swig — layout/_custom/header.swig
  sidebar: source/_data/sidebar.swig — layout/_custom/sidebar.swig

  styles: source/_data/styles.styl — source/css/_custom/custom.styl
  mixins: source/_data/mixins.styl — source/css/_mixins/custom.styl
  variables: source/_data/variables.styl — source/css/_variables/custom.styl

And for your questions:

if i want to change the font-size-base and Global link color in custom.styl (source/css/_variables/custom.styl), what did i do in custom_file_path:?

It's variables, so:

custom_file_path:
  variables: source/any_path_you_want_vars.styl

if i want to change other custom styles in custom.styl (source/css/_custom/custom.styl), i just copy the content to the variables: source/_data/variables.styl ?

It's custom styles, so:

custom_file_path:
  styles: source/any_path_you_want_custom_styles.styl

---

Parameter styles — mean it's custom styles placed in _custom/custom.styl. I can't named it's custom, because all it's styles — they all custom. So, there is vars, mixins and something like global custom styles (which rewrite all styles before), i called it just styles.

[sli1989]

thanks. it's helpful.

---

i would like to say it's amazing.
haha...

[Ahaochan]

I'm sorry to open this issue.
Can you add a block to fill Custom JavaScript file?
I need to add copy event JS in My Blog.

(function () {
    var all = document.getElementsByTagName("*");
    for (var i = 0, len = all.length; i < len; i++) {
        var element = all[i];
        element['oncopy'] = function() { alert("you copy from My Blog") };
    }
})();

[maple3142]

@Ahaochan Use inline-script? <script>/*Your script*/</script>

[Ahaochan]

@maple3142 not only inline-script.
I think like this, the code in _layout.swig.

  {% include '_third-party/bookmark.swig' %}
  {% include '_third-party/copy-code.swig' %}
// =================such as============
  {% if theme.custom_file_path.js %}
    {% set custom_js= '../../../../' + theme.custom_file_path.js %}
  {% else %}
    {% set custom_js= '../_custom/js.swig' %}
  {% endif %}
  {% include custom_js%}
// =================such as============
</body>
</html>

After all the scripts, make sure the All dependencies ( like jQuery ) is loaded.

[ivan-nginx]

@Ahaochan it's already backloged into Roadmap as «Custom JS files.».

But for now, as @maple3142 talked above, u can use custom inline script in layout files:

hexo-theme-next/_config.yml

Lines 21 to 25 in 51b6996

	#custom_file_path:
	# Default paths: layout/_custom/*
	#head: source/_data/head.swig
	#header: source/_data/header.swig
	#sidebar: source/_data/sidebar.swig

So, u can try to add in header.swig your JS code and it must work fine.

[stevenjoezhang]

Theme inject feature added in NexT v7.3.0