It seems that collection do not separate posts from pages or from other type of documents.
They have a docs array containing all elements in the collection.
I can easily select docs with the layout “page” with where filter: site.docs | where: “layout”,“page”
But I want to get all documents except the ones of type post, something like:
site.docs | where: “layout”, not “page”
or
site.docs| where: “layout”, “!=page”
But there does not seem to be a not operator and the string is not interpreted as an expresión like in SQL statements.
How may I filter out elements that match a criteria from an array collection?
I cannot find that filter, where_exp, in Jekyll documented filters nor liquid official documentation.
Good to know about it. Where may I find mor acurate liquid documentation?
I was misundertanding the organization of collections.
I had thought that the Jekyll diferentiates between document types, site.posts or site.pages.
But it seems that they are simply two separate base collections of documents: site.pages and site.posts and you can create more collections (Prologue theme creates a collections named sections).
It is strange for me that in the sites.posts collection seems to be listed in site.collections too, but site.pages does not.
I was traying to get the list of pages by categories.
But it seems that site.categories is only for posts, only uses the posts collection.
I have found a way to circunvent it here in Jekyll talk.
But you need to filter the docs and cycle several times through the entire docs collection.
It would be great to have a site.collection.xxx.categories for each collection.
posts are considered collections, so they show up in both site.posts and site.documents. Pages are different.
Jekyll was initially built around posts and pages - with 2 totally different purposes. Then collections were added which are a lot like posts except the tags and categories and they act a little different.
You can still sort of access categories on a collection or page by using custom front matter - don’t use the word category or tags or the plurals of those, I use Type, and then I can sort stuff by type how ever I want. I do this with pages primarily, but same would work on collections. But since both pages and collections don’t seem to exist in the same array you can’t easily access both.
Yes you can tag pages and any document with categories or any other custom property.
But Jekyll does not provide functionality.
Site.categories are just for posts, permalink based in categories too, as long as i could test.
I could implement categories with pages using custom filtering, but posts have it for granted.
I don’t like blog sites that much. My site would have a blog for news, but it will be mainly organized content about geotechnics.
It seems Jekyll, and other systems, are too much blog centric and give posts a stellar function they should not have.
They should be document centric, with collections of documents with basic functionality like categories and tags, title, creation date and user properties.
You should be able to derive specialized docs declaring a properties template and default layout.
Pages and posts should be just examples of specialized docs, that differ mainly in their layout, being posts publishing day centric.
So there should be two basic collections, posts and pages in the collection array, exposed as site.posts and site.pages for easy access.
Categories should be implement as site.posts.categories, pages.categories and in general docs.categories. Same with tags.
many would agree I am sure, and if someone set out to create it now I would guess that would be how it would be done. There are a lot of people using it on GH and making it work that way would probably break a lot of sites. Not to mention it is free, so not sure the resources are there, as it is I feel lucky to get the updates we do - like the recent 4.x version which sped stuff up quite a bit.
All that said Jekyll is flexible and can handle non blog use cases no problem IMHO, none of my sites are blogs, most do not use posts at all. Using/filtering by custom front matter is pretty easy.
Well yes, you have to give backguard compatibility.
But there is a site.posts collection than now is already under site.collections.posts already.
It won’t be so bad to have a site.collections.pages too.
You could provide a config switch to deactivate the generation listing of pages collection under site.collections to get backward compatibility in case you need it (a theme that uses collections but does not expect to have a pages collection in ther too).
You can conserve site.pages the same there is a site.posts and so themes would be happy any way.
Adding a property categories under the docs collection won’t harm any theme that is using current functionality, but would simplify things to any body using collections and categories.
So pages would have its category collection too, and any doc collection.
I am in the task of learning how to generate category collections for the collections I am building.
Not all that difficult when you know how to do it.
Liquid is not an evident language for people that comes like me from procedural languages and object orienting programming.