Summary always truncates at 300 chars, ignores delimiter and custom int setting

[veggit]

I use Grav 15.10, with the Mediator 1.0.2 skeleton. On the home page, which is a masonry listing of blog posts, each post shows up with title, summary, and ‘read more’ link.

I would like the summary to end at 1000 characters or whenever the delimiter ‘===’ is used. I put those settings in my site.yaml file.

summary:
  enabled: true
  format: short
  size: 1000
  delimiter: ===

On each blog post, I typed ‘===’ between my summary and body (with line breaks before and after).

Yet, my settings don’t seem to have any effect. No matter what I choose, the summary is always truncated at 300 chars.

I simply don’t see any changes. No matter if I choose long or short, different char sizes, different delimiters, etc. I’ve cleared all cache more times than I can count.

Does anyone know what I’m doing wrong?

[hschneider]

Set the delimiter in single quotes:

Any difference ?

[pamtbaau]

@veggit, If I interpret the source-code of Page and my tests correctly:

• format: short
  It seems that when the delimiter is present and format is ‘short’, the delimiter has precedence over size. In other words, the setting for ‘size’ is ignored and not ‘first come first serve’.
• format: long
  Delimiter is ignored and size is used to create summary.

Since you have added === to every post, only the delimiter is honored when format is ‘short’.

You said:

No matter what I choose, the summary is always truncated at 300 chars.

I don’t understand this one and I also cannot reproduce it. When format is ‘short’ and no delimiter is added to the page, page.summary() correctly returns a summary with the given size.
Only when ‘size’ is null, or not numeric, or < 0, then Grav will use 300 as default value.

Hope this helps…

[veggit]

@hschneider:

Any difference ?

Unfortunately no, putting the delimiter in single quotes didn’t solve it.

I would’ve been surprised if that had solved my problem fully, because it’s not just the delimiter that isn’t honored, but neither is the char limit. No matter what I do, I always get the 300 char summary.

[veggit]

@pamtbaau:

That too is how I read it in the docs, but that’s not what happens on my install.

It doesn’t matter whether I choose short or long, with or without delimiter, and char limit. Those changes don’t take effect at all, I always just get a 300 char summary.

I’ve already reinstalled Grav a couple of times, hoping that would solve it. But no. Could it be an issue with the theme or skeleton? It occurs on both Mediator and Masonry.

[pamtbaau]

@veggit, Some investigation on Mediator:

• Looked at the github repo of Mediator and searched for ‘.summary(’ but nothing was found… That means that the function ‘summary()’ isn’t used at all.
• Downloaded the skeleton for Mediator and found the following in template ‘user/themes/mediator/templates/partials/article.html.twig’ I found the following code snippet:

  <section class="post-excerpt" itemprop="description">
     <p>{{ post.content | striptags | truncate(200) }}</p>
  </section>
  

  Well… how about that… hard-code truncation of content. Not at 300 but at 200 though.

Remarks:

• The theme is 5 years old, which is in the early days of Grav. I suspect that ‘page.summary()’ has been introduced later.
• I would suggest to ditch such an old theme and look for a newer alternative…

[veggit]

@pamtbaau:

Wow yes, that explains everything!

I’m sure it’s correct that the summary is 200 chars instead of 300, I didn’t count them.

The theme is 5 years old … I would suggest to ditch such an old theme and look for a newer alternative

I’d definitely be open to that, but none of the themes I looked at appealed to me. I like the look of masonry grids. The only Grav themes I found that use it are Masonry, and Project Space. (Masonry theme assumes use of the Mediator skeleton, that’s why I’m first trying to get Mediator to work correctly) And those two themes are both quite old and not updated often.

Would you know of an alternative that’s newer and/or updated more often?

Otherwise, I can live with changing the code on the Mediator skeleton. You having found the culprit helps a great deal, thanks for solving the mystery. Perhaps the summary feature can be retrofitted on to it.

[pamtbaau]

@veggit, To retrofit the ‘page.summary()’ into Medator you could try to replace:

<p>{{ post.content | striptags | truncate(200) }}</p>

with the following taken from Quarks ‘partials/blog-list-item.html.twig’:

{% if page.summary != page.content %}
    {{ page.summary|raw }}
{% else %}
    {{ page.content|raw }}
{% endif %}

I wouldn’t know which themes would be a suitable alternative for your needs. First, I don’t know your taste and second, I only use my own home-grown themes…

Have a nice day!

[veggit]

@pamtbaau:

That looked promising, but unfortunately didn’t work. When I use that snippet, the summary disappears altogether.

[veggit]

@pamtbaau:

I wouldn’t know which themes would be a suitable alternative for your needs. First, I don’t know your taste and second, I only use my own home-grown themes…

Fair enough. The Masonry theme is very close to what I was looking for. It uses a masonry grid that reflows well and I figured it wouldn’t be too hard to change its appearance to my needs (fonts and colors, different header, etc).

I’ll definitely delve into Twig and want to make my own themes, but this is my first site using Grav, so I just wanted to get started first.

I like that Grav is a static site generator and doesn’t require a database. I like that the themes are all contained in one folder, and that most stuff can be done with HTML/Markdown and CSS, instead of services that require a CLI like Less/Sass, node.js, etc. And the admin interface is a joy to use.

[pamtbaau]

@veggit, Sorry, made a dumb mistake… Snippet should use ‘post’ instead of ‘page’:

{% if post.summary != post.content %}
    {{ post.summary|raw }}
{% else %}
    {{ post.content|raw }}
{% endif %}

[veggit]

@pamtbaau:

That worked like a charm, thanks so much! I understand why it should be ‘post’, not ‘page’, but I’m not experienced enough to have caught the error myself.

Here’s how each item in the article listing looks now, which is the expected behavior:

[hughbris]

Oof, 5 years! Well found @pamtbaau!

I thought it was sounding hardcoded somewhere. Old themes are risky. I’d like to see them somehow checked for compatibility after a year or so of no updates, and archived from the repo if they fail.