Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Offline
Re: Glossary architecture
etc wrote #298509:
I don’t say it’s better, but you can
Hi Oleg. I’m finally setting up the dev install for the glossary project and having another look at your tutorial. I have three questions before digging in.
First, you mention you used the ‘keywords’ field in your example. I will probably use a custom field labeled ‘synonyms’ as you also suggested. Do I need to change anything in the code examples you give if I’m not using the keywords field? It doesn’t appear to me that I do, but it might not be jumping out at me. I’m not familiar with this kind of syntax.
Second, I’m not sure what to do with (where to put) the second block of code that reorders the li items. Does that go in the page template where the index will be as a different header type? A form? Other?
Finally, your resulting list example does not separate terms by alphabetical sections, which I might want to do. I presume that’s possible by just repeating the list blocks somehow?
For example:
A
- Article (see Automatic links)
- Auto (see Automatic links)
- Automatic links
B
- Before/after 4.7 primer
C
- Calendar (see Year 4.7)
Etc.
Offline
Re: Glossary architecture
Destry wrote #323594:
Second, I’m not sure what to do with (where to put) the second block of code that reorders the
liitems. Does that go in the page template where the index will be as a different header type? A form? Other?
Looking at this closer, I guess it just goes where the ul would be in each case.
I’ll see if I can get anywhere with it tomorrow.
Offline
Re: Glossary architecture
Destry wrote #323594:
your resulting list example does not separate terms by alphabetical sections, which I might want to do.
If it was a native Txp solution, you would do that with <txp:if_different> comparing the first character of the term. If the xsl stylesheet can be teased into returning the first letter of the term, you may be able to do something similar there. I’m not an XSLT guru, unfortunately, but it does have a substring function.
That said, things have moved on a lot since 2016. I wonder if this can be realised in a core solution now with some <txp:article_custom> cleverness, iterating over the synonyms to build up the variable containing the entire list. Then maybe a custom shortcode to reorder the list and stuff it on the page wherever you need it: <txp::glossary />.
Not sure how easy that would be. I’d have to grok your setup a little better to figure out if we could do this more simply nowadays.
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
Fawk. Just wrote a detailed response. Session timed out. Browser didnt’ recover it. Nothing pisses me off more than having to rewrite detailed writing lost to web technology.
Is it really necessary to have such short session times? Or do I really have to use an external editor just to ensure forum post drafts are not lost?
/back to the editor/
Offline
Re: Glossary architecture
Have a look at this thread too which discusses another way of alphabetising a list of articles using more core tags.
TXP Builders – finely-crafted code, design and txp
Offline
Re: Glossary architecture
Destry wrote #323610:
Just wrote a detailed response. Session timed out… Is it really necessary to have such short session times?
Feel for you. I’ve stepped on that rake more than a few times. Now, before hitting Submit/Preview, I’ve actually taken to opening a fresh forum tab to see if I’m still logged in and, if not, logging in again then posting straight away. Annoying, but saves rage.
I think the session time’s something like 30-45 mins (a guess). Which is fine for short posts but if, like me, you start writing a post then go off and collect some more background info, get distracted by something shiny and come back to it, that time can easily be eaten.
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
Bloke wrote #323615:
I think the session time’s something like 30-45 mins (a guess).
Yeah, that should be enough. I’ll have to remember to bump it with a preview click more often, I guess. Or draft in Writer, the always-sensible move.
Anyway, the rewrite, not as eloquent as before…
In relation to the original example, I’m roughly aiming for the home/glossary/article structure (all other design elements aside), and the synonymous terms handling, which I’ll come back to.
In my case, if I use that arrangement, the homepage would be the glossary project’s home and about page combined, with some visual pizazz to help give a sense of the site’s subject at a glance. The homepage would be like a book’s front and back jacket covers in purpose/function.
On the other hand, I’m also tempted to put the glossary on the homepage directly, and either a brief overview para at top of that or, more sensibly, use an article for About content and link to it from the footer, for example. But for the moment, the previous structure is on the table.
Either way, I intend on using the /titles only URL pattern (i.e. glossary.domain.tld/term), so how I handle About info wouldn’t make much difference (glossary.domain.tld/about). And if I can get away with using only the ‘default’ section/page/style for the whole site, and whatever forms, of course, I’d be happy.
I like how that site handles the synonymous terms in relation to primary terms. That was the main reason I pointed the site out as a glossary model. And the glossary terms list(s) also have to be ascending alphabetically (not by date, etc). Oleg seems to have captured both behaviours perfectly in his solution, though I’ve not got any further yet than installing the plugin.
[ADDED] I also like the breadcrumbs, but I’m not sure that would work in a sections-less site. If I did use them, I’d want to add the letter sections between ‘Glossary’ and the active term (e.g. Home/Glossary/A/Arsehole). Though that might not be important if the search and tagging features are strong enough. The example glossary linked above has about 210 entries. I don’t think I’ll have that many, but it’s not clear yet.
I’m happy using Oleg’s solution if it’s still considered contemporary enough for the long term. He has captured the synonyms behaviour and alphabetization of terms perfectly, as far as I can tell. But I am also happy using a native solution if it’s not so logically complex that my brains melt and run out my arse. I can maybe manage Oleg’s solution if I don’t have to do more than plug in the snippets, but their constituent syntax is beyond my level or desire to grock.
(Btw, I’ve checked my PHP extensions, and the ‘DOM’ extension — an etc_query requirement — is not listed in the .ini file(s) at all. Don’t know if it’s there by default in PHP 7 or not, or how I would add it, if needed. Also, the XPath link in the plugin docs is broken. Looks like ‘Schools’ updated it to this)
(Remember, I’m happily moving further away from web tech, not closer. If I retain what little I know in the next five years, it’ll be a wonder.)
Textpattern has really blossomed as of late, and that’s fantastic for a new generation, and the die-hards. The logic built into tags now is profound and, in my opinion, often quite abstract. Too abstract for me, anyway. The increasing number of attributes and values, with their symbolism and nuanced magic, seems increasingly geared to developer wavelengths. Sure, you ‘don’t have to know PHP’, but it’s almost a new kind of tag-based programming language to learn, beyond simple HTML. Combined with ‘yield’ and ‘variable’, I’m often puzzled by what others find fundamental. Either that or you stick with the foundational tags that work by themselves and run simple sites. Nothing wrong with simple sites. I like simple sites, front and back.
Maybe my glossary project turns into a general glossary theme so others like me without a dev gene can manage without having to hire anyone. If we can decide which is the easier path in that respect, I might consider putting that dry- prefix to use, or more appropriately, the pub-.
Last edited by Destry (2020-06-08 11:52:53)
Offline
Re: Glossary architecture
Bloke wrote #323615:
I think the session time’s something like 30-45 mins (a guess).
It appears to be 2400 seconds (40 minutes), I’ve just tweaked it up to 3600 seconds (1 hour). If bad stuff happens, we can flip it back.
Offline
Re: Glossary architecture
gaekwad wrote #323626:
It appears to be 2400 seconds (40 minutes), I’ve just tweaked it up to 3600 seconds (1 hour).
Thank you. That’ll please long-formers like me.
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
Destry wrote #323622:
In relation to the original example
That’s a nice looking site. In terms of navigability, I’d be tempted to dim letters such as Q, Z and K in the alphabetic list at the top as they contain no terms. Maybe even make them unclickable, rather than click to find there are no terms. Oh, and I’d remove the duplicate ‘O’ :)
Either way, I intend on using the /titles only URL pattern
Remember, from 4.8.x you can use different permlink schemes for any section so you’re no longer limited to just one site-wide. If the glossary section suits /section/title or /breadcrumb/title better, use that. You can’t (yet) use custom schemes though, so inserting the letter as an extra navigable chunk is not possible.
[well, it is possible but you have to add any stuff after any content that Txp expects – this is what things like smd_access_keys does: adds crud after the URL for its own use. You can then use <txp:page_url> to get at these additional URL components and use them in your page.]
I can maybe manage Oleg’s solution if I don’t have to do more than plug in the snippets, but their constituent syntax is beyond my level or desire to grock…. The logic built into [Txp] tags now is profound and, in my opinion, often quite abstract. Too abstract for me, anyway.
The very programmery nature of Oleg’s solution and the need to understand XSLT a bit is the reason I suggested that core might be bale to help now in a more readily-understandable form.
Yes, things like <txp:evaluate> and the escape attribute need a bit of brain power but for this project I was more thinking of using shortcodes to output various chunks and plugging those into a regular <txp:article_custom> tags. Sorting the data in the second pass might be something that remains a plugin, as is iterating over comma-separated values. Txp can find and match on custom field lists but can’t (yet) iterate over them natively without a bit of trickery.
[side note: perhaps introduce container support such as the following. We’d need to factor in trimming internal values somehow, and how to grab the current value similar to the way <txp:yield> does for output_forms:
<txp:custom_field name="synonyms" separator=",">
do some stuff here with 'current' value set to the iterable content item
</txp:custom_field>]
With the ability to now filter by custom field directly from the URL you might even be able to turn this project on its head. Maybe write your articles and use a custom field to list the terms mentioned. Then use those to offer links back to the content from glossary items so it functions more like a combined glossary/index.
Dunno. That might be tricky, but it’s something I’d be keen to explore and see how far we can get with native tags. Building tables of contents is fairly easy. Building automated indexes is harder and would be something that would certainly set Txp apart if we could demonstrate a way of doing it!
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
Thank you, Bloke. I’m still working on getting some representative content together. Everything will probably be local for a while. But I will undoubtedly need to get back to this thread and some questions eventually.
Offline