Stable: Query for Category/Tag List

Discussion for an extension that allows a Micropub endpoint to return a list of categories that it has already used in the past. There is also an idea of being able to search for categories for an auto-complete.
(See https://indieweb.org/Micropub-extensions#Query_for_Category.2FTag_List)

@dshanske

Currently @dshanske and @swentel have implemented this in Wordpress, Drupal and Indigenous for Android. I have also implemented this in my personal website software, Abode.

@dshanske and @swentel I'm not sure of the exact values that you all return, but I suggest that it returns the following:

The following example would be returned as part of the ?q=category query.

{
  "categories": [
    "tag1",
    "tag2",
    "tag3",
    "tag4",
    "tag5",
  ]
}

The follow example would be returned as part of the ?q=category&search=indie query.

{
  "categories": [
    "indieweb",
    "indieweb-goals",
    "indienews"
  ]
}

The reason is because when you look at
#1 and #4 they both return a JSON object with a descriptive attribute (items or post-types) followed by an array of whatever is requested.

To me this translates to a JSON object with a categories attribute and an array of strings. Is this what your software currently supports and if not, do you see any issues with transitioning to this format or do you have any strong reasons for a different format?

@grantcodes

Both wordpress and Drupal return an array. There's no property 'categories' or anything else in both implementations.

Regarding post-types: it's returned in the q=config request which can contain other elements as well.
As for 'items' in #4 , that's also because there's a 'paging' property needed too.

There's two things I can think of that probably hold me back for changing it at the moment.

We need to coordinate to push 4 releases at the same time: wordpress, drupal and indigenous Android/IOs. I know a few people using the Android version using Wordpress or Drupal. Not sure how many have custom implementations. Maybe @grantcodes does for instance ?
It makes sense to me to have a root property, or even multiple, in case we start supporting multiple vocabularies. Drupal for instance supports creating multiple vocabularies on the fly e.g. 'Main theme', 'Free tags', 'Sub Theme' etc. Returning those in this request could be useful, but probably on a UI level to have separate inputs, because micropub requests are still limited to an array of categories with a name, so on the server level you have to make the distinction (e.g. in Drupal, a category has a primary id, the name is not the main identifier since you can have multiple vocabularies, that's also why in the Drupal micropub configuration you need to select the vocabulary first). A uid/id would make more sense so multiple vocabularies can be more easily recognized on a micropub request. But that would break the spec and/or several existing server implementations then no ? So, unless I miss something, it feels redundant to me to have the array nested.

Now, of course, this is still experimental, so if everyone is up for setting a date to push releases, that's totally fine for me. We can always broadcast this somewhere - maybe we should have a page on indieweb where we can announce these kind of things and push it onto the newsletter. Some sort of 'new or upcoming releases for software' (even including security releases), that actually sounds like a good idea :)

(also now that I'm writing this, the title 'Query for Supported Vocabulary' https://indieweb.org/Micropub-extensions#Query_for_Supported_Vocabulary is confusing to me, but that's my Drupal background of course. Something like 'Query for support post types' would make more sense there, at least imo)

I am fine with coordinated releases

@aaronpk

That makes sense. Definitely a coordinated release can be tricky but since it’s experimental, hopefully it wouldn’t be too disruptive. I know when the “Support Vocabulary” or “Post Types” was discussed, @aaronpk made a point to have it embedded within a JSON attribute. He might be able to shed some more light on why that was and it might help explain if it is important here as well

And also (after a night of sleep), your proposal allows to easily extend in the future without being disruptive then. Paging comes to mind. So yes, we should probably go for it :)

Changed in dev branches of Drupal and Indigenous.

Amend category to wrap in descriptive key to match other properties see

Fixes (#178)

Pushing a stable version that uses the new category markup and adds search

oh, I won't be able to release before next weekend or so

released yesterday!

This will be live in Micro.blog later this week as well (q=category and setting categories on new posts via Micropub). Thanks everyone for the early brainstorming and consensus on how this should work!

Wow that’s awesome!!

Querying for tags is stable, however this remains open for discussion of the query modifier search.

Discussion today in the Micropub Popup session: switch to using a filter parameter that is consistent across many Micropub queries. See #34.

Closed in favor of #34

Navigation Menu

Repository navigation

Stable: Query for Category/Tag List #5

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Stable: Query for Category/Tag List #5

Description

Activity

EdwardHinkle commented on Nov 16, 2018

swentel commented on Nov 16, 2018

dshanske commented on Nov 16, 2018

EdwardHinkle commented on Nov 16, 2018

swentel commented on Nov 17, 2018

swentel commented on Nov 17, 2018

dshanske commented on Nov 17, 2018

swentel commented on Nov 18, 2018

swentel commented on Nov 26, 2018

manton commented on Jan 29, 2019

EdwardHinkle commented on Jan 29, 2019

dshanske commented on Jun 27, 2020

manton commented on Jul 25, 2020

dshanske commented on Jul 25, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions