smd_tags: unlimited article, image, file and link taxonomy

Bloke · 2009-01-26 15:11:18

woof wrote:

I would expect this to output “London, Paris” but no, its blank. However if I go back and ensure it is also tagged with the parent “locations” …it works perfick.

Balls, it’s probably a bug; it’s supposed to work as you describe. If I find a simple fix, I’ll post it here so you can carry on working until I get a chance to release the next version.

In the meantime I’ll add it the list of things to check I’ve squashed next week. Thanks for the report.

jakob · 2009-02-08 11:05:29

Hi Stef, I’ve been experimenting with smd_tags and am too having problems with the client side tags on article list pages, or maybe I am missing something fundamental, which is quite possible. The install and admin-side stuff works just fine (cool with auto-complete), as does outputting the list of tags that are assigned to an article – the “filed under:” in an article form.

The link="1" generates messy links correctly according to the settings in the prefs, but these are not recognised on the article list page, only clean url’s such as /section/article/tag-name or /section/article for all tags (for the moment I made it form clean links manually). Note that just /section/tag-name seems to work too, and this seems to interfere with txp’s normal url-scheme as I can’t get any individual article pages to show. This latter might be part of the problems mentioned earlier. I’ve tried all manner of manual messy entry, e.g. ?tag=mytag&tag_type=article etc. but with no response.

What I am trying to achieve is a list of projects that can be filtered by tag in the same way as one uses categories, e.g.

No tag: /section/ = Section heading – list of all projects – list of all available tags to choose from in that section
With tag: /section/tag-name = Section heading with tag name and count – list of projects with that tag – list of all available tags to choose from in that section.

This is my code to do that:


<!-- heading -->
<h2>
  <txp:section title="1" />
  <txp:smd_tag_list limit="1" wraptag="" break=""> &rsaquo; <txp:smd_tag_name title="1" /> : <txp:smd_tag_count wrapcount=""/>Projekte</txp:smd_tag_list>
</h2>


<txp:smd_if_tag_list>  <!-- when tag is set -->

<!-- project list -->
   <ul id="projekt_list">
    <txp:smd_related_tags section="projekte" wraptag="" break="">
        <li><txp:permlink><txp:title /></txp:permlink></li></txp:smd_related_tags>
   </ul>

<!-- tag list -->
  <h4>Tag list</h4>
  <txp:smd_tag_list>
    <a href="/projekte/<txp:smd_tag_name />"><txp:smd_tag_name title="1" /></a><txp:smd_tag_count />
  </txp:smd_tag_list>

<txp:else />  <!-- when NO tag -->

<txp:article form="projekt_profil" listform="projekt_liste" />   

</txp:smd_if_tag_list>

My questions:

Does the tag section have to be a separate section? If I set it to the same section as my articles, I can no longer call up the individual articles as mentioned above. Presumably it’s looking for a tag with the name of the article_url_title and returning none. Ideally, I’d like to use tags in separate sections (e.g. for projects and for publications) where a common tag-handling page would not be appropriate.
In the heading I want to show the currently active tag (e.g. like one would use <txp:category title="1" /> for the active category). <txp:smd_tag_name title="1" /> doesn’t return anything unless it is within <smd_tag_list>. Using limit="1" works okay, except when all the tags are showing using /section/article as it (correctly) only returns the first one.
How does <smd_if_tag_list> work? I seem to be able to use the various smd_tag functions whether or not it is there.
Am I right in my use of <txp:smd_related_tags>? It seems to me, that this is the tag-sensitive equivalent to txp:article and produces correct output too when a tag is selected. If so, the name of the tag feels misleading to me. Perhaps something like smd_tagged_items or smd_tag_filter?
In the tag list at the bottom I want to see a list of all the tags to choose from (e.g. where one would normally use txp:category_list or txp:article_custom to ignore the context) but I see only the one currently active in the url. Only when I use the url /section/article do I receive them all as one would expect, but the project list is then also not filtered. I guess this is the as-yet-incomplete smd_tag_cloud function?

Maybe I have some fundamental thinking mistake in there or am using the tags incorrectly? If so, I’d be most grateful if you could point me in the right direction.

