smd_tags: unlimited article, image, file and link taxonomy

jakob · 2014-10-03 14:22:17

I have an smd_tags setup as a filter for just one section (called “projects”) and am using the word “filter” as a trigger in the url, so I have urls like this (just examples):

/projects/filter/kent, or
/projects/filter/kent+thatch, or
/projects/filter/yorkshire|kent|tile …

I use smd_tag_list to show the currently active filter(s) at the top of the filtered project list. That all works great thanks to your brilliant plugin (every version gets a bit better)!

I then set about looking for a way to remove individual filters from the selection and found a perhaps somewhat roundabout method by computing what the url would be for a given page without the tag and using that as the href of the “remove this tag from filter“ button, e.g. the “×”-button for the “Kent” tag in the third example above has the href /projects/filter/yorkshire|tile but in the second example it would be /projects/filter/thatch.

When there is only a single filter active (like in the first example), the computer url is then /projects/filter/. Intuitively (from a user-perspective), I’d expect this to be the same as /projects/ without any filter. Interestingly, however, on the /projects/filter/ page, smd_tag_list outputs ALL the available tags as active filters in a long list (I guess no filter is the same as all filters with the OR operator?).

I thought I could get around this by using smd_redirect to redirect ^/projects/filter/$ to /projects/ but it doesn’t take effect. Why? Is smd_tags getting in there first?

Any suggestions? I guess I could add a step to my url computation code, that checks for an empty filter and corrects the url accordingly to remove the filter/ part too. Or alternatively prevent smd_tag_list from being output when if_tag_list returns true (i.e. trigger is in url) but the tag_list is actually empty. Or do you have a better suggestion for dropping a tag from the current filter?

Bloke · 2014-10-03 15:38:12

jakob wrote #284491:

a perhaps somewhat roundabout method by computing what the url would be for a given page without the tag and using that as the href of the “remove this tag from filter“ button

Yes, this is something I’ve been meaning to address. A neat way of being able to add / remove a tag would be very helpful. I’ve tried AJAXy type things, manipulating the URL from Javascript, but the results have so far been unsatisfactory. I have toyed with the idea of special type of URL trigger for ‘add’ and ‘remove’ steps (maybe a minus sign to remove the tag and a caret to add, or something?), but haven’t had that Eureka moment yet. If you do hit upon a cool method (maybe an smd_macro?) that you think might be able to be pluginised, please let me know and I’ll build it in.

But to address your specific problem, yes the absence of any filter shows all available tags. The <txp:smd_tag_list> does just that: lists tags. My reasoning was that, without any input, it has to show you them all so you can start to filter by something, otherwise you’d see nothing and be scratching your head.

As you found, you can circumvent this to a degree by using the conditional <txp:smd_if_tag_list>. If you wrap your <txp:smd_tag_list> in that, it won’t trigger the content unless at least one filter is present in the URL. That could probably be made clearer in the docs, sorry. But it does mean you get no output at all to click. Any way you could detect this by setting a variable and then do a page refresh back to the base URL if the tag returned nothing?

Failing that, if you don’t mind me taking a peek, drop me some credentials and I’ll see if we can figure something out between us to satisfy your requirements.

I thought I could get around this by using smd_redirect to redirect ^/projects/filter/$ to /projects/ but it doesn’t take effect. Why? Is smd_tags getting in there first?

Precisely that, yes. I think smd_tags is pretty hungry and runs on pretext, which probably pips smd_redirect to the post. You could try lowering the load order of smd_redirect but I don’t think it’ll help much.

Hope that helps. Let me know if I can help at all with the filtering side of things, as it’s part of the plugin I really need to beef up so you don’t have to do so much manual skulduggery.

jakob · 2014-10-03 20:35:09

Thanks for the lightning response. For the moment, I’ve opted to simply make the delete link return to the section landing page if no filter remains. To me that seems most intuitive for the user. My ‘manual skullduggery’ (apt description) requires two mini snippets of txp and looks like this…

Somewhere at top of page template, this snippet:

<txp:php>
  global $variable;

  // get pieces of: /section/trigger-word/tag-name-or-combination

  $pieces = explode ( "/", $_SERVER[REDIRECT_URL] );

  // and store in txp variables for later use

  $variable['current_url_stub'] = "/" . $pieces[1] . "/" . $pieces[2] . "/";
  $variable['current_filter'] = $pieces[3];
