Some notes from my experience, not necessarily saying this is the best way to do it:

I have the concept of "pages" on my site as well. They are stored the same as every other post, except that they have an additional property which is a slug that begins with a slash. e.g. this post https://aaronparecki.com/life-stack/ has a slug value of /life-stack.

Technically I can create these pages via Micropub right now, by setting that slug value in the Micropub request. In practice I don't do it that often because I don't make new pages very often. I also haven't attempted any sort of query interface for these.

Thanks @aaronpk. I'd be fine with using slug for this. It feels a little hacky, but it also kind of makes sense if we consider that the slash indicates there won't be a date in the URL.

Like I said, I'm not necessarily saying this is the best option, but it worked for me and was easier than adding a new "type" of post in my system.

So in Koype, I've done this by using a custom type for content. Like instead of sending a h-entry, I send a h-x-page to my site. It informs it that a few things about it might be different (only expected properties are name, content, summary, etc) and allows for the slug to be adjusted to work against my root URI versus being prefixed with post. I chose this approach because it allowed me to move anything too "extra" about it into a separate place. This also required a change / addition to my q=source to have a type parameter, so I can use it to query against one's h- type (only have entry and x-page for now but I consider adding contact and event in the future).

Editing it would be similar to editing a post using Micropub. The entire body is stored in content too so it's usable with the other Micropub actions.

@jalcine That's interesting. I hadn't considered h=page. Makes sense to me, although I wonder if it causes any problems to have a type that isn't defined by Microformats.

Thinking more about this, the biggest problem with "/" is querying for pages. As was mentioned in chat, you could have q=source accept an option to only match posts with a certain slug prefix, but it would often be faked because the "/" is not necessarily included in the actual slug as stored in a database. So you'd have a backend system with logic like "if the parameter starts with a slash, do something completely different".

I'm fine with it if that's the consensus. But it seems more like an implementation detail than a full feature of Micropub.

Thinking more about this, the biggest problem with “/“ is querying for pages. As was mentioned in chat, you could have q=source accept an option to only match posts with a certain slug prefix, but it would often be faked because the “/“ is not necessarily included in the actual slug as stored in a database. So you’d have a backend system with logic like “if the parameter starts with a slash, do something completely different”.

I’m fine with it if that’s the consensus. But it seems more like an implementation detail than a full feature of Micropub.

Yeah, this seems like it’d end up being an implementation detail. I’m deeply in favor though of the h=type approach because it’ll be also easier to do a full list dump against post types (and page types). I know for certain that I’ll be implementing that into my site and my client.