Finally, I’m working with v4.08 on an otherwise naked test setup (no other plugins installed).

Bloke · 2009-02-08 20:42:55

jakob wrote:

I’ve been experimenting with smd_tags and am too having problems with the client side tags on article list pages

They are a bit broken, I admit. And I don’t know why because I swear it was working when I released it… (around mid-4.0.7 release cycle). I must be going mad because it was working for me then, but you’re right, now it definitely is not :-(

The link="1" generates messy links correctly according to the settings in the prefs, but these are not recognised on the article list page

Bug. Was working, not any more for reasons of a mystical nature. johnstephens also had the same issue. Clean URLs will be fixed now I understand them a little better. I’ve no idea why messy URLs are being ignored. It’s supposed to work, which is the very reason for the existence of those last three plugin preferences. *shrug* All I can do is apologise that this heinous error slipped through my usually dolphin-friendly testing net.

No tag: /section/ = Section heading – list of all projects – list of all available tags to choose from in that section <snip>

Your code is (almost) sound. Using smd_if_tag_list in your nominated tag section — or any section, if you use the section / section_link attributes of smd_tag_name / smd_tag_list to force tags to appear on a different page — is supposed to allow you to differentiate between regular articles and tags.

Again, I tried this and had it working on a test site but a gremlin crept in before release and must have broken it. The reason for me saying ‘almost’… see Q4 below.

1) Does the tag section have to be a separate section?

No. The one in prefs is the default. You can override this with section / section_link attributes and use smd_if_tag_list to differentiate… in theory. But beware: in the same way that TXP cannot render a category list in clean URL mode if viewing a section, you cannot use clean URL mode for tags either. For example, TXP cannot successfully differentiate between these:

site.com/articles/my-great-article
site.com/articles/my-tag-type/my-tag

In both cases, TXP will look for an article (called my-tag-type in case #2). But you can (ahem, should) be able to do this:

site.com/my-tag-type/my-tag
site.com/articles?smd_tag_type=my-tag-type&smd_tag=my-tag
site.com/tag-section/my-tag-type/my-tag
site.com/tag-section?smd_tag_type=my-tag-type&smd_tag=my-tag

The first two would require <txp:smd_if_tag_list> wrappers.

2) <txp:smd_tag_name title="1" /> doesn’t return anything unless it is within <smd_tag_list>.

Correct, it is context sensitive. The context is derived from the current smd_tag_list parameters but it should be derived from the URL parameters, if present. Again, this has me baffled because the whole point of the complicated context assignment code in the plugin is for preciesely this scenario. Leave it with me.

3) How does <smd_if_tag_list> work?

It’s only real purpose is if you wish to render lists of tags via the URL params, on a page that is not the default one set up in the plugin prefs. At all other times it is redundant, though there is no harm including it as a wrapper.

4) Am I right in my use of <txp:smd_related_tags>?

Yes and no. It too is context sensitive. Your usage here is correct (the caveat being that the URL scheme is broken) but it can go beyond this, which is why it is called related tags. It is more like txp:related_articles but for tags and all content types.

The default is to find related stuff based on the “current” tag, i.e. based on the current context: it could be the one in the URL, or one from the current article in an article list, or maybe the current file in a file_download_list. It will return a list of all things of the given type that have the same tag. The type defaults to the current context as well, so if you are viewing articles it goes and looks for other articles; if viewing links it finds other links with the same tag, and so on.

But you can change that so you can look for other stuff. e.g. :

other files that share the same tag as the current article
other articles that share a tag with the current file
other articles that have a tag name the same as the current article’s category1
other links that have a category that matches the current article tag
…

So it goes way beyond txp:article, txp:article_custom and even txp:related_articles and was the primary reason for the plugin’s inception in the first place. I wanted to be able to show people, say, a file download and offer other downloads that might be similar. Or other articles that contained content that was similar to the file they were viewing. Categories alone were too restrictive.

Imagine a record label web site: if someone landed on a “downloads” page that listed all your artists and they clicked a particular track to preview, you could offer links to other articles about that artist (perhaps they contain tour dates / album promos / desktop graphics / etc) or show links to other sites (e.g. their myspace page or somewhere you can see videos). And all this can be controlled automatically by a tag mechanism that can interact with other database fields such as category, description, custom fields, and so on.

