smd_tags: unlimited article, image, file and link taxonomy

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

#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