Repository navigation
Standalone pages #25
Description
It is common on blogs to have both timestamped blog posts (articles, notes, and photos) as well as standalone pages that are included in the navigation. These pages are not tied to a specific date and are usually stored separately from blog posts. For example, "About", "Contact Me", or "Resume" pages.
WordPress and Micro.blog both have this concept. Timestamped blog posts are called "Posts", and standalone pages are called "Pages".
I'd like to be able to query for these pages from Micropub, create new ones, edit, and delete them.
Micropub proposals #1 and #4 have a "post type" based on Post Type Discovery. There is no "page" post type that I'm aware of (and there would be no way to discovery the type based on its content).
Possible solutions:
- Formalize a "page" post type. There would need to be a new parameter for passing this when creating a post. Everything else in Micropub remains basically the same.
- Split off "pages" into their own set of API calls, such as
q=pagesfor querying a list of pages.
Prior art: WordPress has long supported pages in their XML-RPC API. I've also recently added support in Micro.blog's flavor of XML-RPC, which I've documented here. WordPress has further consolidated to use a post_type of "page" instead of separate API calls for pages.
Activity
aaronpk commentedon May 6, 2020
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
slugvalue of/life-stack.Technically I can create these pages via Micropub right now, by setting that
slugvalue 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.manton commentedon May 6, 2020
Thanks @aaronpk. I'd be fine with using
slugfor 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.aaronpk commentedon May 6, 2020
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.
jalcine commentedon May 6, 2020
So in Koype, I've done this by using a custom type for content. Like instead of sending a
h-entry, I send ah-x-pageto my site. It informs it that a few things about it might be different (only expected properties arename,content,summary, etc) and allows for the slug to be adjusted to work against my root URI versus being prefixed withpost. 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 myq=sourceto have atypeparameter, so I can use it to query against one'sh-type (only haveentryandx-pagefor now but I consider addingcontactandeventin the future).Editing it would be similar to editing a post using Micropub. The entire body is stored in
contenttoo so it's usable with the other Micropub actions.[tantek] added "Micro.blog page feature thoughts: indieweb/micropub-e…
manton commentedon May 6, 2020
@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.manton commentedon May 7, 2020
Thinking more about this, the biggest problem with "/" is querying for pages. As was mentioned in chat, you could have
q=sourceaccept 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.
jalcine commentedon May 24, 2020
Yeah, this seems like it’d end up being an implementation detail. I’m deeply in favor though of the
h=typeapproach 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 commentedon Jun 27, 2020
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)manton commentedon Jul 2, 2020
I'm starting to implement this in Micro.blog, following @jalcine's example. I plan to support creating pages with
h=x-pageand also querying just page types, e.g.?q=source&post-type=x-pagefrom #4.I'd love to work toward dropping the
x-, though.vikanezrimaya commentedon Jul 12, 2020
I'm planning on supporting pages with @aaronpk's idea of
slugstarting with a slash. This makes it compatible with tons of Micropub clients there already.manton commentedon Jul 12, 2020
As I mentioned above, I still haven't seen any answer to how to query a list of standalone pages using this
slugtechnique. That is 1/2 of the problem.I've already implemented the
x-pagesolution in Micro.blog, for both creating and querying pages. I'm not against changing it if something better comes along, though.manton commentedon Jul 12, 2020
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, justpage) but the "/"slugprefix is like a shortcut for creating a page that some servers support.vikanezrimaya commentedon Jul 12, 2020
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.
manton commentedon Jul 12, 2020
I agree the
x-is ugly. I would love for it to be simplyh=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 theslugor blankpublishedsolves 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.vikanezrimaya commentedon Jul 13, 2020
Maybe we could make a separate command like
mp-asthat 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.vikanezrimaya commentedon Jul 13, 2020
Also, I've seemingly forgot that most Micropub endpoints add a "published" automatically, like mine does.
jalcine commentedon Jul 13, 2020
The use of
xis 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 themp-(Micropub specific) orx-(Microformats specific) property, you’re supposed to completely ignore it. I use this forx-generatorwhich 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)
vikanezrimaya commentedon Jul 13, 2020
@jalcine Oh, TIL about the fact that
x-is an official prefix for experimental Microformats propertiesmanton commentedon Jul 15, 2020
Just an update: Micro.blog supports
x-pagefor creating and querying posts, e.g.h=x-pageand?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!jalcine commentedon Jul 25, 2020
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)
aaronpk commentedon Jul 26, 2020
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!
aaronpk commentedon Jul 26, 2020
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.
jalcine commentedon Jul 26, 2020
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)
manton commentedon Jul 26, 2020
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-pageis a good solution, specifically whether it causes any problems on the Microformats side.aaronpk commentedon Jul 26, 2020
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
/likesor/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.
aaronpk commentedon Jul 26, 2020
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
manton commentedon Jul 28, 2020
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.