Glossary architecture

Destry · 2016-04-05 11:42:46

Attention: If you’re just joining this thread for the first time, you might save yourself some reading and jump to here, which gives a better breakdown of things as of 2020 (and for a different project than originally talked about), or here as of 2022, though the goal is still largely the same.

———————————-

We’re working on a glossary project at CSF. Each term in the glossary will be its own Txp article. However, we need a slightly more robust index for navigation purposes than just making lists of the article titles. That’s the basic idea, but it’s not going to cut it by itself. Some main entry terms have synonymous terms (as I’ve talked about here) that won’t have their own articles, but need to be used in the index somehow as user redirection cues to the associated main definitions.

There’s a glossary for the O’Reilly book, Web Content Management, which demonstrates perfectly what we need to do in our own index.

Just like that index shows, our index will be sectioned by alphabetic regions: A, B, C, D, etc. Then article lists within each region using glossary categories for each alphabetic value. Or at least that’s the initial assumption.

But where the stumper comes in at the moment is how to handle the list items that are not direct articles in the glossary.

For example look at the first 5 list items in the “A” section for the glossary index above, which are:

A/B Testing
Access Control Entry (see Permission)
Access Control List
ACL (see Access Control List)
Action (see Application Programming Interface)

If we think about that as a Txp-powered index, using article titles as index lists, the first and third items make sense, but the others are seemingly static list items with actual term references in them, though we’d want them to be generated dynamically. You see what I’m getting at?

One idea I’ve been stewing over is to use custom fields in the actual definition articles to list any associated synonymous terms (e.g., in the list above, the Access Control List article would have a custom field for “ACL”), then that piece alone would output as:

<txp:if_custom_field name="syn1">
<li><txp:custom_field name="syn1" /> (see <a href="???"><txp:title /></a>)</li>
<txp:else />
</txp:if_custom_field>

But I don’t see how to merge the two kinds of output (article list items and custom fields in a given article) in an alphabetic way across all other items in the index.

Nor would I know how many custom fields I would need in the life of this project, nor if I would need deeply-nested conditional statements in those cases where many synonymous terms could exist.

How can Txp model that same kind of output dynamically? I’m coming up blank.

And we really want this to be as hack-free as possible; i.e.., no blank articles for the sake of making lists, if it can be avoided. But maybe not?

Last edited by Destry (2022-06-04 16:42:19)

sacripant · 2016-04-05 12:40:36

I would like that

each glossary term is an article
each synonymous term is an article too

For a glossary term, you enter Title and body
For a synonymous term, you enter Title and a custom field synonym_of with related article ID

For your list, you simply use

<txp:if_custom_field name="synonym_of">
    <li><txp:title /> (see <txp:article_custom id='<txp:custom_field name="synonym_of">' /> (see <txp:permlink><txp:title /></txp:permlink></txp:article_custom>)</li>
<txp:else />
    <txp:permlink><txp:title /></txp:permlink>
</txp:if_custom_field>

and if you want to exclude synonymous to next/prev links, you can classify them in another section : glossary-syn for example.

My 2 cents

Destry · 2016-04-05 12:57:16

I was hoping to not have to use dud articles for nothing more than list items, but I guess that’s the only way to get it done. Maybe that’s why I couldn’t recognize the solution before. What you propose is straight forward, for sure. That could work. Thanks!

etc · 2016-04-05 17:08:03

Destry wrote #298500:

One idea I’ve been stewing over is to use custom fields in the actual definition articles to list any associated synonymous terms

I don’t say it’s better, but you can

Destry · 2016-04-05 17:23:09

etc wrote #298509:

I don’t say it’s better, but you can

Wow! +1

Fast work, too.

Wait, is it called etc_query or etc_bloatware? ;)

michaelkpate · 2016-04-06 13:59:15

It occurs to me that it would be nice to have the ability to turn off individual article creation for a section – is that a crazy idea to suggest?

Bloke · 2016-04-06 15:49:35

michaelkpate wrote #298528:

It occurs to me that it would be nice to have the ability to turn off individual article creation for a section – is that a crazy idea to suggest?

How do you envision this from a workflow perspective? Just an empty entry at the top of the Section dropdown? And how would you retrieve such articles from the front side? <txp:article_custom section="" />? No idea is too crazy as long as we’re careful what it actually means and doesn’t create endless head scratching.

