I was looking into using cascade filtering to combine tags for the Topics menu page.

Using cascades on the front end would be more accessible to most people. Unfortunately, the cascades make tag/topic counts very challenging. A single url may be represented by several tags that all combine to form one tag. Working the cascade backwards turns out to be problematic. I could only do it using wikify, which doesn't work on the main topics page because of performance issues.

A version of this approach would be to use the cascade filters in conjunction with a data dictionary, so that the reverse lookup process would not be so intensive. This would require keeping the cascade and the data dictionary in synch. Possibly by generating the dictionary from the cascade.

A completely different approach would be to have, perhaps, a JSON file of conversions that is used on the backend when the wikis are downloaded and analyzed. This approach would produce a clean slate of url tiddlers that would be already encoded. This would make display counts straightforward. In fact, nothing on the front end would have to change. But since it's done in javascript, it would be a little less accessible to the general public. I say "a little less", because there doesn't seem to be that much engagement in the first place.

So I'm looking for feedback which approach, if any, would be preferable. Thanks!

Hi,

since I don't have that much time to follow discussions on old Google group or discord, from time to time I check links.tiddlywiki.com to see which new plugins/macros have been recently developed.

It would be nice to have a RSS/Atom feed URL so I can easily add it to my feed aggregator.
Thanks in advance.

Kind regards,
Victor

We should probably entirely disable them.

Part of the problem is that right now the mapping of tiddler links to static file paths is done rather manually, I hope to soon introduce a mechanism that will automate things so that links within the aggregated wiki will work.

We didn't originally have the "original-title" option. So it's not part of the search. But maybe it should be?

What prompted this was looking for "TW Magick", which by chance did not have the term "TW Magick" in the actual searchable text (I'm fixing that in my instance) though it was in the original title.

Go to the search box. Type "plug". Or type "Plug". Either way you will only see 5 topics, and they are all lowercase. Click on "plugin" and it will take you to topic "plugin (25)", which represents only the lowercase topic name -- there are 53 other items under topic "Plugin".

Type "plug" into the search box. Now click on "plugin library". It takes you to a 404 page.

In order to be able to post links from any device as fast as possible, I'd like to submit links via Twitter.

A contributor could register the URL of a twitter account instead of a TIddlyWiki. We could use a convention such as the hashtag #tiddlywikilinks to indicate links, with other hashtags being applied to the link, and the text left over after removing the link being the body text.

I think this kind of thing is straightforward with the Twitter API, but we may want to cache previously read tweets in the repo to keep API usage low.

To facilitate the process for contributors adding their site to TiddlyWikLinks, we should consider a form that generates a PR to add the given site to sites.json

I allowed myself to get distracted and spend some time looking at this yesterday with a Google form that writes to a Google Sheet. It is fairly straight forward with one sticky area: how to remember between Github workflow runs which rows in the Google sheet are new since the previous run.

I tested a few different alternative Github workflows:

Option 1 (with the problem of identifying new rows unsolved)

• make the Google sheet public
• in a cron based workflow run in Github actions, fetch the JSON data from the sheet over HTTP
• run a nodejs based script to update sites.json
• Use a workflow action to create a PR

The problem here is how to remember between runs which rows have already been processed without checking temporary files into the repo.

Option 2

• A script in Google Sheets to mirror new rows to a separate worksheet, so that we can modify it and have the original as a log.
• Use a Github action with read & write access to the Google sheet to remove rows already processed.
  • requires a Google service account that has access to the sheet (and nothing else) with the relevant secrets stored in Github repository settings as secrets.
• run a nodejs script to update sites.json
• Use a workflow action to create a PR

Works but a few too many moving parts, could be refined.

Option 3

• Use a script in Google sheets which triggers on new form submissions and does a POST request to trigger a Github workflow using repository_dispatch event.
  • Requires that you create a Github personal access token with repo scope (read and write) and provide that to the script in Sheets.
• The POST request provides the new form submission data and it is processed using a nodejs script to create a new PR.

This is the cleanest in terms of flow but I am uncomfortable saving that PAT in the Google script with regards to security.

Questions --

Is there a way to fast-start the server without checking for new items every time?

The basic setup won't let you save new tiddlers. I tried adding the tiddlyweb and filesystem plugins, but that resulted in non-stop errors. Is there a way to add new tiddlers?

Thanks!

https://links.tiddlywiki.com/ is currently presented as an old school static site: clicking on a link navigates to a new URL, retrieving an entirely separate HTML page. The pages are all generated in advance, taking about 80MB. The same data is also presented as a 3.8MB TiddlyWiki HTML file.

It was built this way in order to be friendly for search engines but it has been demanding from a development perspective because it is significantly more complex than any other static TW site build I've built. For example, search has had to be redeveloped as a little custom JS app.

There are also some significant recent bugs (#24, #25, #26) that are all due to shortcomings with the current static site rendering framework.

At this point, I'd rather focus effort on the core link aggregation functionality than on fixing and extending the static site generation framework.

So, I propose to remove the static renderings from links.tiddlywiki.com, and build an equivalent user interface in TiddlyWiki.

see: https://github.com/TiddlyWikiLinks/TiddlyWikiLinks/blame/main/bin/clean.sh#L5

Cloning this repo downloads about 210 MByte - IMO that shouldn't be the case for a little bit of links.
I did expect it to be 1 or 2 MB ...

Do you know, where this horrendous size comes from?

Petty gripe that should be equally easy to fix: the number of links for a contributor isn't singularized when there is only one.

Also in the details view:

The links pastel green palette seems to be somewhat unpopular and may be inhibiting uptake. It gets mentioned in the forum regularly.

I would suggest "Blue", or my favorite "Cupertino Dark" (which I use all the time). Dark themes are very popular right now. Or we could make requests (contest?) for a custom palette.

extractTiddlersFromWikiFile() needs to be updated to accomodate the new JSON store area.

Go to topics. Currently you will see "Plugin (53)" and "plugin (25)". Click on the uppercase version. It will take you to the "plugin (25)" results. Effectively, 53 plugins are unavailable through the interface.

I'm already using port 8080. The npm start command used 8081. But the new npm edit uses port 8080 and throws an upcaptured error. Could this be tweaked to work like the start command? Thanks!