Is there a way to use the API to retrieve only tags? I know that I could iterate over the retrieved list of posts, but that feels really inefficient, especially as my blog grows.
Thanks in advance.
Is there a way to use the API to retrieve only tags? I know that I could iterate over the retrieved list of posts, but that feels really inefficient, especially as my blog grows.
Thanks in advance.
Hey @ahribellah, thanks for bringing this up! We’ve actually started refactoring the tag system behind the scenes so that this will be possible in the future. We haven’t fully completed the transition, but I can let you know when we do!
Currently tracking development on this here: ⚓ T495 List all tags on a blog, and I’ve added your suggestion to make this all available via the API.
Okay, to be way more specific, the use case I had in mind for this is a bit different than you have already mentioned in that issue.
So, right now, you have plans to have a catalogue of tags on a specific page somewhere in the blog. My intended use case was to have some way to get a list of tags and add them as a list somewhere to every page.
I’ve gone ahead and implemented my use case, but I feel that it’s ridiculously overengineered.
Basically, I have a PHP script that calls into the API, authenticates me as a user, and gets my entire list of posts. It then sorts through every single one and ouputs the tags and how many times they occur before dumping the list (as a JSON) into a raw JSON file. Because it’s not ideal to have two API calls occurring every single time that someone loads a page on my blog, I have this set up as a cron job that runs once every 30 minutes. That means that the updated number and listing of tags won’t be there immediately after posting, but it will be “good enough.”
I then have another PHP script that returns the JSON file’s contents and has a header allowing for cross-origin requests.
Then, on my blog page, I have an async function that requests the PHP script that returns the JSON file’s contents, puts the contents into two arrays, sorts both arrays based on the number of occurrences, and then places them on the page in the order they’ve been sorted in.
The end result looks like this:
That’s quite a lot of work to do something so simple and it requires a secondary web server. For now, this works for me, but maybe something simpler could be introduced? It would be nice if there were, say, a hidden variable called something like tags
that has this data and could be accessed from the custom JavaScript entry form.
Ah, okay. So to be sure, you want to display:
Ah, okay. So to be sure, you want to display:
Yes, that is correct. The number of posts using each tag is actually less important for display purposes and more important for making a curated list of tags that is shown on every page based on how frequently those tags are used.
As I said, I’ve got it working for now, but it’s not an ideal solution due to it requiring knowledge of servers, PHP, cross-origin requests, etc., making it less accessible to other users.
Yep, makes sense. So I think we will address that with the development task linked above.
We’ll have a way to generate that page of tags, but we’ll also add an API endpoint that lets you retrieve all tags used on your blog, so you can pull that information into your blog. We’re actually already tracking number of posts using a tag in this new system. Then it’ll only take a call to the API to get all of this.
Don’t hold me to this verbatim, but it might return data like:
[
{
"tag": "cats",
"slug": "cats",
"title": "Cats",
"postCount": 13
},
...
]
Would something like that work?
Yeah, something like that would work great. As a note, though, the key thing that led me to handle this the way that I did is the fact that I couldn’t retrieve this data anonymously. If I could have done that, it could have all been done in the custom JavaScript form, but the fact that I had to authenticate means that I had to secure my authentication data elsewhere.