If ever I need an article for supplemental stuff, I’ll usually either:

a) create a Section that is hidden from the navigation and assign articles there, then use article_custom to draw them in where needed.

b) set them to a different status and pull them in using a plugin that allows non-live articles to be viewed.

But either method feels hackish and the first also means that <txp:section_list /> needs customising.

Using a Form is another method and is all well and good, but it lacks custom fields and may lock out content editors with lower privileges. So a way to define articles as content placeholders that aren’t in the regular flow does seem rather attractive.

colak · 2016-04-06 18:00:04

michaelkpate wrote #298528:

It occurs to me that it would be nice to have the ability to turn off individual article creation for a section – is that a crazy idea to suggest?

That is indeed a good idea. There are certain “section” pages in websites which do not need a list of articles. ‘About’ and ‘Contact’ come to mind as a general rule. Both you would want to appear in the search but at the same time you would not want the article urls but the sections to be clicked. (ie: domain.tld/about/)

The way I go about it is not very efficient. I create articles for them and then I use the if_article_id in the search to have the section link shown. For most users, this way is not very obvious and possibly counter-intuitive.

I understand that what I am saying is one thing, and how txp works is another. I cannot think of a method for example that you can have a ‘save as section’ button in the write tab as sections are currently having a dual role: that of a template and that of a url.

Many of us, would want that role to be separated eventually.

jakob · 2016-04-07 12:44:16

There are certain “section” pages in websites which do not need a list of articles.

There are, of course, several solutions that do already exist:

For entirely flat sites without any sub-levels, you can ignore sections altogether by setting Permanent Link Mode to /title in the settings.
For sections without sub-pages, you can make the article a sticky article and make the page-template respond accordingly. IIRC rah_sitemap allows you to ignore sticky articles when generating a sitemap, and you can exclude them from the search too via the searchsticky attribute.
For more complex sites I routinely use sections that don’t display as a menu item. I usually create a menu_exclude_sections variable with adi_variables or oui_prefs that contains a comma-separated list of the sections that should be skipped when generating the menu (and sitemap, if necessary) using the exclude='<txp:variable name="menu_exclude_sections" />' attribute in txp:section_list. That makes it easy to adapt later too. On a side note, I do something similar to "noindex,nofollow" certain sections.
And if for some reason there’s a complication, you can also resort to “smd_redirect” etc. to redirect /contact/contact to /contact.

michaelkpate · 2016-04-07 14:49:53

jakob wrote #298541:

There are, of course, several solutions that do already exist:

I could probably think of a couple more if really hard pressed. But I think the goal would be to do this in the most simple way. We already have an explainer How do I manage static pages?

How do you envision this from a workflow perspective?

I think there two use cases:

1) A Section where you want a page display like About where you don’t want or need individual articles beneath

2) A Section where you want to store something which you don’t want or need a section to appear at all

So that makes the wording tricky – and trickier still if you want them to default to Yes.

Section appears in site navigation? No Yes

Create individual article pages for articles in this section? No Yes

Something along those lines.

michaelkpate · 2016-04-07 14:50:28

jakob wrote #298541:

There are, of course, several solutions that do already exist:

I could probably think of a couple more if really hard pressed. But I think the goal would be to do this in the most simple way. We already have an explainer How do I manage static pages?

Bloke wrote #298530:

How do you envision this from a workflow perspective?

I think there are two use cases:

1) A Section where you want a page display like About where you don’t want or need individual articles beneath

2) A Section where you want to store something which you don’t want or need a section to appear at all

So that makes the wording tricky – and trickier still if you want them to default to Yes.

Section appears in site navigation? No Yes

Create individual article pages for articles in this section? No Yes

Something along those lines.

colak · 2016-04-07 16:10:10

Hi Julian and Michael, I am using a slightly different method for section pages with just one article which works for me. The method described in the FAQ is slightly incomplete as it does not explain how to avoid duplicate urls caused by search results.

Face value I like Michael’s method in your second point but the search results page will again produce the url of the individual article.

The reason I wrote my thoughts above was not so much that I did not have it worked out but because I think that the current methodologies are confusing for some new users who are yet to fully familiarise themselves with the tags.

I also want to apologise to Destry here as I did not mean to highjack his thread.

Textpattern CMS

Textpattern CMS support forum

#1 2016-04-05 11:42:46