smd_tags: unlimited article, image, file and link taxonomy

jakob · 2024-01-30 17:34:33

Wow. I’m not sure I can answer all those questions but I see where you’re coming from. If the new custom_field setup is similar and not stored in the textpattern table, a corresponding lookup would be necessary there too.

Yes, it would be simplest if $thisarticle (and the other data types) could be populated with relevant article data. Then an (smd_)if_article_tag tag could do the same as if_article_category on a per article basis. I’m guessing your JOIN-based solution would be quicker than the query per article article I’ve been using now.

I am working with the dev version, so I’d be willing to trial it.

etc · 2024-01-31 10:29:56

Bloke wrote #336519:

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.

I’m not sure to follow here. If you need to add/filter data to txp list queries, _format_info() does not seem to fit. These functions are db-agnostic and populate $thisitem from their array argument, typically coming from a db query. If you need to extend this array, a callback should be fired on some safe_query() level, like we did with criteria on the admin side. Or am I speaking nonsense?

Bloke · 2024-01-31 10:34:06

etc wrote #336527:

If you need to extend this array, a callback should be fired on some safe_query() level, like we did with criteria on the admin side.

That would save a query, yes. Maybe it is better there. But as this is public side code I wasn’t sure where the best place to inject a query for joins is, and then have the result of the plugin’s changes somehow added to the globals.

Thoughts welcome.

etc · 2024-01-31 10:45:48

filterAtts(), maybe, though it is used only for articles. It returns query clauses that could be altered by plugins. Looks tricky, but feasible perhaps.

Bloke · 2024-01-31 10:54:16

That might work. Tough to cleanly add query parts to it and, as you say, no good for the other content types. Hmmmm.

Any other ways you can think of to get data from the plugin onto the page efficiently so public tags can query it without invoking a tonne of extra queries per article?

etc · 2024-01-31 11:25:35

Probably parseList() function, to avoid callbacks duplication? It could fire a callback, passing its $object by reference to plugins before parsing it. It’s only used for lists, but in individual items context there are many other callbacks to employ.

jakob · 2024-02-28 14:58:26

Still keen on a way to bring an article’s tags into $thisarticle as there are multiple uses for this, but in the meantime I’ve reduced server load by first getting all the relevant article ids that match the tag in question, and then checking if the respective article is one of them:

<txp:variable name="matchtag">mytagname</txp:variable>
<txp:php>
    global $variable;
    // get tag id of tag name
    $matchtag_id = safe_field("id", 'smd_tags', "name = '" . $variable['matchtag'] . "'");
    // get list of article_ids with matching tag_id
    $rs = safe_column("item_id", 'smd_tags_used', "tag_id = $matchtag_id");
    if ($rs) {
        $variable['is_' . $variable['matchtag']] = implode(",", $rs);
    }
</txp:php>

That gives you an is_mytag variable populated with a comma-separated list of the matching article ids. You can then check against that in your article list form, for example:

<article<txp:if_article_id id='<txp:variable name="is_mytagname" />'> data-label="featured"</txp:if_article_id>>
    …
</article>

replacing mytagname with your actual desired tag name.

—

Will one of the existing smd_tags get me a comma-separated list of articles ids matching a specified tag? The main smd_related_tags tag takes the current page as its basis, but here I just need one specific tag. (I know the admin side does a similar thing to make the search links for the tag counts on the manage-tags pane).

jakob · 2024-02-28 17:03:22

A second question:
I’ve been trying to add pagination to smd_related_tags. I’ve done this before a long time ago using etc_pagination but this time I wanted to use the core txp:pages tag. I’m almost there and think I’m just missing a couple of small details.

Part 1: Using limit and offset to produce smd_related_tags output paged results

<!-- set the number of articles per page --> 
<txp:variable name="pageby" value="12" />
<!-- calculate the article offset -->
<txp:variable name="offset"><txp:evaluate query='<txp:variable name="pageby" />*(<txp:page_url type="pg" default="1" escape="integer" />-1)' /></txp:variable>

<!-- output articles matching the current tag using calculated limit and offset -->
<txp:smd_related_tags section="my_section_name" type="article" form="article_list_item" 
         limit='<txp:variable name="pageby" />' offset='<txp:variable name="offset" />'
         wraptag="" break="" />

