smd_tags: unlimited article, image, file and link taxonomy

Bloke · 2021-07-19 12:14:11

Nice one, thanks. Been on my list for a while to fix that. Using jquery seems neater.

jayrope · 2022-03-24 14:23:23

I’d like to import files and their tags into a completely new TXP install.
What’s the best way to do this?

Can i simply copy files and database tables smd_tags, smd_tags_cats and smd_tags_used and txp_file into the new site and that’s it?

Bloke · 2022-03-24 14:26:58

Never tried it but yes in theory. As long as the file IDs exactly match up – that’s what’s used to link the content to the tags in the database tables.

jayrope · 2022-03-29 18:32:18

Bloke wrote #332991:

Never tried it but yes in theory. As long as the file IDs exactly match up – that’s what’s used to link the content to the tags in the database tables.

Worked!

jayrope · 2022-03-29 18:37:46

I am tagging files – only files – and wonder:
How could i restrict the user to only be able to use max 10 of a much longer list of tags?

And a more complicated issue.
The file i am tagging are audio files. These are being random played. That’s easy for the whole pool, however my brain is blocked in seeing, how exactly i could select files of just one tag (or up to three) for random play.

Could somebody give me a roadmap? Although i use smd_tags every once in a while it has remained a mistery to me, how exactly it works. Could be aging. Thank you in advance!

Bloke · 2022-03-29 19:36:50

The second one is simpler to solve. Assuming you have a tag pool (<smd::tag_list>) set up in a section of your site, when you click on it you’ll get a URL of, say, example.com/tags/death-metal. So what you need to do on that page is detect if a tag is ‘in use’ (i.e. in the URL, compared to there being no tag, whereby you’ll display the entire linked tag list).

What you could do is show files that match the current tag (as displayed in the URL) and just use limit="3" sort="rand()" to pick 3 random files that have that tag.

<smd::if_tag_list>
   <smd::related_tags type="file" limit="3" sort="rand()">
      // Display stuff from your file
   </smd::related_tags>
</smd::if_tag_list>

The smd_related_tags defaults to matching tag_name, so it’ll find files that match the tag in the URL as you click one from your tag list.

Limiting tag selection is not something I’d considered so it’s not built in. At the moment you’d perhaps have to add some JS to the page to count the ones selected and hide the tag pool if a nominated limit had been reached. Alternatively, add a field text prompt to the tag pool to say that only the first N tags will be counted, and then only display 10 whenever you list them.

The label used in the plugin unfortunately predates the inline help text concept in core. When I next tweak the plugin a little, I’ll add that ability.

jayrope · 2022-03-29 20:25:51

Thank you, Bloke. You’re invaluable. I go from there.

(Where is your music?)

Bloke · 2022-03-29 20:30:39

I haven’t got any of my stuff up currently. I mainly produced/engineered stuff for other people anyway.

I’ve got an empty domain ready for it, but whether I make time to populate it with content and music remains to be seen!

jakob · 2024-01-19 13:14:26

Is there an efficient way of checking if an article has a specific tag in an article_list situation, kind of the equivalent of if_article_category but for tags?

I couldn’t fathom if one of the existing tags can do specifically that, so I tried outputting a comma-separated smd_tag_list for each article and then checked against matches against a specific string using txp:evaluate. It works* but is extremely expensive in terms of queries, slowing down the page significantly.

As the tags are stored in a separate table, they are not part of the $thisarticle array like categories are. To reduce queries, I considered perhaps doing this differently in two parts with some php: first get and store the list of article ID#s with the tag in question, then compare the article id of each article against the list. But I thought I’d ask here first if there’s a better/easier way.

*I got some erratic behaviour here: On a regular article list, it worked: I got matches only on the articles with the tag in question. But when viewing a list of articles filtered by tag (i.e. on a /tag/tag-name page), I got more matches than I expected. I output the tag-list for each article in full, and it seems to spit out the entire list of tags sometimes, and then not others.

jakob · 2024-01-19 13:21:15

A second query/note (unrelated to the one above):

I’m using the ancient autocompletex script (found via GitHub) and a textarea to enter tags. Sometimes Textpattern doesn’t save the tag. It seems to happen when a tag has special characters in its title, e.g. Erzählung or café with the tag name erzaehlung or cafe). I changed the title to read Erzaehlung and saving works again.

jakob · 2024-01-30 15:15:30

jakob wrote #336424:

Is there an efficient way of checking if an article has a specific tag in an article_list situation, kind of the equivalent of if_article_category but for tags?

May I gently bump this?

Bloke · 2024-01-30 16:00:57

jakob wrote #336424:

Is there an efficient way of checking if an article has a specific tag in an article_list situation

Hmm, that’s not something I’d considered, primarily because there’s no sane way to inject plugin data into the globals.

But what if there was?

Would a callback in article_format_info, image_format_info, link_format_info, and file_download_format_info be useful, do you think? Well, aside from the fact that article_format_info() and link_format_info() aren’t used by core anywhere, so I’m not sure how useful the callbacks would be.

But if we could retrofit those calls into the data preparation flow in some capacity, it would mean that plugins could camp on the output and add their own data to the $this*arrays. And it may be beneficial when we move to having custom fields exposed in all data types too, so we might as well think about it now as it’s not exactly an onerous change (I don’t think).

Of course, it may mean extra queries if linked table data is fetched, but plugins should check the internal cache before firing a query off anyway.

In the case of this plugin, there could be a pref “pre-load tag data” or something, which would hook into the callbacks and add an ['smd_tags'] entry to the $this array globals. Perhaps <smd::if_tag> could check there too. Not sure.

If so, that seems like it would solve your problem, at the expense of one extra query join per article/data type. Which is probably way less expensive than pulling out an entire tree and comparing it against a tag in each article in the list.

Does that sound feasible or is there a better way? And would something like that be generally useful do you think for other plugins? Or is it going to litter the Txp garden with rakes to stand on?

Textpattern CMS

Textpattern CMS support forum

#493 2021-07-19 12:14:11

Re: smd_tags: unlimited article, image, file and link taxonomy

#494 2022-03-24 14:23:23

Re: smd_tags: unlimited article, image, file and link taxonomy

#495 2022-03-24 14:26:58

Re: smd_tags: unlimited article, image, file and link taxonomy

#496 2022-03-29 18:32:18

Re: smd_tags: unlimited article, image, file and link taxonomy

Bloke wrote #332991:

#497 2022-03-29 18:37:46

Re: smd_tags: unlimited article, image, file and link taxonomy

#498 2022-03-29 19:36:50

Re: smd_tags: unlimited article, image, file and link taxonomy

#499 2022-03-29 20:25:51

Re: smd_tags: unlimited article, image, file and link taxonomy

#500 2022-03-29 20:30:39

Re: smd_tags: unlimited article, image, file and link taxonomy

#501 2024-01-19 13:14:26

Re: smd_tags: unlimited article, image, file and link taxonomy

#502 2024-01-19 13:21:15

Re: smd_tags: unlimited article, image, file and link taxonomy

#503 2024-01-30 15:15:30

Re: smd_tags: unlimited article, image, file and link taxonomy

jakob wrote #336424:

#504 2024-01-30 16:00:57

Re: smd_tags: unlimited article, image, file and link taxonomy

jakob wrote #336424:

Board footer