Forums / General / Glosarry Extension Problem: Unwanted Recursive Issue

Glosarry Extension Problem: Unwanted Recursive Issue

Next topic

Author	Message
Alex Jones	Wednesday 23 July 2003 1:56:04 pm I've installed the glossary module and really like it, but I am experiencing an odd occurrence. When it sends the text to the page it will on occasion apply itself to the text it generated. An example of the output is below - note, I have set it up to print acronym tags instead of anchors. I have substituted [ and ] for the open and close brackets used by HTML to ensure the forum doesn't eat the code. For several years we have been selling the Gentleman's [acronym title="A style of sheath [acronym title="A tool with a blade and a handle. The blade will have at least one sharp edge. The first blade could have been of bone or stone, the first handle may have been a piece of hide used to protect the hand from sharp edges of chipped or broken stone."]knife[/acronym]. Used for hunting, camping and skinning."]Hunter[/acronym] What it should be: For several years we have been selling the Gentleman's [acronym title="A style of sheath knife. Used for hunting, camping and skinning."]Hunter[/acronym] But, apparently the operator saw that we also have the word 'knife' in our glossary, so it defined it within the acronym title for 'hunter'. This is causing some major display issues for us. How can I ensure that the operator does not recursively define words within the definitions it is displaying? I hope this makes sense. :) Alex Alex [ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ] <i>When in doubt, clear the cache.</i>
Paul Borgermans	Thursday 24 July 2003 4:13:01 am Alex, I think you need to add the acronym tag to the exception list on line 253 in ezglossaryoperator.php: $res = stripTags( $operatorValue, array( "link", "a", "object", "acronym" ) ); Didn't test it however. If this does not work, I'll work on it after august 4th (holidays now). -paul eZ Publish, eZ Find, Solr expert consulting and training http://twitter.com/paulborgermans
Alex Jones	Thursday 24 July 2003 6:49:18 am Thanks for the quick reply Paul! I'm afraid this didn't work, as I continue to get the same result. I also tried reverting back to an anchor tag which renders the same problem. Here is some additional information for you when you return in August. :) My glossary is set up with sub-folders (Zero through A, B, C, D through F etc.) within which all of the definitions are stored. Here is the code that builds the link or the acronym from ezglossaryoperator.php (note one of the two lines is always commented out): $replace[] = "<a href=\"/ez/index.php/agr/content/view/full/" . $item["NodeID"] . "\" title=\"" . strip_tags($item["Desc"]) . "\">" . $name . "</a>"; $replace[] = "<acronym title=\"" . strip_tags($item["Desc"]) . "\">" . $name . "</acronym>"; Here is the line within the template that calls the glossary and outputs the description: {$content_version.data_map.description.content.output.output_text\|glossary(true,472, "replace")} Thanks for your help! Alex Alex [ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ] <i>When in doubt, clear the cache.</i>
Hans Melis	Monday 04 August 2003 12:10:07 am Hi Alex, Paul notified me of this issue. Finding the problem went rather fast. The problem occured in the preg_replace functions. $search and $replace are arrays, so the function processes the entries one by one. When it has replaced one "match", it uses that temporary string to search for the other entries in $search. That explains the issue you described: a match of a glossary word inside a previous replacement would cause a recursive replacement, and thereby breaking the functionality. I fixed it by using a negative lookahead assertion in the regular expression for $search entries. The original code only looked for words. The new code looks for words, and if there's a match, it looks ahead in the string and searches for: "></tag> * means any amount of characters, and "tag" means the closing tag of whatever tag you use. In your case, it would automatically look for </acronym>. If it finds such a pattern after the glossary word, there's no match. I tested it with your examples, and it worked. The original tests I used for this operator also still work. You can get the new operator here: http://www.ez.no/developer/ez_publish_3/contributions/updated_glossary_operator Thanks for your feedback :) Hans Hans http://blog.hansmelis.be
Alex Jones	Monday 04 August 2003 6:49:40 am Hans and Paul, thank you for fixing this! The operator will be used throughout our site and will prove very helpful to our users. :) When our site is visible to the public, I will post it so you can see it in action! Alex Alex [ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ] <i>When in doubt, clear the cache.</i>
Alex Jones	Thursday 07 August 2003 8:36:16 am I finally got a chance to try this out and am still running into the same issue. I overwrote my previous version of the glossary operator and have not modified the new one as of yet. Here is an example of code generated by the new operator: Features a very stout 3" blade of AUS-8A high-<a href="/index.php/demo/content/view/full/634" title=" The mineral that transforms iron into steel. High-carbon steel results when .5 percent or more carbon is present. Only a bare .8+ can be absorbed by the iron, the balance in extremely high carbon steel goes to add <a href="/index.php/demo/content/view/full/682" title=" The measure of hardness for tool steels is most commonly done with a Rockwell tester, see Rockwell. The best hardness for one steel is not always the best for another. Generally, the best knives with steel blades should be hardened to the high 50s or low 60s on the Rockwell C <a href="/index.php/demo/content/view/full/786" title=" To knife people the word scale refers to the handle parts on each side of a full <a href="/index.php/demo/content/view/full/818" title=" That part of the blade that is either fastened between scales to make the handle or goes through a hole in the handle material. Also the part of a pocket knife blade that is between the handles. ">tang</a> hunting knife or the parts on the sides of a pocket knife or folder. ">scale</a>. An exception to general hardness rules is for Stelite, (not a steel) will be about 42 on C scale. ">hardness</a>. Expressed as C. ">carbon</a> stainless at 57-59 <a href="/index.php/demo/content/view/full/494" title="The C scale which is used for measuring the hardness of tool steels is measured by pressing a diamond a precisely measured distance into the steel. These measurements can be understood throughout the World.">Rc</a>., housed in a sturdy Zytel® handle with a rubber inlay on one side, in black only. Measures 4-7/8" closed, including the attachment device. Weighs 2.7 oz. Which should actually be: Features a very stout 3" blade of AUS-8A high-<a href="/index.php/demo/content/view/full/818" title="definition of carbon">carbon</a> stainless at 57-59 <a href="/index.php/demo/content/view/full/494" title="The C scale which is used for measuring the hardness of tool steels is measured by pressing a diamond a precisely measured distance into the steel. These measurements can be understood throughout the World.">Rc</a>., housed in a sturdy Zytel® handle with a rubber inlay on one side, in black only. Measures 4-7/8" closed, including the attachment device. Weighs 2.7 oz. The operator still appears to recursively define words found in the title of the anchor tag. Here is a tree showing how it is recursively adding anchor tags to words within the definition above: Carbon > Hardness >> Scale >>> Tang As I mentioned, I haven't changed any code in the operator, so I'm stuck. Is there anything I can do to solve this? Thanks! Alex Alex [ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ] <i>When in doubt, clear the cache.</i>
Hans Melis	Friday 08 August 2003 3:10:13 am Hi Alex, I just tried recreating the problem you're experiencing, but all I get is the correct version. I took your text and explanations and made the glossary accordingly, but it doesn't break the explanation of "carbon". Are you sure you downloaded and installed the updated operator? Hans http://blog.hansmelis.be
Alex Jones	Friday 08 August 2003 6:40:14 am Hans, thanks for replying so quickly. :) I'm positive that I downloaded the new one and even double-checked the modification date of the documents within the zip file to ensure it was newer. According to Winzip the only file that was changed is ezglossaryoperator.php the date of which is August 4, 2003. I'll try another clean install today to ensure I didn't mess something up along the way though. Alex Alex [ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ] <i>When in doubt, clear the cache.</i>