</txp:php>

… and then later in the page template where the tag list shows this code (in a slightly less verbose form):

<txp:smd_if_tag_list>

  Filtered by: 
  <txp:smd_tag_list wraptag="ul" break="li" class="tag-list">

    <a href="<txp:php>
      global $variable, $smd_thistag, $pretext; 

      // subtract current tag name from the browser filter string stored previously

      $remainder = 
        str_replace( $smd_thistag['tag_name'], '', $variable['current_filter'] );

      // clean up remainder string: correct any mid-string instances of || or ++
      // and trim any stray | or + sign from beginning and end of string

      $remaining_filter = 
        trim( preg_replace( "/([\|\+])+/", "$1", $remainder ), "|+" );

      // if resulting tag filter is empty then return to section page
      // otherwise re-assemble complete link using url_stub stored previously

      echo ( $remaining_filter == '' ) ?
        '/' . $pretext['s'] . '/' : $variable['current_url_stub'] . $remaining_filter;

    </txp:php>" title="remove this filter">×</a>
    <a href="/<txp:section />/filter/<txp:smd_tag_name title="0" />">
      <txp:smd_tag_name title="1" />
    </a>

  </txp:smd_tag_list>

</txp:smd_if_tag_list>

It works well enough. I’ve just not trapped someone entering /projects/filter/ manually, but that’s no big deal.

The presence of the trigger-word “filter” in the url seems to be enough for txp:smd_if_tag_list to be true even if there are no tags, so the other method would involve outputting the tags into a variable and then testing if that is empty.

Bloke · 2014-10-03 23:04:19

jakob wrote #284499:

My ‘manual skullduggery’ requires two mini snippets of txp

Very clever. I’ve been tinkering with those ideas this evening, but not yet found a way to ‘monetize’ them into something generic for the plugin. The major stumbling block seems to be that once you’ve clicked one to add it to the filter, you no longer see the rest of the list from which to choose from because the act of adding it to the URL filters the smd_tag_list to only include the given tag.

My logical brain says there ought to be a way to “break out” of the URL-generated list in order to display a complete list at any time, unencumbered by the in-force tags. Then you could show a list of possible tags and use the add/remove technique to alter the URL and ‘do stuff’. I thought that was already possible, so perhaps there is a way and I’ve just been away from the plugin for too long to remember how to do it. Clearly you’ve managed to solve it in some way, so if you could see your way clear to reveal how you did that bit, I’ll be able to create something akin to your setup on my local dev installation and start to tinker with native mechanisms for adding/removing tags.

Does it rely on some specially crafted URL trigger? Presumably you’re solely triggering on filter? Or some cunning use of tag attributes / smd_related_tags?.

jakob · 2014-10-04 11:06:25

My logical brain says there ought to be a way to “break out” of the URL-generated list in order to display a complete list at any time, unencumbered by the in-force tags.

Yes, a kind of tag_list_custom and a tag_list. I’ve not (yet) dreamt up a good UI for adding tags to the current filter, so at the moment I just have three drop-downs for different filters, e.g. building_type, building_technique, building_location at the top of the page and there’s currently no way (via the UI) to choose combinations of tags. The basic setup for each drop-down is this:

<txp:smd_tag_list type="article" parent="building_type" offset="1" showall="1" wraptag="ul" break="li">
  <a href="/<txp:section />/filter/<txp:smd_tag_name title="0" />"><txp:smd_tag_name title="1" /></a>
</txp:smd_tag_list>

These are not wrapped in <txp:smd_if_tag_list> so the possibility to choose a tag filter is given on the normal section landing page. I guess it’s the showall attribute that’s making them show when the tag context is triggered (see note below).

Further down on the page, there is the code from the previous post which shows the in-force tags. That is wrapped in <txp:smd_if_tag_list> so it only shows if a filter is active.

… so perhaps there is a way and I’ve just been away from the plugin for too long to remember how to do it.

Me too. A few other things I noted, but haven’t investigated enough to say if they are a bug, or just a product of the way I’m using tags here:

In the above example, if you leave out the showall="1" I thought it would show at least the tags that have been assigned to articles but it doesn’t.
In the above example, I expected exclude="building_type" to prevent the parent tag from being listed, but it didn’t. Using offset="1" skips the first tag, which is the parent.
I got confused (more probably I confused myself) by the URL name / type / trigger settings and relating that to the ‘projects’ section, so eventually ended up setting the trigger word and baking my own links manually.
One more (unrelated) thing, while I’m at it: I’d love to be able to hide the tag panel in the write tab on a per-section basis using bot_write_tab_customize but currently the tag panel needs a wrapper and a way for bot_wtc to recognise it.

jakob · 2014-10-09 06:18:50

Is there a way of getting the total count of articles output by a smd_related_tags query? i.e. not just the number of articles assigned to a single tag, but the number of articles output when a tag combo is used. Or does smd_related_tags produce a variable with the query count that I can tap into?

I’m trying to get the total number of articles output for use with etc_pagination to work out the number of pages. I have it working fine for a single tag by storing smd_tag_count in a variable as part of “filtered by (tag-name)” notice (output using smd_tag_list) higher up the page. This I can then use to calculate the number of paged pages for etc_pagination.

I considered cumulatively adding the tag count for each of the tags using adi_calc or similar, but that won’t work in AND filter cases or in OR filter cases when an article is assigned to both tags.

etc · 2014-10-09 07:25:50

Just in case, you can count html nodes with etc_query. If each item of smd_related_tags output is wrapped in (say) <article> tag, this will count them (and store in <txp:variable name="count" /> if needed):

<txp:etc_query name="count"
	data="output of smd_related_tags"
	query="count(//article)" />

If you look for the number of pages (by 10) instead of the number of articles, replace query="count(//article)" with query="ceiling(count(//article) div 10)".

jakob · 2014-10-09 16:59:25

Thanks Oleg. If smd_tags doesn’t have something in-built, I’ll give that a go. I’ve still to fully investigate the wonders achievable with your plugin but I see the logic behind your idea.

While each item has an HTML node, I’m using the limit and offset attributes in smd_related_tags with the help of your etc_offset tag to effect article-custom-style pagination for smd_tags. Won’t that falsify the results? Or do I need to simply use the smd_related_tags, once to get the total number, and again for the paginated output? I guess that adds some query overhead…

etc · 2014-10-09 19:46:20

jakob wrote #284645:

While each item has an HTML node, I’m using the limit and offset attributes in smd_related_tags with the help of your etc_offset tag to effect article-custom-style pagination for smd_tags. Won’t that falsify the results?

They certainly will…

Or do I need to simply use the smd_related_tags, once to get the total number, and again for the paginated output? I guess that adds some query overhead…

True again. But, unless you look at the page source and adapt the appropriate db query (with smd_query or etc_query) to count articles, there seem to be no lightweight solution.

If the number of articles is reasonable, you could retrieve them all, count and then use limit and offset of etc_query to display a slice. This avoids the second query. But we’d better wait for Stef.

Bloke · 2014-10-09 20:31:43

jakob wrote #284618:

Is there a way of getting the total count of articles output by a smd_related_tags query?

There wasn’t, but try the latest bleeding edge version and let me know how you get on. If you add <txp:smd_tag_count /> after your call to <txp:smd_related_tags /> has completed, it’ll now return the total number of matches it found. It takes into account AND/OR tag sets in the URL.

It’s not exactly had much testing yet, but worked in the limited set of cases I threw at it. Please report back on its success or otherwise and we’ll go from there. I may be able to extend this to do gross counts of articles from other places (like smd_tag_lists) so if that’d be useful I can look into it.

jakob · 2014-10-09 21:50:21

I miss this place: it’s just great how you people keep coming up with good ideas so quickly!

Thanks, Oleg, for your ideas. That confirms what I thought.

Stef, it does exactly as you say (my emphasis):

If you add <txp:smd_tag_count /> after your call to <txp:smd_related_tags /> has completed, it’ll now return the total number of matches it found. It takes into account AND/OR tag sets in the URL.

But … it still doesn’t do quite what I want, as I have the offset and limit attributes set to achieve pagination with smd_related_tags.

<txp:smd_related_tags 
      type="article" 
      section="projects" 
      limit='<txp:variable name="pageby_projects" />' 
      offset='<txp:etc_offset pgcounter="page" pageby=''<txp:variable name="pageby_projects" />'' />' 
      break="" 
      form="projects_grid-item" />