Part 2: Getting the total number of pages for use with txp:pages

This follows on directly after the smd_related tags tag (it has to come after the main tag) and gets the total number of matched articles and number of pages needed for the pagination:

<!-- store total number of matches -->
<txp:variable name="matches"><txp:smd_tag_count wrapcount="" /></txp:variable>

<!-- calculate total number of pages (must be after smd_related_tags tag) -->
<txp:variable name="num_pages"><txp:evaluate query='ceiling(<txp:variable name="matches" /> div <txp:variable name="pageby" />)' /></txp:variable>

You can then use <txp:variable name="num_pages" /> for the total attribute of txp:pages:

<txp:pages pg showalways="2" link="" total='<txp:variable name="num_pages" />' evaluate="5,2,8,4,6">
    …
</txp:pages>

Two problems and one suggestion

The pagination is not output if the total attribute is specified but empty
Passing a value from a variable set higher up the page into the total attribute works great when it contains a numeric value – I get the correct number of pagination links – but if it that variable is empty or non-existent, no pagination is output.
This means you can’t use the same code snippet for both tagged and regular article lists. You can get around it by having two code blocks and switching between them accordingly using if_section or if_variable. If the pager function could ignore an empty total attribute, that would be great. I tried resetting an empty $attr['total'] to null at the top of that function in the core and got good results.
The pagination link in <txp:yield item="url" /> lacks the entire url path. It only contains the site_url/tag-section/ part but not the tag-name that follows it. The resulting links are then incorrect.
Is there any way to either retain the full existing url or to specify a custom url stub for populating the url yield item. I had some success by searching and replacing the url yield string –
<txp:yield item="url" /> with <txp:yield item="url" trim="tag/" replace='tag/<txp:variable name="tag_name" />' /> – but it is anything but DRY.
Connected to both the above, could txp:pages have a form attribute, so that the contained code block, which is often quite large, can be organized elsewhere in the theme?

Bloke · 2024-02-28 17:40:03

This plugin should, by rights, set the core pagination accordingly. But that may trample on any article pagination so I’m not really sure how to handle both in a sane way.

Regarding the loss of the tag in the URL, does the context attribute help? Do we even have a context attribute for txp:yield? I can’t remember and I’m just scurrying out so can’t check at the mo.

If there’s anything we can do in core to facilitate plugins hooking into pagination, now is the time to strike since Oleg has tamed the pager tag a little recently. And I agree a form attribute would be most excellent. That should be easy to add.

jakob · 2024-02-28 18:25:14

Thanks. Yes, I’ve been reading around and saw Kjeld and Oleg’s discussion here with page_url used as a wrapper to provide context. What would I use here?

I’ve tried tag, tags, smd_tags, tag_name… but neither tags nor that part of the url feature in $pretext so I’m not sure how to help it recognize the respective tag context.

This post with Oleg and Patrick was also enlightening and uses the same principle for limit, offset and page number as I have used above but more elegantly with txp:evaluate query="…" instead of txp:php snippets. I’ve cleaned up my code above accordingly. That doesn’t have an affect on the output of txp:pages, though.

Bloke · 2024-02-28 18:27:19

Hmmm, maybe context only works with $pretext then. I thought it was more general purpose than that for custom URL params. Sorry if I’ve steered you wrong there.

jakob · 2024-02-28 18:32:23

No hurry, but any pointers on the post before that?

Textpattern CMS

Textpattern CMS support forum

#505 2024-01-30 17:34:33

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

#506 2024-01-31 10:29:56

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

Bloke wrote #336519:

#507 2024-01-31 10:34:06

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

etc wrote #336527:

#508 2024-01-31 10:45:48

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

#509 2024-01-31 10:54:16

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

#510 2024-01-31 11:25:35

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

#511 2024-02-28 14:58:26

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

#512 2024-02-28 17:03:22

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

#513 2024-02-28 17:40:03

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

#514 2024-02-28 18:25:14

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

#515 2024-02-28 18:27:19

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

#516 2024-02-28 18:32:23

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

Board footer