Use nodes for glossary entries instead of taxonomy

The glossary has the ability to attach nodes to taxonomy items (even more nodes to one term). So you get the best of the two worlds... You still need to have taxonomy rights though, but you get the other advantages of having nodes (history, owner, commentable explanations, longer descriptions).

Found one pssible Bug:

Changed:
$replace = l(t(variable_get("glossary_superscript", "i")), "glossary#$term->tid", array ("class" => "glossary_indicator", "title" => str_replace("\\", "\\\\", htmlentities($term->name. ": ". $term->description))));
to:
$replace = l(t(variable_get("glossary_superscript", "i")), "glossary#$term->tid", array ("class" => "glossary_indicator", "title" => str_replace("\\", "\\\\", htmlentities($term->name. ": ". utf8_decode ( $term->description ) ))));

I had the need to do this for work. We needed multiple people to be able to create terms in the glossary as well as wanted to use the submission queue to approve new terms. Attached is the patch.

This patch also does the following:
* Clears out dead code
* Fixes a bug where new terms where not clearing filter.modules filter caches
* Allows setting of glossary parameters per input format
* Prevents adding glossary term links back to themselves if patch http://drupal.org/node/11225 is applied
* Removed style elements from the module itself, these should reside in the themes style sheet not hard coded in the module

doh.. that's a patch ;)

As far as being able to have a tree structure of nodes like you do with Taxonomy - have you considered collaborating with the author of the relativity module? Seems that the glossary and it could work hand in hand.

A definite +1

The Tagnode module, if used in conjunction with the Glossary module can automatically create a glossary item when a new node (of a specified type) is created. The only problem is that it does not create a Description for the Term.
Cheers,
Chris

The Glossary2 (G2) project is already using node-based storage. For more info see - http://drupal.org/node/41641

I've just posted the link - it's not my project. Please follow-up with the project developer.

A unified glossary with node-based storage would certainly be better than having 2 separate modules.

Moshe,

We chatted about glossary features vs my own needs a bit in late december, if you'll remember. I wrote G2 after that discussion because due to the specific needs I had for my site it seemed simpler to write it from scratch than to twist glossary.module to my needs, which I had initially thought of doing.

If you look at the project page and wiki, you'll notice this module is explicitly described as *not* replacing glossary.module because they serve different types of needs. There's even a comparison chart (currently on the wiki) to help users choose one or the other depending on their needs. The design assumptions are quite different: nodes vs terms, single vs multiples glossaries, high vs low volume, manual vs automatic links.

I called it "G2 glossary" because it *is* a glossary-managing module so it wouldn't make sense to call it otherwise, and use G2 instead of the full "glossary" because it limits confusion.

This does not mean they could not be merged at some point or that code from one of the modules couldn't be used in the other, but given the difference in design assumptions, I'm not sure this would be useful.

Implementing node-based storage for the glossary module may no longer be necessary. The glossary module is now fully compatible with the category module, when using the bundled taxonomy wrapper module to provide a compatibility layer. Since categories are nodes (which have a body as well as a description), if you create glossary terms using the category module, your glossary terms are also nodes.

Doing it this way brings you all of the benefits (as outlined by moshe), and none of the risks (as well as losing hierarchy functionality, there is also the 'related terms' stuff to consider). What's more, you don't have to change a single line of code in the current glossary module.

I wanted to include the main glossary page in a "book" which would mean that it would have to be a node correct? Would using relativity or category service my needs? I'd like to know where this stands.

I am using the latest Categoris module, the taxonomomy wrapper. and have installed Glosaary. What are the simple steps to start developing a Glossary, with a Glossary Menu item that shows glossary terms grouped alphabetically, and with glossary terms identified wherever used in text. Do I need to create a Glossary container? a Glossary category? Categories for A, B, C, ...? How do I trigger Glossary to begin identifying glosaary terms?

I'm sure this will be very simply for someone to explain. I have searched for two days for the answer. Thank you very much for your time.

Hi betsyjanuary,

