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

post.content markdown not rendered #28

Open
gdhnz opened this issue Dec 18, 2014 · 45 comments
Open

post.content markdown not rendered #28

gdhnz opened this issue Dec 18, 2014 · 45 comments
Assignees
Labels

Comments

@gdhnz
Copy link

gdhnz commented Dec 18, 2014

I'm displaying full posts in my archives but the post is displaying the raw markdown and not being rendered.

@gdhnz gdhnz changed the title page.content markdown not rendered post.content markdown not rendered Dec 18, 2014
@gdhnz
Copy link
Author

gdhnz commented Dec 18, 2014

Using {{ content }} also doesn't show the content at all.

@parkr parkr added the question label Dec 18, 2014
@parkr
Copy link
Member

parkr commented Dec 18, 2014

Ah, I see. Generators are called before the render process is complete. That said, this should work nevertheless. Can you post a link to your site? What does your archive template look like? What version of Jekyll are you using?

@gdhnz
Copy link
Author

gdhnz commented Dec 18, 2014

I haven't got the site live yet as there's still a lot of other things I need to first.

Here's the archive layout I'm using with the Jekyll 2.5.2.

---
layout: default
---

<h2 class="archive-title">Archives: {{ page.title | date: '%B %Y' }}</h2>
{% for post in page.posts %}
<article> 
    <header class="entry-header">
        <h2 class="entry-title">
            <a href="{{ post.url | prepend: site.baseurl }}">{{ post.title }}</a>
        </h2>
        <time class="published" datetime="{{ post.date }}" pubdate="">
            <a href="{{ post.url | prepend: site.baseurl }}">{{ post.date | date_to_string }}</a>
        </time>
    </header>

    <div class="entry-content">
        {{ content }}
    </div>
</article>
{% endfor %}

Using {{ content }} instead of {{ page.content }} doesn't return anything.

@parkr
Copy link
Member

parkr commented Dec 18, 2014

Yeah it has to be post.content instead of content or page.content.

@gdhnz
Copy link
Author

gdhnz commented Dec 18, 2014

and we're back to my original statement. When I use post.content, none of the markdown or liquid tags are rendered.

@parkr
Copy link
Member

parkr commented Dec 18, 2014

and we're back to my original statement. When I use post.content, none of the markdown or liquid tags are rendered.

What does that mean? Plain text? Or a code block? Can you paste a screenshot?

@gdhnz
Copy link
Author

gdhnz commented Dec 19, 2014

Here's the screenshot.

screen shot 2014-12-19 at 1 01 49 pm

@alfredxing
Copy link
Member

Is this not the case for any post/page listing? post.content contains the raw input, not the processed output.

@gdhnz
Copy link
Author

gdhnz commented Jan 7, 2015

Here's the snippet for my index.html file that displays everything correctly.

<div class="listing">
    {% for post in paginator.posts %}
    <article> 
        <header class="entry-header">
            <h2 class="entry-title">
            <a href="{{ post.url | prepend: site.baseurl }}">{{ post.title }}</a>
            </h2>
            <time class="published" datetime="{{ post.date }}" pubdate="">
            <a href="{{ post.url | prepend: site.baseurl }}">{{ post.date | date: '%B %d, %Y' }}</a>
            </time>
        </header>
        <div class="entry-content">
            {{ post.content }}
        </div>
    </article>
    {% endfor %}
</div>

@davepeck
Copy link

I'm running into this bug too -- {{post.content}} in an archive page loop does not process through markdown -- so you end up getting the raw markdown text instead of intended HTML.

@parkr
Copy link
Member

parkr commented Jan 13, 2015

I'm running into this bug too -- {{post.content}} in an archive page loop does not process through markdown -- so you end up getting the raw markdown text instead of intended HTML.

Generators are run before the render step. https://github.com/jekyll/jekyll/blob/master/lib/jekyll/site.rb#L51-L58

@davepeck
Copy link

Understood, thanks!

I'm wondering where the solution lies. It feels like the current behavior is undesirable. Is this something that needs to be filed against Jekyll itself -- an improvement for Generators for future consideration? Or is there a way to improve jekyll-archives here? Thanks.

@parkr
Copy link
Member

parkr commented Jan 13, 2015

The solution is to allow Jekyll to do the rendering itself. The jekyll-paginate process does this by appending a Page to site.pages and letting Jekyll do its thing. From a cursory glance at the source code here, the render process is taken care of here, which would yield this error. /cc @alfredxing

@alfredxing
Copy link
Member

@parkr Nice catch! I'll see about fixing that up and just adding it as a Page.

