Textpattern Support Forum

saccade – I can’t think of a way to do what you want, in the current version of tru_tags. What you’d need is another attribute that said “don’t redirect if the results are empty”. I’ll add it to my list for the next release.

What’s the original goal of having the second call? Is it just to have sticky results filter to the top? That might be something else I could just add as a specific feature to tru_tags.

I’m pleased to announce the release of tru_tags v3.6, which fixes most of the outstanding issues that have been reported on the forum (excluding any major feature requests). Please see the releases page for details, but notable items include:

• Added tru_tags_search_result_excerpt to work around a problem with using TXP’s search_result_excerpt for tag search pages.
• Added a 404_redirect attribute to tru_tags_handler to allow disabling of the 404 redirect feature. This is necessary when calling tru_tags_handler twice, for example when showing sticky articles followed by non-sticky articles.
• Expanded the tag clouds on the Write page and Extensions page to include future-dated tags and tags from non-searchable sections.
• Significantly improved the performance of tru_tags_from_article on article list pages by removing an unnecessary database query.
• Worked around a few javascript/DOM issues in IE that broke styling of the tags on the Write tab.

Enjoy!

Last edited by truist (2009-11-21 22:46:35)

Whups! Links fixed.

Hello,

I have a strange problem.

Everytime when I switch the tru_tags plugin on, I get a high cpu load of my fastcgi processes. But I have less than 1 request/second. The most interesting for me is, that all the tags of tru_tag are cached that means in the main section I have something like that:

<txp:zem_cache id="tags_handler" timeout="86400">
<txp:if_section name="tag">
  <txp:tru_tags_handler />
</txp:if_section>
</txp:zem_cache>

and the cloud is generated by

<txp:zem_cache ctx="tags" timeout="86400">
<div id="tagwolke">
<h3>Topthemen</h3>
<txp:tru_tags_cloud listlimit="50" mintagcount="5" minpercent="90" maxpercent="200" countwrapchars="()"  showcounts="1" texttransform="capitalize" title="Favoriten" activeclass="tagwolke" generatelinks="1" usenofollow="1" section="artikel" />
</div>
</txp:zem_cache>

The article form has this inside:

<txp:zem_cache id="keywords" timeout="86400">
<txp:tru_tags_if_has_tags>
<p class="chlforbidden linie_unten">Damit verbundene Stichworte:<br /> 
<strong>
<txp:tru_tags_from_article texttransform="capitalize" generatelinks="1"/>
</strong>
</p>
</txp:tru_tags_if_has_tags>
</txp:zem_cache>

The strange thing is that everything works fine, with a maximum cpu load of 10% per php-cgi process , when tru_tags is switched off.

The server has a 2 core Opteron with 1,6 Ghz, Debian Lenny, PHP 5.2.6-1+lenny3, MySQL v5.0.51a-24+lenny2, Lighttpd 1.25 with XCache 1.2.2, Textpattern 4.2.0 and tried tru_tags 3.5 and 3.6. I also tried first different versions of Lighttpd, selfcompiled and standardpakets. For PHP I tried the standard php.ini`s and some own optimized. MySQL v5.0.51a-24+lenny2. The textpattern table has about 31MB and there are about 2100 articles with at least 3 keywords per article.

At first I supposed, that is has something to do, with clean urls, but switching between these options doesn´t change the behaviour.
I use clean-urls over the server.error-handler-404 directive from Lighttpd, see here

Has anyone else this problem? Where to look? Has anyone a hint? Maybe another plugin together with tru_tags causes this high load??

Last edited by whocarez (2010-01-21 16:11:34)

Thanks Markus for your hints.

I tried to reduce the attributes – no success.
Then I removed separately the tags in article form and the cloud – no success
I removed all tru_tag tags – no success.
Only and only switching of the plugin brought me a acceptable load.

Btw. I stressed the site with a curl (no cache) script – individual articles and the mainsite.
When I have tru_tags switched on, then a single page request from a partly cached side needs about 10s and the php-cgi process uses 1 core! If I switch tru_tags off, then ceteris paribus a single page request needs only 1s at max!

Hm, I´m stucked :-(