search.pages() and search.page() should return the data object instead of the full Page instance.

[oscarotero]

This makes working with pages easier. For example, instead of this:

{% for article in search.pages("type=article", "date=desc") %} 
<a href="{{ article.data.url }}">
  <h1>{{ article.data.title }}</h1>
</a>
{% endfor %}

It would become to this:

{% for article in search.pages("type=article", "date=desc") %} 
<a href="{{ article.url }}">
  <h1>{{ article.title }}</h1>
</a>
{% endfor %}

If it's necesary to access to the Page instance (to get the src data, for example) it's available at data.page. Example:

{% for article in search.pages("type=article", "date=desc") %} 
<a href="{{ article.url }}">
  <h1>{{ article.title }}</h1>
  Loaded from {{ article.page.src.path }}
</a>
{% endfor %}

Due this is a breaking change, it will be in Lume 2.0.

[naiyerasif]

I like this but aren't the functions search.pages() and search.page() signalling that the return type would be a Page (at least from naming perspective)?

For data, I'd say, there should be search.data() which can return Array<Data> | Data depending on filter. If we choose to add search.data(), we can bring it in 1.x by deprecating search.pages() and search.page().

[oscarotero]

search.data() already exits and returns the data associated to a file or directory. For example search.data("/") returns the data associated to the root directory (the _data files/folders), and search.data("/post/first-post.md") the data associated to this specific page.

In Lume 1.11, I've added the data filter as a temporary solution, so it's possible to do the following:

{% for article in search.pages("type=article", "date=desc") | data %} 
<a href="{{ article.url }}">
  <h1>{{ article.title }}</h1>
  Loaded from {{ article.page.src.path }}
</a>
{% endfor %}

But I think the Page instance is something internal, a implementation detail that users working with templates shouldn't need to know.

[paulrobertlloyd]

Might it be possible to enable this behaviour in v1.0 via an option in the plugin’s config?

[oscarotero]

Yes, it's a good idea.

[oscarotero]

Implemented in v2 branch #446