Ghost: `fields=excerpt` requires underlying knowledge

[ErisDS]

The excerpt field is a calculated field based on plaintext at the moment if you request e.g. ?fields=title,excerpt you won't receive the excerpt field unless you also supply ?formats=plaintext.

To Reproduce

1. Visit https://demo.ghost.io/ghost/api/v2/content/posts/?key=22444f78447824223cefc48062&fields=title,excerpt
2. Notice excerpt is missing completely
3. Add &formats=plaintext https://demo.ghost.io/ghost/api/v2/content/posts/?key=22444f78447824223cefc48062&fields=title,excerpt&formats=plaintext
4. Now we get the excerpt and the plaintext field.

It's unexpected that I am only able to get the excerpt field whilst the plaintext format is also included. This logic should be "behind the scenes" much the same as the url field.

Technical details:

• Ghost Version: master

[naz]

After trying multiple approaches with adding this field on different levels: input/output serializers or on model layer; there doesn't seem to be any clean way of including this field without hacking some kind of 'defaultColumn' or hacky detection of excerpt field and than forcefully adding/removing plaintext format on different serialization levels.

Think that most sane approach to having this field work is adding it as a new excerpt field in the posts table and setting it along with plaintext in onSaving method of post model. This is mostly due to the fact that this is a calculated field or another calculated field (plaintext) , which makes things a bit too complex.

What do you think @kirrg001 @ErisDS ?

[kirrg001]

much the same as the url field.

The url field is not really compareable with the excerpt virtual, because we only need the model id to get the url.

Think that most sane approach to having this field work is adding it as a new excerpt field in the posts table

Our post table row size limit is almost reached. I agree in general that without virtuals, it would be much easier and less challenging. I understand your suggestion.

---

IMO the most generic and re-usable solution is: if a user passes the "fields" param, we automatically tell the model layer to fetch more columns. We just need to define a set of general fields we should fetch - e.g. a minimum basic set of fields for this API version. The API (shared) output serializer needs a generic piece of logic to remove any column which was not requested. This should be independent of the excerpt feature. IMO a default set of columns should not be implemented on the model layer.

Alternative is to treat "fields" on API layer only and always fetch a full resource, but this change has for sure a performance impact.

[ErisDS]

As this issue has a clear workaround, I think it is lower priority than many of the other API issues.

[iifeoluwa]

Hi @ErisDS,

I think this issue is interesting and, I'd like to help out with it if you think it's something a total stranger to the project can handle.

My understanding of the issue is; we want to be able to fetch fields=excerpt without having to supply formats=plaintext. And, the suggested ideal solution is to have the model always return some set of "default" fields, if specific fields are requested, those are also fetched by the model.

Then, we make the API output serializer remove fields that have not been requested.

Is my understanding of this correct please? And, do you think it's something a new contributor can handle? I do not want this to be more of a burden than a help to you by requiring a lot of handholding.

Thanks and well done for such a great product!

[ErisDS]

@iifeoluwa it definitely sounds like you've understood. I think you're probably best able to answer whether it's ok for you - if you take a fixed amount of time to review the codebase and can find roughly the right bits that need editing, then you should be set 💃

[iifeoluwa]

Alright then. I'll take some time to go through the codebase and report back when I feel I've found where the needed changes need to happen.

Thanks for your help!

[zicklag]

I've noticed that the excerpt retrieved with the workaround is also different than the excerpt that I get when retrieving the whole post. When querying with fields=excerpt&formats=plaintext, it will give me the first so many characters of the post, but when querying the whole field, I will get the custom excerpt if it was specified.

I'm trying to use the API to get a list posts with their titles, authors, excerpts, etc. for a home page, but I didn't want to download the entire page contents so that I could save on bandwidth. This is a blocker for that. For now I'll have to resort to downloading the whole post. :slightly_frowning_face: I'm pretty sure it is still fast enough without the optimization, but it would be nice to get this fixed. :+1:

[kevinansfield]

@zicklag can you try with fields=excerpt,custom_excerpt&formats=plaintext? I believe the fields parameter limits what's fetched from the database so if the custom_excerpt isn't included then it can't be used for the excerpt generation (this is similar to what the original bug report is about)

[zicklag]

Ah, that did work, but now I'm also downloading the plaintext render for the whole post, which means I'm probably not saving much in the way of bandwidth.

[TheRoccoB]

Thanks for this bug report, saved me some time figuring out why excerpts wasn't working as a field. It is pretty annoying, though that formats=plaintext also serves the full text of the article, especially on a JAMstack / SPA app where I am showing things dynamically via frontend ajax calls.

I think it's a pretty common use case where you'd want to pull down JUST the article excerpt and not the whole text.

Overall though, still loving ghost as a CMS for my site. I fought with strapi.io for awhile, but ghost is a better solution for writing articles for my site. Thanks for your hard work folks!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tvld]

@ErisDS As we can not get field reading_time without getting the whole plaintext / article, I would not consider this a low priority. If we have 100 articles, show the user a list with _titles, reading_times_ and the _publication_date_, we need to fetch each time 100 full posts? It gives a serious performance hit and overload the client's mobile phones...