fix: external_link should use after_render

[curbengh]

What does it do?

after_post_render only applies to rendered posts/pages, so external_link doesn't work on links specified in themes. This PR fixes that by using after_render:html instead.

Added options

external_link:
  enable: true
  field: 'site'|'post'
  exclude:
    - 'exclude1.com'
    - 'exclude2.com'

Backward compatible with

external_link: true|false

How to test

git clone -b external-link https://github.com/curbengh/hexo.git
cd hexo
npm install
npm test

Pull request tasks

• Add test cases for the changes.
• Passed the CI test.

[coveralls]

Coverage increased (+0.03%) to 97.281% when pulling 26b010a on curbengh:external-link into ffe4eaa on hexojs:master.

[curbengh]

not sure why it fails the test (including local unit test). It works in actual use case.

[SukkaW]

I don't see why external_link should be registered at after_render.

If there are external links that not in the post.content, which means those links is in the theme layouts, then _target attributes can be added directly in the theme template.

[curbengh]

If there are external links that not in the post.content, which means those links is in the theme layouts, then _target attributes can be added directly in the theme template.

I assume user expects external_link to apply to all the links including those listed in a theme.

We can't expect user to verify the rendered html and modify the theme accordingly.

[SukkaW]

We can't expect user to verify the rendered html and modify the theme accordingly.

For me, best practice is to let user decide which to choose, but adding a configuration might cause a break change and have no backward compatibility.

[curbengh]

For me, best practice is to let user decide which to choose...

you mean choosing which links to apply?
before this PR, if user does not disable external_link, all the links in posts/pages will be applied. This PR simply include links in the theme as well, which I don't think is a breaking change; it means the links in the theme will behave the same as posts/pages'.

I understand this approach incur performance cost, but this is necessary for consistency.

---

What I meant in previous comment is that we can't expect to verify each and every <a> in the rendered html, then cross-check with all the links in theme. Links in posts/pages should behave the same as theme's.

[curbengh]

On the user customization, we can introduce an extra option (e.g. exclude_external_link) to exclude user-specified domains from being processed by external_link. It's relatively easy to implement, just need to port over these lines.

[SukkaW]

IMHO, since we are going to release a big version 4.0.0, we could just bring something new to external_link like:

external_link:
  enable: true
  onlypost: false
  exclude:
    - 'exclude1.com'
    - 'exclude2.com'

And still accept external_link: true to maintain backwards compatibility.

[curbengh]

I can introduce exclude_external_link (or similar) in a separate PR.

[curbengh]

rebased

[curbengh]

rebased

[curbengh]

IMHO, since we are going to release a big version 4.0.0, we could just bring something new to external_link like:

external_link:
  enable: true
  onlypost: false
  exclude:
    - 'exclude1.com'
    - 'exclude2.com'

And still accept external_link: true to maintain backwards compatibility.

Added in latest commits.

[curbengh]

btw, I did attempt to dedup based on approach used in hexo-filter-nofollow, but somehow it affects other unit tests.

[curbengh]

Rebased to fix failing test.