Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Glossary architecture
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)
Offline
Re: Glossary architecture
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
Offline
Re: Glossary architecture
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!
Offline
Online
Offline
Re: Glossary architecture
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?
Offline
Re: Glossary architecture
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Glossary architecture
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.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Glossary architecture
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 theexclude='<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
.
TXP Builders – finely-crafted code, design and txp
Online
Re: Glossary architecture
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.
Offline
Re: Glossary architecture
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.
Offline
Re: Glossary architecture
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.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline