--- pagetitle: "TODO" author: onefang feedatom: https://sledjhamr.org/cgit/notYetAnotherWiki/atom history: https://sledjhamr.org/cgit/notYetAnotherWiki/log/TODO.md sourcecode: https://sledjhamr.org/cgit/notYetAnotherWiki/ --- ## Do these Footer is still wrong. Clean up the favicon and logo stuff. Have one in a root directory that the pages in sub directories point to, instead of the current symlinks. Apply the same solution to default.template. Clean up docs and bump to version 0.0. RELEASE!!!????!!!!???? See the conversion therapy section below. Add an Edit button that opens up the page in what ever wiki system it came from, for editing. Check the timestamps on the files, only update if source is newer than destination. Meh, it's already 600 times faster than the pandoc version. - One quirk to watch for is if a URL path changes, the docs that have that URL need to be redone. - pandoc is a lot slower though, so do this for sure when dealing with that. Add atom feed for single page. Alas cgit only seems to have ATOM feed on the whole repo, not individual files. ### conversion therapy For importing from other systems, have a script that runs on that system and creates a nYAWsite.lua structure, same as sites[], which nYAW then downloads so it knows what web pages to convert. Both ends need to know what they are converting - - Other system end needs to know how to construct a nYAWsite.lua table from whatever format it's content is in. - Both system ends may need to cooperate to get nYAWsite.lua into a place nYAW can download. Or if running on the same system, drop it into the other system root. - nYAW system end needs to know how to convert and clean up the pages. - nYAWsite.lua should include the name of the convert and clean up script that will be part of notYetAnotherWiki. NOTE - security risks here - - Automatically running Lua scripts from some other system. - Letting the other system tell us what script to run. Alternative is to figure out what the nYAWsite.lua is by poking at the other system. Any given other system might not give that info easy. #### conversion ROADMAP put my table dumping stuff in it's own Lua library use it to write the Foswiki and PmWiki install -> nYAWsite.lua scanners, which gets created in their respective directories while notYetAnotherWiki is scanning for .md files to convert to HTML, if it comes across a nYAWsite.lua file in a directory, stop scanning for that directory and use that instead. - this is where it needs to know where to get the web pages to convert, and how to convert - - which is stored in the nYAWsite.lua file - - so we can start with a bare minimum one that just tells us the format, to be replaced by the newly generated one, which needs the format in it as well for next time - pandoc URL | cleanupscript > page.md - page.md -> page.HTML as usual figure out the nYAWsite.lua file downloading step later ## Try out htmx pandoc replacements - cmark-gfm cgit has Lua ## User system levels - - banned - reader - member - moderator - editor - admin - shell - root Banned people can't do squat, except maybe pester an admin once to start the unbanning process. When first registered, accounts are set to reader level. Initial verification by email. Readers can only edit their own profile. If an existing member vouches for a reader, they get promoted to member. Some invite system would count is vouching, but need to get secure invite credentials to someone outside the system. Members can chat, and create their own sandboxes that might get promoted by editors / moderators to proper content. Moderators can move things around, including to a spam/trash place. They can ban readers and members. Editors can edit any content, and move things around. They can't edit the site elements itself. So they can edit the site menu and structure of the content, but not the footer? Certainly can't edit any admin stuff. Admins are set by other admins. Admins can promote / demote people and content at any time. Admins can edit anything, including web editing of config files, and managing of modules. shell level means you have direct access to the files that are the web site, including configuration and modules. Likely this is the person that set the system up in the first place. Admin should have access to everything that shell level has, but there's always things need tweaking at some lower level. Built in file browser might do the trick. Would be useful for content creators to to organise the content. Naturally should obey the permisisons. root level is whoever controls the server things are running on. They can do anything at all.