To set up glossaries with category, you install glossary, category, and the taxonomy wrapper, and you then follow the instructions in the glossary module's README.txt file (i.e. create a 'glossary' container, enable the 'glossary' filter in your input formats, associate the glossary container with your filters).

Your support request does not belong in this thread. Please do not hijack this issue again. If you have further queries, please post them as support requests in the category module's issue queue.

Is this still on the TODO list?
Shouldn't we ask "ccourtne" to prepare a new patch and get it committed?
Or, have you all migrated to G2 and do not care about this module anymore?

Hey Jaza,

> Implementing node-based storage for the glossary module may no longer be necessary. The glossary module is now fully compatible with the category module, when using the bundled taxonomy wrapper module to provide a compatibility layer. Since categories are nodes (which have a body as well as a description), if you create glossary terms using the category module, your glossary terms are also nodes.

Does that mean we can delegate access to non taxonomy administrator, so they can add and manage their own terms? I am thinking no. Seems this module has a lot more controversy then I originally thought, with G2 and all.

I am going to evaluate this patch for potentially usage in my v5.1 drupal implementation. It might solve a lot of the current needs I have.

About the suggestion of using category as nodes for glossary, my only comment is that category is a dangerous module that can screw the whole content of your existing web. I installed it once, and will do never again.

As for the G2 glossary issue, it is indeed incoherent to offer the same thing in two different places. Instead of dividing efforts, joining efforts is much more intelligent. I can't believe glossary couldn't be tweaked insted or rewritten from scratch for G2.

Farreres,

It seems that you did not consider the issue in deep enough detail. G2 was created after discussing my needs with Moshe, and the design goals are actually very different, with resulting different compromises based on these different goals.

I suggest you take a look at the module comparison chart on http://wiki.audean.com/g2/choosing You'll notice that, apart from the fact that both manage a glossary, modules have very little in common.

