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

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

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.

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.

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.

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.

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.

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.

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

rebased

rebased

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.

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

Rebased to fix failing test.