introduce filtered pagination

[DjThossi]

I'd like to propose the following feature.

filtered pagination is providing an opportunity to generate an overview page only with blog posts which have a certain meta block provided. It is indifferent if it is part of a list or a simple string.

example
In blog post itself:

---
...
show: this
...
---

in overview page:

---
...
generator: pagination
pagination:
  max_per_page: 9
  provider: filtered.posts.show.this
...
---

On this overview page will now appear only entries with the meta information 'show: this'.

I hope you find this feature helpful and consider to merge it in.

[lex111]

You can simplified to this, what do you think?

list($name, $expectedKey, $expectedValue) = explode('.', $matches[2]);

[DjThossi]

I'm personally not the biggest fan of writing code like this because it reduces readability in my opinion.
I like the code more if it is written in a way that it is possible to read it like a book and not stacking up too many things into one line.
This is just personal taste. Anyways, I don't want to open a discussion on code style so I will just follow any advice.

[lex111]

Is not it necessary to check the existence of the key, like this?

array_key_exists($expectedKey, $page->meta())

[beryllium]

As master is on PHP 7.2 now, both of these approaches could probably be simplified using the null coalesce operator. As an example:

$actualValue = $page->meta()[$expectedKey] ?? null;
if ($actualValue === $expectedValue) {
    ....
}

However, I'd caution against accepting that code example verbatim - I'm only speaking on a syntactical level, I'm not currently sure if the value null is an appropriate default to use there.

[beryllium]

I'm not 100% sure what this would look like in the common use case. Could you provide a more detailed explanation of the goal and what the outputs/advantages would be?

I guess I'm not exactly sure what the advantage is here instead of the common usages of tags/categories. Or, to put it another way, I'm wondering if the taxonomies feature (used for tags and categories) could be leveraged to make this functionality more widely applicable.

[DjThossi]

Hey
I changed the code as recommended.

Here a bit more about the use case:
I had just one big travelblog where I have all my posts in chronological order.
The filtered function in Pagination helps me to generate additional pages where I now can combine all posts with a certain information like category or location. On top, this will not kill the chronological order of the post. Here an example for better understanding:
Here my general travel blog with all posts:

• Page: http://www.sebastianthoss.de/de/reiseblog/
• Source: https://github.com/DjThossi/sebastianthoss.de/blob/master/source/de/reiseblog/index.html

On top I build now sub overviews for my trip to OZ 2017

• Page: http://www.sebastianthoss.de/de/reiseblog/2017-asia-oz/
• Source: https://github.com/DjThossi/sebastianthoss.de/blob/master/source/de/reiseblog/2017-asia-oz/index.html

In the last source file, you can see now that I used the filtered option.

  provider: filtered.reiseblog.categories.2017-asia-oz

In all my blog posts regarding my trip to OZ you'll find this at the top:

categories:
  - de
  - Reiseblog
  - 2017-asia-oz

The function filtered() will now generate a list of entries which have a categories key with value 2017-asia-oz. Any other blog post will be ignored from list reiseblog will be ignored.

I hope now it is more clear what it's used for.

[peter279k]

I think using the short array syntax is better than array syntax 😄 :).

[peter279k]

How about using the short array syntax? I think this short array syntax is better than array 😄.

[peter279k]

It's the same problem and I mention in the previous comment.