smd_tags: unlimited article, image, file and link taxonomy

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?

Bloke · 2024-02-28 18:38:31

Not until I sit down and comb the plugin, sorry. Just fixing something in com_connect tonight. If I get a chance I’ll see if I can get my head round what you’re doing and try to suss it the plugin can be bent to do what you want.

etc · 2024-02-28 20:14:21

jakob wrote #336795:

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.

Sorry, I need to delve a bit more into smd_tags to say something clever, but here is how context attribute currently works. Say, we set <txp:page_url context="c, tag" />. From this point, any URL generated by txp core will inherit the category parameter (if any) stored in $pretext['c'] and the value of tag passed via $_GET/$_POST arrays. So, this would work if the links created/used by smd_tags were of the form site_url/tag-section/?tag=tag-name. But I guess they are not, and core has no idea how to handle site_url/tag-section/tag-name URL (this is done by the plugin).

The URL chunks are stored as $pretext[1] etc, so we probably could try to preserve them in <txp:page_url />-generated links via context="1,...", but it looks tricky to avoid clashes with standard txp URL schemes. We could also make <txp:pages /> just append page numbers to the current URL, but it feels a bit restrictive. Brilliant ideas welcome.

jakob · 2024-03-01 10:43:30

etc wrote #336799:

Sorry, I need to delve a bit more into smd_tags to say something clever, but here is how context attribute currently works. Say, we set <txp:page_url context="c, tag" />. From this point, any URL generated by txp core will inherit the category parameter (if any) stored in $pretext['c'] and the value of tag passed via $_GET/$_POST arrays. So, this would work if the links created/used by smd_tags were of the form site_url/tag-section/?tag=tag-name. But I guess they are not, and core has no idea how to handle site_url/tag-section/tag-name URL (this is done by the plugin).

Yes, I think that is how it works: with clean urls, the plugin detects tag-name from the incoming url, hence it’s not in the $_GET/$_POST arrays.

The URL chunks are stored as $pretext[1] etc, so we probably could try to preserve them in <txp:page_url />-generated links via context="1,...", but it looks tricky to avoid clashes with standard txp URL schemes. We could also make <txp:pages /> just append page numbers to the current URL, but it feels a bit restrictive. Brilliant ideas welcome.

The idea of altering the url yield value according to $pretext[1], $pretext[2], $pretext[3] sounds good to me. I remember now using them for custom url patterns. Could one end up with something like this (or some other similar notation) to alter the context for a specific if_condition?

<txp:if_section name="tag">
    <txp:page_url context="s, [2]">
</txp:if_section>

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

<txp:if_section name="tag">
    </txp:page_url>
</txp:if_section>

assuming the total attribute is made tolerant of empty values so that this would work with a regular page when no total is specified (see above). The notation could alternatively be <txp:page_url context="[1],[2]"> …

Or another variant – if txp:pages were to get a new form attribute – could be:

<txp:if_section name="tag">
    <txp:page_url context="s, [2]">
        <txp:pages pg showalways="2" link="" total='<txp:variable name="num_pages" />' evaluate="5,2,8,4,6" form="pagination" />
    </txp:page_url>
<txp:else />
    <txp:pages pg showalways="2" link="" evaluate="5,2,8,4,6" form="pagination" />
</txp:if_section>

Might that be plausible / feasible?

etc · 2024-03-14 12:40:38

jakob wrote #336793:

Two problems and one suggestion

The pagination is not output if the total attribute is specified but empty … 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.

That’s easy to do, but what if total is populated from some tag that counts pages and this tag returns 0 (e.g. no search match)? Should we output the whole navbar in this case?

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?

Actually, form could be global (in the single-tag mode). I’ve tried and it seems to work. Any drawbacks to this?

Bloke · 2024-03-14 12:46:32

etc wrote #336903:

form could be global (in the single-tag mode). I’ve tried and it seems to work. Any drawbacks to this?

Sounds good to me. So if someone uses a form attribute and a container, perhaps inadvertently, what happens? I can’t remember if we assume a standard precedence order here. Like, if you go to the trouble of putting contained content in, then does that beat the form? Because it’s more specific.

I’m fine with whatever makes most sense.

etc · 2024-03-14 13:02:59

AFAIK, there is no standard precedence, each tag handles content/form like it needs (sometimes inconsistently).

Dunno what is the most useful precedence in the case when both are defined:

if set (and not empty?), the content always beats the form,
or the form beats the content, but the latter plays the role of default when the form does not exist?

Bloke · 2024-03-14 13:04:46

etc wrote #336908:

the form beats the content, but the latter plays the role of default when the form does not exist?

Ooh, that has merit.

Edit: Or, presumably if the form returned ‘empty’ then the contained content could be used?

That would make for some interesting constructs when a form could use conditional output but you don’t have to specify the default ‘else’ condition in the form itself.

Example:

<txp:variable name="user" form="fetch_user" trim>
Nobody in particular.
</txp:variable>

Form fetch_user:

<if::logged_in>
   Get username somehow
<txp:else />
   Find user's first and last name from cookie.
</if::logged_in>

Last edited by Bloke (2024-03-14 13:23:15)

etc · 2024-03-14 13:21:36

Bloke wrote #336909:

Or, presumably if the form returned ‘empty’ then the contained content could be used?

This looks tricky to do (globally) without some code refactoring. If a tag does not has its own form attribute, we’d need to process the tag first, and then the global form outside the tag, but the context could be different. It’s more straightforward to replace $thing with form content and pass it to the tag.

Bloke · 2024-03-14 13:24:57

Ah yeah. Oki doke, that’s fine. Whatever is most logical and simplest that also adds power works for me.

Textpattern CMS

Textpattern CMS support forum

#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

#517 2024-02-28 18:38:31

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

#518 2024-02-28 20:14:21

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

jakob wrote #336795:

#519 2024-03-01 10:43:30

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

etc wrote #336799:

#520 2024-03-14 12:40:38

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

jakob wrote #336793:

#521 2024-03-14 12:46:32

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

etc wrote #336903:

#522 2024-03-14 13:02:59

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

#523 2024-03-14 13:04:46

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

etc wrote #336908:

#524 2024-03-14 13:21:36

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

Bloke wrote #336909:

#525 2024-03-14 13:24:57

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

Board footer