It is the lifeblood of the plugin (if only it was reliable). But perhaps smd_tag_filter would be a better name, not sure. Suggestions on a postcard to the usual address!

5) In the tag list at the bottom I want to see a list of all the tags to choose from

Yeah, because all tag tags(!) are context sensitive you will always only see the ones that relate to the current context. You can override this in my dev version so you can “break out” of the context if you wish. On a non-default tag page you should be able to simulate this by using an smd_tag_list outside the <txp:smd_if_tag_list> container because the context is ‘forgotten’ outside the list:

<txp:smd_if_tag_list>
  <txp:smd_tag_list>
    <txp:smd_tag_name /> [<txp:smd_tag_count />]
    // Do some other stuff in the context of the current URL tag
  </txp:smd_tag_list>
</txp:smd_if_tag_list>

// List all other article tags availabe
<txp:smd_tag_list type="article">
  <txp:smd_tag_name link="1" /> [<txp:smd_tag_count />]
</txp:smd_tag_list>

Does that make sense?

I guess this is the as-yet-incomplete smd_tag_cloud function?

Kind of. That would be a way out, but I’m thinking of combining the tag_cloud into the tag_list because a tag cloud is really a specialised tag_list with various weighting algorithms applied. I’ve not really devled into this yet because I want to get the core functionality working properly first. If it complicates the tag_list too much then I’ll offer a separate tag, probably for convenience (it may well use the same logic of smd_tag_list but I’ll package it up to look like two distinct tags).

I’m working with v4.08

Apologies for the TXP warnings then. Plenty of them, since the new columns appeared in the textpattern table *sigh*

In a very big nutshell, the plugin is FUCT and needs some lovin’ to restore it to a time when I actually had it working sweetly and also with the new stuff I want to bring to the table. That’ll take a bit of time, but I should be able to get to it sometime towards the back-end of this week and begin to re-ravel the pieces.

Sorry it’s not living up to your expectations. Will try harder next time…

Last edited by Bloke (2009-02-08 20:43:32)

Hennie · 2009-03-03 21:18:05

Is there someone who has succesfully implemented smd_tags with images? I can make additional tags (hoera!), but how can I display them by tag?

Bloke · 2009-03-06 08:58:44

Hennie wrote:

Is there someone who has succesfully implemented smd_tags with images?

Sorry for the delay in replying. I don’t know of anyone who has implemented image tagging yet. The tags themselves will work, as you have found, but you need to use smd_tag_list to show them. Unfortunately, TXP has no concept of “this” current image (like with articles it ‘knows’ which article is being displayed, and ‘knows’ which link/file from a list is being displayed). So to actually show the tags associated with an image is tricky without the (now out-dated) image patch I mentioned in the first post.

Have you tried using upm_image? That can understand the concept of image iteration and might just work. I don’t know, as I’ve never tried it, but it might be worth a shot. If it works (or doesn’t) please let us know here.

I must also apologise — again — to all the people waiting for this plugin to be fixed. I’ve been inexplicably waylaid by other projects and plugins needed for more pressing sites. Things are moving waaay slower than I’d like :-(

Hennie · 2009-03-06 09:22:45

Bloke wrote:
I must also apologise — again — to all the people waiting for this plugin to be fixed.

Dear Stef,

Thanks for your reply, and I don’t think YOU have to apologise for ANYTHING.

H.

jpdupont · 2009-03-06 10:59:14

Stef or TXP team,

very difficult to add the “this” current image concept in the next txp build/release ?

Hennie · 2009-03-06 16:04:24

I’m very sorry, its too complicated for me. TXP is beautiful and I can use some plug-ins when they are well documented, but I’m afraid I’ll have to stick with basic-TXP.

Thanks anyway :-)

maniqui · 2009-03-06 16:48:50

Hi Bloke, hi Hennie

I would bet that a combination of smd_gallery, smd_if, txp:variable, smd_tags (I’ve never tried this one) and maybe a plugin that gets variables from the URL (like adi_gps) would be enough, and wouldn’t be that hard.
Ok, I’m just guessing. Of course, some experimentation is needed to confirm or deny that it’s possible.

