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.

spiridon · 2025-01-06 19:40:11

Hi, guys!

Does anyone know why the import processes only 1388 articles and then the browser crashes? I’m getting Failed to load resource: net::ERR_INSUFFICIENT_RESOURCES after 1388 records.
This happens in Chrome only.
Firefox processes all 2076 articles.

And the next question…
Why does the import transform different keys міфологія and мифология into one with the name MIFOLOGIYA?
The same happened with keys етимологія and этимология (they were transformed into one with the name ETIMOLOGIYA).

How can I fix that?

Bloke · 2025-01-07 00:37:06

The first one is probably my stupid implementation of how it processes tags. I seem to recall it sends back a JSON blob for each one so it can update the counter or notify the database or… something. It’s been a while. The upshot is that the page gets heavier and heavier as the JavaScript returns more and more records so I guess at some point, Chrome just gives up. Or, perhaps there’s something in that 1388th record that it chokes on. Which leads maybe to your second question…

That is strange it can’t differentiate between two independent tags. My guess is that when it tries to automatically “dumb down” the tag title to store it as a unique name with only ASCII chars, it happens to throw away too much, so both tags resolve to the same key name.

It may also be the collation in use, which is causing the plugin to misinterpret the string.

I’m not sure how to improve that. Perhaps relax the ASCII-isation? I’m sure tags with Cyrillic characters in their name will operate just fine so there may not be any need to alter the tag any more.

I’ll have a look and see. Testing with non-English languages and character sets is not something I’ve done much.

spiridon · 2025-01-07 12:03:38

Yeah, the first issue looks like architectural oversight. But it works in Firefox, so it’s not a blocker.

Regarding the second one… smd_tag_getsert() calls sanitizeForUrl() which transforms non-latin symbols into Latin. Looks like the same one substitute used for the different symbols. Unfortunately, there was a case when different words from different languages that differed by 1-2 letters were translated into the same word.

I can replace the transformation function with my. But… Will there be any problems in using it?

I tried to create a tag with the Ukrainian name, but it was still converted to the Latin name in capital letters. So, do I need to replace all calls to sanitizeForUrl() with my own so it works correctly?

There are no problems with the Cyrillic alphabet in the URL as with Unicode. Example

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

#526 2025-01-06 19:40:11

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

#527 2025-01-07 00:37:06

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

#528 2025-01-07 12:03:38

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

Board footer