@matthewmcvickar
Copy link

I’m not sure if I’m misunderstanding the status of this issue, but is there a workaround for this currently, or does the jekyll-archives plugin need to be fixed?

@alfredxing
Copy link
Member

@matthewmcvickar Sorry for the wait; I've been quite busy recently with school. I'll get around to this as soon as I have some time!

@alfredxing alfredxing self-assigned this Apr 2, 2015
@alfredxing
Copy link
Member

Just looked into this again, and now I remember why I didn't append the archives to site.pages: if this was done, anyone iterating over site.pages (in the nav, for example) would see archive pages as well...
@parkr Any suggestions?

@parkr
Copy link
Member

parkr commented Apr 2, 2015

The only way to enforce this would be to render every item...

@alfredxing
Copy link
Member

You mean render every page as necessary?

@DylanVann
Copy link

The markdownify filter might be useful for this.

{{post.content | markdownify}} or {{ content | markdownify}}, whatever fits.

@gdhnz
Copy link
Author

gdhnz commented Apr 21, 2015

While using markdownify does appear to render the markdown, it doesn't render {% highlight bash %}

@sumdog
Copy link

sumdog commented May 12, 2015

I had this same issue. I have an _include file for all my posts. For the archive layout, I just did the following:

{% for post in page.posts %}
  {% include post.html item=post markdown=true %}
{% endfor %}

and within my post include:

  {% if include.markdown %}
    {{ include.item.content | markdownify }}
  {% else %}  
    {{ include.item.content }}
  {% endif %}

