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

Add a mechanism for disabling @mentions on a page #39

Open
bkeepers opened this issue Aug 23, 2016 · 6 comments
Open

Add a mechanism for disabling @mentions on a page #39

bkeepers opened this issue Aug 23, 2016 · 6 comments
Labels
upstream-issue Issue related to a dependency.

Comments

@bkeepers
Copy link

I'm following the Jekyll search using lunr.js guide, and one step involves outputting JSON on the page:

<script>
  window.store = {
    {% for post in site.posts %}
      "{{ post.url | slugify }}": {
        "title": "{{ post.title | xml_escape }}",
        "author": "{{ post.author | xml_escape }}",
        "category": "{{ post.category | xml_escape }}",
        "content": {{ post.content | strip_html | strip_newlines | jsonify }},
        "url": "{{ post.url | xml_escape }}"
      }
      {% unless forloop.last %},{% endunless %}
    {% endfor %}
  };
</script>

This works fine, except that the jekyll-mentions plugin still finds @mentions in content and autolinks them, which then breaks the json.

For this specific use case, one solution is to move just the json to a separate file called content.json, since jekyll-mentions only operates on html pages.

Are there other uses cases though where it might make sense to allow disabling @mentions per-page?

@benbalter
Copy link
Contributor

This works fine, except that the jekyll-mentions plugin still finds @mentions in content and autolinks them, which then breaks the json.

Is it linking the mention once it's been jsonified, or the content when it renders the underlying post?

For this specific use case, one solution is to move just the json to a separate file called content.json, since jekyll-mentions only operates on html pages.

Exactly what I was going to suggest.

@bradjc
Copy link

bradjc commented Mar 18, 2017

Are there other uses cases though where it might make sense to allow disabling @mentions per-page?

Yes and no. The case is if you include CSS in a page and it has an @media attribute. However, disabling in this case absolutely makes sense.

@mbirth
Copy link

mbirth commented Apr 19, 2017

I'd prefer a way to prevent single @… statements from being linked, e.g. by escaping the @ like in \@something. This is how it works for other markdown, too.

See also: gjtorikian/html-pipeline#232 and gjtorikian/html-pipeline#250

@DirtyF DirtyF added the upstream-issue Issue related to a dependency. label Mar 14, 2018
@parkr
Copy link
Member

parkr commented Jul 2, 2018

I'm wholly 👍 to the idea of a front-matter option like jekyll-mentions: disable or jekyll-mentions: false or disable_plugins: [jekyll-mentions] on a per-page/per-document basis.

@emmahsax
Copy link
Contributor

emmahsax commented Jan 6, 2020

Also, would be super nice if you could override the base_url for a single file, such as

jekyll-mentions: https://twitter.com

in your _config.yml, but

jekyll-mentions: https://github.com

for a different file to use that base_url.


I made a fork of this gem, and made both of the changes discussed here: https://github.com/emma-sax4/jekyll-mentions.

So, we can override the base_url in each specific page/post frontmatter. Or, we can disable mentioning on a specific page/post by specifying false:

jekyll-mentions: false

It can be included by specifying this in the Gemfile:

gem 'jekyll-mentions', :git => 'https://github.com/emma-sax4/jekyll-mentions.git'

@ashmaroli
Copy link
Member

@bkeepers I would like to inform you that this feature has landed on the master!! 🎉 ✨
If you're still using this plugin, do let us know if it works for your use-case. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
upstream-issue Issue related to a dependency.
Projects
None yet
Development

No branches or pull requests

8 participants