(Originally published at: https://v2.jacky.wtf/post/d0bd7253-f656-4bf3-9a89-47d99f7c0a30)

@jalcine That's interesting. I hadn't considered h=page. Makes sense to me, although I wonder if it causes any problems to have a type that isn't defined by Microformats.

Regarding this, I explicitly leaned on using h-x-page; I recalled somewhere on the Microformats wiki mentioning this as a way to use vendor-specific or experimental things (like h-app)

I'm starting to implement this in Micro.blog, following @jalcine's example. I plan to support creating pages with h=x-page and also querying just page types, e.g. ?q=source&post-type=x-page from #4.

I'd love to work toward dropping the x-, though.

I'm planning on supporting pages with @aaronpk's idea of slug starting with a slash. This makes it compatible with tons of Micropub clients there already.

As I mentioned above, I still haven't seen any answer to how to query a list of standalone pages using this slug technique. That is 1/2 of the problem.

I've already implemented the x-page solution in Micro.blog, for both creating and querying pages. I'm not against changing it if something better comes along, though.

I should have added… @kisik21, that's a good point about compatibility with existing Micropub clients. It makes me wonder if there could be a hybrid solution: full page support uses x-page (or later, just page) but the "/" slug prefix is like a shortcut for creating a page that some servers support.

IMHO, the x is ugly and I don't think we should do custom formats. The h-entry without a published date seems like a perfectly fine solution and I personally don't see any problems with it.

Disclaimer: I didn't exactly read the whole thread thoroughly, so I might have missed something important.

I agree the x- is ugly. I would love for it to be simply h=page, but I think it would need to be an accepted part of Microformats first, not an experiment. It's still not clear to me how either the slug or blank published solves the problem of querying for a list of standalone pages, unless a client downloads all pages and then filters them itself to show certain types.

Maybe we could make a separate command like mp-as that could specify the post type like "page"? Then it would get placed into a separate index, wouldn't be as ugly with the x, wouldn't invent a custom Microformat and will be backwards-compatible with everything.

Also, I've seemingly forgot that most Micropub endpoints add a "published" automatically, like mine does.

The use of x is recommended by the spec, IIRC. It’s safer than introducing a property that endpoints might attempt to parse. IIRC (and I need to check this), if you don’t recognize the mp- (Micropub specific) or x- (Microformats specific) property, you’re supposed to completely ignore it. I use this for x-generator which I tag into my posts after they’re saved so I can highlight what tool I used to generate my posts.

I’d want to opt for something that doesn’t require too many changes in a micropub endpoint and leans more on markup than anything too blackbox-y.

(Originally published at: https://v2.jacky.wtf/post/b55c178c-47ec-4b92-bb58-ff63d5e275c8)

@jalcine Oh, TIL about the fact that x- is an official prefix for experimental Microformats properties

Just an update: Micro.blog supports x-page for creating and querying posts, e.g. h=x-page and ?q=source&post-type=x-page. As far as I can tell, this is the only solution that has been proposed that solves both sides of the problem (creating and querying). I'd be happy to consider other solutions if they support the same functionality. This would be great to discuss at the Micro.blog pop-up!

After a quick discussion in https://v2.jacky.wtf/post/789e96e8-2791-40c4-8370-fff06ab10369, I’m going to drop the use of h-x- since it’s a deprecated approach to using experimental properties and pages are a proven feature of blogs.

(Originally published at: https://v2.jacky.wtf/post/d59e66a8-2f08-4f25-a7f4-c976cccc2b19)

I started this section on the wiki to document how pages are different from posts: https://indieweb.org/page#Differences_from_Posts It'd be great to collect more examples of how pages are published there!

One of the other primary distinguishing factors of pages is that they don't appear in feeds alongside other posts.

In my case, I have a flat list of pages at the root of my website. @chrisaldrich described a hierarchy of pages, where some can be contained in other pages.

The other approach we could take here is having the client ask the server for the posts contained within a collection, where "normal" posts are in the "default" collection, but pages are in the "page" collection. (Internally you may store these in different database tables, a "type" column in a database, or in different folders on disk.) A benefit of this approach is that it would also handle @grantcodes' example he mentioned of treating "journal" entries as entirely different things as well.

I like this idea of storing them in a collection that’s usable for the editor to look up. I can do this internally to give a list for editing (it might not show anything to anyone who’s logged out on my site since that’s irrelevant for them tbh).

(Originally published at: https://v2.jacky.wtf/post/6181ed74-b87d-4912-a751-5a47548f1777)

If collections aren't a predefined list, so you could have arbitrary collections like "journal", wouldn't that start overlapping with what categories are used for? It seems like collections would exist kind of in the middle of post types and categories.

I'd still like to see us explore whether h-page is a good solution, specifically whether it causes any problems on the Microformats side.

Whether you call them collections or categories doesn't really matter. (Also not every website even has the concept of categories.) If you already have some idea of categories, just imagine making a new category to collect the pages in. Your site would treat that category specially and not show a list of pages in that category.

What WordPress calls categories, I call "channels" on my site. That's the top-level feeds like /likes or /replies, but it's not strictly segmented by type. I kind of like the idea of making a channel to collect my pages into.

So I don't see this as being something in addition to categories really. It's custom server-side logic whether to show a particularly named category as a feed.

As for exploring h-page, the next thing to do there is continue to collect examples of pages so that we can look for commonalities and differences between pages and posts.

https://microformats.org/wiki/process

There's a start to this collection on the IndieWeb wiki already:

https://indieweb.org/page

There was a lot of good discussion here. Thanks everyone. With the momentum behind #40, I'm going to close this issue so it doesn't add any confusion for newcomers. If anyone has concerns or isn't convinced by #40, feel free to keep the discussion going or re-open.