Since generators are run before renders, this might be the only solution (unless you do the markdown step in the generation in jekyll-archives itself... haven't looked at the code to see how possible that is)

@gdhnz
Copy link
Author

gdhnz commented Jun 5, 2015

While the previous suggestion of an include works for markdown, it still doesn't render {% highlight bash %} blocks.

Is there a similar method like markdownify that does render code highlights? hilightify?

{{post.content | markdownify | hilightify }}

@MaximeKjaer
Copy link

Not to my knowledge. I've been able to get rid of the problem by downgrading from jekyll-3.0.0.pre.beta8 to jekyll-2.5.3 for the time being... (though that means going back to dealing with issue #2607 which was fixed in the beta 😥).

@nbolten
Copy link

nbolten commented Aug 14, 2015

This still happens with jekyll-2.5.3 and jekyll-archives 2.0.0. @MaximeKjaer, what is your setup where you can get post.content rendered from a jekyll-archives layout?

ZE3kr referenced this issue in ZE3kr/GuoZeyu.com Aug 15, 2015
目前 `jekyll-archives` 插件[存在不能解析文章内容的
Bug](https://github.com/jekyll/jekyll-archives/issues/28),等待官方更新。
@nexocentric
Copy link

@DylanVann If content written in markdown needs to be run through a filter to be displayed properly, shouldn't that be added to the documents? Or is this thread actually not a question, but a bug?

@metachris
Copy link

Any feedback on this issue?

{{ post.content | markdownify }} works as a workaround for the markdown, but syntax is not highlighted.

Seeing this on jekyll 3.1.1

@fabacab
Copy link

fabacab commented Mar 19, 2016

Just a note to say I ran into this today, too. {{ page.content | markdownify }} works for me, too, though, so all things considered, pretty minor.

@OscarPellicer
Copy link

I was having this problem, where a post preview would (only in some pages) show unrendered liquid code from some includes I had

`


{{ post.content | strip_html | truncatewords:43 }}

`

Since I wasn't able to find a solution I included this quick and dirty fix at the end of every page, until I find something better:

<script> 
        $( ".remove-jekyll-js" ).each(function() {
            var post= $( this ).html();
            $( this ).html(post.replace(/\{\%.*?\%}/, "").replace(/\{\%.*?\.\.\./, "..."));
        });
</script>

This uses jquery and js to get rid of {% whatever %} and {% whatever ...
Maybe someone finds it useful in the meanwhile.

@breakingespanol
Copy link

breakingespanol commented Jun 28, 2016

I'm having this issue as well, however, part of the page is rendering but not all. Specifically, the unordered list is not rendering.

repo:
where: http://breakingespanol.com/about/
my page layout:

---
layout: default
---
<article class="page">
<h1>{{ page.title }}</h1>
<div class="entry">
{{ content }}
</div> `

markdown-error

@KendallPark
Copy link

Interestingly, my gh-pages site depends on page.content being the raw markdown of the page. Now it seems that gh-pages has "fixed" this, subsequently breaking my site, which requires raw markdown for Remark.js. Is there a way to get the raw, unprocessed markdown?

@ghost
Copy link

ghost commented Aug 5, 2016

@KendallPark I don't think your problem is related to jekyll-archives however a solution for you is to add a generator plugin that adds a variable containing the raw markdown. Use this variable in place of page.content. However you'll have to build your site locally before pushing to Github Pages.

@groundh0g
Copy link

Sorry if this is off-topic, but I ran across a similar issue with a very simple fix.

My code to aggregate a list of book summaries looked like this:

{% for file in site.pages %}
    {% if file.path contains "books/" and file.path contains "/summary.md" %}
        {{ file.content }}
    {% endif %}
{% endfor %}

The content wasn't formatted. So I tried the markdownify solution and it became unformatted, raw HTML. That made me think it was being treated like a code block (indented by more than 4 spaces).

The following fixed it for me. (Note the unindented {{ file.content }} statement.)

{% for file in site.pages %}
    {% if file.path contains "books/" and file.path contains "/summary.md" %}
{{ file.content }}
    {% endif %}
{% endfor %}

@groundh0g
Copy link

@breakingespanol, when you wrap markdown in a <div/>, you'll see that behavior. Does the markdownify filter not fix it?

(eg. <div class='entry'>{{ content | markdownify }}</div>)

alfredxing added a commit that referenced this issue Aug 24, 2016
Make Archive a subclass of Jekyll::Page, and render it using the regular
Page pipleline. This should fix long-standing issue #28.
alfredxing added a commit that referenced this issue Aug 24, 2016
Make Archive a subclass of Jekyll::Page, and render it using the regular
Page pipleline. This should fix long-standing issue #28.
olistik added a commit to emergenzeHack/terremotocentro that referenced this issue Aug 26, 2016
Usa `post.excerpt` invece di `post.content` in quanto quest'ultimo può contenere codice Markdown non ancora renderizzato.

Vedi [issue](jekyll/jekyll-archives#28).

fixes #27
@2m
Copy link

2m commented Feb 10, 2017

Got bitten by this in https://github.com/akka/blog

Worked around with:

{% assign curlyend = '}' %}
{{ p.content | markdownify | strip_html | replace: "{% include JB/setup %", "" | replace: curlyend, "" | truncatewords: 30 }}

@alfredxing
Copy link
Member

@2m Are you using jekyll-archives? I looked at your repo and it looks like you're using Jekyll Bootstrap, but I couldn't find Archives in your _config.yml anywhere.

@2m
Copy link

2m commented Feb 11, 2017

Hm. You might be right. I am not that experienced in jekyll. If you say that you could not find jekyll-archives in the project, then I am not using it. Sorry for the noise here. The problem described here looked similar enough to the one I was having, therefore I assumed my blog was using jekyll-archives for displaying post archive.

@ashmaroli
Copy link
Member

Hello everyone!!
Is this still an issue while using Jekyll 3.7 / Jekyll 3.8 ? If yes, would you be able to provide a link to a minimal test repository that I can just clone and use..?

wez added a commit to wezterm/wezterm that referenced this issue Jun 24, 2019
I'm committing this because it captures a repro for the situation
described across these two issues:

Refs: jekyll/jekyll-archives#28
Refs: jekyll/jekyll#6209

This commit has a workaround in place; to demonstrate the problem,
change this line of `_layouts/default.html`:

```
 {% include toc.html sanitize=true baseurl=p.url html=p_content %}
```

to:

```
 {% include toc.html sanitize=true baseurl=p.url html=p.content %}
```

Then navigate to various pages: the TOC in the LHS inconsistently
shows headers from different pages depending on the current page.
@wez
Copy link

wez commented Jun 24, 2019

I think this issue and jekyll/jekyll#6209 have some similarities in how they manifest. I'm using GH pages with no explicit configuration of jekyll-archives so perhaps this issue is not the best one to remain open to track this. I pushed wez/wezterm@b0f2edd which captures the state of the weirdness in case someone would like to dig in and resolve things. I have a workaround that I'm "OK" to stick with for now.

rsanheim added a commit to rsanheim/rsanheim.github.com that referenced this issue Nov 19, 2021
because this is a very old jekyll site and ya know, software

see jekyll/jekyll-archives#28
@trivedihiralm
Copy link

Running into similar issue.
markdownify did help with rendering the page correctly but my .md file has an HTML included in it.
{% include links.html %}

The links.html doesn't get rendered correctly for a few when the HTML files are getting generated.
Any tips on how to solve this?

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

No branches or pull requests