Well, for my late 2 cents worth. It is not necessary to switch to a node base to delegate taxonomy maintenance. I have a module that will do that (just waiting on the sponsor's okay) and I believe I saw another one that intimated it would already do that.

Other than that, I largely agree with the other reasons for doing it.

@fgm, I pretty much have to agree with Moshe on the naming. G2 does indeed sound like it is a replacement for this module, and I suspect most people would see that way. But I do see that you have tried to make it very clear on your project page. Perhaps Moshe could reference yours for "high-volume" glossaries.

I agree that glossary entries as nodes makes more sense for a variety of reasons. Perhaps the most important is the flexibility afforded when displaying the glossary term. By making the term a node, you can access the term via views, you can theme the node and you can inject views into the node itself -- all of this makes for a more powerful way do display information.

I've been working on this for about a week now and I believe there's a way to do this using the NAT module (http://drupal.org/project/nat) and a small patch to the glossary module (which I haven't written, cause I don't know how to write a patch yet.)

For those who don't know, "the NAT module is a helper module used to maintain node-term relationships, i.e. when a node is created, an equivalent taxonomy term is automatically created in any associated vocabularies. This module is a simple but effective way to create node-node relationships via the taxonomy module."

So if you create a glossary vocabulary, and create a CCK node type (call if glossary if you want) and use NAT to "connect" the two, whenever you create a new glossary node, it will automatically create the new vocab term. NAT even let's you convert the body of the node into the description of the term automatically. Neat, right?

Now the other part of the puzzle is the fact that by default, the glossary module (input filter) links terms to their associated vocabulary term. For a true node based glossary, we need the hyperlinked term to link to it's node id!

Again, NAT comes to the rescue. Remember that for every glossary node created, there is a corresponding glossary term. This relation is held in the NAT table. So to get the node associated with the term, you could first add the following to your glossary.module :

// converts a tid to the nid via the NAT module table
function nat_convert($tid) {
  $result = db_query('SELECT nid FROM {nat} WHERE tid = %d', $tid);
  while ($row = db_fetch_object($result)) {
    $nid = $row->nid;
  }     
  return $nid;
}

Then, in _glossary_filter_process (i didn't want to paste the whole function here)

      if ($term->nodes > 0) {
       // $linkto = "taxonomy/term/$term->tid";
        $linkto = "node/". nat_convert($term->tid);
        $hash = NULL;
      }
      elseif (count($vids) > 1) {
        //$linkto = 'glossary/'. $term->vid;
        $linkto = "node/". nat_convert($term->tid);
        $hash = NULL;
        // Old Method (maybe should add a setting)?
        //$hash = 'term'. $term->tid;
      }
      else {
        //$linkto = 'glossary/term/'. $term->tid;
        $linkto = "node/". nat_convert($term->tid);
        $hash = NULL;
        // Old Method (maybe should add a setting)?
        /*$linkto = 'glossary';
        $hash = 'term'. $term->tid;*/
      }

I'm not advocating hacking your glossary module. I'm merely suggsting that with two simple(?) administrative options ($linkto path root and node vs. taxonomy based) the glossary module could quite easily be converted or convertible (best of both worlds) between node and taxonomy based schemes.

ps. I have this working on my localhost -- I'll try to get a public demo going if there is interest.

Hmm, I wonder if this is why Moshe sponsored that module? I'll definitely take a look at this.

I wonder how different the nat table is from the term-node table.

How many entries do epxect to return from the nat table in the nat_convert function (which should be named glossary_nat_convert)? The way you have it written, $nid will only be the last one returned. If you only expect one back, then you should at least use "LIMIT 1" to optimize the query, and probably the db_result function as well.

"elseif (count($vids)" is gone now.

Are you sure that the "_glossary_filter_process" code needs to be changed? If a node has that term attached to it, then it will already be linked to.

As for patches, you don't actually write one. You make a base copy of the code, modify it, and then run the "diff" command (or program) against it. That will create the patch file, which the developer (e.g. me) can then apply to her copy of the code. Effectively, a patch is merely a communication tool. There are several posts here on DO that explain how to get and use the patching programs.

Hi Nancy,

Hmm, I wonder if this is why Moshe sponsored that module? I'll definitely take a look at this.

I was thinking the same thing...

I wonder how different the nat table is from the term-node table.

the nat table has one more column for vid, so actually they are quite similar. The way I understand it however, they are different in that the term-node table contains relations manually set by the author -- ie. "I think I'll tag this blog post with this term" where as the nat table contains the automatically set relation. By that token, (I think) the node isn't actually tagged with any term in the drupal sense.

How many entries do epxect to return from the nat table in the nat_convert function (which should be named glossary_nat_convert)? The way you have it written, $nid will only be the last one returned. If you only expect one back, then you should at least use "LIMIT 1" to optimize the query, and probably the db_result function as well.

Good question. I was thinking only one, in the sense that you should only have a one-one glossary term-glossary node relationship. (However, there's no way, except manually, to ensure that glossary nodes with the same title don't get submitted.) I'll take note of your recommendation. I believe there are other areas that need to be examined. One that I can think of is whether this scenario will still hold up if the vocab is made/converted into a hierarchical vocab.

Are you sure that the "_glossary_filter_process" code needs to be changed? If a node has that term attached to it, then it will already be linked to.

I'm pretty sure -- as I was saying, when you create a node/term relationship with NAT, the node isn't actually tagged with the term.

As for patches, you don't actually write one. You make a base copy of the code, modify it, and then run the "diff" command (or program) against it. That will create the patch file, which the developer (e.g. me) can then apply to her copy of the code. Effectively, a patch is merely a communication tool. There are several posts here on DO that explain how to get and use the patching programs.

I'm gonna look into this...

Thanks!
Mike

However, there's no way, except manually, to ensure that glossary nodes with the same title don't get submitted.

Actually, take a look at (I think) node-family. If my memory serves me (which it often does not), this module can be used to restrict the number of nodes.

Hey, moving from taxonomy to nodes would make it possible that glossary terms inside glossary entries were also marked, making glossary a network itself. Good move!

Yes, there are a number of pluses to making the change. However, we also have to consider that some people like it the way it is and don't want a lot more nodes; a migration plan; other things that I can't think of right now.

Also, please check the issue on a settings page. I have several ideas for improvements in addition to this one, and I really don't like the way settings are done right now. As a matter of fact the code for the "user disable" feature is already committed, it just doesn't have a setting to turn it on.

Well, it's a marvelous module as it is now. If you are improving it right now, do it. In any case, I prefer (it looks you too) first to offer a solid implementation and then thing about a change to better, never to worse.

I was only saying that nodes would have benefits.

By the way, would it be possible that glossary worked the same way unless the other modules (NAT and node-family) were included and the user requested nodes to be created? That would help that users could choose between taxonomy or nodes.

When I get to looking at this, I hope to make NAT optional. That would ease the migration and allow people to keep it the way it is if they want to (I'm undecided on which way I'd prefer it.)

And, yes, I am trying to improve it now. I know I've done more than 18 commits so far.

I've been rereading this thread to start laying out a battle plan. It's interesting that Moshe initiated this discussion but now thinks it's not a great idea.

• do not have to give admin taxonomy permission to create glossary entries - There is already one module that appears to give this ability, and I have one that I am about to submit that definitely can accomplish this.
• glossary entries can be queued - I'm not sure what this means. Is it the ability to submit a definition that is not published so that it can be reviewed? That would be an interesting concept.
• glossary entries have an 'owner'. we actually have definition debates in my company - The module I'm getting ready partially gives this, but I'm not sure all that this means.
• glossary entries have a revision history - If I understand some of the changes going in, I believe D6 has some of this.

@Farreres - with the new support for the Hovertips module, you get another level deep in "glossarizing" the glossary terms.

Having said all that, and with the revelation above that the Category module provides another way of doing this, how much interest remains in doing this?

Nancy,

> there is already one module that appears to give this ability, and I have one that I am about to submit that definitely can accomplish this.

Could you please post a patch so we can review it in the mean time?

Revisions and queuing is already handled with modules like Revision Moderation and Workflow (or Workflow NGm, havent used it). Wouldn't this gives us more reasons to move this type of content to a standard node based format? I realize there are gains from having it as a term with filtering (all of which is a bit foggy to me at the moment). But seems like the more we want a glossary term to act more like content we are rewriting or adding other modules to make it conform. At a certain point we need to start weighing the options the other way.

Have you evaluated further or have other thoughts at this point? I can probable make due by just leaving the responsibility to add terms to an admin, but that isn't the best solution long term. As far as revisions, etc, I think that might be a bit much, but I could see others needing it. But I am a reasonable person. I can make local modifications and track them myself, but if other are interested in this direction we should consider it.

If you want to alpha test my module, send me a contact and I will email it to you. I don't want to contribute it yet because I'm trying to work out a kink with Taxonomy Image. As is, it should work fairly well if you don't need taxonomy image support.

But seems like the more we want a glossary term to act more like content...

I see it that the glossary term is not "content" but a modifier of content.

I am certainly not opposed to trying this concept, but my time is limited. And I haven't even started doing any version 6 stuff yet. I would really prefer it being an option if that is possible.

Nancy,

While the two modules are certainly not merging any time soon, maybe there are some parts that could be made common between the two : it would probably increase our respective efficiency and/or facilitate use by standardizing what the modules may have in common. I'm thinking especially of the filter part, which could be improved in both cases.

What do you thiknk of it ?

I'm certainly not opposed to that either. Can you handle turning the filter off inside a <code> block? That one's driving me crazy.

Back burner for now.

Has anyone done any experimenting on this? Patches?

Have we revisited g2 yet?

http://drupal.org/project/g2

As has often been told in this issue, the two modules do not really target the same needs. Nancy and I have yet to make any progress on finding something that could be put in common between the two modules.

In addition, note that an official release of G2 for D5 will actually be released in a few weeks, significantly rewritten, and the official D6 version to follow will be based on this rewrite.

Yes, I'm sorry, Frederic, I've been swamped with maintaining and upgrading my modules while my mother was sick and then died, so the last few months have been super hectic.

I'm marking this as "won't fix". Moshe agrees with me. I do occasionally go back and look at things with this status to see if I change my mind. But for now, let's just get it out of the queue.