#dev 2025-12-13

2025-12-13 UTC
gRegor joined the channel
#
gRegor
!tell [Al_Abut] re photo posts, I think of it like this: they have a `photo` property, URL of the photo; and (usually) a `content` property, which is the caption. The prefix on the class names is just a directive in how it should be parsed. `p-content` means it's parsed as plaintext, which is common for a short photo caption. `e-content` means it's parsed as HTML. Latter can be handy if you use multiple lines of text or
#
Loqi
Ok, I'll tell them that when I see them next
#
gRegor
other formatting in your caption. Consumers, like Monocle, should work with either.
#
gRegor
I use e-content on mine because I publish multi-line captions, links, etc.
#
gRegor
Happy to talk more this weekend on it
#
[Al_Abut]
Yeah, definitely would appreciate a tutorial this weekend!
#
[Al_Abut]
I think we’re saying the same thing and you’re unpacking the details, yeah?
#
gRegor
Not quite. I read you as asking about the `summary` property vs `content` property, and multi-photos. `content` property isn't about whether there's multiple photos
#
[Al_Abut]
Actually, wait, no. It looks like you alternate between `p-content` and `e-content` but don’t use `p-summary` at all, is that right?
#
gRegor
You could also use a `summary` property around part of your caption, if you wanted consumers to have that option, though I don't know of any consumers currently that wouldn't prefer the `content` property.
#
gRegor
Here's a contrived example: photo, long caption, but I also made the first sentence the summary: https://php.microformats.io/?id=20251213004817526
#
[Al_Abut]
Ah, intesting.
#
[Al_Abut]
*interesting
#
[Al_Abut]
So I guess you *can* slur your words over Slack…
#
[Al_Abut]
I'm looking at this example on the photos page as a reference. It seems like I read that the p-content there is just a summary description and should be p-summary
#
gRegor
Ah, no. `summary` and `content` have different meanings. I kind of think of it like RSS feeds sometimes are just summaries of posts with a [read more] link, or a feed with the full posts.
#
gRegor
Heading off for now, will talk tomorrow!
#
[Al_Abut]
Bye!
troojg and jeremycherfas joined the channel
#
ulhar4409
When I get a micropub request with parameters like `mp-photo-alt` in the post parameters, where do those go in the MF2 json?
#
ulhar4409
Currently my endpoint treats mp-* args as "reserved" and logs them before silently discardimg them which is probably wrong
#
ulhar4409
Wordpress plugin seems to file those into `properties`, before "consuming" them? Hard to work out if these are supposed to stay or not after the post is made
#
GWG
Define consume, I don't think we do anything with that property in the plugin
#
ulhar4409
Chew and swallow, maybe? Digesting is optional
#
ulhar4409
This is less about mp-photo-alt than mp-* properties in general
#
ulhar4409
Basically, if I were to request the post's `source`, should those properties appear?
#
ulhar4409
(in the json response)
grufwub joined the channel
#
GWG
mp is meant to be a command, so it shouldn't
#
ulhar4409
ok, gotcha
#
GWG
I forget how we handled that in the WordPress plugin
#
ulhar4409
what about mp-slug? that one feels like a property with extra steps
#
ulhar4409
GWG: i think it just skips those when it's storing properties, from my reading
#
GWG
Slug is a defined extension
#
GWG
But it does skip things it doesn't understand
#
GWG
The implementation could use some refreshing
#
GWG
I have not touched it in a while
#
ulhar4409
~~presses f5~~
#
ulhar4409
does "defined extension" just mean you explicitly handle it?
#
GWG
Yes
#
ulhar4409
oh, i mean that your particular implementation supports it
#
GWG
Yes
Maxpm, [Sophia_wood], athenaeryma, Chataigne, ttybitnik, DanQ, Hiiiiiuu, llll, perryflynn, HI, aaronpk, Hey, oodani, proofreed, hiiiiiii, ggarcia24, [gRegorLove], lanodan, jack7087, gRegor, Welcome, thegreekgeek, hotcoffeeee, rrix, troojg, pizza-gregor, barnaby and chrisaldrich joined the channel