where “pageby_projects” is just a variable I have set in adi_variables to make it easier to play with settings (apologies for the particularly convoluted example with tag in tag in tag). etc_offset does the nice calculations to output the right articles for each page. As such the tag only outputs a bunch of 9 articles (or whatever the variable is set to) or less.

What I’m trying to get is the total number of matches for tag filter, so that etc_pagination can work its magic correctly. The etc_pagination tags do that nicely for article_custom but not for smd_related_tags (as far as I am aware), so I do that with this snippet instead:

<txp:php>
   global $variable; 
   $variable['num_pages'] = ceil($variable['num_tagged_articles'] / $variable['pageby_projects']);
</txp:php>

where num_tagged_articles is just the tag count without formatting (i.e. <txp:smd_tag_count wrapcount="" class="" />).

BTW: Do you have a text pack for smd_tags somewhere? The bleeding edge version reverts to the placeholders.

Bloke · 2014-10-09 22:59:11

jakob wrote #284657:

What I’m trying to get is the total number of matches for tag filter, so that etc_pagination can work its magic correctly.

I haven’t used etc_pagination (shock, horror) so I don’t know its capabilities, nor what it needs as input. I figure it needs the usual three things to calculate how many pages to use:

The total number of results
The desired number of records per page
The current page (offset)

So if the result of searching for a couple of tags returned 30 articles from smd_related tags, plugging that value into etc_pagination’s “limit” and telling it you’d like 10 per page would allow it to figure out that it needs to display 3 pages of stuff. Right? Then it’s a case of getting at etc_pagination’s current page to shove into the offset/limit of smd_related_tags. [I’m modelling that behavior on my pagination patch which never saw the light of day (yet…) but looking at Oleg’s examples, his plugin seems to do things rather differently, so maybe I’m wrong here].

Either way, I think I see the problem. When you use the offset/limit attributes, the total that smd_related_tags spits out at the end is the total number of things matched, with those attributes in place. What you need (I think) is the total number that match without any limit/offset filtering. In other words, the total value should be static for every page load, for every given tag combo, irrespective of which page you’re currently viewing. Is that what you’re after?

Txp does such internal pagination using two queries. First with the criteria applied, but with no limits, the second time with limits. It uses the first for pagination totals and the second for actually displaying results. That’s pretty inefficient and given the heavy nature of smd_tags (even with aggressive cacheing), running the same query twice just for the sake of getting totals is something I’d rather avoid.

MySQL does have a nifty feature SQL_CALC_FOUND_ROWS. Simply adding that to the query and then calling SELECT FOUND_ROWS() immediately afterwards tells you how many rows are in your total result set, regardless of offset/limit. It’s far more efficient than calling the main query twice. Unfortunately (I believe) it’s non-standard SQL so if we move to PDO or something, that’ll not be an option. But I might look into SQL_CALC_FOUND_ROWS in the short term for the plugin, and worry about what the hell to do when we move to PDO on another day!

EDIT: of course, there’s a gotcha. The query returns multiple rows per tag and the PHP filters out duplicates, so maybe a pure MySQL solution isn’t possible unless I manage to rewrite the queries better.

BTW: Do you have a text pack for smd_tags somewhere? The bleeding edge version reverts to the placeholders.

Oh yeah, sorry. I took out the local gTxt() in this version. The top of the plugin template houses the Textpack. Just copy out the strings there and paste the block into the bottom of your Admin->Prefs->Languages panel to install them.

Last edited by Bloke (2014-10-09 23:13:09)

Textpattern CMS

Textpattern CMS support forum

#277 2014-10-03 14:22:17

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

#278 2014-10-03 15:38:12

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

jakob wrote #284491:

#279 2014-10-03 20:35:09

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

#280 2014-10-03 23:04:19

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

jakob wrote #284499:

#281 2014-10-04 11:06:25

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

#282 2014-10-09 06:18:50

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

#283 2014-10-09 07:25:50

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

#284 2014-10-09 16:59:25

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

#285 2014-10-09 19:46:20

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

jakob wrote #284645:

#286 2014-10-09 20:31:43

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

jakob wrote #284618:

#287 2014-10-09 21:50:21

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

#288 2014-10-09 22:59:11

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

jakob wrote #284657:

Board footer