@Bloke, one question:

could smd_gallery (or even upm_image, as you suggested above) access to the “smd_tags” of ‘this’ image?
I mean, smd_gallery can be “aware” of many values (id, alt, caption, etc) for ‘this’ image…
Couldn’t it be “aware” of the tags (the smd_tags) it has assigned?

Bloke · 2009-03-07 17:11:00

All

I would love for the ‘this’ image context to appear in the next version of the core but it seems there’s not enough interest to warrant it :-( Only about 2 people have even tried the patch and I’ve had no feedback so I assume it was a flop; I guess people prefer using upm_image or smd_gallery to get at the caption etc and being able to iterate over pictures.

I’d be very happy to see the demise of <txp:image_index /> and <txp:image_display /> in favour of a more “TXPish” native solution that allowed a list of images to be output — like <txp:linklist /> or <txp:file_download_list /> do — such that you could then display parts of that image (caption, alt, width, etc) with one or two dedicated image tags inside a form/container.

That’s what my patch does. The only thing it doesn’t do is extend that capability to article_images just yet. It’s easy to do, but it’s possibly a non-backwards compatible change (depending on how it’s implemented) so I left it out of this patch for now, perhaps to be addressed in a later patch. Once that is addressed, everything you can do in upm_image becomes native, but via a smaller tag set.

could smd_gallery (or even upm_image, as you suggested above) access to the “smd_tags” of ‘this’ image?

Yes, in theory. Thinking about it again in the cold light of day, it’s not very practical for a plugin author to do so because it’s quite involved to get the tags out of the smd_tags plugin (the tags are in a series of extra database tables; it would slow TXP down to have to keep querying the tags on each image. Plus it would be reliant on me keeping the table structure unchanged as the plugin is developed). I suppose I could add an API of sorts, whereby other plugins could query the tags of the current ‘thing’, but it still suffers the slowdown and would become superfluous if the ‘true’ image iterator from my patch (or similar) is adopted in the core one day.

Hennie

Sorry it’s too awkward for you to use. Perhaps if I had it firing on all cylinders it would be more useful. If I get anywhere with this image issue I’ll give you a nod so you can perhaps try it again one day.

Last edited by Bloke (2009-03-07 17:12:09)

MattD · 2009-03-15 22:49:09

I hate to say that I haven’t read through this entire thread but I’ve looked through the plugin documentation and wonder if this is possible or can be made possible.

Can you output a tag list in the following format?

<a href="{link}" style="{count}" >{name}</a>

This would allow something asked for by jshan

Bloke · 2009-03-15 23:20:11

MattD wrote:

Can you output a tag list in the following format? <a href="{link}" style="{count}" >{name}</a>

In theory, yes using the container/form:

<txp:smd_tag_list>
   <a href="/smd_tags/article/<txp:smd_tag_name />" style="<txp:smd_tag_count />"><txp:smd_tag_name /></a>
</txp:smd_tag_list>

I say in theory because the URL rewriting that allows the URL to work that way is brain dead in the current version and doesn’t take your permlink mode into account :-( Some day in the hopefully not too distant future I’ll have a chance to fix this along with a load of other stupidities that I’ve spotted while testing this.

It also depends where you want your link to go — if you want to show a specific article then I’m not sure off the top of my head because I don’t populate that info at present. The next version may well do that if I can be sure exactly which type of tag you are displaying (and you are in an individual article context of course)

Last edited by Bloke (2009-03-15 23:21:34)

Textpattern CMS

Textpattern CMS support forum

#37 2009-01-26 15:11:18

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

#38 2009-02-08 11:05:29

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

#39 2009-02-08 20:42:55

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

#40 2009-03-03 21:18:05

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

#41 2009-03-06 08:58:44

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

#42 2009-03-06 09:22:45

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

#43 2009-03-06 10:59:14

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

#44 2009-03-06 16:04:24

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

#45 2009-03-06 16:48:50

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

#46 2009-03-07 17:11:00

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

#47 2009-03-15 22:49:09

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

#48 2009-03-15 23:20:11

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

Board footer